[w3ctag/design-reviews] Scheming Cookies (#483)

Guten TAG!

I'm requesting a TAG review of [Scheming Cookies](https://github.com/mikewest/scheming-cookies).

Data sent over plaintext HTTP is visible to and can be manipulated by anyone on the network. The exposure of identifiers like cookies is a particular risk. Cookies' `Secure` attribute and the more recent `__Secure-` prefix mitigate this problem, but are not used nearly widely-enough to be a robust defense for users. We should shift the defaults by **locking cookies to the scheme of the origin from which they're set** (like every other kind of web-facing storage), and **dramatically shortening the lifetime of non-secure cookies** by defining a set of heuristics around a user's "session" on a site, expiring cookies along with the session.

  - **Explainer**: https://github.com/mikewest/scheming-cookies

  - **Security and Privacy self-review**: If RFC6265 had done a security and privacy self-review, the comments in https://tools.ietf.org/html/rfc6265#section-8.5 would have been high on the list of issues discovered. This proposal aims to improve cookies stance vis a vis network attackers, mitigating a number of security threats, and bringing cookies somewhat more into alignment with treating an `origin` as a security boundary.
  - **Primary contacts** (and their relationship to the specification):
      - Mike West (@mikewest)
  - **Organization/project driving the design**:
      - Google
  - **External status/issue trackers for this feature**: Nothing yet; it's an early-stage proposal without implementation work. I expect Chrome to begin poking at a prototype in ~Q2, depending on how other cookie related changes (`SameSite` in particular) land. I'll update the link at that point.

Further details:

  - [X] **I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)**, particularly the comments around secure contexts. I'm also passingly familiar with the [Securing the Web](https://www.w3.org/2001/tag/doc/web-https) finding, which is relevant here.
  - **The group where the incubation/design work on this is being done**: personal repo -> WICG if there's interest.
  - **The group where standardization of this work is intended to be done** ("unknown" if not known): IETF's HTTPbis is most likely.
  - **Existing major pieces of multi-stakeholder review or discussion of this design**: The conversation at https://twitter.com/mikewest/status/1235945994946252800 is basically it (along with some private outreach).
  - **Major unresolved issues with or opposition to this design**: Some folks really don't like limiting the power of HTTP, and have been upset in the past at the notion of treating "state" as a feature that ought to be locked to secure contexts.
  - **This work is being funded by**: Google (as a side note, this question seems somewhat redundant with questions above about who's driving the project organizationally and personally)

You should also know that this proposal dovetails with others that aim to reduce the power of non-secure sites, notably [schemeful `SameSite`](https://github.com/mikewest/cookie-incrementalism/pull/3) on the one hand, and [requiring `Secure` for `SameSite=None`](https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#name-requiring-secure-for-samesi) on the other.

❤️ 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/483