Re: Alt-Svc Privacy Concerns

> 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.
>

Thanks, that's a good start; in an ideal world, I'd hope for a successor
that included a bullet-point summary to help techies in non-technical
organisations present a concise "industry standard" to decision makers.
That said, I fully appreciate the complexities of obtaining consensus when
balancing different cultural norms, commercial and consumer interests, and
given geopolitics, it's a moving target.

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.
>

That's great news, I will certainly try to contribute to that effort -
although, no doubt like many others, I'm already struggling to keep up with
the volume of messages accross multiple technolgoy lists.


> 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.
>

I'll mostly concede that point; it's the potential for subsequent
aggregation on one connection under HTTP/2 that is the new challenge.
However, I do think that there needs to be a recommendation for UI/UX
behavior around here - I haven't got a good solution, since displaying two
servers in the address bar would just add to clutter. Perhaps an
info/warning indicator by the address bar would work, showing where
subsequent requests would load from (but not hugely effective for on-page
assets, unless these are pushed from origin).

I think aggregation concerns are likely to become a bigger issue given the
trends towards cloud computing and CDNs.

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/>.
>
> Indeed, it's an ongoing battle.


> 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?
>
>
I think the process generally works quite well; the unfortunate timing is
more of a time issue my end, to be honest - my involvement on IETF lists at
present is part of a vested professional interest rather than part of my
day job - although I'm actively seeking to change that. I doubt I'm the
only participant with that issue.

The process that could potentially do with refinement is encourage
general-public review of the privacy aspects of consumer technologies (HTTP
being the most obvious, possibly mail/news protocols, others more
debatable); that said, it would appear to be a significant change of scope
for the IETF, and present a lot of new challenges, so might be best left to
a partner organisation.


>
> > 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/
>
>