Get Ready for New SameSite=None; Secure Cookie Settings

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

by migueldemoura • 7 years ago

137 51 7 years ago

blog.chromium.org

Animats• 7 years ago

Why doesn't this break Google tracking?

hirsin4• 7 years ago

They (will) add the samesite decorators.

syncerr• 7 years ago

1/ Google Analytics uses 1st-party cookies since their scripts execute directly on websites. 2/ Chrome relays its own browsing data.

lrem2• 7 years ago

Can you point me at a link for 2?

Disclaimer: despite working for Google, I don't have a clue about this. I'm deep in the backend.

y42• 7 years ago

GA usually comes from a Google-domain. Implementing GA on one of your properties always means using 3rd-party cookies (as long as you not configure some CNAME-records to point your own 1st party tracking domain to GA's tracking domain). Where the script is being executed does not matter in this case, the script is just building the tracking request to the tracking app.

yoloClin2• 7 years ago

The intent isn't to break tracking, it's to prevent CSRF.

One of the nice side effects is it will temporarily break tracking, though.

jwilk• 7 years ago

Archived copy, which can be read without JS enabled:

https://archive.is/YOIND

flukus• 7 years ago

Ridiculous that they're trying to secure cookies but their blog requires you to access at least 6 domains to get more than a title. They push out other ad providers with the comfort of knowing they can use their CDN's to harvest user data.

hirsin4• 7 years ago

Not mentioned in the article, but critical for debugging and testing - Chrome has added a 2 minute grace period, where cookies set in that time period are still allowed on non-get requests even without a samesite policy. This is considered temporary and will be removed some day in the future.

If you test with Chrome 78, and your app works, you can't know if it'll work once the 2 minute grace period goes away. Please test your app using an old version of Chrome (76/77) with the flags for this enabled.

Epskampie• 7 years ago

Wow, what an incredibly hard to debug hack. I fear the day I’ll walk into this. Thanks for making me aware.

lchen025• 7 years ago

There is a DevTools console message warning you about this that pops up if the cookie would have been rejected, if not for the 2 minute threshold for POST requests (and friends).

xchaotic• 7 years ago

What am I missing, what’s the point? Companies can still aggregate data about you by combining data from those separate cookies?

Andrex• 7 years ago

It kills Cross-Site Request Forgery (CSRF): https://news.ycombinator.com/item?id=19854328

hirsin4• 7 years ago

On top of preventing CSRF, it forces labeling of cross site cookies, commonly used for tracking. There's an option in the latest builds to remove all 3p cookies (and add a site allow list)

Ajedi322• 7 years ago

This kills most Cross-Site Request Forgery vulnerabilities, since sites will now need to explicitly opt-in to allowing authentication cookies to be served in cross-site requests.

Of course, it'll probably be a long time before enough browsers support this that you can actually rely on this behavior, and even once support is universal there'll probably still be some sites doing dumb stuff like setting `SameSite=None` on authentication cookies without taking additional precuations, or allowing data to be modified with GET requests. But overall this is a huge win for security on the web.

Previous discussion from back when this was first announced: https://news.ycombinator.com/item?id=19853090

baroffoos3• 7 years ago

it'll probably be a long time before enough browsers support this

Will it? All major browsers now receive automatic or timely updates. The speed of features rolling out over all major browsers is pretty rapid now days and unless you care about supporting IE you can expect new features to be ready to use within a year.

There is only so much you can do to support users using a discontinued browser many many years out of date. Unless you want to be stuck in 2013 forever you have to let them go eventually.

Ajedi322• 7 years ago

The problem is that this is a critical security feature, so the consequences for users are rather severe if you rely on it but their browser doesn't support it.

Instead of your site simply being broken or a certain feature on it not working, you'd instead be opening up all users on older browsers to a CSRF attack against your site.

lioeters2• 7 years ago

For anyone else wondering: the new default SameSite=Lax should (continue to) work fine for cookies with the "Domain" attribute, for sharing with subdomains.

chrishynes• 7 years ago

Thanks for mentioning this. I've poured through docs on SameSite and none seem to mention subdomains or what setting is required for a cookie set at root Domain to be shared with subdomains.

zaroth• 7 years ago

The other thing I had a really hard time finding an answer to is how SameSite handles sibling subdomains like www.foo.com and api.foo.com.

Apparently browsers will use the public suffix list to determine what constitutes the first part of a domain which is identifying, and anything beyond that is considered SameSite.

So www.foo.com is the same site as api.foo.com, but user1.github.io is not the same site as user2.github.io. Because github.io is on the public suffix registry.

That is according to web.dev anyway...

https://web.dev/samesite-cookies-explained

will42742• 7 years ago

This change makes a mockery of Google's commitment to a compatible web. There have been 5 SameSite drafts over two year. This change is strictly incompatible with two of the drafts that shipped in two different browsers (Chrome 66 and Safari 12). Users of LTS Linux distributions will find random websites broken because of this change. It's a great idea on paper, but by shipping so many incompatible versions in the draft stage, Google has virtually ensured breakage for certain user agent - service combos. They should have held the change for another 18 months.

rubbingalcohol• 7 years ago

Can you give some examples with specifics on how their changes are causing problems? I only recently became aware of the SameSite setting and was considering using it on my apps, but might hold off

hirsin4• 7 years ago

If you have cookies that need to be read in a 3p context (federated auth for instance), you must UA sniff in order to figure out if setting samesite=none is going to break your cookies, do nothing, or be required for your cookies - just across three versions of Chrome.

Then there are the apps that forked Chromium 66 and then renamed it, so you can't tell what version it is. We're planning to just break them, since it's impossible to tell what to do there.

will42742• 7 years ago

If you return SameSite=None to Chrome 66, it ignores the cookie entirely. If you return SameSite=None to iOS 12, it treats it as SameSite=Strict. At the time each software was written, the behavior was blessed by the spec ("None" wasn't yet a valid value).

Deimorz• 7 years ago

LTS Linux releases still get browser updates. The purpose of LTS is to continue getting updates for years, they're not frozen with old versions.

Ubuntu 16.04 LTS currently has Chromium 77 and Firefox 69.

throwaway07Ju19• 7 years ago

My website has one affiliate link to Amazon page and a PayPal Buy It Now button (implemented as a form). Chrome's console message suggests I add 'SameSite=None' and 'Secure'. Any advice on where I would add those properties and if they are the right value for these type of links? I didn't realize these type of links had anything to do with cookies.

hn_throwaway_99• 7 years ago

Maybe I'm misunderstanding, but isn't the whole point that Amazon and PayPal need to update their cookies if they intend for these affiliate/pay now links to their domain to pass along their own cookies?

yoloClin2• 7 years ago

I don't know how AWS and Paypal affiliate links work and if they even send a cookie, or if they just send to a URL with your account ID embedded in the link. You could probably check by using the 'Network' tab in your browsers developer tools, or as other have suggested newer versions of chrome allow testing of this feature.

If there are any cookies, you will need to add SameSite=none or similar to the Set-Cookie directives for the cookies which are intended to be shared cross-domain.

eximius• 7 years ago

I don't think this breaks your usage. Assuming those links/buttons sends the user to Amazon/Paypal, then the cookies will be 1st party.

danShumway3• 7 years ago

I've gone back and forth on this since it was first announced.

It's a very tough pill to swallow and is absolutely going to break a lot of web content. There's just no way around that. And there are very few things that are worth breaking the web over.

This is probably one of them. The security benefits of this change are very, very high. It's fixing something that arguably was broken since the introduction of cookies.

I am, as a rule, fairly skeptical when Chrome/Chromium devs say they're going to break something for security. Usually I think they're wrong, this time I think they're right, and I'm grateful that they've pushed for the change.

Also to the Chromium team's credit, they're taking the lead on something that they are 100% going to get criticized about. There are going to be some very angry threads about how they did it wrong, and how a 2020 release is too soon. I don't think the rollout has been perfect either, but... somebody has to do it. Once everything dies down, Firefox is going to implement the same changes, and no one will bat an eye because everyone will have already adjusted to Chrome. There's very little upside to being the browser that makes these changes first, but one of the browsers needs to do it first.

A nontrivial portion of our privacy/security problems on the web come from some fundamentally bad sandboxing; and frankly, cookies are badly sandboxed. This change makes the default at least a little better, and will immediately block a large number of CSRF attacks.

So, yeah. I get that it's annoying, but I'm with Google on this one.

dfabulich• 7 years ago

Firefox and Safari are way ahead of Chrome on this. Safari has blocked third-party cookies for years, with no way to opt-in to supporting them. Ad companies have worked around that restriction, using a number of circumventions that Chrome does not currently intend to block.

When ad companies attempt to circumvent Safari's third-party cookie policy, Safari tries to block them as part of their non-standard ITP (Intelligent Tracking Prevention) program. https://clearcode.cc/blog/intelligent-tracking-prevention/

Firefox has followed suit with an "Enhanced Tracking Protection" feature, which was optional, but became mandatory in September of this year. https://blog.mozilla.org/blog/2019/09/03/todays-firefox-bloc...

Rather than fearing to break the web, Apple has broken the web's ad tech frequently and aggressively; users seem not to mind.

Browser vendors fear "breaking the web," in part because they're afraid that users will switch browsers if their favorite web site stops working. But it turns out that if you just break the web's ads, users tend to like it, if they even notice in the first place.

danShumway3• 7 years ago

The point of this change isn't to break ads, the tracking benefits are at best incidental. Ad networks can just opt-out anyway.

The point is to block CSRF attacks on ordinary websites for developers who don't know enough to secure their cookies.

But it turns out that if you just break the web's ads, users tend to like it, if they even notice in the first place.

Breaking just the web's ads wouldn't have the same impact on security. The reason this change is valuable is because it's not restricted to specific blacklists or domains or applied via an algorithm, it's universal. I really like the tracking protections that Safari/Firefox are adding, but comparing them to this is apples and oranges.

They're policies that are designed for different purposes.

cpeterso2• 7 years ago

Firefox's Enhanced Tracking Protection is not mandatory. It's just enabled by default now. You can configure it in your Firefox settings or disable for individual sites via the address bar's shield icon.

KwanEsq• 7 years ago

Firefox seems to have already implemented it behind prefs in Fx69 [0], and are just now waiting to toggle them to default true, presumably around the same time Chrome ships it, February 2020.

[0] https://groups.google.com/d/msg/mozilla.dev.platform/nx2uP0C...

danShumway3• 7 years ago

Thanks for the heads up, I was curious what Firefox's status was.

I think that's just a smart move in general. There's certainly no PR reason to preemptively turn this setting on, it's better to see what happens when Chrome does. If it turns out to be a disaster, you delay, if not, you flip the switch a few days later so you're not lagging behind on security. Again, I have a reasonable amount of respect for the amount of publicity that the Chromium team has done here, because I think that if things go wrong, they're the ones who will be blamed by most people.

It's good to bring up that Mozilla and Microsoft are also on board with this. It's not Google going off and doing something on their own or forcing the change despite objections, pretty much everyone including Mozilla seems to agree, and would like to see this change.

Bnshsysjab2• 7 years ago

I find it ironic that Microsoft will be implementing it when the latest version is IS11 on a fully patched windows 7 host doesn’t support samesite.

I have no idea why the host OS is relevant, but the feature should never have been limited by it, and it’s a nasty move given it’s a security feature and not just some random shiny new button.

baroffoos3• 7 years ago

Windows 7 is end of life in about 2 months. There should be no expectation of future updates on an OS passed its EoL especially when it was such a long support period.

TylerE• 7 years ago

Technically Win7 was already EoL almost 4 years ago... it's the extended support they're killing at the end of the year.

Bnshsysjab2• 7 years ago

Same site was implemented in IE some time ago, but they didn’t implement it in Windows 7 (which, as you pointed out has not yet been end of lifed).

It’s still in support, and the function shouldn’t even care about the host OS, I think the lack of implementation was more likely completely intentional (on the level of ‘if Windows.version < 10 return true’) which is an absolute dick move.

RaiseProfits2• 7 years ago

Why are cross site cookies allowed at all? Wouldn’t it make more sense to just disable them entirely?

_fbpt• 7 years ago

I've heard that https://tools.ietf.org/html/rfc2109 (the cookie RFC) was originally meant to not allow third-party cookies by default.

In my opinion, cookies on cross-site requests (third-party cookies) should be sent to web servers under a different request header, since they're semantically different (do not necessarily imply user authorization and intent) from cookies attached to a request initiated by the user from a first-party page.

Thorrez2• 7 years ago

cross-site requests (third-party cookies)

I thought "third-party cookies" generally referred to cookies that were set in a third-party context. Whereas you're talking about cookies being read in a third-party context.

Get Ready for New SameSite=None; Secure Cookie Settings

Related Stories