Subject: Some half-baked thoughts about cookies.

From: Mike West <[email-masked]>
Date: Tue, 14 Aug 2018 12:38:24 +0200

Hey folks,

https://github.com/mikewest/http-state-tokens suggests that we should
introduce a client-controlled, origin-bound, HTTPS-only session identifier
for network-level state management. And eventually deprecate cookies.

I think there's a conversation here worth having, and this group has
thought a lot about the space over the last decade or two. I'd appreciate
y'all's feedback, both about the problems the document discusses with
regard to cookies as they exist today, and about the sketchy proposal it
advances about managing HTTP state in the future.

Thanks!

-mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 14 Aug 2018 12:07:21 +0000

--------

>for network-level state management. And eventually deprecate cookies.

Well, pretty much exactly what I proposed early in the HTTP/2 cycle,
so I'm all for it.

I would dedicate the top bit of the session-id, still under client
control, to tell the server if this should be considered a ephemeral
or persistent session, to make it easier for the server to garbage
collect state.

If the top bit is zero, this session is ephemeral and when the
browser leaves, the session ceases to exist.  UX wise this would
typically be browsing in "private mode" or if "do not track" is
set.

If the top bit is one, the user allows this session to be persistent
across visits to the site, aka enabling "Leave me logged in" etc.

Poul-Henning

PS:  64 bits is not enough for everybody, in particularly not when
they are randomly generated by less than perfect implementations.
Make then 128 bit from the start.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 14 Aug 2018 14:18:10 +0200

Hi Poul-Henning,

> Make then 128 bit from the start.

No, that's what we discussed at the HTTP workshop 3 years ago already,
putting too many bits will cause the inverse of what is desired, it
adds unique client identifiers making tracking even easier and at the
same time will make distributed server stickiness very hard if not
impossible. If instead we only place a few bits for routing information
(say 16 bits) and place it upfront, all the routing information is
present and there is no need to distinguish between multiple clients.
The server will then be able to figure the real client from the
decrypted traffic (potentially via another client-fed ID if needed).

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Aug 2018 14:36:59 +1000

Hi Mike,

On 14 Aug 2018, at 8:38 pm, Mike West <[email-masked]> wrote:
> 
> Hey folks,
> 
> https://github.com/mikewest/http-state-tokens suggests that we should introduce a client-controlled, origin-bound, HTTPS-only session identifier for network-level state management. And eventually deprecate cookies.
> 
> I think there's a conversation here worth having, and this group has thought a lot about the space over the last decade or two. I'd appreciate y'all's feedback, both about the problems the document discusses with regard to cookies as they exist today, and about the sketchy proposal it advances about managing HTTP state in the future.

This reminds me very much of a proposal from Apple that was floating around a few years ago. Do you remember the source? I can dig around if you don't.

I think the pushback at the time was that it didn't have significantly better privacy properties as compared to cookies. Looking at what you've written, it seems like you're trying to "reset the defaults" for cookies more than anything -- i.e., make them origin-scoped, secure, etc. out of the box.

Personally I think that's a worthy goal, for the same reasons that you point out at the top of the doc; current security mechanisms are getting abysmally low deployment.

By it's nature, this is a very long-term process (much as the transition to HTTPS is, although hopefully less painful). It's probably premature to speculate about how exactly the transition will happen (in terms of incentives), but *some* sense that it's at least possible would be good. Maybe the HTTPS transition is proof enough.

Overall, I personally think this is worth pursuing, as long as we understand it's a very long-term thing.

One specific thing -- requiring a single token that's generated by the client precludes a server using this to distribute state to load balancers, CDNs, etc. for various purposes, which is a fairly common pattern. I suspect that the current design is going to create friction against deployment as a result; it effectively places all state at the origin.

Cheers,

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

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 15 Aug 2018 08:01:45 +0200 (CEST)

> for network-level state management. And eventually deprecate cookies.

I'm thinking this suggestion will handle some cookie use cases really fine 
(login-like for example) but some others much less fine:

Imagine a site that uses a cookie (for millions of users) if they saw the 
introduction page or not and can skip showing it if the user already saw it. 
Setting a cookie "sawintro=yes" is very lightweight and easy. Each client is 
then responsible for telling the server on the next visit that it already saw 
it; cookies used for client-side state as it was meant to be. Sec-HTTP-State 
doesn't make this very easy...

So, looking into the crystal ball, won't this lead to clients using both 
cookies *and* Sec-HTTP-State ?

Then, a suggestion on terminology: The document says "browser" in eight places 
when talking about a cookie-using HTTP client. Cookies is a well used 
mechanism even for non-browser HTTP clients and I believe referring to the 
user-agent as a "browser" in a document like this is bad.

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Aug 2018 17:18:05 +1000

> cookies *and* Sec-HTTP-State ?

To Daniel's point here (and Mark said something similar), this does
several things at once.  It removes the option for state offload at
the HTTP layer in favor of a (long) fixed string.  It also resets the
scope of identifiers that can be persisted.

I really like the idea of narrowing the scope problem of cookies;
cookies are awful, mostly because they cross origin boundaries in
awful ways.  And document.cookie is similarly terrible.  Bundling
those two changes with the removal of state offload might be too much
though.  Other HTTP clients don't have indexedDB or service workers to
fall back on for this use case.

Cookies are - from the perspective of a user - superior in almost
every way. The CSRF benefits here seem fairly hard to get excited
about enough to use this new, more limited thing.  I can maybe see
sites doing this for high value state, if it comes to that, but that's
being optimistic.

I don't understand how the cross-origin use of these is intended to
work (what requests do the options apply to?).

p.s., Not sure that son-of-token-binding is worth doing here.  Proving
that you know a cookie-analogue as opposed to just providing the value
might be neat, but it's still leap of faith.  Besides, token binding
was a ton of work to get right.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 Aug 2018 08:42:55 +0000

Daniel Stenberg wrote:

> Then, a suggestion on terminology: The document says "browser" in eight places when talking about a cookie-using HTTP client. Cookies is a well used mechanism even for non-browser HTTP clients and I believe referring to the user-agent as a "browser" in a document like this is bad.

+1

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Aug 2018 23:20:00 +0100

Hiya,

> advances about managing HTTP state in the future.

I'd be very keen to see HTTP state management become more privacy
friendly, but I don't see how this moves us in that direction tbh.
Be happy to be wrong though.

Things that make me think that include:

- new unique IDs for clients seems like a bad plan (64 bits seems way
  too many from a re-identification POV), the idea of the web UA just
  automatically spewing those out seems particularly misdirected, if
  that is the idea

- I don't see how this'd incent web UAs nor web servers to behave in
  more privacy friendly ways, at best it seems neutral

That said, I do support discussing these ideas, just not (what I think
is) this particular less-baked plan in it's as-is state.

S.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 16 Aug 2018 14:26:53 +1200

> is) this particular less-baked plan in it's as-is state.

It moves us all one step closer to the situation where the security vs
privacy model scoped at just session-ID values can be reasoned about and
tightened up far better than the free-for-all values Cookie may contain.

Unfortunately Cookie are so weak in regards to those properties that a
session ID performing what is actually current practice get thrown out
immediately as terrible design from either security or privacy viewpoint.

As you say, its a neutral proposal. That itself places it on the losing
side in the perfection-or-nothing battle.

AYJ

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 08:23:27 +0200

On Tue, Aug 14, 2018 at 2:07 PM Poul-Henning Kamp <[email-masked]>
wrote:

> --------
> In message <CAKXHy=
> [email-masked]>, Mike West
> writes:
>

Oh, great! Can you point me to the proposal? I'd love to read it.

> typically be browsing in "private mode" or if "do not track" is

Hrm. Some browser vendors attempt to hide the fact that a user is running
in "private mode". Advertising it via the top bit of the identifier might
butt up against that goal.

But assuming we ran with this model, what heuristics would you expect
servers to use when cleaning up session identifiers that are no longer in
use?

> Make then 128 bit from the start.

After a discussion on Twitter
<https://twitter.com/patricktoomey/status/1029318457957871616>, I
ended up bumping
this to 256 bits
<https://github.com/mikewest/http-state-tokens/commit/2fc6f828c1641eaf78bf85a64aea1ef7507647c1>.
I think there's probably more discussion to be had around exactly the right
length and whether that's too long, but I agree that 64 isn't enough.

-mike

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 08:27:13 +0200

On Tue, Aug 14, 2018 at 2:18 PM Willy Tarreau <[email-masked]> wrote:

> impossible.

Can you point me to notes on this discussion? I'm quite curious!

For clarity, I think this identifier is supposed to make it possible to tie
multiple HTTP requests together into a coherent session, which (I think?)
means that a unique-enough identifier is essential.

> If instead we only place a few bits for routing information

Hrm. I might be misunderstanding the use of "decrypted" here, but exposing
any of the identifiers bits over plaintext is a non-goal of this proposal.

-mike

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 08:39:43 +0200

On Wed, Aug 15, 2018 at 6:37 AM Mark Nottingham <[email-masked]> wrote:

> This reminds me very much of a proposal from Apple that was floating
> around a few years ago. Do you remember the source? I can dig around if you
> don't.
>

I don't remember it. I'd love to take a look if you can dig it up!

I think the pushback at the time was that it didn't have significantly
> better privacy properties as compared to cookies. Looking at what you've
> written, it seems like you're trying to "reset the defaults" for cookies
> more than anything -- i.e., make them origin-scoped, secure, etc. out of
> the box.
>
> Personally I think that's a worthy goal, for the same reasons that you
> point out at the top of the doc; current security mechanisms are getting
> abysmally low deployment.
>

I don't believe this proposal significantly changes the technical privacy
story (except insofar as it locks the identifier to encrypted connections,
which mitigates their usefulness for pervasive monitoring). I do think it
resets the defaults, as you say, and I think that's quite valuable.

By it's nature, this is a very long-term process (much as the transition to
> HTTPS is, although hopefully less painful). It's probably premature to
> speculate about how exactly the transition will happen (in terms of
> incentives), but *some* sense that it's at least possible would be good.
> Maybe the HTTPS transition is proof enough.
>

That's the way I'm looking at it. I would like to create a thing that we
collectively think is better-suited to managing HTTP state today, and point
people to it as a better option. Over time, we can encourage that option's
usage, but I agree both that this is a long-term play, and that the
encouragement mechanisms are currently speculative.

One specific thing -- requiring a single token that's generated by the
> client precludes a server using this to distribute state to load balancers,
> CDNs, etc. for various purposes, which is a fairly common pattern. I
> suspect that the current design is going to create friction against
> deployment as a result; it effectively places all state at the origin.

