Re: Fixing cookies (Re: Some half-baked thoughts about cookies.)

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

On Tue, Aug 28, 2018 at 9:25 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

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


> Cookies aren't well scoped in several ways.  This will be a theme I
> 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.

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.


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
> document.cookie is really used that much and to see if there were ways
> 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.

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

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.


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

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


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

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.

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

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