Re: What will incentivize deployment of explicit proxies?

OK, it sounds like people are retreating back from the
autoconfiguration+interstitial part of an explicit proxy proposal...except
maybe Nicholas? I'd love to hear more thoughts on
autoconfiguration+interstitial. It sounds like the prevailing sentiment is
it's unacceptable from a security UX perspective.

And now we're back to one-time setup operations. And in contrast to MITM
proxies, we see an opportunity to improve on the UX here, since installing
a root cert sucks. It seems like all browsers here rely on the system for
proxy configuration (Pat corrected me earlier on that), so this will tie us
to OS versions if we pursue this path. So if the OS vendors do not improve
the UX for installing MITM proxies, and instead focus energies on creating
a better explicit proxy configuration UX, then maybe that'll encourage
proxy operators to deploy more explicit proxies.

That's probably most of the proxy incentives there. Now it's interesting to
analyze the site operator incentives and the browser incentives. Site
operators will like explicit proxies, since they probably like having more
knowledge/power. Although there's the concern Stephen raised earlier about
banking site operators blocking access if an explicit "trusted" proxy is
present. This may impact the incentives of proxy operators to deploy
explicit proxies since they may not want site operators to be able to do
this. Thoughts on that?

And now there are the UAs, of which browsers are the most prominent. For
tools like curl, I don't think they'd have a problem with "trusted"
proxies, since the user presumably knows what he's doing? Maybe? For
browsers though, I expect there will be some hesitance to sacrifice e2e
security guarantees. Pat already mentioned this earlier about his dislike
of proxy termination of https:// requests. My teammates have similarly
voiced concerns here. Would we be willing to move forward with explicit
HTTPS proxies (UA<=>proxy TLS connection) without any "trusted" modes? Or
is that a key part of the proposals?

Cheers.


On Tue, Dec 3, 2013 at 3:07 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 3 December 2013 14:37, Yoav Nir <synp71@live.com> wrote:
> > It might be prudent to sacrifice expediency and block all access through
> > unrecognized proxies. Adding an explicit proxy would then have to be done
> > through a different UI, not a prompt that surprises a user who is trying
> to
> > do something.
>
> That's exactly what we've decided to do for screen sharing in WebRTC.
> It's got a similar sort of security profile: deceptively simple, but
> in practice there are subtleties users cannot be expected to evaluate.
>  In that context, Chrome - the only browser thus far to even have
> screen sharing support - have decided to move access to this into
> their extension framework.
>
> In order to enable screen sharing in Chrome, sites will need to use an
> extension that enables screen sharing for their site.  That hasn't
> been a universally popular decision, but I believe it to be a
> reasonable one given the nature of the problem.  It takes the decision
> off the critical path; it allows for revocation of rights when there
> are bad actors; etc...
>
> I'm not suggesting that this is the right decision here, but some
> greater awareness of the sorts of things people are doing when
> presented with similarly tough decisions can't hurt.
>