That might be the case.
https://github.com/mikewest/http-state-tokens#server-controlled-values
hints at an alternative that would allow the server control over the
token's value. I prefer to put it completely under the client's control, as
that gives some nice guarantees around the lack of interesting information
in the identifier itself, but I recognize that it's a big shift.

-mike

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 08:53:55 +0200

> doesn't make this very easy...

I agree that folks are using cookies for this kind of work today, and that
they're a very convenient way of outsourcing the responsibility for
maintaining state to the client. It's not clear to me that we should ask
clients to accept that obligation. In my opinion, the analysis of status
quo `Cookie` header length presented in
https://github.com/mikewest/http-state-tokens#a-problem is fairly damning
of the current setup, suggesting that servers are abusing the ability to
offload work to the client. It seems reasonable to me to ratchet down on
that ability over time, and to encourage server operators to take on both
the cost and responsibility.

> cookies *and* Sec-HTTP-State ?

For a (long) while, yes. There are specific use cases that this new thing
will server very well that can be quickly adopted. There are other use
cases that this new thing suggests should be done differently. Those will
take time to sort out. My goal here is to build a new thing to point folks
towards, which will allow us to impose restrictions on cookies over time
that will guide developers towards the new thing and away from the old
thing.

> user-agent as a "browser" in a document like this is bad.

Yes. That was myopic of me:
https://github.com/mikewest/http-state-tokens/commit/e577abc6baf18bedfc4ea6973e864eb0ca1ca363
.

-mike

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 09:10:48 +0200

> fall back on for this use case.

That's a very reasonable point.

I've gone back and forth a few times about what changes would be good to
push for here (https://github.com/mikewest/http-state-tokens#pivot-points
outlines some of those considerations). My intuition is that it would be
better to try something with more radical properties if we're confident
that the radical thing would actually be better than the status quo. I
agree with you, however, that more radical proposals will have longer and
shallower adoption curves, and that we might end up in a world with both
the old thing and the new thing. Cookies' ubiquity make that a pretty
likely outcome, honestly, regardless of the new thing's amazing properties.

My hope is that having a new thing will allow us to ratchet down on the old
thing more aggressively than we'd be able to otherwise.

> every way.

Superior in what sense?

> The CSRF benefits here seem fairly hard to get excited

The options are meant to apply to the token itself; the `delivery` token in
particular is similar to the `SameSite` attribute if you squint a bit. That
is, when the server says "This token should be delivered cross-site.", then
it will be delivered along with any request that would deliver cookies that
weren't set with a `SameSite` attribute. If the server says "This token
should be delivered same-origin.", then it would be delivered along with
any request that would deliver a cookie set with a theoretical `SameOrigin`
attribute.

> was a ton of work to get right.

I agree that the sketch in the proposal document is not at all fleshed out,
but it aims to solve a smaller problem than either token binding or channel
ID did. I hope that means that it will be simpler to analyze, but it
certainly needs more discussion, both in terms of the threat model, and in
terms of the implementation.

-mike

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 09:20:59 +0200

Combining Stephen's and Amos' responses here:

> > Be happy to be wrong though.

As noted in my response to Mark, I don't think that this proposal is
technically different to cookies with regard to privacy (modulo
encryption). It has better security properties, which reflects my
underlying goals.

In some discussion at Dagstuhl, some folks suggested that there may be
regulatory impacts to taking control of the identifier away from the site
and giving it to the user agent, and to the suggestion that the user agent
create a purposeful story around the identifier's goals. Rigo Wenning
spelled out his views on that subject in
https://github.com/mikewest/http-state-tokens/pull/2. I am neither a
lawyer, nor a regulator (nor do I actually agree with everything Rigo wrote
in that PR! :) ), so I don't know how compelling that story actually is,
but it does intuitively make sense to me that splitting "authentication"
and "advertising" into distinct things that can be manipulated separately
would be valuable.

> >   automatically spewing those out seems particularly misdirected, if

It's non-obvious from the proposal doc, but the UA would only "spew"
identifiers for same-site requests, given the defaults. It would not spew
cross-site identifiers until the relevant origin was visited in a same-site
context and explicitly declared its tokens as being deliverable cross-site
(at which point the UA could make some decisions about how to handle that
declaration). That's not nothing.

> >   more privacy friendly ways, at best it seems neutral

As above, there are distinctions around the margins, but I agree that it's
~neutral from a privacy perspective.

> > is) this particular less-baked plan in it's as-is state.

I'm not dead-set on this proposal as-written. :) I hope it sparks some good
conversation, and that we end up with something better in the long run.

> side in the perfection-or-nothing battle.

I agree with this assessment, and I'd suggest that we're unlikely to
practically deploy perfection (assuming that we can even define it!). This
proposal feels radical in some ways, and would have some interesting
impacts if deployed. I look forward to exploring those with y'all. :)

-mike

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 16 Aug 2018 09:28:59 +0200

Hi Mike,

> Can you point me to notes on this discussion? I'm quite curious!

All I could find was summarized as "upfront routing information" here, as
we didn't take that much notes by then, we were mostly discussing ideas :

    https://github.com/HTTPWorkshop/workshop2015/wiki/HTTP-Ideas

> means that a unique-enough identifier is essential.

In fact I'd reformulate this differently. I'm aware about two (valid) use
cases of cookies :

  - put a server identifier so that a request finds its way through an
    infrastructure and keep the same path as the previous requests from
    the same session. That's called "persistence" or "stickiness". Usually
    there are not that many paths, so a few bits are often enough (typically
    16 should be enough for most cases I think). There is no problem with
    collisions since such paths are shared between many sessions already.
    There's always the possibility to do that based on client-fed info only
    (eg: hash on whatever) but then it significantly degrades the ability to
    perform correct load balancing (no more consideration for server load,
    no more graceful shutdown, no more scale-in/scale-out, etc). So here
    it's really desirable to let the load balancer return a path identifier.
    Usually that's done using one or more cookies (typically one per load
    balancing layer) which indicate a server identifier the request was sent
    to.

  - retrieve the user session's context from a database or from memory.
    Here it's different as it's critical from a security perspective that
    there is no collision, as you certainly don't want one user to end up
    on another user's context. The cookies address this in a relatively
    elegant way since they're provided by the server which can decide on
    what is needed to guarantee their unicity. If instead this information
    is passed by the client only you can expect that all those devices with
    low entropy will very often collide and occasionally land on another
    one's session. The raise of IoT and low-power, lightly designed stacks
    further increases this risk. However here I'd say that the server does
    not need to have very strong identifiers, it would only need to figure
    the session among all those it knows, and ensure that these ones cannot
    be brute-forced by clients. Ie if a server supports only 1 million
    concurrent sessions, it could possibly use 20 bits to identify them,
    then seal the value with its own private key so that other valuess cannot
    be injected by clients.

I know I'm simplifying the problem a little bit because it's common nowadays
to have multiple layers of infrastructure with multiple entry points. The
multiplicity of entry points is what causes the problem because you cannot
easily expect that each front point stores and hides the cookies learned
from next levels, so often you need to pass that information to the client
as well.

> any of the identifiers bits over plaintext is a non-goal of this proposal.

The idea instead was to expose those bits (which are not specific to a client
but to a path taken by several clients) so that load balancers do not even
need to decrypt TLS to find the routing information anymore. That was
discussed as a way to improve server-side performance, and it also happens
to reduce the need for decrypting along the path, which can be an improvement
overall.

Willy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Aug 2018 08:53:48 +0100

Hiya,

On 16/08/18 08:20, Mike West wrote:
> On 16/08/18 03:26, Amos Jeffries wrote:

I don't think asking that we aim for a better than ~neutral
privacy outcome is fairly cast anything related to perfection.
(I'm not saying anyone's being unfair, it's just not particularly
useful rhetoric;-)

I do think we ought try for, and perhaps require, any long
term cookie dis/re-placement scheme have better privacy
properties than the current miasma.

I fully agree that aiming for better than ~neutral makes a
hard problem harder though, and maybe we'd find that there's
no feasible approach. OTOH, in one recent case (SNI encryption),
we do seem to have made progress despite that problem appearing
practically unsolveable for quite a while.

What I'm asking is that, if doing this, we aim for a real
improvement in privacy too, and include relevant actors and
incentives in the analysis. We might fail to meet that goal
of course, but I reckon we really ought try.

Cheers,
S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 16 Aug 2018 08:08:35 +0000

--------
In message <CAKXHy=[email-masked]>, Mike West writes:

>clients to accept that obligation.

We should absolutely not, and if for no other reason then because
the local cookie-store on client computers is the first thing
criminals raid when they get a chance, because it reveals a lot of
ways they can exploit the access.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 16 Aug 2018 08:11:29 +0000

--------

>to reduce the need for decrypting along the path, which can be an improvement

A bit more context: http://phk.freebsd.dk/sagas/httpbis.html

---

From: Rigo Wenning <[email-masked]>
Date: Thu, 16 Aug 2018 10:38:28 +0200

Stephen, 

> Hiya,

long time no talk. Normally Mike and I have near to insurmountable 
differences over near to all aspects of web technology :) This time 
it seems different to a certain extend.

Unique IDs remain uniqueIDs. AFAI understand (or to me), this is not 
a proposal to stop tracking by uniqueIDs. And in the very large 
picture, there is no big difference as we replace UniqueIDs by 
UniqueIDs. But the proposal offers some interesting properties. 

We need uniqueIDs for stateful browsing and many other purposes. I 
don't think this proposal will mean one can technically stop abusing 
uniqueIDs for bad things. In this case, it should use anonymous 
credentials and the things Jan Camenisch and David Chaum suggest 
since a long time. 

The attacking scenario is a different one. If we assume that the 
service follows the purpose given to the UniqueID (behave as 
stated), the proposal can help further data self determination. This 
is the "data protection" aspect, rather than the "privacy" US aspect 
that looks into secrecy or access control. Data protection looks 
more into "dossiers". 

This should not replace cookies. It is just a new attempt (P3P was 
the last one we tried) to distinguish between good IDs and bad IDs. 
And my suggestion is NOT to start with "authentication" and 
"advertisement". My suggestion is to start with "authentication" 
only. This has more social merits than technical merits. The 
"authentication" token will have an expected use and behaviour. In 
regulated environments like the EU, the purpose can be enforced. By 
minting its own uniqueIDs, the browser has more control over the 
semantics of it and when to send or lie. 

