Re: [w3ctag/design-reviews] Deprecating nonsecure cookie delivery. (#239)

> The word "Chrome" appears a lot...maybe less of that?

This started as an internal doc, and you're right that I should have fixed a few more of those references: https://github.com/mikewest/cookies-over-http-bad/commit/fd77fa3116dfdc58dbf4477c655c800faac07081

> Have you discussed, or is it the intent, that this would be paired with a flip from insecure to `Secure`-flagged cookies by default at some date in the future? Or is the addressed in the discussion of hiding vs. deleting?

I think this will indeed depend on the exact mechanism that we end up choosing to run with. I still prefer the simplicity of removing the cookie entirely, as that seems easiest to reason about, both from the browsers' and developers' perspective, but I look forward to the discussion.

> Would it be possible to identify a tipping point at which we should make it hard (impossible?) to mint new insecure cookies? Do you have thoughts on that?

It should be possible, yes. And I do have thoughts! If it turns out that folks are generally on board with the idea (and the initial round of feedback is sounding good), my next step is to work out a more detailed schedule with vendors and developers that we think sounds reasonable. Chrome's "HTTP Bad" project took ~2-3 years, as a benchmark...

In my dreamy world of dreams, I could imagine ending up with something like starting with a maximum lifetime of ~a year, and chopping 6 weeks off of that with every browser version until we end up at something suitably small. So, this time next year, non-securely delivered cookies could live for ~6 weeks. Moving from ~6 weeks to ~0 weeks will probably take another year. I'm not sure how we'd wrangle that kind of schedule with vendors that have a more-than-6-week release cycle, but I'm sure we'll work something out. :)

> This has been discussed for a long time in the various ways. Current thinking in HTTP WG is here, although I'm sure folks would welcome further discussion / modification if a consensus position can be found.

I fully intend to send this to the HTTP WG in the form of an ID (and I see it as somewhat critical to RFC6265bis, as it otherwise has no story for pervasive monitoring). omnomnom is of course an inspiration for this approach, and I hope this feels like a natural extension of @martinthomson and @cpeterso's existing work (actually, I'd love to collaborate with them on a draft if they have some free time, since it's pretty clear that I'm bad at writing drafts these days... (he says, hopefully?)).

-- 
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/239#issuecomment-379459385