- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Wed, 18 Jul 2012 15:24:08 +0200
- To: "Mike Belshe" <mike@belshe.com>
- Cc: "Phillip Hallam-Baker" <hallam@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, "Rajeev Bector" <rbector@yahoo-inc.com>, "Martin Thomson" <martin.thomson@gmail.com>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Doug Beaver" <doug@fb.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> 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