This will carve out a space where uniqueIDs are not considered 
harmful. Like Mike pointed out, it can require TLS to send the ID, 
which helps with pervasive monitoring. There are many more little 
improvements possible this way. As the ID is on the user agent, it 
rather considers the user while a site (cookies) will consider more 
its own needs. 

On the long run, more 80/20 cases can be taken up in 
standardization, like "advertisement" or "audience measurement". But 
I wouldn't start with those as it makes the content of the 
specification too contentious to go through. DNT was a nice proposal 
and suffered especially from the clash between certain branches of 
the industry. "Authentication" only could avoid that here. "Audience 
measurement" is also not too contentious but far from unanimity.

 --Rigo
> >> As you say, its a neutral proposal. That itself places it on
> >> the losing side in the perfection-or-nothing battle.
> > 
> > I agree with this assessment, and I'd suggest that we're
> > unlikely to practically deploy perfection (assuming that we can
> > even define it!). This proposal feels radical in some ways, and
> > would have some interesting impacts if deployed. I look forward
> > to exploring those with y'all. :)

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 10:56:52 +0200

Hey Stephen!

Forking this into a separate thread to focus the conversation.

> (I'm not saying anyone's being unfair, it's just not particularly

I take that point, thanks.

> properties than the current miasma.

I suspect that we'll agree on this, as "better" doesn't seem difficult to
achieve with respect to the status quo.

> of course, but I reckon we really ought try.

I agree that it would be helpful to spell out the axes along which we think
cookies need improvement from a privacy perspective. In this thread, I've
talked about the ways in which this proposal impacts two privacy-relevant
aspects of cookies:

1.  They are potentially delivered in plaintext.
2.  They enable third-party tracking.

I think this proposal has significantly positive impact on the first
insofar as it prevents plaintext delivery, and minorly positive impact on
the second insofar as it requires an initial same-site request in order to
enable subsequent cross-site delivery.

I'm sure, however, that there's a lot more here to discuss, and that y'all
have thought about the problem deeply over the years. For instance, you
mentioned incentives for UAs and servers to behave in more privacy-friendly
ways: did you have anything in particular in mind?

Thanks!

-mike

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Aug 2018 19:18:08 +1000

>> Cookies are - from the perspective of a user - superior in almost

Well.  Everything we hate is a feature someone else relies on.

> The options are meant to apply to the token itself; the `delivery` token in particular is similar to the `SameSite` attribute if you squint a bit. That is, when the server says "This token should be delivered cross-site.", then it will be delivered along with any request that would deliver cookies that weren't set with a `SameSite` attribute. If the server says "This token should be delivered same-origin.", then it would be delivered along with any request that would deliver a cookie set with a theoretical `SameOrigin` attribute.

So, if I'm visiting a page on example.com, the default behaviour would
be to have the token delivered in requests to example.com.
Subresources loaded on the same page would - by default - have no
associated token?  Or the token associated with that origin?  And if
the site said "cross-site" in a response, then the token would be
attached to all subresource requests?  Doesn't that mean that you
can't pass it to a.example without also passing it to b.example?

Given that sites have finer-grained means of passing information to
subresource loads, why even provide this capability at all?

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 11:22:58 +0200

>     balancing layer) which indicate a server identifier the request was

I agree that there's value to intermediate servers knowing how to route
requests. That said, 16 is a lot of bits, enough to separate ~7 billion
users into chunks of ~100k or so. Below, it sounds like you're suggesting
that these bits would be visible to an intermediate server without
decrypting the connection. That, plus the originating IP address, sounds
like it would entail some fairly substantial risk of pervasive monitoring
similar in kind to the risk we'd like to prevent by locking the token away
behind TLS.

I think we'll need to weigh the value of public load-balancing/stickyness
against this kind of risk in order to determine whether it's a reasonable
thing to include in plaintext.

It seems much less risky to give the server some measure of control over
the high-order bits of the identifier in order to enable internal
load-balancing and stickyness after TLS is terminated. I'm pretty sure we
could find a compromise here between complete client-side control over the
identifier's value, and some number of server-controlled bits in the
identifier.

>     then seal the value with its own private key so that other valuess

I think there's a lot of flexibility in the length of the identifier we
provide to servers, if we run with something purely client-controlled. It
seems to me that high-traffic sites would benefit from granular
identifiers, and that if we accept that we need to avoid collisions, then
it would be reasonable to send enough entropy to make them truly unlikely.
I'm confident that some sites could get away with 20 bits and a key. I'm
less confident that larger sites could do the same.

> from next levels, so often you need to pass that information to the client

Likewise, I'm sure I'm oversimplifying the problem from your perspective,
as I'm looking at this with my browser hat on. I hope we can find a
reasonable set of compromises over time. :)

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 11:29:30 +0200

> Well.  Everything we hate is a feature someone else relies on.

Got it. :)

> > The options are meant to apply to the token itself; the `delivery` token
> in particular is similar to the `SameSite` attribute if you squint a bit.
> That is, when the server says "This token should be delivered cross-site.",
> then it will be delivered along with any request that would deliver cookies
> that weren't set with a `SameSite` attribute. If the server says "This
> token should be delivered same-origin.", then it would be delivered along
> with any request that would deliver a cookie set with a theoretical
> `SameOrigin` attribute.
>
> attached to all subresource requests?

In a browser context, when a user navigates to `https://example.com/`:

*   The navigational request would include `https://example.com`'s token.
*   Requests to `https://example.com/` would include `https://example.com`'s
token.
*   Requests to `https://sub.example.com/` would include `
https://sub.example.com`'s token, unless it had opted-into `same-origin`
delivery (in which case it would be excluded).
*   Requests to `https://not-example.com/` would include `
https://not-example.com`'s token iff it had opted-into `cross-site`
delivery.

Doesn't that mean that you can't pass it to a.example without also passing
> it to b.example?

Correct. This proposal ~matches the granularity we created with `SameSite`,
with the addition that it can be tightened beyond a "site" to an "origin".
Do you think more granularity would be helpful?

> subresource loads, why even provide this capability at all?

What means are you thinking of? Cookies? GET parameters?

-mike

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Aug 2018 19:42:53 +1000

On Thu, Aug 16, 2018 at 7:29 PM Mike West <[email-masked]> wrote:
> *   Requests to `https://example.com/` would include `https://example.com`'s token.
> *   Requests to `https://sub.example.com/` would include `https://sub.example.com`'s token, unless it had opted-into `same-origin` delivery (in which case it would be excluded).
> *   Requests to `https://not-example.com/` would include `https://not-example.com`'s token iff it had opted-into `cross-site` delivery.

OK, I misunderstood who was opting in.  Thanks.  I suspect that some
of the cross-site options here might be blocked by browser policy
(double-keying).

> What means are you thinking of? Cookies? GET parameters?

In the context you are talking about, GET and service workers
primarily.  (If the goal is to progressively neuter cookies, then we
can't start to rely on them more.)

---

From: Mike West <[email-masked]>
Date: Thu, 16 Aug 2018 12:55:50 +0200

On Thu, Aug 16, 2018 at 11:43 AM Martin Thomson <[email-masked]>
wrote:

> > In a browser context, when a user navigates to `https://example.com/`
> <https://example.com/>:
> >
> > *   Requests to `https://example.com/` <https://example.com/> would
> include `https://example.com`'s token.
> > *   Requests to `https://sub.example.com/` <https://sub.example.com/>
> would include `https://sub.example.com`'s token, unless it had opted-into
> `same-origin` delivery (in which case it would be excluded).
> > *   Requests to `https://not-example.com/` <https://not-example.com/>
> would include `https://not-example.com`'s token iff it had opted-into
> `cross-site` delivery.
>

I think that's very likely. I imagine these being an upper-limit on
availability that the site is responsible for setting. User agents can
ratchet that down based on a number of heuristics and/or user-facing
permission grants, just as they do for cookies today.

> can't start to rely on them more.)

Got it, thanks.

 -mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Aug 2018 11:52:32 +0100

Hiya,

(Sorry for the slow response...)

> Hey Stephen!
...
> enable subsequent cross-site delivery.

Seems about right (though I'm not sure I yet get the cross-site
details but that's ok for now).

> 
> I'm sure, however, that th> Forking this into a separate thread to focus the conversation.
> 
>>ere's a lot more here to discuss, and that y'all
> have thought about the problem deeply over the years. 

I wouldn't claim to ever have had deep thoughts:-)

> For instance, you

Fair question.

What I'd like (but don't know how to get) is something like:

- an HTTP state mechanism that is not likely to be used when
  not needed for managing state
- stateless operation to become a more normal thing, e.g. I'd
  like stateless operation to work more often/better when
  browsing sites with which I don't have a relationship
- a mechanism that is harder to abuse, and where abuse could
  be detected (possibly that last would need an auditor or
  researcher to figure out clever ways to spot abuse)
- and a pony :-)

I think there could be incentives for servers, if the above
was more efficient than the status quo ante, and if they
ended up with higher quality information about the user
agents that actually matter to them, and didn't have to
deal with the chaff from every UA that ever made a connection.
(And the potential costs if that chaff leaks due to some
incident in a server or partner site.)

Similarly, I'd hope reducing stateful operation could be
viewed as a positive by UAs, if it allowed them to render
pages more quickly in enough cases. i.e. if the servers
were incented to play this kind of game for enough content,
then maybe it'd also be attractive to UAs.

I'm not sure how that'd translate into something that
could be used, but perhaps something like: default to not
send any identifier on 1st contact, to start sending short
identifiers when needed (making 'em longer as needed), and
with those identifiers cycled by default (e.g. for new
TLS sessions) with some way that a server who needs to
could spend a bit of effort that'd allow them to know
that a chain of identifiers are from the same UA. (That
starts to sound a bit like the quic connection ID
discussion though.)

If the upshot of all that was that real HTTP state
management was less likely to be used for tracking and
that those wanting to track were left with cookies, and
if turning off cookies worked well more often, then I
guess that'd be a win.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Aug 2018 14:14:04 +0100

Hi Rigo,

(This topic maybe belongs more in the other thread?)

On 16/08/18 09:38, Rigo Wenning wrote:
> UniqueIDs. 

Not sure I agree there, if UAs by default sent a different
64 bit randomly generated ID to each origin and kept those
IDs for a long time, that seems worse to me than the current
situation. (I'm not saying that's Mike's proposal, but
just disagreeing with your "no big difference" statement.)

> But the proposal offers some interesting properties.
> 

I'm not arguing for something that'd prevent all abuses. I
am arguing that since we know abuses will occur, we need to
consider the privacy aspects of that and try to do better
than the current situation.

> that looks into secrecy or access control. Data protection looks 

I'm not following that. What is "data self determination"
and I don't get what you mean by dossiers.

> the last one we tried) to distinguish between good IDs and bad IDs. 

