Subject: Alt-Svc Privacy Concerns

From: Phil Lello <[email-masked]>
Date: Sat, 9 Apr 2016 18:41:00 +0100

On Sat, Apr 9, 2016 at 2:36 PM, Ryan Hamilton <[email-masked]> wrote:

> On Fri, Apr 8, 2016 at 11:01 AM, Patrick McManus <[email-masked]>
> wrote:
>
>> On Fri, Apr 8, 2016 at 2:31 PM, Ryan Hamilton <[email-masked]> wrote:
>>
>>> Howdy,
>>>
>>> It is common for web sites to serve content from a variety of different
>>> origins within the same domain. For example, www.example.com,
>>> accounts.example.com, images.example.com. A single page view may
>>> require loading resources from several such origins. (Tricks like domain
>>> sharing can exacerbate this proliferation of origins.) It would be great if
>>> the service had some way to tell the client, "All of my domains can use
>>> this alternative service". What would folks thinks of an include-subdomains
>>> parameter in the Alt-Svc value? If such a parameter were present in an
>>> Alt-Svc advertisement, a client could use this advertisement to apply to
>>> any sub-domain of the origin that the client does not already have an
>>> alternative for. This would avoid the need to discover the alternatives
>>> individually.
>>>
>>>
>> the server can send, unsolicited, on stream 0 an altsvc frame for each
>> origin it wants to provide alt-svc info for (the connection needs to be
>> authoritative for those origins, of course).
>>
>> yesterday's discussion of adding certificates to an established
>> connection would make that more powerful.
>>
>> I would encourage h1 servers to update to h2 to get this feature :)
>>
>
> Hm. This seems plausible for the simple case where the number of extra
> origins is small. But in some cases, the number of extra origins can be ...
> enormous.
>
> ​In the case of YouTube which I'm quite familiar with, there are literally
> thousands of hostnames and they all have the same Alt-Svc. We can't
> practically push an origin frame for each server.​ And even if we could, I
> suspect that browsers will limit the number of servers for which they are
> tracking Alt-Svc information.
>
> I'm concerned that Alt-Svc, especially used like this, is re-introducing
the sort of privacy issues people have been trying to eliminate with
cookies for years. Appologies if this has already been discussed and I
missed it.

Specifically, although I know that, for example, google.com and youtube.com,
are tightly related, the average user might not. Over a TLS end-to-end
connection, Alt-Svc seems to make it easy to track activities between
domains without user knowledge or consent. Ditto for blog1.wordpress.com
and blog2.wordpress.com.

There's also a danger that while a CDN might legitimately advertise Alt-Svc
for different sites it caches, a rogue CDN might seize the opportunity to
track activity across unrelated entities.

Best wishes,

Phil Lello

---

From: Martin Thomson <[email-masked]>
Date: Sat, 9 Apr 2016 14:51:14 -0300

On 9 April 2016 at 14:41, Phil Lello <[email-masked]> wrote:
> I'm concerned that Alt-Svc, especially used like this, is re-introducing the
> sort of privacy issues people have been trying to eliminate with cookies for
> years. Appologies if this has already been discussed and I missed it.

http://httpwg.org/http-extensions/alt-svc.html#tracking

---

From: Phil Lello <[email-masked]>
Date: Sat, 9 Apr 2016 19:25:59 +0100

This is a slightly different issue than the described scenario, and I'm far
from certain that the risks are adequately highlighted there.

"By using unique names, servers could conceivably track client requests."
seems incredibly weak to the point of being dismissive, since it suggests a
per-client hostname being generated, and that it's incredibly unlikely
anyone would bother.

IMHO, it's quite likely that multiple seemingly unrelated sites operated by
the same entity might legitimately converge users to a common servername.
It's quite likely that at this point that the user agent would see these as
candidates for sharing the same connection. It seems reasonable that there
should at least be a recommendation for a user agent to warn users that
there is significant potential for being tracked, and gain consent.

On Sat, Apr 9, 2016 at 6:51 PM, Martin Thomson <[email-masked]>
wrote:

> the

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 9 Apr 2016 21:04:34 -0700

On Sat, Apr 9, 2016 at 10:41 AM, Phil Lello <[email-masked]> wrote:

> Specifically, although I know that, for example, google.com and
> youtube.com, are tightly related, the average user might not. Over a TLS
> end-to-end connection, Alt-Svc seems to make it easy to track activities
> between domains without user knowledge or consent. Ditto for
> blog1.wordpress.com and blog2.wordpress.com.
>

​Cookies can already be set on wordpress.com which would apply to blog1 and
blog2 so isn't the tracking your are describing already possible?​

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 10 Apr 2016 14:47:06 +1000

On 10/04/2016 4:33 AM, "Phil Lello" <[email-masked]> wrote:
>
> This is a slightly different issue than the described scenario, and I'm
far from certain that the risks are adequately highlighted there.
>
> IMHO, it's quite likely that multiple seemingly unrelated sites operated
by the same entity might legitimately converge users to a common
servername. It's quite likely that at this point that the user agent would
see these as candidates for sharing the same connection. It seems
reasonable that there should at least be a recommendation for a user agent
to warn users that there is significant potential for being tracked, and
gain consent.

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.

