More on Chrome updates and headers
I’m not the only one who has been unpleasantly surprised by the way Chrome now handles logins on Google services (more on Techmeme). This new feature was unexpected, it was also not announced in Google post about the Chrome update, there is no simple opt-out, it makes the Chrome Privacy Policy outdated and it confusingly as creates different user experiences on Android and on desktop. Indeed, for your browsing activity to be linked to your Google account you must sign-in on the browser and enables browser synchronization. On desktop, signing-in to the browser is almost mandatory but synchronization is off by default, on Android sign-in is off by default, but as soon as you sign-in synchronization is enabled. This are about to get even more complicated as Google introduce a new features that sends data to Google even when synchronization is off.
The only document which announced all changes is the Chrome privacy whitepaper. I doubt many people read it, but it’s a treasure trove of info about Chrome features and interactions with Google services.
Google service integration
As, the Verge already explained, Chrome is turning into the new IE6 (in case you wonder, that’s not a compliment). Not only is Google making some services running faster on Chrome, the browser also sends information only to Google. Indeed, Google developed several headers that are only sent to Google to make the integration with the services even smoother.
You can see headers on Chrome using the developper tool. To see all headers, you’ll have to “Copy all headers” as HAR and past the result in a text editor (thanks to Gunes Acar for the tip), otherwise you’ll see only provisional header.
The x-client-data header
This is probably the most problematic header and I did not see it mention anywhere else than in the whitepaper. Most users are not aware of it but this is header sent with every request sent Google services (and only Google services) to do A/B testing. Google services include most Google domains, including Doubleclick. Even when Google is a third party, the header is sent. Because it’s a header and not a cookie, it is sent even when you block cookies. The only way to not send it is to turn-on “Incognito Mode”.
If you have disabled usage statistics and crash reports, this header might not be used to track you without additional info. But the whitepaper is unclear about how this header is updated to describe “server-side experiments“ so I wouldn’t bet on it.
So not only this header may have some privacy implications, it makes the browser not neutral as it gives more data to Google services.
See https://www.google.com/chrome/privacy/whitepaper.html#variations for more details
Consistency/Connected headers
As mention in the chrome whitepaper, this header is sent to some Google servers. Most of the time, this header does not contain any identifier and is a low entropy cookie.
Only from time to time it includes your Google account number. Looking at Chromium source we get more details about how this header is used: it is used to redirect some action to the browsers UI instead of the content.
It may not have privacy implications yet, but it means that Chrome will benefit from integration with Google services that other services could not have.
New settings
The latest update mentions two features that are only tested on a subset of users. These features are more or less on opt-in basis (see bellow) and send data to Google when you’re signed-in, even when synchronization is off. These data are used to make personalized suggestions and improve the “general browsing experience”.
Actually, no need to be in the test group. You can use this feature on Chrome Canary. Once you’ve installed the browser, just sign-in and you’ll see this “opt-in” dialogue. If you accept or click on “Settings”, you’ll have access to the “Sync and Google services” section in the settings page.
Notice that if you click on “Settings”, all settings will be on by default, including sync.
Conclusion
By “forcing” users to sign-in to Chrome and by using custom headers, Google is less and less dependant of third party cookies. I would not be surprised if Chrome started to block third party cookies. Actually this may be in Google financial interest to do that.