So RFC 3514 then? ;-)

> only. This has more social merits than technical merits. 

I've no problem with the idea of trying to address HTTP state
in a way that doesn't set out to try help advertising. But I
think we do need to consider unintended but known possible
(ab)uses of any new HTTP state mechanism.

> The 
> harmful. 

Possibly, yes. (Though s/uniqueIDs/a new HTTP state mechanism/)

> Like Mike pointed out, it can require TLS to send the ID, 
> which helps with pervasive monitoring. 

That helps with PM from intermediaries, yes, which is a fine
thing. There is still PM done by servers e.g. for commercial
reasons. Again, I'm not arguing that a new HTTP state mechanism
must solve that problem, but that we need to take it into
account and try do better than today.

> There are many more little 

Bit of a nit but I'm not sure that the user's and the UA's
goals are always the same here. The point being that the
requirements for a new HTTP state mechanism may not be the
exact same for users and for UA developers. Asking that we
try do better wrt privacy I hope makes us consider that in
our analysis of a new mechanism.

Cheers,
S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 17 Aug 2018 15:44:24 +0000

--------
In message <[email-masked]>, Stephen Farrell wr

>just disagreeing with your "no big difference" statement.)

How is that worse than sending an opaque cookie, possibly
containing imcompetently protected GDPR-covered personal
information for a long time ?

At least with a randomly generated ID, you know it cannot
leak information on the local machine (hacked/lost/discarded).

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Aug 2018 16:51:03 +0100

Hiya,

On 17/08/18 16:44, Poul-Henning Kamp wrote:
> How is that worse than sending an opaque cookie,

If it was always sent, with no opt-out. (Again, I'm not
saying that was Mike's proposal though.)

> possibly

True.

Cheers,
S.

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 19 Aug 2018 09:04:40 +0300 (EEST)

https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0217.html
https://github.com/mikewest/http-state-tokens/pull/2
https://github.com/mikewest/http-state-tokens/blob/60e9066f39d345679bbf5bf0151575652e90d9cb/README.md

> just disagreeing with your "no big difference" statement.)

Then it seems that for uniqueID with purpose "authentication",
need mechanismim

* to server indicate that uniqueID for "authentication" is needed
  to be generated by Browser for that site because user is about
  to log in

* to server indicate that that uniqueID for "authentication" is
  no longer needed, because user is logged out

  Perhaps these are on Sec-HTTP-State-Options:

Perhaps these may be usefull to compine with /.well-known/ URL
to browser signal

  - uniqueID for site is allocated
  - uniqueID for site is destroyed

to help site maintain site wide database

Yes there was Javascript 

 let resetChannel = new BroadcastChannel('http-state-reset'));
 resetChannel.onmessage = e => { /* Do exciting cleanup here. */ };

   ( I understand that javascript does not see that uniqueid
     and anyway because Sec-HTTP-State header start with "Sec-"
     browser needs add it to requests generated by Javasript.
     Javascript can not add that header.
   )

So looks like uniqueID should not automatically generated before
they are needed. 

* When Sec-HTTP-State includes purpose, does that mean that
  there is several uniqueID for different purpose

  or

  is uniqueID always combining different porposes ?

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 19 Aug 2018 11:16:29 +0300 (EEST)

https://github.com/mikewest/http-state-tokens

> It might be reasonable instead to send something like Sec-HTTP-State: ? to advertise the feature's 
> presence, and allow the server to ask for a token by sending an appropriate options header 
> (Sec-HTTP-State-Options: generate, or something similar).

Yes. In that case Sec-HTTP-State-Options can also indicate how many bits
server wants (32 - 128 bits perhaps is acceptable) for uniqueID/token.

> Slowly and gradually. User agents could begin by advertising support for the new hotness by appending a 
> Sec-HTTP-State header to outgoing requests (either setting the value by default, or allowing developers to 
> opt-in, as per the pivot point discussion above)

Servers may need then also Set-Cookie: flag telling "Do not send this cookie,
if you generate Sec-HTTP-State: -header".

Servers need some motivation so that not just Set-Cookie: is used.

So perhaps this is useful  to compine with /.well-known/ URL
to browser signal

  - uniqueID/token for site is allocated
  - uniqueID/token for site is destroyed

to help site maintain site wide database. This is motivation
for Sec-HTTP-State: -header.

> To that end, servers can generate a unique key, associate it with the session identifier on the server, and 
> deliver it to the client via an HTTP response header:
> 
> Sec-HTTP-State-Options: ..., key=*ZH0GxtBMWA...nJudhZ8dtz*, ...

That key may be returned from

 /.well-known/ which browser calls when uniqueID for site is allocated.

> Sec-HTTP-State: token=*J6BRKa...MonM*, sig=*(HMAC-SHA265(key, token+metadata))*

Sig can be just hash from uniqueID/token and key. That may be 
proof that /.well-known/ URL is visited. If metadata is considered
that goes too complex (and there is too many design considerations).

Hash from key is needed, or otherwise this allows site
store arbitary data as cookies allow. Purpose is not
allow to store arbitary data to browser.

/ Kari Hurtta

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 11:01:45 +0200

> (Sorry for the slow response...)

Sorry for the even-slower response. I should have learned by now not to
throw interesting ideas out to a mailing list just before leaving on
vacation. That said, the beach was lovely, so I don't have too many
regrets... :)

> details but that's ok for now).

#3 in
https://github.com/mikewest/http-state-tokens#does-this-proposal-constitute-a-material-change-in-privacy-properties
copy/pastes some words from earlier in these threads. I'll attempt to
explain it more clearly if I get to the point of writing out a more formal
spec for this proposal.

>   browsing sites with which I don't have a relationship

These two seem to be inextricably bound together, as it seems likely to me
that intentionally stateless operations on the web today are few and far
between. Basically everything interesting we do on the web today requires
state of some kind to bind HTTP requests together, even when that state
isn't explicitly user-focused (see the discussion of routing metadata Willy
raised earlier in
https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0203.html).

That said, it seems like many sites that don't require an authenticated
session do _work_ without cookies, and it seems like user agents could give
users more control over when they'd like to be in that explicitly
unauthenticated state. I'm not sure what impact that would have on the
technical mechanism by which the user agent informs the server about the
user agent's state, however. It seems like we'd still want a session
identifier of some sort for the times when a user is visiting a site in a
stateful way.

>   researcher to figure out clever ways to spot abuse)

What's abuse? I'm sure we all have pervasive monitoring in mind, and I'm
sure many have advertising/tracking in mind as well. I don't think we have
a good, shared grasp on where the line is, however. Re-identifying a user
over time as they make subsequent connections to an origin might be a
perfectly reasonable thing to do! It might also be a terrible thing to do,
depending on context. I'd like to understand how

> then maybe it'd also be attractive to UAs.

Performance seems tangential to the underlying questions here. Anecdotally,
web pages are slow because developers deliver megabytes of JavaScript with
every page load. Shifting that incentive is critical to the web's success,
and seems to utterly swamp the benefits of reducing the connection overhead
that things like cookies have introduced.

I think there's an argument to be made for "stateless" connections from a
privacy perspective, but I think it's unlikely to be justifiable from a
performance perspective.

> identifiers when needed (making 'em longer as needed)

These certainly seem like reasonable places to compromise.

> starts to sound a bit like the quic connection ID

It would certainly be possible to introduce some sort of rotation scheme.
What benefit would that provide, with regard to the privacy properties
discussed above? Surely a server with interest (financial or otherwise) in
re-identifying a user over time would do the work to support whatever
rotation scheme we introduced? Is the mitigation aimed against
unintentional re-identification, rather than the abuse cases?

> if turning off cookies worked well more often, then I

I'm pretty explicitly aiming towards something that could replace cookies
in the long run. My hope is that by introducing something with properties
the user agent more explicitly controls, we'll be able to collectively
start more aggressively ratcheting down on cookies' behaviors in the medium
term. Even if all that we can agree upon is that cookies are bad, that
seems like an outcome that we could both celebrate.

Thanks!

-mike

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 11:10:40 +0200

> saying that was Mike's proposal though.)

IMO, users must always have the ability to opt-out of sending this
identifier to any entity, just as they do with cookies today. User agents
should likely aim above that bar, but an opt-out is the bare minimum.

It also seems reasonable to either (a) give servers the ability to opt-out
of an identifier which the user agent creates by default, or (b) give
servers the ability to opt-into an identifier which the user agent does not
create by default. It seems to me that (a) is more practical if we want to
get away without letting the server control the identifier's value and
without exposing the value to JavaScript, as the server would otherwise be
unable to bind the initial request with subsequent requests. That said, (b)
is by no means out of the question, and I'm sure we could make it work with
some efficiency loss if that's the direction we end up deciding to run in.

> > leak information on the local machine (hacked/lost/discarded).

Indeed.

Thanks!

-mike

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 11:19:06 +0200

>      Javascript can not add that header.

In a browser context, I'm imagining that a Service Worker would handle this
state change, and could ping back to the server if desired in order to
update any backend. I'm not sure why it would be desirable to bake such a
ping into the user agent itself. What use cases do you think it would serve?

> So looks like uniqueID should not automatically generated before

This question is captured in
https://github.com/mikewest/http-state-tokens#opt-in, and it seems to me
that there are reasonable arguments on both sides. I fully agree that we'll
need to hammer it out one way or the other.

>   is uniqueID always combining different porposes ?

We don't have consensus on this point (nor, really, do we have consensus on
whether a "purpose" is a reasonable thing to add in the first place! :) ).

I believe Rigo's proposal in
https://github.com/mikewest/http-state-tokens/pull/2 is to bind multiple
purposes to a single identifier. I think we'd be better served if the user
agent minted distinct identifiers for a (very) small number of purposes
whose intentions are publicly described. Either way, there's room for
healthy debate on the topic.

-mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 09:21:03 +0000

--------
In message <CAKXHy=eVOjyXa8+iLrXt8AYtFj1wDPrp_ZQAHjX3f4U_=[email-masked]>

>should likely aim above that bar, but an opt-out is the bare minimum.

My original proposal was that this identifier is 100% under the
clients control, and that one bit is a courtesy bit where the
client signals if it intends this to be a permanent session or an
ephemeral/temporary session.

