Re: Alt-Svc Privacy Concerns

Hi Phil,

> On 11 Apr 2016, at 2:19 AM, Phil Lello <phil@dunlop-lello.uk> wrote:
> 
> Hi Mark,
> 
> As Working Group Chair, could you respond to at least the BCP/policy statement request below? I fully appreciate your silence thus far is most likely because it's a weekend, and not because of a lack of interest.

It's actually because I was flying home from Buenos Aires, and dealing with jetlag (still ongoing).

I think the document you're looking for is <https://tools.ietf.org/html/rfc6973>. It's only Informational at the moment, but it is a product of the IAB, and in time it (or its successor) might become "more official," so it's the closest we have to a policy statement.

There's also an active discussion in the HRPC - <https://irtf.org/hrpc>, who are trying to figure out how to apply human rights considerations to protocol design.

Regarding Alt-Svc: people are comparing its privacy properties to cookies, but I think a more apt comparison would be DNS CNAMEs. The scenario you describe is already quite possible and easy to implement on the Internet, and Alt-Svc doesn't make it significantly easier or more successful, as far as we saw; it just shifts the redirection mechanism to another layer. 

Even in a world where both of these were not possible (and that's a stretch), colluding servers could share information about you in a back-end channel, using a variety of techniques to identify you as the user. 

That's not to dismiss the concerns you have; it's just that tracking on the Web is very difficult to prevent. The W3C TAG talks about this a bit here: <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>. 

One final thing - it's a pity that we're getting this feedback from you now, after the document is published. While we can, of course, revise it if need be, it's much more effective to have wide review before publication. Is there anything we could have done to get it earlier?

Cheers,



> On Sun, Apr 10, 2016 at 2:47 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> On 10/04/2016 9:06 PM, "Phil Lello" <phil@dunlop-lello.uk> wrote:
> >
> > On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> >>
> >>
> >> This sounds like a UX thing -- incognito sessions oughtn't reuse connections for different URI hostnames, even if the alt-svcs point to the same name. The consent, then, is not being incognito.
> >
> >
> > The primary justification I've read (both on IETF lists and industry forums) for TLS-by-default and retiring HTTP-over-TCP boils down to not trusting users to make security decisions for themselves. I don't see why an inconsistent philosophy should be taken here.
> >
> > Given the history and motivation for the 2011 EU Directive on cookies, I don't think that would be viewed as sufficient consent, and this could be interpreted as bypassing the intent of the law (but let's not engage in too much debate here, that's a job for the law makers).
> >
> 
> If service providers want to cover their butts, can't they add an "EU cookie law"-like banner that says, "We'll also do this thing, which could leak personal info this way. Click this X to opt out" and then not send the alt-svc stuff? The onus is on them not to stalk us, after all.
> 
> At least that way alt-svc is no worse than cookies, even if it's no better.
> 
> This requires documenting in an RFC. The service provider could be unaware of tracking if a rogue CDN operator was aggregating multiple sites via a common Host and is using Alt-Used to choose the content. I will try to find time to look into Firefox and Chromium source to see if/how they currently handle http Alt-Svc pointing to https on another hostname - a version of Alt-Svc is already in the wild, but may be limited to same-host (as in the output of curl -I https://www.youtube.com)
> >>
> >> Is it worth documenting this risk/advice somewhere, or is it already self-evident?
> >
> > Given previous IETF standards and subsequent abuses (going back at 1981's RFC 791 and Strict Source Routing), I don't think self-evident is good enough.
> >
> > IMHO, the UX aspects need documenting, for the following reasons:
> >
> >  - It is presumably intended that the server certificate for the Alt-Svc is matched on Host and not Alt-Svc
> >  - It is reasonable to assume that with Alt-Svc, a user agent will continue to display the original URI to avoid confusion (and because correctly displaying both Alt-Used and Host in the URI would be ugly and confusing).
> >  - When viewing the certificate for a resource, the user agent needs to choose between the chain for the Alt-Svc, which won't necessarily match the original URI, the chain for the original URI, which misrepresents the source of the information, or both chains, which will require further user education.
> >
> 
> I don't understand the third point... The cert for the alt-svc wouldn't be any different than if the URI hostname was a CNAME pointing at the alt-svc address, which serves a cert with a SAN for the original URI hostname. Or am I misunderstanding how you verify that the alt-svc is a valid origin for the URI?
> 
> It's not like receiving an alt-svc frame/header causes the client to redirect the current request (does it?) -- it comes into play on subsequent requests. Since by the time you hit the alt-svc there's no "original URI" connection, there's no "original URI chain" per se.
> 
>  I misunderstood the specification here, this is loosely covered by RFC7838 s2.1 "For example, if the origin's host is "www.example.com" and an alternative is offered on "other.example.com" with the "h2" protocol, and the certificate offered is valid for "www.example.com", the client can use the alternative.". This has, however, been left up to the client, and is not a MUST - the stipulation is "Clients MUST have reasonable assurances that the alternative service is under control of and valid for the whole origin."
> >
> > There appears to be a conflict when using Alt-Svc over TLS between keeping information secret and respecting user privacy. Given that the IETF has adopted a position on the former, it seems essential to adopt one on the latter.
> 
> I don't follow; however...
> 
> The bigger conflict as I see it is between speed and privacy. Spinning up a TCP connection across the world is slow enough, adding TLS just makes it that much worse -- if you can reuse an existing tube you can save all of that lost time. The cost,
> 
> Yes, and as a technical solution, this is absolutely fine, however.... 
> then, is that the server at the far end of that tube knows for sure that the client at the near end is the same client for both requests down that tube, which it might not otherwise know. It doesn't know that the client is a single UA (or a single human) though; it might be a gateway/proxy of some sort.
> 
> It's pretty unlikely to be a gateway/proxy though, given that TLS is intended to be end-to-end, and there are active efforts to defeat the use of a proxy with HTTPS (RFCs 7469 and 7671, for example). 
> So the choice we offer to users is: maybe announce that you're one person across multiple requests vs. maybe watch cat gifs sooner. We already provide a similar choice: maybe announce that you're one person across multiple requests vs. be able to use online services the way they're written across sessions. (I.e. incognito vs. not). "Incognito" means "privacy", so why not include this under that?
> 
> Except it's not really being offered to users; it's being offered to browser vendors competing to produce, amongst other things, the fastest browser. Guidance on the wording is important, because it would be trivial to influence users to consent to "allow aggregation to make my experience faster" and downplay "allow service providers and aggregators to track my activity accross multiple sites" - indeed, RFC 7838 already downplays the privacy issue with "By using unique names, servers could conceivably track client requests. Such tracking could follow users across multiple networks, when the "persist" flag is used.".
> 
> I really think there needs to be a BCP created that describes the IETFs official position on privacy - it's already entered the social change/policy arena with at least BCP188 in May 2014, if not earlier. I'd be a lot more comfortable if as well as seeking to restrict monitoring by parents, schools, corporate administrators, network operators, and law enforcement agencies it sought to restrict monitoring by service providers and agregators.
> 
> Would the Working Group Chair care to weigh in on this? I appreciate policy statements probably need to come from the Area Director and the Internet Engineering Steering Group, so acknowledgement that it's under discussion would suffice.

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 11 April 2016 01:06:48 UTC