Re: Trusted proxy UI strawman

> It's simply unreasonable to imagine that users -- real users out
> there, not "users" that really means operators, or content providers,
> or browser makers, or whatever -- will have the first idea what
> they're really giving up by accepting the proxy

But the situation is much worse today! Look at the dialog on the left: http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3

At least what I am proposing involves telling the user explicitly that the certificate enables the proxy to decrypt and alter traffic. And then provides an indication that it is active and a means to disable it. You don't see this as an improvement over the current MITM functionality supported in all the mainstream browsers?

Again, because pinning is not enforced if the trust anchor is a user installed CA, browser manufacturers are in fact choosing to support MITM proxies. But they are doing it without informing the user when it is being enabled and without any indication to the user when it's active.  I don't understand why anyone would defend the status quo on this.

Stephen doesn't like my metaphor, but I still see not improving this as burying our heads in the sand.

Thanks,

Peter


On Jun 18, 2014, at 1:59 PM, Barry Leiba <barryleiba@computer.org> wrote:

> The biggest problem with all of this is that you're making an
> unreasonable assumption at the start: that users can reasonably "opt
> out" of a <strike>privacy-invading</strike> "trusted" proxy.  (And,
> yes, we have to call it something else: the *user* certainly does not
> trust the proxy.)
> 
> 1. If such a thing were to be deployed, it would immediately be
> deployed in a way where the option to accept the proxy's intervention
> becomes a Hobson's choice: either you accept the proxy or you don't
> get to the web site you're trying to get to.  What do you think a user
> (see below) will do in that situation?
> 
> 2. It's simply unreasonable to imagine that users -- real users out
> there, not "users" that really means operators, or content providers,
> or browser makers, or whatever -- will have the first idea what
> they're really giving up by accepting the proxy, nor that they will
> have any understanding of what your UI markers (a "trusted proxy logo"
> or any such thing) mean.  They will not have a clue, and they will not
> be making an informed decision to put themselves in a position where,
> for example, this proxy that they don't really trust now has their
> username and password for their bank.
> 
> To believe otherwise is to ignore all research that's been done on this stuff.
> 
> Barry
> 
> On Mon, Jun 16, 2014 at 11:12 PM,  <bizzbyster@gmail.com> wrote:
>> Thinking about this some more. In particular this:
>> 
>> "It's probably worse. It's risky to take the approach of "better to show
>> something than nothing at all" if the something just trains users to ignore
>> your signals. Maybe later we will come up with a better heuristic, but we've
>> already trained people to ignore our UI warnings. A better way would perhaps
>> be something like suggested in
>> https://code.google.com/p/chromium/issues/detail?id=81623. But
>> unfortunately, due to the technical issue I referenced earlier with tainting
>> web resources that were MITM'd, we can't provide a meaningful UI indicator."
>> 
>> To avoid warning fatigue, maybe it's better to not do the UI warning via the
>> infobar but just show the user the trusted proxy logo to the left of the
>> lock. This is a constant reminder that the trusted proxy is seeing the
>> encrypted traffic without presenting as a warning to learn to be ignored.
>> 
>> Peter