As a starting point, browsing in private mode would set the bit
to ephemeral, browsing in normal mode would set it to permanent.

But obviously the user should have a way to say "always send
ephemeral id's to $ADNETWORK" etc.

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 11:36:34 +0200

On Mon, Aug 27, 2018 at 11:21 AM Poul-Henning Kamp <[email-masked]>
wrote:

> clients control

This is the proposal I put forth in the explainer document as well. It
sounds like there's some interest in letting the server set some number of
bits at the front of the identifier for routing, etc. and I can see how
that would be helpful, but I think there's a strong case for complete
client-side control.

> , and that one bit is a courtesy bit where the

I'm still not convinced that this is a good idea. :)

> ephemeral id's to $ADNETWORK" etc.

My impression is that folks are generally happier sending no identifier at
all when opting-out of advertisers' tracking (or an explicit "0" in the
case of platform-level advertising identifiers like we see on iOS and
Android), but randomizing on every hit is certainly something we could
consider doing.

-mike

---

From: Rigo Wenning <[email-masked]>
Date: Mon, 27 Aug 2018 11:38:11 +0200

On Monday, August 27, 2018 11:19:06 AM CEST Mike West wrote:
> https://github.com/mikewest/http-state-tokens/pull/2 is to bind
> multiple purposes to a single identifier. I think we'd be better
> served if the user agent minted distinct identifiers for a (very)
> small number of purposes whose intentions are publicly described.
> Either way, there's room for healthy debate on the topic.

My suggestion was actually the contrary: To bind identifiers to a 
certain class of purposes (one purpose). 

The problem with purposes is that there is an infinite number of 
them. But we also have purposes that are relatively common. I want 
to cover those first. Even though this sounds like multiple purposes 
I want to clarify here that this could also mean one identifier per 
purpose (or class thereof). 

Because IF we have a purpose stated in a specification or 
description, using that identifier for a different purpose (e.g. 
cross-site tracking) is then triggering the potential for legal 
actions in most countries except in the US. 

 --Rigo

---

From: Rigo Wenning <[email-masked]>
Date: Mon, 27 Aug 2018 11:45:05 +0200

On Monday, August 27, 2018 11:01:45 AM CEST Mike West wrote:
> These two seem to be inextricably bound together, as it seems
> likely to me that intentionally stateless operations on the web
> today are few and far between. Basically everything interesting
> we do on the web today requires state of some kind to bind HTTP
> requests together, even when that state isn't explicitly
> user-focused (see the discussion of routing metadata Willy raised
> earlier in

Just a small remark: Most of the stateful interaction in plain 
content browsing (HTML4.01) is required to measure outreach to 
justify cost of advertisement or to make statistics. There could be 
a much smarter way to allow a less identifiable way of measuring 
audience. Maybe we would even manage to do that while the service 
remains stateless. 

 --Rigo

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 11:48:52 +0200

> certain class of purposes (one purpose).

Then I misunderstood your PR, apologies.

> purpose (or class thereof).

That sounds reasonable to me, with the caveat that because there are an
infinite number of purposes with an infinite amount of granularity, I do
not want to put user agents in the position of mediating all of them. It
makes more sense to me for user agents to circumscribe a set of purposes in
a general topic area ("authentication" and "advertising" both seem like
reasonable levels of granularity to me), and mint distinct tokens for each.
It makes much less sense to me for user agents to accept arbitrary purposes
and mint distinct tokens for each; that's basically the status quo, with
the minor change that we'd have renamed "cookie's name" to "token's
purpose".

> actions in most countries except in the US.

I'll defer to lawyers on legal questions, and note instead that providing a
well-lit path gives user agents the ability to put fences in place that
keep folks on said path.

-mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 10:02:32 +0000

--------
In message <CAKXHy=[email-masked]>

>that would be helpful, but I think there's a strong case for complete

Historically pretty much anything the server has ever had any amount
of control over has been used to track users across the network,
so there is a very strong case for not making the same mistake
again, and give the client complete control.

>Android), but randomizing on every hit is certainly something we could

This is where I take the servers side.

I want it to be random to give the server-sandwich has something
to route on, and I want to mark it ephemeral so that servers can
avoid storing session state that will never be reused.

Ideally the server would prefer the client to say "I'm leaving,
you'll never see this session again", but I doubt that would be
reliable enough.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 10:09:53 +0000

--------
In message <2594476.hbmTAoiaoX@hegel>, Rigo Wenning writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>justify cost of advertisement or to make statistics.

This is where it is important to remember that they are called
"Human Rights" and not "Business Rights" :-)

Privacy is much more important than being able to optimize profit.

---

From: Rigo Wenning <[email-masked]>
Date: Mon, 27 Aug 2018 12:14:35 +0200

On Monday, August 27, 2018 12:02:32 PM CEST Poul-Henning Kamp wrote:
> Historically pretty much anything the server has ever had any
> amount of control over has been used to track users across the
> network, so there is a very strong case for not making the same
> mistake again, and give the client complete control.

And a lot of business cases are totally dependent on this. My 
suggestion is NOT to be disruptive, but to create a new identifier 
and keep cookies for those. Over time, people will use to the new 
identifier as it will be easier to handle and more reliable and 
easier in GDPR compliance etc. Remember that people erase their 
cookies at least once a month nowadays. Carving out easy good use 
cases (like authentication) and leaving the others with the broken 
cookie world is the basic idea why I jumped on the bandwagon.

 --Rigo

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 10:20:56 +0000

--------
In message <4165429.BoAPEO5tno@hegel>, Rigo Wenning writes:
>And a lot of business cases are totally dependent on this.

I don't see anything in the UN Human Rights Charter about
business cases ?

>Remember that people erase their cookies at least once a month nowadays.

They do ?

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 12:52:34 +0200

On Mon, Aug 27, 2018 at 12:02 PM Poul-Henning Kamp <[email-masked]>
wrote:

> --------
> In message <CAKXHy=
> [email-masked]>
> , Mike West writes:
>

Agreed. I don't actually think you and I are arguing on this point. :)

> you'll never see this session again", but I doubt that would be

I see. You're not suggesting that the identifier would be changed on every
request, but after some period of time (e.g. after the user's private
browsing session ended), and that the ephemerality signal is a nice way to
let servers know that they can drop the session information after some
reasonable period of time.

I'm not sure user agents would want to advertise to servers that users are
in such a mode, as it seems like there would be consequences to doing so
(e.g. "We've noticed that you're visiting us ephemerally. How unfortunate!
Please opt back into persistence to read the next page."). Is there an
advantage to the user in this situation?

-mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 11:20:55 +0000

--------
In message <CAKXHy=[email-masked]>

>reasonable period of time.

I'm sure there is a browser-world word for this, but I don't know it,
so you will have to suffer a long-form description:

I would expect an ephemeral ID to be forgotten when:

A)  I close the browser or tab

B)  Enter a new URL

C)  Go to a bookmark

D)  In any other way indicate that I'm done with this site.

>advantage to the user in this situation?

Valid point.

But we are not seing this with DNT or private browsing mode, are we ?

I would expect it to be preferable to show "unoptimized" ads or make
a sale, rather than reject users at the front door with no economic
benefit ?

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 13:46:41 +0200

On Mon, Aug 27, 2018 at 1:21 PM Poul-Henning Kamp <[email-masked]>
wrote:

> --------
> In message <CAKXHy=
> [email-masked]>
> , Mike West writes:
>

We are. Visit the Boston Globe in private mode, for example (e.g.
https://www.bostonglobe.com/news/nation/2018/08/26/mass-shooting-reported-jacksonville-fla/q17XvjlR2Aj6jfk4CuIcXN/story.html,
the current top story).

> a sale, rather than reject users at the front door with no economic

You would think that, wouldn't you. My impression is that that's not
exactly how it's playing out.

-mike

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 27 Aug 2018 13:45:46 +0200

> again, and give the client complete control.

As one user of those server-controled bits where I place the ID of
the server the load balancer decides to send the traffic to, I
disagree on this point. The client cannot have complete control
of its routing for the simple reason that it does not have all
the elements to take the routing decisions in the middle. Keeping
enough bits to be able to accurately pick a server among a few
hundreds to a few thousands is largely enough for the vast majority
of load balancing architectures where this matters, without leaving
enough bits to draw immediate conclusions about who's coming back.

I disagree with breaking what makes the infrastructures reliable for
the sake of preventing tracking, while much more advanced tracking
than what cookies permit is already possible and much scarier [1]
[2].

Let's instead focus on what is *really* needed. The benefits of
server-initiated cookies are :
  - for security, expected better randomness providing identifiers
    that resist better to brute-force attacks than those created
    from poor entropy clients which are trivially guessable ;

  - ability to pass routing decisions back and maintain consistency
    between requests belonging to a same session even when the size
    of the farm changes ;

The downsides are that these identifiers tend to live much longer
than a session and that because of this they allow user tracking to
be performed.

For long-lived sessions (those which actually also happen to track
all of us), letting the client choose an identifier can make things
even worse because it will make it impossible to only set some
unimportant preferences in a cookie (eg: user-prefers-dark-background)
and will force the server to store all of these information associated
to the client's ID into a database. This means that in addition to
requiring more storage, it will new create very attractive data
collections of all visitors' preferences. Guess what you'll find there?
Since it comes with a cost, the cost will be amortized by the amount of
extra data stored there while only a background color was needed.

In my opinion the root cause of the problem comes from the fact that
historically, a cookie with an expiration date was a permanent cookie
while a cookie without was a session cookie. Nowadays, browsers are
not closed anymore (smartphones, suspend-to-ram, etc), so sessions last
forever. We could address this by having an attribute on session cookies
indicating how long they should last, and letting the user choose in his
browser how soon to expire them.

Seeing a small "W" in a circle at the top right of my Google search
window irritates me as much as seeing my linkedin avatar in front of
the comment field of certain sites. Just for this I'd like to be able
to control the maximum duration of session cookies. I'd like to see
these sessions end even when I don't click "logout". Ideally over time
we should expect browsers to emit a warning when a site wants to place
a cookie without an expiration date. This alone would be a good incentive
against infinite session cookies.

And ideally we'd need to support an end-of-session signal for applications
to send to clients. In load balancing, this is a big problem because you
often want to destroy the stickiness cookie as fast as possible to optimize
the load balancing, and you don't always have the information. Being able
to pass this information on the login page, the logout page or even the
"session timeout" page would significantly help, as it could allow the
browser to destroy all associated cookies at once.

