Chrome Caught Exempting Google Sites From User Requests To Delete Data (msn.com) 50
This week the Verge reported:
If you ask Chrome to delete all cookies and site data whenever you quit the browser, it's reasonable to expect that this policy applies to all websites. Recently, though, a bug in the browser meant data wasn't being removed for two sites in particular: Google and YouTube.
This problem was first documented by iOS developer Jeff Johnson on his blog. Johnson found that in Chrome version 86.0.4240.75, "local storage" data for Google.com and YouTube.com stuck around even after restarting the browser. We've been able to replicate similar behavior... The Register notes that Chrome's behavior could allow Google to stash cookie-style data as site data, allowing it to track users even when they think they're being careful by deleting their cookie and site data every time they close the browser.
In a statement, Google said it was aware of the issue and was working on a fix... At least one of the affected sites, YouTube, appears to have already been fixed. After we upgraded the Chrome browser to version 86.0.4240.111, YouTube's local storage data seems to successfully purge after a restart, although the data from Google.com still sticks around.
This problem was first documented by iOS developer Jeff Johnson on his blog. Johnson found that in Chrome version 86.0.4240.75, "local storage" data for Google.com and YouTube.com stuck around even after restarting the browser. We've been able to replicate similar behavior... The Register notes that Chrome's behavior could allow Google to stash cookie-style data as site data, allowing it to track users even when they think they're being careful by deleting their cookie and site data every time they close the browser.
In a statement, Google said it was aware of the issue and was working on a fix... At least one of the affected sites, YouTube, appears to have already been fixed. After we upgraded the Chrome browser to version 86.0.4240.111, YouTube's local storage data seems to successfully purge after a restart, although the data from Google.com still sticks around.
Don't be evil (Score:5, Funny)
Is actually a shortening of "don't be merely evil".
Re: (Score:3)
Is actually a shortening of "don't be merely evil".
I believe their original Mission Statement was, "Don't be Dr. Evil" -- and their second choice was, "Don't be Evel Knievel."
[ Ben Stein: Anyone, anyone? Bueller, Bueller? ]
Re: Don't be evil (Score:2)
Still using Chrome? (Score:1)
It is your own fault then. If you don't ditch the products of the US intelligence services, the products of US intelligence will collect information about you to the extent you make it possible.
Re:Still using Chrome? (Score:5, Insightful)
I only use Chrome for limited purposes.
The main reason for Google not erasing the data related to Google sites is because they "need" that data to build a profile on you and if that data is erased then you damage their statistics.
Re: Still using Chrome? (Score:3, Funny)
There really is nothing interesting to see here. It is by design to benefit people who want to use Google services to the fullest. I am certain they will correct this for people who do not want to use Google Accounts for sync, GMail and ot
"a bug in the browser" (Score:5, Insightful)
Re: (Score:2)
No wait, it's fake news! We don't have to fix anything!
Re:"a bug in the browser" (Score:5, Informative)
Lately Google has been making changes to the site storage API that could have triggered this bug. The changes were at the request of add-on developers to bring it up to parity with Firefox.
Previously add-ons could only delete cookies for a site, not other kinds of stored data. The improved API allows everything to be removed. The development history of Cookie AutoDelete charts the changes. So it looks like when they changed the API they broke something as this used to work.
If someone could be bothered to go back and test old versions, and maybe test Chromium as well, they could pinpoint exactly when it happened.
Re: (Score:2)
Yeah, ok, sure, whatever.
From the summary:
In a statement, Google said it was aware of the issue and was working on a fix...
So this happened by accident did it? Like a coding error? If the above is accurate reporting, then Google are really taking the piss. Everything points to Chrome favouring other Google products. That does not happen by accident.
Suggestion (Score:2)
Shocking (Score:5, Insightful)
Re: (Score:2)
The Monopoly case gets stronger (Score:3)
Bug? I think not. (Score:5, Insightful)
>"In a statement, Google said it was aware of the issue and was working on a fix..."
Implying it was a bug? And "fixing" it requires any kind of effort??
Exactly how can it delete everything EXCEPT two of Google's most important sites without being intentionally coded that way? Someone caught their secret binary blob doing something bad that Google probably did on purpose. Color me not surprised.
https://www.mozilla.org/en-US/... [mozilla.org]
Re:Bug? I think not. (Score:5, Insightful)
The bug was letting people find out the cookies were not deleted. After it was "fixed", no one will find out those cookies were kept no matter how hard you tried to delete them.
Re: (Score:2)
Re: (Score:3, Insightful)
That would be a rather specific check. Which people will now make, but otherwise the cheat might have gone unnoticed for quite a while. Like backdoors in Cisco equipment. Or cheating with the exhaust gas treatment at Volkswagen.
It is also a reason to stay away from Chrome.
Re: (Score:2)
If the cookies are really getting kept while the software somehow tries to mask their existence from the end user, sniffing the local port with a tool like wireshark when connecting to a google site would still reveal it.
Not if the communication between Chrome and Google were encrypted end-to-end. You can only see a mass of meaningless bits, with the secret cookie encrypted inside.
Re: (Score:2)
Re: (Score:2)
Good luck seeing the cookie through the SSL encryption. Just imagine code like this in Chrome:
if (destHost.endsWith("google.com") &&
connection.isEncrypted() &&
connection.ssl().matchesHardCodedGooglePublicKey())
{
connection.appendCookie(secretGoogleTrackingCookie());
}
The function names are made up, but code like this would make it so that a tracking cookie would only be sent to google.com sites for encrypted (like HTTPS or SPDY) with a non-spoofed certifi
Re: (Score:2)
>You will have no trouble seeing this. You can man-in-the-middle yourself fairly easily. This is done for debugging purposes all the time. It's also often done on corporate networks so that the IT folks can snoop. Yes you have to trust the certificate but that's part of the debugging process and/or the corporate infrastructure.
In order to make this work the code would also have to code that checked against a hard-coded or pinned certific
Re: (Score:2)
Evidently you were unaware that SSL encryption can be fairly easily decrypted by tools such as wireshark when you are doing it on the same machine that is doing the encryption. Anything that Google might try to do to cover up that they are encrypting certain packets which you cannot decrypt locally will be fairly obvious to someone who is checking this.
Re: (Score:2)
Interesting [wireshark.org]. I had no idea that most browsers would output the keys used if the SSLKEYLOGFILE environment variable was set. I'm going to have to watch out for that one in the future! Though, since this does seem to require the help of the browser, and the goal is to try to see if there is secret code in that browser that would sometimes send extra cookie information, that's just another thing for the secret code to check for. Though some other variations described on page talk about extracting the keys
Re: (Score:2)
Re: (Score:2)
*Shrug*
Re: (Score:1)
I would suggest that your inability to imagine how such a thing could have been accidental on Google's part speaks more to the limits of your own imagination than it does to any objectively wrong intent by Google.
Hanlon's razor may well apply here.
Re:Bug? I think not. (Score:5, Insightful)
You're missing the point that you generally expect a browser to treat all sites the same and not write hard-coded code in the browser to treat different urls differently. The probability here is that Google wrote the code to check if the site is theirs and then skip it when deleting cookies. The likelihood of this happening any other way is very remote.
If you're using Chrome then either you're a newbie or you don't care about an advertising giant tracking you and building up a big database of data metrics about you.
Re: (Score:3)
>"you generally expect a browser to treat all sites the same and not write hard-coded code in the browser to treat different urls differently. The probability here is that Google wrote the code to check if the site is theirs and then skip it when deleting cookies. The likelihood of this happening any other way is very remote."
+1, that was exactly my point. I don't see how it is possible to have code that "accidentally" does not delete something so specific when the code should simply delete everything.
I
Re: (Score:2)
I'm afraid that admission speaks more loudly to your own lack of imagination than it necessarily does to some dark intent on Google's part.
Perhaps it is because code that might have admittedly been intentionally put in there for some specific and perhaps entirely legitimate reason during testing and development was simply accidentally forgot about and left in
Re: (Score:2)
Yes, master (Score:5, Insightful)
Re: (Score:1)
People are quick to jump down Google's throat over this, and TBH, I can perfectly understand why.... but honestly, I think that this is a reflexive reaction that is only indicative of a lack of imagination, and underestimating just how large the capacity for human error actually is.
If you would like to hear a explanation for how this could possibly be accidental, consider the idea that not deleting google's data was actually part of something that was meant to test a specific facility during the developm
Re: (Score:3)
I'm usually the first to reach for Hanlon's razor, and you know, even here I'll give google the benefit of the doubt in that this could be an accidental bug.
But that doesn't get them off the hook: The only way such a bug can exist is because there's code in there that special-cases these google domains. Maybe in a subtle way: It could be a special feature that any site could in theory use, but in practice is only used by google domains, and no-one else knows about it. In that code there's a site-data bug
Re: (Score:2)
Almost certainly, but my point is that it's certainly possible that this code was still never intended to be part of the release, and therefore technically still an accident. How do you figure that the special case code will still be there if they go and correct it?
Re: (Score:2)
Because I expect that the reason it affects only these two domains, is not because they are specifically mentioned in the site data delete procedure, but due to a subtle interaction of complex features.
If I'm wrong, and they literally wrote:
if(site!="google.com") delete_site_data(site)
then sure, fixing the bug would end any special treatment, but that kind of code would stand out as a sore thumb in any kind of code review.
Re: (Score:2)
I imagine that it may be a little more complex than just the one line... but even so, at the time of review such code might have looked entirely innocuous for something that was originally expected to be a debugging aid, with the expectation that the code would be removed later, and then everyone who happened to know that it was there forgot it did this when they made the release branch, until someone pointed it out.
I am not eliminating the possibility that Google was really doing this in the hopes they
Re: (Score:2)
I'm usually the first to reach for Hanlon's razor, and you know, even here I'll give google the benefit of the doubt in that this could be an accidental bug.
This is pure speculation on my part, but I think it possible that Google are using "in the cloud" stuff to provide browser features, and the cloud stuff is run by Google, of course. My guess is that these browser features bypass the usual cookie management applied to other sites. However, even if my charitable interpretations are correct, it does not let Google off the hook, because this covert activity would constitute some kind of hidden "phone home".
seems to me (Score:2)
Google has been deceitful since day one. Anyone remember their toolbar where you were supposed to be able to opt out back in the beginning. I have never trusted them. The only time I use chrome is if my current browser is having problems.
Chromium too? (Score:2)
I've experienced this personally. (Score:4, Interesting)
Re: (Score:3)
I wouldn't doubt for a minute, however, that the link was harvested from an @gmail message sent by you to your brother's bandmates, for example. Or harvested in Android... or any number of other things besides DNS.
Google Evil (Score:1)
An old story (Score:2)
Silicon Valley, the shopkeepers who became warlords and thought they could be kings, only to find out that reality is far more complex than their machines? Indeed. Of course they have become manipulative, more than Microsoft or IBM before it, simply because they are one-hit wonders who now see their business model failing.
Firefox (Score:2)