Re: Some half-baked thoughts about cookies.

On Mon, Aug 27, 2018 at 10:02:32AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <CAKXHy=c5DhRq7b7xeH_7YHggL8vmJZYedSzAHLMtgqe4yv-gLA@mail.gmail.com>
> , Mike West writes:
> 
> >> My original proposal was that this identifier is 100% under the
> >> 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.
> 
> 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.

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

Received on Monday, 27 August 2018 11:49:49 UTC