In conclusion, I'd say that there's fortunately many more clean and valid
use cases for cookies than there are bad ones, and that the bad ones can
very likely be addressed without breaking the good ones. We must not create
a void somewhere or something else will fill it (including redirects to
$random_id.domain.tld using wildcards, making you even more traceable).

Regarding the load balancing space, I'm fine with having a few bits to
assign a server. As a user I *don't* want my browser to make my bank
session's privacy depend on a potentially poor random and in any case
I would very much like my browser to be able to automatically forget
session cookies without having to open so called "private browsing"
windows each time I have to use a different account somewhere.

Regards,
Willy
---
[1] https://github.com/ben174/hsts-cookie
[2] https://github.com/cyph/hpkp-supercookie

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 11:57:22 +0000

--------
In message <CAKXHy=[email-masked]>
, Mike West writes:

>We are. Visit the Boston Globe in private mode, [...]

Works for me, but that's maybe because I'm in GDPR-land ?

>exactly how it's playing out.

I still think we should let clients set the "ephemeral" bit as appropriate.

If servers react negatively to that, they automatically self-declare
as not respecting the clients desire for privacy, and that seems
the best outcome:  It leaves the initiative with the client who
gets to decide if they want to be tracked or want to boycott the
sites that do so.

---

From: Mike West <[email-masked]>
Date: Mon, 27 Aug 2018 14:05:57 +0200

On Mon, Aug 27, 2018 at 1:57 PM Poul-Henning Kamp <[email-masked]>
wrote:

> --------
> In message <CAKXHy=
> [email-masked]>
> , Mike West writes:
>

Idunno.
https://arstechnica.com/information-technology/2017/05/boston-globe-website-no-longer-lets-you-read-articles-in-private-mode/
has a screenshot of what I saw. Perhaps they have some heuristics around
the blocking behavior?

> gets to decide if they want to be tracked or want to boycott the

That's a reasonable argument. I think I fall on the other side, suggesting
instead that user agents should attempt to make private browsing appear
similar-enough to regular browsing so as to remove the ability to treat
them differently, rather than attacking the incentives.

Either way, I think assigning meaning to particular bits in the identifier
is something user agents could certainly choose to support.

-mike

---

From: Roland Zink <[email-masked]>
Date: Mon, 27 Aug 2018 15:31:45 +0200

Boston Globe doesn't let me read the article in private mode although 
I'm in GDPR-land.

Roland

Am 27.08.2018 um 14:05 schrieb Mike West:
> On Mon, Aug 27, 2018 at 1:57 PM Poul-Henning Kamp <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     --------
>     In message
>     <CAKXHy=[email-masked]
>     <mailto:[email-masked]>>
>     , Mike West writes:
>
> has a screenshot of what I saw. Perhaps they have some heuristics 
> around the blocking behavior?
>
> That's a reasonable argument. I think I fall on the other side, 
> suggesting instead that user agents should attempt to make private 
> browsing appear similar-enough to regular browsing so as to remove the 
> ability to treat them differently, rather than attacking the incentives.
>
> Either way, I think assigning meaning to particular bits in the 
> identifier is something user agents could certainly choose to support.
>
> -mike

---

From: Daniel Veditz <[email-masked]>
Date: Mon, 27 Aug 2018 08:32:25 -0700

On Mon, Aug 27, 2018 at 5:05 AM, Mike West <[email-masked]> wrote:

> Idunno. https://arstechnica.com/information-technology/
> 2017/05/boston-globe-website-no-longer-lets-you-read-
> articles-in-private-mode/ has a screenshot of what I saw. Perhaps they
> have some heuristics around the blocking behavior?
>

My ad blocker appears to be blocking the script which complains about
private mode. Ironic if their complaint-wall drives more privacy-concerned
folks into full-blown ad blockers, though I'm sure it will since that's the
path I followed.

-Dan Veditz

---

From: Rigo Wenning <[email-masked]>
Date: Mon, 27 Aug 2018 17:59:17 +0200

> Privacy is much more important than being able to optimize profit.

Before doing the trade-off weighing, I'm inclined to avoid a 
situation where we have to make trade-offs. But I agree that some of 
the excesses will have to be cut out to make it work. My work on DNT 
has given me a good overview on the landscape of actors. Some of 
them will only give in to hard blocking.

 --Rigo

---

From: Rigo Wenning <[email-masked]>
Date: Mon, 27 Aug 2018 18:07:50 +0200

On Monday, August 27, 2018 2:05:57 PM CEST Mike West wrote:
> suggesting instead that user agents should attempt to make
> private browsing appear similar-enough to regular browsing so as
> to remove the ability to treat them differently, rather than
> attacking the incentives.

I think we are diluting the discussion about the identifiers here. 
Because if the user wants to indicate tracking preferences, they can 
already do so with the DNT-header. (I still think the UX for that 
token needs major improvement). No need to re-invent that, perhaps 
just start using it. (And DNT:0 (allows tracking) in private mode is 
an interesting combination)

I think we should stick to the ID and purpose discussion. Because 
IMHO and AIAL, this will serve data protection/self determination 
the most. (Yes I deliberately did not use "privacy"). 

 --Rigo

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 27 Aug 2018 16:57:39 +0000

--------
In message <CADYDTCCcnFJnxSXwrW=[email-masked]>

>folks into full-blown ad blockers, though I'm sure it will since that's the

That could be it for me too...

Speaking of commercial opportunies and decisions:  latimes.com has
been inaccessible to EU since GDPR went into effect...

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Aug 2018 06:15:55 +0000

--------

>the most. (Yes I deliberately did not use "privacy"). 

Having slept on it, I have come to the conclusion that nothing
is really gained by the client informing the server that a
given session ID is to be permanent or transient.  Please forget
that idea.

So just to make sure we are on the same page here:

* The session-ID lives and dies with a single "UX session"
  (Ie: when the user moves to another site by means exterior
  to the shown content, bookmarks, type URL, close tab etc.
  the session-ID is thrown away.)

* A separate session-ID is used for each server contacted in a "UX
  session" (ie: www.example.com, img.example.com, example_com.cdn.com
  gets three different session-ID's)

If so, I am not opposed to the server sending back a routing-ID to
be used for subsequent requests in the same "UX-session" and to
be thrown away with the session-ID

---

From: Mike West <[email-masked]>
Date: Tue, 28 Aug 2018 08:20:52 +0200

>   the session-ID is thrown away.)

If the user agent supports a transient session mechanism of some sort, then
yes, I'd expect the identifier to be cycled whenever the user agent
believes that a "session" has ended. I'm not sure it makes sense to specify
that in great detail, given the diversity of user agents and their
propensity to have different ideas about what's best for their users.

>   gets three different session-ID's)

The current proposal is indeed origin-scoped. Each of these hosts wold
receive a distinct value.

> be thrown away with the session-ID

Are you intentionally distinguishing "routing-ID" and "session-ID"? If so,
what is the former?

-mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Aug 2018 07:20:10 +0000

--------

>propensity to have different ideas about what's best for their users.

I don't know about "great detail", but it is important to make it clear
that browsers SHALL NOT make it persistent across what users think of as sessions.

>Are you intentionally distinguishing "routing-ID" and "session-ID"? If so,

It's sort of in between what Willy called for in <[email-masked]>
and what you have in your point 3 (token provenance).  I might go something like:

	server sends:

		Sec-HTTP-State-Options: ..., route=*UGxlYXNlIHVzZSBlbnRyYW5jZSAjMwo=*
	
	and the client echoes this in future requests:

		Sec-HTTP-State: token=*...*, route=*UGxlYXNlIHVzZSBlbnRyYW5jZSAjMwo=*

	The client throws the route= token away with the session-id.

This way a CDN can assign you a random(-ish) backend server on first request, and
use the route-ID to make sure all your subsequent requests end there too,
without the CDN having to hold state on all the client session-IDs.

The crucial point is that the client throws this route-id token away with the
equally transient session-id, so the server cannot use it to track you.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Aug 2018 17:25:24 +1000

Resetting on this, because I want to make a meta-level comment after
having spent some time thinking about it more.

There are three classes of problems that the write-up claims to be
addressing: Security, Inefficiency, and Privacy.

Security:

Cookies aren't well scoped in several ways.  This will be a theme I
get back to, particularly the origin-scoping thing, but there are two
things that directly read on CSRF that are fairly compelling.  It's
sad to see that HttpOnly is still so rarely used and that script can
often read cookies when it shouldn't be able to.  And I'm not going to
defend the use of cookies without Secure.

HttpOnly using being at sub-10% is a warning sign we should probably
pay attention to.  It suggests that attempts to deploy this sort of
mitigation aren't failing for lack of mechanisms, but from an absence
of the right incentives.  It would be interesting to see whether
document.cookie is really used that much and to see if there were ways
to close it off (CSP is an obvious path here), but this is a primarily
a problem of incentives.  Sites are completely in control of this.  In
other parts of the industry, you would throw some combination of
linting and public awareness campaigns at this class of problem.  You
might also do things like change the default in common server
containers and stacks.

The Secure problem is fixed by moving more to HTTPS and HSTS, pure and
simple.  I don't see much point in looking for alternative solutions
for this class of problem.

Inefficiency:

Here, I can't really bring myself to care.  Inefficiency is annoying,
but I'd rate cookie bloat pretty low on the list.  And this is
entirely in the control of sites.  This does have some small effect on
performance, but I'd rather tackle this one as part of making sites
more responsible for their bad practices.  My understanding is that
cookie size isn't that big a contributor to performance woes in
comparison to things like video, images, bloated JS frameworks, fonts,
then maybe kitchen-sink CSS.

Privacy:

The first thought when I saw this was "great, progress". And then I
watched a presentation on cookie matching and real-time bidding [1].
That reminded me that as long as we have incentives in place and poor
technical defenses, this is likely to be an effective privacy measure
either.  As long as sites can each get their own identifier, and that
identifier is stable for a given origin as the top-level browsing
context visits different pages, then the trackers can match up
identifiers.  The research I saw found most identifier matching
happens via URL parameters on redirects, but bigger networks are able
to use back-end systems to link identifiers.

In terms of privacy, I hold hope for two technological mitigations:
content blocking, and double keying.  Content blocking because it
means refusing to talk to bad actors.  Double-keying cookie stores by
top-level browsing context and target origin is probably less crude in
terms of collateral damage to those systems that rely on cookies
(though that might derive more from selective application to "ads" or
"trackers", than from any inherent property). The ultimate defense
probably also relies on fingerprinting resistance, but we're still
working up to a solid defense there.

