W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [SRI] Escaping mixed-content blocking for video distribution

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 12 Nov 2014 13:03:56 -0800
Message-ID: <7578070337762888436@unknownmsgid>
To: Brad Hill <hillbrad@fb.com>
Cc: Adam Langley <agl@google.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Nov 12, 2014, at 12:27 PM, Brad Hill <hillbrad@fb.com> wrote:

>> ​I think that is about enabling the server to authenticate the request.
>> What I think we need is for the UA to verify that the request processed
>> by the server was the same as the one it sent, so that the ​
>> ​UA can be sure the traffic is not subject to attacks such as the Verizon
>> "perma-cookie".​
> It's too late at that point, isn't it? You've been identified to the
> server (and anyone in the middle).
> I believe the concerns blocking consensus are regarding the privacy, not
> the integrity, of requests, so not sure this is a productive track to head
> down.

It's true that the server learns that this user made a request. But
the response is going to be ignored and subsequent requests sent over
HTTPS. The UA might remember the scenarios when this happened and
default future requests to HTTPS too. The egregious thing about the
Verizon attack is that it permits tracking over time, even if the user
clears cookies and changes IP address. That possibility is undermined
if the identifier is only
sent once.

Remember that there is little we can really do at the client about
such network attacks on outgoing messages except make them more
difficult / less useful: the network could independently send messages
to the destination identifying the user associated with each TLS

I appreciate that this track is not a panacea, but neither is TLS. And
this approach could get a lot of sites into secure origins a lot
sooner, which is why I wonder if it is worth exploring despite the
rough edges ?

> -Brad
Received on Wednesday, 12 November 2014 21:04:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC