- From: Adrien de Croy <adrien@qbik.com>
- Date: Mon, 09 Dec 2013 04:26:32 +0000
- To: "Roberto Peon" <grmocg@gmail.com>, "Mark Nottingham" <mnot@mnot.net>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
- Message-Id: <em6d0616cc-c14b-4624-90d6-c8eeed4a7a20@bodybag>
and DLP (data leakage protection) ------ Original Message ------ From: "Roberto Peon" <grmocg@gmail.com> To: "Mark Nottingham" <mnot@mnot.net> Cc: "HTTP Working Group" <ietf-http-wg@w3.org> Sent: 9/12/2013 5:17:26 p.m. Subject: Re: What will incentivize deployment of explicit proxies? > > > >On Sun, Dec 8, 2013 at 6:33 PM, Mark Nottingham <mnot@mnot.net> wrote: >>This thread makes me wonder if, rather than focusing on introducing a >>new kind of proxy to address the “enterprise/school/prison” (ESP) use >>case, we* should instead focus on fixing how trust roots are >>configured and managed in browsers / OSs. >> >>I say that because the requirement is already being met in the market; >>ESPs are able to inspect and modify traffic as it goes by on the wire >>by configuring a new trust root. It’s just that there are some nasty >>side effects brought about by that solution. >> >>We may be able to mitigate the bad effects of the current solution — >>e.g., by allowing the user to understand when their browser is using a >>trust root that was added later (AIUI some versions of Chrome already >>do this visually?), by giving the user more fine-grained control over >>what new certificates can be used for (to address the BYOD user), etc. >> >>If we can do that, we avoid the potential for new security choices in >>front of non-enterprise end users, ones that Will is justifiably >>nervous about (since anything that would allow a MITM warning to be >>clicked through is a VERY attractive attack vector). >> >>The one thing that wouldn’t be addressed by this approach is the >>potential for a “semi-trusted” proxy that can see inside encryption >>and yet promises e2e integrity. So, to me it seems like we should be >>focusing on the use cases that lead us there (rather than on that >>particular solution, yet). >> >>The one that’s been clearly identified is shared caching; is there >>another? > >malware/virus scanning > >-=R > >> >>Cheers, >> >> >>* for some value of “we". Not every problem needs to be hit with an >>HTTP-shaped hammer. >> >> >> >>On 7 Dec 2013, at 7:26 am, Werner Baumann >><werner.baumann@onlinehome.de> wrote: >> >> > Am Tue, 3 Dec 2013 10:53:26 -0800 >> > schrieb William Chan (陈智昌) <willchan@chromium.org>: >> > >> >> >> >> <pushback> >> >> I can probably expect to be tarred and feathered by my security >>team >> >> if I tell them we need to put up a UI asking the end user to make a >> >> decision about security :) >> >> </pushback> >> >> >> > Yes, that's the problem with your security team. Talking about >>security >> > for the end user, but the one party that has no saying is the end >>user. >> > >> > Talking as an end user: It is me, and only me, who decides whom to >> > trust in which respect and to what extend. It is not your security >>team. >> > >> > Sure, there are users who don't care. And there are lot of users who >> > can't make informed decisions, because all the necessary information >>is >> > hidden from them, many times by UI-experts who work based on the >>dogma >> > that users are stupid. >> > >> > Werner >> > >> >>-- >>Mark Nottingham http://www.mnot.net/ >> >> >> >> >
Received on Monday, 9 December 2013 04:26:48 UTC