Re: Re[6]: HTTP2 Expression of Interest

> Lets not get personal.

> It does not go without notice from me that the battle lines are drawn
> around which type of developer you are.  Browser developers and social
> content providers are all in the protect-the-users camp (encrypt
> everything).  Proxy vendors, which have an uncertain role in an encrypted
> future, are unilaterally against it.  This is a power struggle of products.
> Are the endpoints in charge?  Or is the 3rd party middleman in charge?

Disclaimer:
1. I am not a developer. I am an operator
2. I am tasked to secure a minimum the Internet accesses from my employer,
parters and subsidiaries networks
3. I don't care a bit about any of the actors that you mention. They all
collectively failed to provide a working and secure HTTP solution to us in
the past decade. I don't like how I have to manage a pile of workarounds
because browsers do not play nice with intermediaries and the protocol is
full of loopholes that let them do it so. I don't like how web site
developers think playing nice with their users tools (and I am part of
those tools) is being held in hostage and how they strive to bypass it. I
don't like the bugs in the proxy systems we bought.
4. there are enough users behind my systems one of the major airlines of
the continent blacklisted our public ips for a while because its
equipments decided we were performing a DOS against its ticketing system
(and buying air-plane tickets is not our core business, though like
everywhere our users do need to travel occasionally). Some traditional
out-of-band negotiation fixed this.
5. I am paid to help those users (WRT Internet accesses). I don't live by
feeding them spam, adds or reselling their private info to third parties
6. unlike a consumer ISP, I am supposed to provide always-on connectivity
and can not just issue reimbursements or promotional offers when capacity
planning mistakes (or other mistakes, including bored users misbehaviours)
result in broken Internet accesses

That being said:

1. I don't read the bank (or other correspondence) of my users

2. I'm not asked to read the bank (or other correspondence) of my users,
either by management or a police state (divulging it would take a legal
injunction I think, never had to deal with those)

3. When confidential (company or user) data leaks it's always at the
server endpoints, usually because those endpoints didn't care a bit about
user data confidentiality. The typical profile of such an endpoint is the
kind of social content providers you claim is in the protect-the-users
camp. Well they aren't. They're in the
pump-as-much-user-data-as-we-can-and-figure-how-to-monetize-it-later camp.
They don't like intermediaries because 1. they force them to invest
resources in something else than monetizing user data 2. we understand IT
and are not fooled by some pretty graphics and animations 3. we are on the
users' side, not theirs (I'm pretty sure *they* get served injunctions to
divulge user data and *they* are not shy to oblige police forces, who are
quite happy others do free data collection for them)

4. the alert is raised not by some evil spying on our part but by users
that belatedly realise they've been had by the glossy social (or other)
web site they wrongly assumed cared enough about them to secure their info
(and *that* unlike requests to spy on users, happens all year round)

5. Users ask operations to fix those leaks and remove the job-endangering
or social-life-endangering data those web sites published everywhere
(another common scenarii is unscrupulous contractors that attempt to
deliver business apps on the cheap by pushing processing of company data
in the 'cloud' via web services, without checking the other side can be
trusted)

6. Users ask operations to figure their computers got infected or spammed
and to fix it magically so they can get on with their life without
bothering with IT problems. They would do the same at home except no one
is mad enough to propose the kind of service we perform here at a price
they'd be willing to pay, and we can only perform it here thanks to a few
restrictions they don't like much

7. Users complain to us how come browsers still do not play well with
proxies after all those years. They actually believe the 'browsers care
about users' party line and think we're withholding some magic
browser-supported secure proxy login tech that was standardised a long
time ago. They rely on us to fill browser problem reports in their stead
(boring uninteresting IT work).

8. we can't perform the missions users ask of us without at minima seeing
the full http routing envelopes (to block dangerous web sites, to diagnose
problems, to alert users something on their computer accesses URL
associated with malware)

9. we can't perform the missions users ask of us if browsers refuse to
display the errors and messages we generate when a user stumbles on
something forbidden for its safety

10. we'd much prefer that any traffic that didn't present any
confidentiality issue was sent in clear so we could scan it for malware
and avoid to our users the unpleasantness of having their computer broken
by hostile, infected or breached web sites

11. we'd much prefer that any traffic that didn't present any
confidentiality issue was sent in clear so it could be cached and the user
experience improved by speedier browsing

12. we absolutely do *not* want to eavesdrop on bank accesses,
e-government forms, etc. We'd much prefer if such a traffic could be send
in encrypted payloads with in-clear routing metadata (there I differ a bit
from Willy, but I accept he has customers with stricter requirements than
ours)

(Sorry if I've been a bit long, but there has been enough misinformation
about intermediaries on this list)

Sincerely,

-- 
Nicolas Mailhot

Received on Wednesday, 18 July 2012 13:24:58 UTC