Is it worth documenting this risk/advice somewhere, or is it already
self-evident?

---

From: Phil Lello <[email-masked]>
Date: Sun, 10 Apr 2016 11:30:23 +0100

On Sun, Apr 10, 2016 at 5:04 AM, Ryan Hamilton <[email-masked]> wrote:

> ​Cookies can already be set on wordpress.com which would apply to blog1
> and blog2 so isn't the tracking your are describing already possible?​
>
> Yes, in the common base domain scenario, it's already possible, but
requires design choices by the hosted application(s) to set domain-level
cookies. In cross-domain scenarios, it's as bad for privacy as 3rd party
cookies. Alt-Svc abstracts the behaviour up to at least the webserver
level, if not out to the network edge.

---

From: Phil Lello <[email-masked]>
Date: Sun, 10 Apr 2016 12:05:54 +0100

On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <[email-masked]>
wrote:

> > "By using unique names, servers could conceivably track client
> requests." seems incredibly weak to the point of being dismissive, since it
> suggests a per-client hostname being generated, and that it's incredibly
> unlikely anyone would bother.
> >

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

> Is it worth documenting this risk/advice somewhere, or is it already
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.

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.

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 10 Apr 2016 23:47:06 +1000

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.

self-evident?
>  - 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).

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.

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

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?

---

From: Phil Lello <[email-masked]>
Date: Sun, 10 Apr 2016 17:19:27 +0100

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.

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

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

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

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

---

From: Erik Nygren <[email-masked]>
Date: Sun, 10 Apr 2016 15:00:48 -0400

> cookies for years. Appologies if this has already been discussed and I

I don't see the issue here really being with Alt-Svc. Rather, this is
another issue/risk with consolidating requests for multiple origins onto a
single TLS connection that has a valid cert for all of the origins. (I
don't think this was on my list in the slides in B.A. in discussion of the
ORIGIN frame and related topics, but is certainly in that class I'd
issues.)

I'm not sure I see how Alt-Svc actually makes this worse by itself.  I do
agree that when we look at the proposal for adding additional allowed
server certs to a connection that this will certainly be something we'll
want to discuss in more detail (although that is also orthogonal from
Alt-Svc).

A general point (which goes as much to UI behavior as anything) is that the
Secure Connection Info tab in many browsers only shows the CN and buries
the SANs below what users might normally see.  (And even in today's world,
resources embedded in pages are also typically not something users see and
provide many opportunities for active linking of users, such as through
URIs.)

       Erik

(resending with some edits from an email address hopefully on the list ACL)

---

From: Phil Lello <[email-masked]>
Date: Sun, 10 Apr 2016 21:33:18 +0100

On Sun, Apr 10, 2016 at 8:00 PM, Erik Nygren <[email-masked]> wrote:

> You may be right that the real issue is more widespread and affects
re-using the connection for multiple origins in general; I was thinking
about Alt-Svc when this attack vector occured to me. It's the stealth
factor of the Alt-Svc redirection that troubles me, but I suppose it's no
more inherently risky than aggregation when two or more servers resolve to
the same IP. That said, it's more complex to casually detect, as a quick
dig/nslookup will show if two server names are pointing to the same
destination; with Alt-Svc it becomes necessary to make an HTTPS request,
inspect headers, then check the IP addresses.

I have similar stealth concerns about the ORIGIN frame, since by
potentially eliminating DNS lookups it adds to the complexity of auditing
which services information is potentially shared across (e.g. if tabs to
a.com, b.com are open and using two connections, and a new tab opened to
c.com reuses a connection, is the data available to a.com or b.com?).

> A general point (which goes as much to UI behavior as anything) is that
> the Secure Connection Info tab in many browsers only shows the CN and
> buries the SANs below what users might normally see.  (And even in today's
> world, resources embedded in pages are also typically not something users
> see and provide many opportunities for active linking of users, such as
> through URIs.)
>

Yes, I agree we've already got lots of attack vectors for tracking users
without consent, and that's something the industry needs to work on
eliminating, both via the IETF and the W3C. However, UI/UX guidance for how
and when to display certificate chains and related warnings feels like the
IETF's domain to me, since it's the IETF providing the transport
protocol(s).

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Apr 2016 11:06:17 +1000

Hi Phil,

> On 11 Apr 2016, at 2:19 AM, Phil Lello <[email-masked]> 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 <[email-masked]> wrote:
> > On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <[email-masked]> 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.
> 
> 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.
> >
> >  - 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.
> 
> 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,
> 
> 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/

---

From: Phil Lello <[email-masked]>
Date: Mon, 11 Apr 2016 12:40:58 +0100

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

> > > 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
> > 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)
> > >>
> > >  - It is presumably intended that the server certificate for the
> Alt-Svc is matched on Host and not Alt-Svc
> > >  - 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
> > 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?
> >
> >  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."
> > >
> > 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
> > 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
> > 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.
>
> --