The problem with any attempt to break linkability of identifiers is
that you need to break the link at every layer of the stack.  When you
change one identifier, you need to change all of them.  Double-keying
might work better because it changes cookies - and all storage - for
all origins when the top-level context changes origin.  This is a hard
problem, because we often rely on example.com being able to access a
shared context when accessed from x.example and y.example.  Login
flows often depend on this.  It's also imperfect as a defense because
information can flow across top-level navigations (again via URL
parameters), and we've ample evidence that redirect chains at that
level will be used if other methods are taken away.

Techniques like what has been proposed here, when deployed in
isolation, might be a stepping stone toward a grander plan, but this
doesn't seem to be part of any strategy I can conceive of (if I missed
something, feel free to enlighten me).  Right now, I see more hope for
measures that focus on narrowing the scope of applicability of
cookies.  That means double-keying, but it also includes things like
narrowing the time over which cookies are stored (millenia is a joke)
as we've discussed for insecure cookies, and stopping their
propagation across origins in various ways.

Part of the problem here is that you aren't willing to break any use
cases [2].  But as long as those use cases align with things like
tracking, I think that we ultimately need to consider some classes of
breakage to be on the table.

So, I've concluded that there is no motivation in favour of this
proposal.  I'm not really happy saying that, because cookies are
terrible and awful and in desperate need of fixing, but there it is.

[1] https://www.youtube.com/watch?v=GLvug8jdges
[2] https://developers.google.com/authorized-buyers/rtb/cookie-guide
is definitely a use case.  As is federated sign-on.  Both exploit the
same properties.

---

From: Mike West <[email-masked]>
Date: Tue, 28 Aug 2018 09:34:17 +0200

On Tue, Aug 28, 2018 at 9:20 AM Poul-Henning Kamp <[email-masked]>
wrote:

> --------
> In message <CAKXHy=
> [email-masked]>, Mike West
> writes:
>

That makes sense.

> without the CDN having to hold state on all the client session-IDs.

What lead you to accept the server setting a value, rather than the value
being completely client-controlled (as it seemed like we were agreeing upon
yesterday)?

> equally transient session-id, so the server cannot use it to track you.

If we accept the server controlling some value on the client, did you
consider embedding the routing information in the first X bits of the
identifier? That would make it quite clear that the routing information
would be discarded when the identifier was rotated.

-mike

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Aug 2018 10:05:49 +0200

Hi Martin,

On Tue, Aug 28, 2018 at 05:25:24PM +1000, Martin Thomson wrote:
> But as long as those use cases align with things like

In my opinion every hard-breakage makes the situation worse. Look at
the result of the GDPR crap : as already anticipated, it's impossible
to access any simple web site without having to click multiple "I accept
to swallow everything" buttons. It's become a real pain. Has it improved
privacy ? Surely not, it's got worse. In 3 months we've been trained to
click everywhere without thinking anymore. And worse, some sites are now
delivering a cookie to know that they asked you the question! Every time
we try to enforce solutions the hard way, we make the end user experience
even worse. Those of us who remember the web in 1999 with "this site is
best viewed with MSIE" or "site designed for 800x600" should realize how
much worse the experience has become since then, mainly over the last few
years, with alerts and ask-for-consent pop-ups everywhere.

What (in my opinion) works is raising awareness to the end user and
leaving him the choice, because in this case the sites operators have
an incentive to try to be better than the competitor in terms of UX,
instead of being forced by law to be as bad.

Some simple examples that come to my mind and which could improve the
situation already :
  - when a site delivers a cookie with "too long" a duration, ask the
    user if he's willing to accept it or to trim the duration to a
    shorter one. Let the user configure the max duration before warning.
    Sites will learn that the shorter the duration, the least number of
    irritated people they have, pretty similar to the response time or
    lack of HTTPS these days.

  - when a tab is closed with session cookies in it, ask the user what
    to do with these cookies. This way we'll train users to use the
    "logout" button of the site before closing tabs, and sites to purge
    cookies on logout. This is much more powerful for privacy and
    confidentiality than just trying to redefine cookies.

  - support a maximum duration on session cookies, and offer the choice
    to the user to override it. This problem is not new, we already had
    to work around it in haproxy many years ago because some mobile browsers
    would stick for too long to the same server, thus we encode an expiration
    date in the cookie value to force it to be ignored. It would be way better
    if it could be done by the browser : it would both solve a technical
    problem *and* improve privacy. I even suspect that some users will want
    to have the ability to control the maximum cookie's life and idle time
    by domain. By the way, in haproxy we support both idle and life time,
    which allows a cookie to be dropped past a certain age, or after some
    inactivity period. Typical sites using it for load balancing set the
    max age to around a week and maximum inactivity to around 8-12 hours.
    This can perfectly make sense for applications as well.

  - add the ability for server-side equipments to purge *all* cookies
    for the same domain ; right now it's extremely complicated for an
    edge component to emit a response asking to purge all cookies upon
    a logout page, while I think the browser easily knows all of them.
    Thus if the front load balancer could detect the logout page and emit
    a "set-cookie: *=" or something like this to mention that all known
    cookies for the site must be purged (possibly before a specific date
    or only session cookies), that would greatly help framework and
    infrastructure component authors to perform some cleanups by default.

These in my opinion are very low hanging fruits which can already improve
the situation a lot, first by giving the control back to users, second by
creating incentives for site operators to try to appear better than others
instead of just saying "I'm forcing you to accept these terms because I'm
required to by the laws of your country".

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Aug 2018 18:56:09 +1000

On Tue, Aug 28, 2018 at 6:05 PM Willy Tarreau <[email-masked]> wrote:
> to swallow everything" buttons.

As much as I find the "consent" provisions in the GDPR meaningless and
annoying, I don't think that we improve things by loading more
decisions like this on the people who are least empowered, informed,
equipped, or inclined to deal with those decisions.  For instance, if
we think that a cap on duration is sensible, browser-makers can
implement that cap.  Asking questions tends to lead more to social
engineering than it does positive results.

So yeah, this isn't easy.

---

From: Daniel Veditz <[email-masked]>
Date: Tue, 28 Aug 2018 10:02:34 -0700

>     shorter one. Let the user configure the max duration before warning.

No asking! Opinionated browsers could do this today if they wanted to, but
it should not ask the user! Of course there should be a way for a user to
modify the default max in with other cookie settings.

>     to do with these cookies.

No asking! If we think the current session lengths aren't working browsers
are free to re-define it. We could even propose modifications to the spec
to recommend definitions of a "session".

It's hard to believe that a post that starts out decrying all the GDPR
prompts is proposing more prompts.

>     for the same domain ;

You might be interested in https://w3c.github.io/webappsec-clear-site-data/

I believe Chrome already supports this. Firefox will be shipping support in
October (testable on nightly now, beta in a couple weeks).

-
Dan Veditz

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Aug 2018 19:14:34 +0200

> modify the default max in with other cookie settings.

Quite the opposite in fact : asking *is* useful, it's what pisses off
users and encourages sites to be careful not to piss them off. You just
want to ask this when it's above the configured threshold.

> We could even propose modifications to the spec to recommend
> definitions of a "session".

This would be an immense help.

> prompts is proposing more prompts.

The difference is that these are prompts that are easy to fix (both
by site operators and the users). The GDPR crap is unfixable by the
user and unfortunately often unfixable by the site as well depending
on their multi-tier architecture, without having to redesign it. By
the way sometimes browsers are pressuring you hard to give them all
your passwords by asking you all the time "remember password ?" where
you can only reply "not for this site" or "not now" but not "never",
it's terribly painful, and quite sad from a security perspective as
it further complicates users education. But I'm resisting.

> You might be interested in https://w3c.github.io/webappsec-clear-site-data/

Oh, very interesting, I wasn't aware, thank you very much! I'm adding
the link to my todo list :-)

Willy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Aug 2018 11:38:40 +1000

> want to ask this when it's above the configured threshold.

Asking has a real cost and we are very careful not to do that if we
believe that it will result in bad answers.

How many people would be inclined to click on a blue box that said
"Acknowledge" next to a notice that was framed as a cookie warning
that instead said:

"This site uses cookies.  We make every effort to use best practices
for building this site to modern privacy standards, but we also sell
all the information we collect such as names, addresses, and credit
card details to anyone we please, a list of whom you can find
described in more detail in our lengthy _privacy policy_.  [
Acknowledge   ]".

Who would believe that this comprised meaningful consent to those practices?

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Aug 2018 04:13:58 +0200

> believe that it will result in bad answers.

I know and my suggestion is to ask only when cookies have too long
validity duration, and the question should not be about "yes/no" but
"this site uses abnormally long-lived cookies that allow to track your
activity on 3rd party sites. What maximum duration do you want to apply
to such cookies ? [ session | 1 day | 1 week | 1 month | 1 year | unchanged ]".

> Who would believe that this comprised meaningful consent to those practices?

It's almost what we're asked to validate today with GDPR. Some allow you
to choose what to share, others only allow you to click on accept :-/
That's why I don't just want "yes/no".

Willy

---

From: Mike West <[email-masked]>
Date: Wed, 29 Aug 2018 10:07:15 +0200

Hey Martin! Thanks for the thoughtful critique!

(This response will likely be quite long, apologies. I'll trimming much of
the detail in your response to get to what I think are the high-level
points. If I cut out something you think deserves additional attention,
point it out!)

> Security:

I think we agree that the proposal we're discussing has better security
properties than cookies. I think your central claim here is that we should
spend our time trying to get developers to use cookies more securely rather
than spending our time trying to get developers to use something new with
better defaults.

In my opinion, the latter is more likely to be successful, given the usage
data we see in the wild today, and the fact that security experts have been
banging on about things like HttpOnly for quite some time. That, of course,
is a pretty reasonable conclusion to argue about, and I look forward to the
conversation! :)

> get back to, particularly the origin-scoping thing

You focus below on the privacy-focused aspects of cookie scoping. Here,
though, I think you underplay the security value of shifting to an
origin-scoped model. There are real use-cases for origin-scoped cookies, as
the meagre use of the `__Host-` prefix seems to prove.

> of the right incentives.

I think the incentive problem is harder than you make it sound. My
impression is that developers _like_ being able to access cookies from
JavaScript. It allows a certain set of things to be done more conveniently,
skipping a round-trip to the server (consider Willy's
"user-prefers-dark-background"
example from a different thread). I don't think that a PR campaign, or
negative scores in https://observatory.mozilla.org/ are going to shift
incentives radically enough to cause change.

