Google is tracking Safari users across the web even though when they attempt to block 3rd party cookies and have never visited Google.com. This is a function of the anti phishing and malware lists used by both Safari, Firefox (and, of course, Chrome) that automatically update from Google in the background and places Google cookies.
This is a separate issue than the one uncovered Feb 17, 2012 surrounding Google circumvention of Safari’s default cookie blocking features. Essentially, even though Google has fixed the Doubleclick issue due to ‘social sync’, they are still able to track Safari users everywhere there is a +1 button on the web, even when users have 3rd party cookies blocked.
Google sets a PREF cookie from ‘.google.com’ automatically when a user opens Safari, even when that user isn’t making any explicit connections to Google or even browsing the Internet (i.e browser is left open to a blank page). This cookie is when the pre-bundled Google ‘Safe Browsing’ background service automatically communicates with Google in order to update anti-phishing/anti-malware blacklists.
In a survey performed Feb 13, 2012, I noticed that 65 of the Top 100 Internet sites had a ‘.google.com’ PREF cookie even though the browser had 3rd party cookies blocked and had not directly connected to Google.com in a 1st party setting. After further testing, I determined that this cookie was set simply on account of the browser being opened, even when it hasn’t actually visited any websites.
This ‘.google.com’ PREF cookie is also present in Firefox if 3rd party cookies are allowed (the default) but does not appear in Chrome regardless of cookie privacy settings (more below).
Why This is Significant
The ‘.google.com’ PREF cookie enables cross-site tracking by Google’s +1 buttons. This button is similar in functionality to Facebook’s ‘Like button’ and other social widgets, which have been the subject of much attention for their ability to profile users across the web. As with the ‘Like button’, the PREF cookie and corresponding referer header (which reveals the page the user is browsing) is transmitted to Google anytime there is a +1 button present on a webpage (without the user taking any action).
However, in this case, the pseudonymous tracking cookie is essentially preloaded with Safari browsers and cannot be disabled by consumers without disabling core browser security features such as anti-phishing protection or blocking ALL cookies. Attempting to delete this cookie will simply result in a new cookie being placed the next time the service updates.
Prevalence of +1 Buttons
There were +1 buttons on 44 of the 100 sites based on data collected February 13, 2012. However, these buttons were not present when the browser identifies itself as an iPhone browser. More broadly, BuiltWith shows ~400k domains using +1 buttons and Blekko shows ~450k although both figures are likely not comprehensive.
The cookie that is set is the standard google.com ‘PREF’ cookie, set to expire after 2yrs. For example:
PREF=ID=c61655f0547ffc67:TM=1329628258:LM=1329628258:S=MIzIQNYw6lgIaJL-;expires=Tue, 18-Feb-2014 05:10:58 GMT; path=/; domain=.google.com
Google states that the PREF cookie is used to ‘identify your computer and tells us your preferences’ in this video. There’s also an older post on this cookie by Peter Fleischer discussing reducing the expiration date on this cookie to improve privacy. I think it’s probably worth digging a bit more into the exact use of this cookie (relative to the other ‘.google.com’ cookies) but at the very least, it contains a unique identifier.
How to Replicate
1. Configure Safari to ‘Block cookies – From third parties and advertisers’ (default)
2. Set the ‘Safari Start Page’ to be an ‘Empty Page’ (under General settings)
3. Reset Safari (from the Safari menu)
4. Do not browse or connect to any websites, simply wait a little while (say ~30minutes) with Safari open
5. Look for the presence of a .google.com PREF cookie after about 30 min using Safari Cookie Cutter or just the normal cookie dialogue.
(Firefox methodology is the same although this can be blocked if you set FF to block 3rd party cookies)
One of the challenges is determining whose privacy statements apply here since the Safe Browsing functionality is provided by default as part of Apple’s Safari browser.
“Most browsers are initially set up to accept cookies, but you can reset your browser to refuse all cookies or to indicate when a cookie is being sent. However, some Google features and services may not function properly if your cookies are disabled”
“maintain logs of Safe Browsing usage for a period of two weeks. This allows us to improve the quality of the service, and guard against denial-of-service (DoS) attacks. After a period of two weeks, the original logs are discarded and only aggregate usage information is retained.”
However there is no specific mention the +1 button even though tracking for non-authenticated users is facilitated via the same PREF cookie.
Internet Explorer utilizes Microsoft’s own anti-phishing system called ‘SmartScreen’ and doesn’t suffer from the same ‘automatic Google cookie’ issue described above. However, Microsoft’s mechanism isn’t without its own privacy concerns, since it transmits the ENTIRE visited URL to Microsoft (the Google system uses a hashed portion). This is also probably worth digging into at some point.
Google’s own Chrome browser obviously also uses the ‘Safe Browsing API’ as it’s developed in house. However, of the three, Chrome is the only browser that currently (as of v17) blocks the setting of Google’s own ‘PREF’cookie as the result of the Safe Browsing API. There is also a lengthy thread on the Chromium developer mailing list discussing the lack of a Safe Browsing cookie and the need for it in order to assist with security and service management. The word ‘privacy’ doesn’t appear anywhere on that page.
There is a lengthy thread dating back to 2007 on the Mozilla developer mailing list discussing the issue of automatic Google cookies being set in Firefox 2.0, described by one developer as “WONTFIX” and a “privacy invasion”. While this has been a known issue for nearly 5yrs, the bug was only recently re-opened after the WSJ reached out to Mozilla about this matter.
In this discussion, multiple Mozilla engineers expressed concerns about Google’s ability to track individuals IP address history using this cookie and suggested that either a cookie not be used, or that the cookie be sandboxed. Reed Loden summarizes the issue:
“I don’t think the problem here is that safe browsing sends _a_ cookie, but instead that it sends the main google.com cookie (that ties the user to iGoogle, GMail, etc.). If safe browsing had its own separate cookie and did not send any other google.com cookies along with it (basically, it was sandboxed), this wouldn’t be a problem and nobody would be complaining about privacy issues.”
Ian Fette, a Senior Product Manager at Google, responded:
“Is it possible to use a different cookie? Probably, but really what would this accomplish? First of all, the privacy policies in place explicitly state what we can and can not do with the logging data, and what you are talking about is prohibited.”
He goes on to say:
“We retain the original logs for only two weeks. We are not trying to spy on users, build a profile of all the URLs that you have visited, etc. We have determined that two weeks of logs gives us enough data to monitor the quality of our service and get the metrics we need – after that two weeks, the logs are dropped, and all we retain are statistics that we’ve aggregated, e.g. how many users did we have on day X, how many users were how out of date on day X, how many QPS did we have at peak, how much bandwidth, etc. Nothing about individual users.”
Note this discussion took place before Google developed a +1 button and enhanced their ability to link user’s web browsing activity to this cookie. As demonstrated in the traffic captures below and in Google’s recent privacy policies, Google does have the ability to “profile of all the URLs that you have visited” and their updated privacy policies reserve them this right.
The current version of Firefox only suffers from the ‘automatic cookie’ if 3rd party cookies are not blocked (which is the default setting effecting most users). If 3rd party cookies are set to ‘block’, the same safe-browsing connection is still made but the browser does not store the resultant ‘PREF’ cookie. After being contacted by the WSJ, Sid Stamm posted Mozilla’s position on this issue describing their use of Safe-Browsing and defending Google’s use of the Safe-Browsing cookie, even though Mozilla is simultaneously working to a privacy feature that isolates this cookie from being used in 3rd party tracking.
Finally, it’s worth noting that all 3 browsers that use Google Safe-Browsing also use Google’s ‘Search Suggestions’ feature that allows users to ‘auto complete search queries as you type’. This feature is similar in function as Safe-Browsing in that it’s pre-bundled with the browser and that it uses Google services. However, even though ‘Search Suggestions’ requires that the browser to communicate with Google.com services, Google doesn’t attempt to set a cookie in response to these HTTP requests. As with Chrome’s blocking of the PREF cookie, it’s clear that these services could be provided in a privacy-friendly manner, such as not requiring a cookie to be set but Google has opted to set a cookie anyway.
APPENDIX 1 – Traffic logs Feb 18 2012
Tests were performed using OSX 10.7.3/Safari 5.1.3 and also verified in OSX 10.5.8/Safari 5.0.3.
In all test, the instructions above were used.
HTTP REQUEST: POST_http://safebrowsing.clients.google.com/safebrowsing/downloads ?pver=2.2&client=Safari&appver=5.1.3 <- 200 application/vnd.google.safebrowsing-update, 1.12kB goog-phish-shavar;a:187077-200473:s:88183-93162goog-malware-shavar;a:53419-69371:s:59904-76297
HTTP RESPONSE: Content-Type: application/vnd.google.safebrowsing-update Set-Cookie: PREF=ID=c61655f0547ffc67:â„¢=1329628258:LM=1329628258:S=MIzIQNYw6lgIaJL-; expires=Tue, 18-Feb-2014 05:10:58 GMT; path=/; domain=.google.com X-Content-Type-Options: no sniff ...a bunch of safebrowsing hashes...
PLUSONE BUTTON HTTP REQUEST: GET_https://plusone.google.com/_/+1/fastbutton?url=http%3A%2F%2Fwww.drugs.com%2Fcdi%2Flyrica.html&... <- 200 text/html, 1.67kB Host: plusone.google.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.53.11(KHTML, like Gecko) Version/5.1.3 Safari/534.53.10 Referer: http://www.drugs.com/cdi/lyrica.html Cookie: PREF=ID=c61655f0547ffc67:â„¢=1329628258:LM=1329628258:S=MIzIQNYw6lgIaJL-
APPENDIX 2 – Top 100 Sites with Google Plus Buttons – Feb 13 2012
01. google.com 10. wordpress.com 12. answers.com 14. blogspot.com 15. huffingtonpost.com 17. blogger.com 20. ehow.com 23. aol.com 24. foxnews.com 29. weather.com 32. whitepages.com 33. comcast.net 34. godaddy.com 35. target.com 36. manta.com 37. thepostgame.com 45. bestbuy.com 47. chacha.com 49. att.com 53. legacy.com 55. bizrate.com 56. hubpages.com 57. dailymotion.com 62. jcpenney.com 63. tmz.com 64. squidoo.com 65. cnet.com 67. people.com 74. metrolyrics.com 78. americangreetings.com 79. barnesandnoble.com 83. bleacherreport.com 84. simplyhired.com 86. typepad.com 88. merriam-webster.com 90. wunderground.com 94. lycos.com 95. inbox.com 97. drugs.com 99. fandango.com 100. howstuffworks.com 000. wsj.com
The Google Cookie that Seems to Come out of Nowhere Wall Street Journal, February 28, 2012