Re: Trusted proxy UI strawman

On Jun 18, 2014, at 2:30 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 18 June 2014 10:59, 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.
> 
> Yes, and I'd point out that the sort of things that Will refers to
> undermine the integrity of the user-site contract from the perspective
> of the site operator too.

IMO this topic points at a general need for the web to have finer grained encryption. Some content on a connection should be unreadable to intermediaries (perhaps using session based encryption based on out of channel negotiated keys). Other content simply needs to be signed (i.e. address the cache poisoning example Will mentions). The remaining presentation oriented content is freely cacheable without concern.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 18 June 2014 20:29:00 UTC