Intent to Ship: the SameSite cookie attribute.

[Mike West]

# Contact emails
mk...@chromium.org

# Spec
https://tools.ietf.org/html/draft-west-first-party-cookies (note that there's an -07 draft that I can't upload at the moment because the IETF has closed down submissions prior to their upcoming face-to-face meeting)

I haven't discussed this spec with the TAG, as cookies are somewhat outside their purview.

# Summary
I'd like to ship the `SameSite` attribute (née "First-Party-Only" (née "First-Party")) for cookies. This attribute can mitigate cross-site request forgery and information leakage attacks by ensuring that a particular cookie is sent only in a "same-site" context. That is, `https://evil.com` will have a harder time tricking `https://bank.com/` into honoring a forged request if the latter marks its cookies as same-site.

# Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/KrxJvW80yPg/-UC9370USHYJ

Almost exactly a year ago, I tried to ship this in https://groups.google.com/a/chromium.org/d/msg/blink-dev/wKZBCzcNssg/GxwA-Y8Gs84J. I believe the current spec resolves the questions raised on that thread by clarifying worker behavior, and by introducing a distinction between "strict" and "lax" same-site mode. "Lax" is a cleaned up version of what I wanted to ship way back when, "Strict" is a more robust defense.

I don't believe sites will use "Strict" right out off the bat, as it requires some refactoring to create a two-cookie setup as described in https://tools.ietf.org/html/draft-west-first-party-cookies-06#section-5.2. However, it seems like a fairly robust defense against CSRF, and could justify the work necessary to refactor.

I've CC'd the folks who were involved in that discussion. I think they'll be pleased with where the spec ended up.

Sorry it took so long... I got distracted. :/

# Is this feature supported on all six Blink platforms?

Yes.

# Debuggability

Once https://codereview.chromium.org/1827743002 lands, devtools will display cookies' same-site status in the same way it displays other attributes on the resource and network panes.

# Interoperability and Compatibility Risk

The "SameSite" attribute provides defense-in-depth, and gracefully degrades into a "normal" cookie in browsers that don't support the new attribute. That is, they'll treat `Set-Cookie: name=value; SameSite=Strict` as `Set-Cookie: name=value`. Sites which use the attribute will not break in browsers that don't support it, they just won't be locked to same-site contexts.

- Mozilla has been supportive of this feature. Mark Goodwin has signed on to co-edit the spec, and tells me that they plan to start implementing in the near future. 

- The HTTP WG has flagged the spec as a candidate for adoption.

- Developers are interested: GitHub has re-enabled its experiment, support has landed in Rack, folks at Facebook and Twitter have expressed tentative interest, and it's possible that some folks at Google could use this as well (though `youtube.com` and country-coded domains make it non-trivial to implement).

# Is this feature enabled in non-secure contexts?

Yes, which you might find surprising given my comments in some other threads. :)

In short, I expect this feature to create a net reduction in the number of non-secure cookies floating around in cross-site contexts. This is especially valuable as a (marginal) defense against pervasive monitoring, as same-site cookies cannot be used by a network attacker to correlate user behavior across distinct origins. I've noted this in that un-uploaded -07 draft: https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-07.html#rfc.section.6.2.

I'm willing to go either way on this point, however; there's a good argument to be made in terms of reducing cognitive overhead for developers by restricting all new features to secure contexts rather than creating well-meaning exceptions. I think the feature's purely restrictive nature make it an exception that proves the rule, but I'd appreciate other opinions. :)

# OWP launch tracking bug

https://crbug.com/459154

# Entry on the feature dashboard

https://www.chromestatus.com/features/4672634709082112

Thanks!

-mike

[Rick Byers]

Two questions regarding the interop risk:

1) Have you asked anyone at Microsoft or Apple for their feedback?

2) Worst case and the IETF/HTTP standardization process wanted some changes (say including changing the "SameSite" token name) the compat risk of changing wouldn't be a big deal, right?  I.e. since this is a defense-in-depth feature, sites can't really come to rely on it, so we can take it away (replace it with something better) without "breaking" them, right?

[Mike West]

On Wednesday, 23 March 2016, Rick Byers <rby...@chromium.org> wrote:

Two questions regarding the interop risk:

1) Have you asked anyone at Microsoft or Apple for their feedback?

I have asked, but not recently. I'll ping folks again.

 

2) Worst case and the IETF/HTTP standardization process wanted some changes (say including changing the "SameSite" token name) the compat risk of changing wouldn't be a big deal, right?  I.e. since this is a defense-in-depth feature, sites can't really come to rely on it, so we can take it away (replace it with something better) without "breaking" them, right?

Yes. Renaming or removing the feature in the future would be annoying, but I don't believe it would break websites. It doesn't provide any additional capabilities beyond what cookies provide today; it is purely negative in nature. Same-site cookies are strictly less capable than regular cookies.

-mike

--
-mike

[Rick Byers]

Thanks.  LGTM1 to ship (provided, of course, the other vendors don't come back soon with some major concern).

Rick

[Jochen Eisinger]

lgtm2

[Chris Harrelson]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

LGTM, but I would prefer this get sent to the TAG as an FYI (not a review). It impacts a lot of the discussions that are ongoing about strengthening the same-origin model and is a good example we can point to in future for how to retrofit an existing system that appears hopelessly broken.