Re: [w3ctag/design-reviews] Scheme-bound Cookies (#483)

Hi, @jwrosewell! Thanks for the feedback. I'll add some comments regarding the portions of your response that seem most relevant to this proposal, but will defer to the TAG on the other questions you raise.

**First**, you suggested that the proposal doesn't have a clear justification. I'll try again:

This proposal suggests that something like HTTPS is an architectural prerequisite for both security and privacy, and that web security is predicated upon [the origin](https://html.spec.whatwg.org/multipage/origin.html#origin) being a defensible boundary.

These suggestions seem foundational and widely-supported in the [W3C](https://www.w3.org/2001/tag/doc/web-https), the [IETF](https://tools.ietf.org/html/rfc7258), the [IAB](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/), and so on. Accepting them leads fairly directly to the proposal's claims that cookies should be origin-bound (just as every other kind of storage is origin-bound), and that state should be limited when traversing non-secure channels.

**Second**, you asked about the provenance of data regarding the age of non-securely delivered cookies. This data comes from Chrome's telemetry, covering stable-channel users who opted into sharing usage statistics for the 28-day period ending December 31st, 2019. It's a fairly broad set of users, and we find it to be a relevant and representative measure. We've since removed the histogram from Chromium, but you can see how it was previously collected by examining [the historical implementation of `LogCookieUMA()`](https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/url_request_http_job.cc;drc=9fb497f41bde7ed4fb3a340b53452a7a0a2dfa55;l=203?originalUrl=https:%2F%2Fcs.chromium.org%2F). I've [added this context](https://github.com/mikewest/scheming-cookies/commit/ac85d87ad7577c58dbc615ffd3d32e43ba18b56d) to the explainer.

I don't have a breakdown of that data by physical location, nor can I provide a concrete percentage of population that decided to share metrics with Google. The data represents a global statistic for Chrome's users, and should be interpreted as such. IMO, it provides a solid-enough basis to answer to the question "Do non-secure cookies have a long or a short lifetime in the status quo?" for the set of users that would be affected by changes to Chrome's behavior.

Related to this data, you suggest a risk of time being wasted if folks need to sign into their favorite sites again. I'd first note that this seems to apply only to the portion of the proposal that would limit the lifetime of non-secure state, and doesn't appear to be an objection to binding state to an origin by bifurcating HTTP and HTTPS cookies to begin with. That said, I agree that we should evaluate this risk, and carefully weigh it against the risks that the status quo imposes on those same folks. My hypothesis is that [the substantial shift towards encryption in users' traffic patterns](https://transparencyreport.google.com/https/overview?hl=en) will make it possible to enact this change safely.

**Third**, you asked about external feedback and raised concerns about this being a proposal with insufficient input from the ecosystem. Given this proposal's posture as an early-stage review intended to gather directional feedback, I don't find it surprising that the community hasn't loudly weighed in. The focus at this stage is on browser vendors, and folks who are deeply engaged in the web's architecture.

That said, the TAG is not the only forum involved. I [sent this proposal to the IETF's HTTP WG](https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0188.html) on the same day I raised it with the TAG, where many of the entities you mention are quite engaged. HAProxy's lead in particular gave several helpful pieces of feedback on the thread, as did folks from Mozilla. Mozilla has also given [quite positive signals via their standards positions repository](https://github.com/mozilla/standards-positions/issues/298).

As we build an implementation developers can play with, and get closer to having something we think might be shippable, browsers generally are likely to use the channels I mentioned in the explainer (public announcements, mailing list threads, blog posts, Lighthouse scores, devtool warnings, etc) to broaden the set of the developers we can learn from.

Thanks again for your comments. Feedback is important to us, and I appreciate yours!


-- 
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#issuecomment-616964617