> It would be interesting to see whether
> to close it off (CSP is an obvious path here)

`document.cookie` is used often, at least in Chrome:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2195. I
suspect that a reasonable chunk of that ~75% is driven by analytics
packages that use cookies explicitly because they escape the origin
boundary, but that's just an intuition. Regardless, usage is high enough
that it's likely to be as difficult to deprecate `document.cookie` as
cookies themselves.

> for this class of problem.

User agents should certainly should push towards HTTPS everywhere, and I
would love for us to collectively make this argument non-unique by removing
storage entirely from plaintext pages. Chrome aims to experiment with some
ideas in this space and I'm sure other user agents have good ideas as well,
but it's going to take a while. In the meantime, having a well-lit path
with reasonable defaults seems valuable.

> Inefficiency:
>
> Here, I can't really bring myself to care.

This is a weak argument. :) I agree with you that cookie bloat is less
important to performance overall than the megabytes of JavaScript that some
pages require. I disagree strongly that it's not worth addressing the fact
that 1 out of 1000 requests is  ~10k larger than it needs to be.

Privacy:

This seems to be the core of your concern: the proposal doesn't do enough
to change the status quo with regard to tracking on the web.

> propagation across origins in various ways.

I'm culling the details you provided at the top of this section about how
cookies are used today, but one point I'd pull out is that tracking is
possible when first-parties collaborate. That is, even if third-party
storage was wiped out completely, it is quite possible to shift to passing
first-party identifiers in URL parameters (or, worse, partyless identifiers
like hashed email addresses or device fingerprints). I don't think that the
underlying HTTP state management mechanism has a dispositive effect on
tracking, except in terms of its convenience.

It is quite reasonable to make tracking less convenient, and I think this
proposal does so by stripping JavaScript access to underlying token, by
requiring same-site and explicit declaration that a token should be
delivered cross-site, by origin-scoping the tokens, and by removing
servers' control over their value.

I agree with you that it doesn't solve the problem you're pointing to, and
agree that it's a good idea for user agents to continue exploring options
to make both explicit and implicit identifiers less available than they are
today. Whatever strategies we come up with for limiting access to cookies
would likely be quite applicable to this mechanism as well.

(P.S. Capping cookies' lifetime seems totally reasonable to me. As you
note, we have concrete proposals for non-secure cookies
<https://github.com/mikewest/cookies-over-http-bad> on the table. I
wouldn't be sad if we were able to expand those to include all cookies.)

> breakage to be on the table.

I think the diversity of use cases is actually an argument for the variant
of this proposal
<https://github.com/mikewest/http-state-tokens#just-one-token-really> that
would shard the identifier into promulgated purposes. That is, it might be
helpful if user agents were able to provide an identifier for
authentication, and a distinct identifier for things like advertising,
treating both differently with regard to lifetime, availability, and scope.
Some policy folks here and elsewhere believe that could have an impact on
reasonable actors.

> terrible and awful and in desperate need of fixing, but there it is.

I agree with your indictment of cookies, but disagree with your conclusion
that this proposal has no motivation. It has better security properties, it
provides a migration path that we can point folks to while ratcheting down
on cookies over time (making it more likely that we can _successfully_
deprecate them), and puts user agents in control of explicit identifiers in
a way that they aren't today. It also seems like a simpler story to tell
developers: "Use this thing. It's good." as opposed to "Rename your
cookies. And add several attributes. Also remove an attribute." I think
it's worth my (our?) time to work through in a little more detail.

Thanks again! I enjoy the conversation!

-mike

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 29 Aug 2018 18:05:54 +0900

>> modify the default max in with other cookie settings.

 From everything I have heard about users and browsers, my guess is that 
users would blame the browser and switch to another browser.

That's true of general browsers, it might not be true of specific 
privacy-enhanced browsers (which is maybe what you mean with "opinionated").

Regards,   Martin.

---

From: Daniel Veditz <[email-masked]>
Date: Wed, 29 Aug 2018 09:52:51 -0700

On Wed, Aug 29, 2018 at 2:05 AM, Martin J. Dürst <[email-masked]>
wrote:

>>> No asking! Opinionated browsers could
>>> [impose a shorter max-age] today if they wanted to
>>>
>>

If it's too short, sure. The length would be a decision the browser vendor
ought to make carefully based on data and user studies. The default would
no doubt have to be longer than the more privacy-conscious users would want
which is why a user-adjustable setting would be nice. I'm confident users
wouldn't even notice a cap of a year, for example, and that's a lot shorter
than the many "expires in 2038" cookies I see. What about a month? Probably
fine. A week? I think users would start noticing and get annoyed. But
that's just guessing and such a decision shouldn't be based on guesses.

-
Dan Veditz

---

From: Erik Nygren <[email-masked]>
Date: Wed, 29 Aug 2018 13:25:19 -0400

> having spent some time thinking about it more.

I've also been thinking some on this and came to a similar conclusion as
Martin.
In particular, two big gaps we seem to face with Cookies today are:
* The defaults are generally unsafe (and/or surprising in ways cookies
differ from the Origin model).
* The available mitigations can only be applied when setting cookies,
meaning that sites/origins/domains have no way to control their exposure.

Ideally we'd find some way to transition to safer defaults, even if it
takes 10+ years to get there.  I suspect we'll have better luck if we can
provide a way to slowly migrate most sites to a safer default cookie
behavior than we'll have if we introduce a radically different programming
model (that may not cover many cookie use-cases).

Migrations to safer behavior are more likely to succeed if we have ways to
give service operators and application owners way of safely rolling out
those safer behaviors, rather than relying purely on client-side
deprecation.

One approach to consider would be to introduce an HSTS-style model to allow
sites to switch defaults to be more sticky in a stateful manner.  In
particular, to allow specifying that some of the rfc6265bis improvements
can be applied to a site in a sticky manner for some time period.

For example:

    Cookie-Limit: HostOnly; SecureDefault; ttl=604800

which would mean that for the next week cookies on that site would be
constrained to be host-only and the default would be "Secure".  Cookies set
on a broader domain would then not be sent to this origin, document.cookie
would be unable to set cookies with a Domain, and the default for HTTPS
cookies would be "Secure" even if that attribute was missing (or
maliciously removed, e.g., see resolved Chrome issue 244260).

Policy attributes to constrain behavior would be cumulative (ie, you can
add them with a TTL but they stick around until that TTL expires within
that context).

Operationally I'd expect operators would start with a low TTL for a policy
and crank them up over time.
(One could see extending this to also include properties such as a max
cookie lifetime.)

Having a mechanism such as this also means that site operators could start
to get behaviors such as "cookies-over-http-bad" without needing to wait
for browser adoption and/or without needing to enable HSTS.  The HTTP
cookie one is perhaps less compelling as HSTS exists, but there are other
controls like this where there may be a pattern of getting sites to deploy
a more secure profile for a bunch of years prior to client-side deprecation
of the less secure behaviors.

(There's been a discussion on the W3 AppSec forum around enabling servers
to constrain cookies to be site-specific.  This is somewhat of an
extrapolation from that.  On that thread Mike West indicated that CSP is
unlikely to get more added into it.  As a result it is unclear where the
best destination for something like this would be.  Given the special
history of cookies, a dedicated cookie-specific header/feature might almost
make sense.  I'm not sure if we'd be willing to put something like this
into rfc6265bis or if every little thing we add there will just make it
less likely to ever ship.)

      Erik

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Aug 2018 19:30:34 +0200

> that's just guessing and such a decision shouldn't be based on guesses.

Sure and really, expiring without activity and with activity are two
different things. From what I've seen and leading me to implement it in
haproxy, people are willing to support shorter inactivity times if they
have longer expiration times with regular activity. Typically one week
will be too short for many users as a maximum duration and many will be
fine with a month. But many users would be fine with one week (or even
3 days) of inactivity with a cap to one month in any case. This is a
safeguard for them that all the random sites they visit by accident or
after a search will forget them faster. The sites they care about are
visited often.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Aug 2018 09:42:23 +1000

On Thu, Aug 30, 2018 at 3:25 AM Erik Nygren <[email-masked]> wrote:
> One approach to consider would be to introduce an HSTS-style model to allow sites to switch defaults to be more sticky in a stateful manner.  In particular, to allow specifying that some of the rfc6265bis improvements can be applied to a site in a sticky manner for some time period.

See I like that idea. It maintains the existing pipeline for
production and consumption, but fixes the defaults problem without
adding a parallel mechanism.  The failure modes are scary though: if
you did rely on broader scoped cookies and didn't realize, then things
break (and the browser gets the blame, because it works in
$other_browser...).

I think that as long as certain cookies can opt-out (notSecure,
notHttpOnly), then it might work as well as an entirely new mechanism.

---

From: Mike West <[email-masked]>
Date: Thu, 30 Aug 2018 10:56:31 +0200

On Wed, Aug 29, 2018 at 7:25 PM Erik Nygren <[email-masked]> wrote:

> One approach to consider would be to introduce an HSTS-style model to
> allow sites to switch defaults to be more sticky in a stateful manner.  In

I think this is a good idea. I'm somewhat embarrassed that we let it drop
~years ago when mnot@ made a similar proposal, but adding this kind of
opt-in tightening is an important part of any migration story away from
today's morass into a better world.

I'd like to do this in addition to introducing a new thing. :)

> maliciously removed, e.g., see resolved Chrome issue 244260).

As Martin noted, this will likely not get substantial adoption unless we
have ways to carve out specific cookies in order to allow them to bypass
the kinds of default protections the `Cookie-Limit` header expresses. For
example, folks often rely on a cookie set at the apex of a registrable
domain in order to push sign-in state across subdomains. There are good
reasons to encourage folks to migrate to a more explicit SSO model, but
doing it all in one step will be a tough sell.

> less likely to ever ship.)

It's true that I don't want to put anything new into CSP. For completeness,
we also talked about Feature Policy as a delivery mechanism, but that
feature's developers aren't terribly interested in extending it past its
current focus on documents to include things like subresource requests.

A separate header makes sense to me. I'm not opposed to adding it to
rfc6265bis, with the caveat that it's already taken forever for me to find
bandwidth to work on that document. Now that +John Wilander
<[email-masked]> is joining in, perhaps things will go more smoothly?
Putting the header in a separate document seems equally reasonable, though
it might make it more difficult to introduce the kinds of `NotX` flags
we'll need.

-mike