Google Chrome: better cookie protections and controls announced
Google plans to improve cookie controls and protections in upcoming versions of the company's Chrome web browser.
The company revealed plans to change how cookies work fundamentally in the web browser in third-party contexts.
Google Chrome will make use of the SameSite cookie attribute to enforce the new behavior by setting it to lax by default. What this means, essentially, is that the Chrome browser won't send cookies with cross-site requests anymore.
SameSite supports the three values not set, lax and strict, with not set the default on today's Internet. SameSite defines access rights to cookies and it the attribute is not set at all, cookie sending is not limited.
A value of strict on the other hand prevents cookies from being sent to all sites in all cross-browsing contexts. In other words, cookies are only sent if the the requesting site matches the site that is shown in the browser's address bar.
Lax is a compromise between better security and convenience. A Lax value would still block cookies from being sent in third-party contexts, e.g. when requested from a different site, but it would allow cookies to be sent if the user would follow a link to the site.
The "SameSite" attribute limits the scope of the cookie such that it will only be attached to requests if those requests are same-site, as defined by the algorithm in Section 5.2. For example, requests for "https://example.com/sekrit-image" will attach same-site cookies if
and only if initiated from a context whose "site for cookies" is "example.com".
If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests. If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in Section 188.8.131.52. (via IETF)
Developers and site operators will have to define SameSite values explicitly if they require different values. If they don't, Lax is enforced.
The change has significant consequences. First, it is beneficial for security as it protects cookies from cross-site injections and data disclosure attacks like CSRF (Cross-Site Request Forgery) by default. Google plans to limit cross-site cookies to secure contexts (HTTPS) in the future to improve privacy further.
Google Chrome will feature new cookie controls that "enable users to clear all such cookies" without impacting any "single domain cookies" so that logins and preferences set by single domain cookies are preserved.
Chrome users who run development versions of Chrome may experiment with new SameSite defaults already.
- SameSite by default cookies enforces the Lax value for all cookies that don't specify the SameSite attribute: Load chrome://flags/#same-site-by-default-cookies and set it to Enabled.
- Cookies without SameSite must be secure requires that all cookies without SameSite attribute need to be Secure as well. Cookies that fail to do so will be rejected. Load chrome://flags/#cookies-without-same-site-must-be-secure and set this to enabled.
- Restart Google Chrome
Note that some sites may break when you enable these in Google Chrome. You can undo the changes at any time by setting the experiments to Default or Disabled.
Mozilla introduced SameSite support in Firefox 60.
It is not clear yet when the new controls or regulation is implemented in Chrome Stable. Chrome Canary users can test some of it already. The feature improves protections against CSRF and other attacks significantly.
Now You: How do you deal with cookies in your browser?
I would hope the future cookie control optionally allows a cookie taskbar icon for one click to toggle the cookie setting when appropriate. Many Chrome extensions work this way.
“How do you deal with cookies in your browser?”
I don’t sweat them as much as in the old days. I disallow third-party cookies, and I periodically go through the ones that have been stored and delete the obviously marketing and tracking-related ones. Well, more specifically, I delete them all except the ones that appear to be used for anything other than storing preferences on sites I care about. If I don’t care about (or recognize) the site, I just delete all of the ones for that site.
Blocking 3rd party cookies should be the default setting imo. It is amasing how many domains appear in the cookie manager with that option disabled. I guess it would break the ability of the average joe to “like & share” on facebook from a 3rd party website, but other than that I see no major inconvenience.
Wow, typical phone gibberish; confusing verbiage so that users pick the settings best for google.
When they implement settings that allow all browsing data to be deleted on shutdown, they’re showing some good intent. Otherwise, users who block third party cookies for the first time are going to see some sites not work correctly and will have to sort through whether it matters.
“Wow, typical phone gibberish; confusing verbiage”
To this day Safari is the _only_ major browser that has reasonable security and privacy features:
We can only hope that Safari and Brave will become the standard on the web, the WebKit team and Brendan Eich are the only parties that are actually working on solving this.
I came across a post just yesterday claiming that Brave whitelists scripting from at least *some* Facebook and Twitter domains, including tracking domains, out of the box, and that at the time of writing (less than three months ago) there was no way for users to disable it:
I find this alarming, since Facebook is one of the most notorious non-consensual personal-profile builders on the Net. (I haven’t read as much about Twitter, so I can’t speak to them.) I put Facebook in my NoScript “Untrusted” blacklist quite some time ago, and when I switch to uMatrix/eMatrix, it’s going to get similar treatment there as well.
Anyway, I was enthusiastic about a lot of what I’d read about Brave, but this news was an icy cold shower.
You can disable this tracking in the settings. It was only allowed because social logins were getting removed from sites where you could only login from these. So they allowed this and gave the user the choice to disable this.
So, you’re saying that users can now block scripting from Facebook domains? Or just cookie-setting and -reading?