Google Chrome To Support Same-Site Cookies, Get Anti-Fingerprinting Protection (zdnet.com) 57
Google plans to add support for two new privacy and security features in Chrome, namely same-site cookies and anti-fingerprinting protection. From a report: The biggest change that Google plans to roll out is in regards to how it treats cookie files. These new controls will be based on a new IETF standard that Chrome and Mozilla developers have been working on for more than three years. This new IETF specification describes a new attribute that can be set inside HTTP headers. Called "SameSite," the attribute must be set by the website owner and should describe the situations in which a site's cookies can be loaded.
[...] Google engineers also announced a second major new privacy feature for Chrome. According to Google, the company plans to add support for blocking certain types of "user fingerprinting" techniques that are being abused by online advertisers. Google didn't go into details of what types of user fingerprinting techniques it was planning to block. It is worth mentioning that there are many, which range from scanning locally installed system fonts to abusing the HTML5 canvas element, and from measuring a user's device screen size to reading locally installed extensions.
[...] Google engineers also announced a second major new privacy feature for Chrome. According to Google, the company plans to add support for blocking certain types of "user fingerprinting" techniques that are being abused by online advertisers. Google didn't go into details of what types of user fingerprinting techniques it was planning to block. It is worth mentioning that there are many, which range from scanning locally installed system fonts to abusing the HTML5 canvas element, and from measuring a user's device screen size to reading locally installed extensions.
Google doesn't do privacy (Score:4, Insightful)
Re: (Score:1)
The entire sub-thread was just sock puppets, so that a political statement could be made. That's how modern politics works, on all sides -- by being shitty.
Re: (Score:3)
Yeah, but pretending they do care and doing something 1/100-assed way stalls others' work and, especially, legislation.
No it's not. (Score:3, Insightful)
Don't be dense. Google makes money from targeted advertising. These features limit their competitors' ability to get the demographic data, so that Google can become even more of a monopoly on an even more scarce resource: your data.
In case that wasn't clear enough: Google still gets to know everything about you. It does not need cross-site cookies or browser fingerprinting to do so. Only Google's competitors in the information market rely on those features. Google is not doing this to give you a drop o
Re: (Score:2)
fake news (Score:2)
This is obvious fake news.
If Big Brother Google is involved in anything, then it is fully certain that thing is harmful to privacy, freedom, solidarity, and/or democracy.
Re: (Score:2)
Privacy is core to Google's business model.
Their advertising business is so valuable because of their ability to target ads well. If your data is not kept private, everyone gains that ability and their service is devalued.
Thus, it is important for Google to protect your privacy.
Also protects you by banning Dissenter (Score:1)
So you don't hear incorrect speech.
Re: (Score:1)
No, that has been blocked for your protection too. Going forward, no major website hosts shall permit incorrect speech and no payment processor, credit card company, or bank shall accept payments for or from those who speak incorrectly either.
It's for your safety. You shouldn't be subjected to the violence of incorrect speech, in any capacity. And we will ensure that by non-personing anyone who engages in it. For a better world.
Re: (Score:2)
Look around, sweetie. It's real and it's already happening.
Re: (Score:2)
Incorrect speech is speech that disagrees, of course. That's an act of violence on the listener. And violence must be stopped, obviously.
About time (Score:5, Funny)
Re: (Score:2)
Firing James Damore wasn't anyone's decision but whiny incel crybaby James Damore's. Google gets "Ok, they breathe oxygen and understand dollars" credit for that, not more. The incel-supremacist faggots took extreme butthurt, is all.
51% of society is women. You're going to be very afraid in the future, my fine-feathered crybaby incel snowflake. Having a job where people respect each other publicly is not a right - except it is enforceable, that's basic shit you don't get.
Crying and playing the victim doesn't help you understand this reality of dealing with other people who aren't you, snowflakes. You are being watched, yes.
Calm down muchacho.
what about this thing from a recent article (Score:4, Insightful)
from the article: Betas of Chrome 74 (which ships later this month) have dropped this flag, as has Opera which is built on the same Chromium engine and has shadowed the change in its developer builds.
Re: (Score:1)
Websites already control the link you are clicking on their site, they can use javascript to track clicks or just route all links though a redirect to track (v common, obscures the link).. pings actually improve things by putting this under browser control - so you can have real links and a site that works without JS... yet "privacy experts" try to cast this as a bad thing.
Re: (Score:3)
They are removing it because doing so actually improves privacy and performance for users.
If hyperlink auditing is not available the site owners just use Javascript to do the same thing. Javascript means larger page downloads and more wasted CPU cycles. Unlike hyperlink audit pings the browser can't optimize them effectively, e.g. by making them async background tasks while the actual page you requested loads.
Hyperlink auditing pings can be blocked by ad blockers, and in fact are even easier to block than t
RFC 6265 (Score:3)
Re: (Score:2)
Same site cookies? The domain attribute for cookies is already part of the spec (Section 5.2.3) why do they need another of the same?
This controls domains the browser is allowed to transmit a cookie for. For example session cookie should be accessible to subdomain.mywebapp.org .
What this is about is different from that. Say you own a website with a login form that uses session cookies. You happen to be logged into it. Now imagine you are on Google and do a search for your website. With this change when you follow that hyperlink to your own website it won't see you as logged in because the browser will be prevented from transmitting
Re: (Score:1)
The proposal is for default-default of "Lax" mode which would not break in the way you describe since lax sends cookies for top level nav via safe HTTP method (GET is safe). If someone sets their default mode to Strict then that is their problem (or your problem if your website set strict on the cookie).
There are scenarios Lax would break (by design), eg cross site form submission via POST, but following a link isn't one of them.
SameWhat? (Score:3)
SameSite has been supported in Chrome for years. In fact TFA even mentions this.
What seems to be new and very much newsworthy is the attempt by Google to impose breaking global changes in existing behavior.
It's May 8th and a draft adopted by no WG that is not even a day old is being cited in news articles. Why? Lets look at that draft.
Based on conversations at [HTTP-Workshop-2019] and elsewhere, I'd
suggest that we have something like agreement on at least two
principles:
1. HTTP requests should not carry state along with cross-site
requests by default (see Section 8.2 of [RFC6265bis]).
2. HTTP requests should not carry state over non-secure channels
(see Section 8.3 of [RFC6265bis], and [RFC7258]).
This is breathtaking. Commentary in the context of a completely different state management system is being assigned to justify *breaking changes* in EXISTING production mechanism in production use globally.
The conclusions themselves are cracked pottery at best.
1. So decrees king Google who doesn't have to answer to anyone.
2. WTF? This is what the secure flag is for. People already have the ability to decide whether this should or should not occur.
With those principles in mind, this document proposes two changes
that seem possible to deploy in the near-term. User agents should:
1. Treat the lack of an explicit "SameSite" attribute as
"SameSite=Lax".
I'm all for headers that impose additional constraints. This isn't that. It's breaking existing systems globally and unilaterally for no good articulated reason.
Re: (Score:1)
CSRF the reason, and it is a big pressing problem. Cookies are a horrible security mess, and ultimately something will have to broken, whether this particular change does enough good to justify the breaking is a more nuanced question.
Re: (Score:2)
CSRF the reason
No shit.
and it is a big pressing problem.
Citation required. Regardless of characterization of problem scope solutions that don't break anything are both well known and trivial to implement.
Cookies are a horrible security mess
No. I R A dev crowd who don't know what they are doing = "horrible security mess".
, and ultimately something will have to broken,
Keyboards? Digitizers? Car windows? Supermarket PA systems?
whether this particular change does enough good to justify the breaking is a more nuanced question.
I'll leave this stunning lack of objective basis speak for itself.
Re: (Score:2)
It's breaking existing systems globally and unilaterally for no good articulated reason.
The reason is spelt out quite clearly in the references the document cites: Security.
Without the SameSite attribute cookies are always sent when a site is loaded, and that means if you are, say, logged in to Slashdot another site can send you a link to Slashdot that triggers some action which will be executed when you click on it.
By making all cookies have a default setting of "lax" this attack is blocked.
It breaks almost nothing except for malicious links. It's only very, very broken sites that rely on thi
Re: (Score:2)
The reason is spelt out quite clearly in the references the document cites: Security.
Without the SameSite attribute cookies are always sent when a site is loaded, and that means if you are, say, logged in to Slashdot another site can send you a link to Slashdot that triggers some action which will be executed when you click on it.
This has been well understood property of web for decades from the very beginning. This is why sites deploy measures to prevent this from happening.
One of the easiest methods for those unwisely electing only to use cookies is simply to check HTTP_REFERER header. Sites could also use the SameSite header if they want crummy half-assed protection that SameSite offers and don't feel like implanting it themselves. None of this is rocket science.
By making all cookies have a default setting of "lax" this attack is blocked.
It breaks almost nothing except for malicious links. It's only very, very broken sites that rely on this to work.
**BULLSHIT**
I personally have a site that employs CSRF protections
Re: (Score:2)