1. Chrome is the only major browser not to support the Do Not Track header. Google is also the browser vendor whose bottom line would be most impacted if users could easily opt out of tracking. Coincidence?
While I welcome folks from the Chrome team to weigh in on the reasons for this, my own understanding is that adoption of this feature is being blocked by Google's Mountain View based policy team, and is not a decision that is in the hands of engineers.
Compare this to Chrome's absolutely spectacular record in the area of security, where folks like Adam Langley and Chris Evans have been able to ship innovative features that haven't worked their way through the standards process. Examples include HTTPS certificate pinning (that recently led to the discovery of MiTM attacks against Iranian users using the DigiNotar certs).
In the area of security, Chrome's engineers deploy whatever they think will help users. In the area of privacy, Google's lawyers and lobbyists are calling the shots.
(Also, there still isn't a working API to let others support DNT in Chrome. An API exists, I think, but it is quite buggy, AFAIK)
2. Blocking 3rd party cookies by default. Apple defaults to blocking 3rd party cookies, Chrome does not. Both are derived the same webkit core (yes, I know there is different code now), but when Google decided to create Chrome, they went with a different default than the one that Apple had already used -- one that hasn't led to websites breaking for Apple users.
Again, which browser vendors' bottom line would suffer if Chrome users could not easily be tracked? Google.
Let me be clear - I don't think that Chrome is engaging in any sneaky shenanigans to directly track users. No, that would be too obvious. Instead, Chrome just makes it easy for Google's other services to track users, when they stick with the deaults.
> 1. Chrome is the only major browser not to support the Do Not Track header. Google is also the browser vendor whose bottom line would be most impacted if users could easily opt out of tracking. Coincidence?
The Chrome team has already addressed this issue. The problem with Do Not Track is that it isn't clear what it blocks and what it does not. It is also pretty useless as most websites that survive using ads will never support the Do Not Track headers, so it's a faux solution to the problem. Google already offers a browser extension (Firefox, Chrome and IE) to block Google Analytics. Last but not least, there is a dashboard on Google to know what Google ads know about you and the possibility to delete this information.
I think what's really bad is that DNT headers offer a false sense of privacy when in fact no websites respect the headers. Google's alternative solutions have the upside of being very clear about what they accomplish for your privacy.
> 2. Blocking 3rd party cookies by default. Apple defaults to blocking 3rd party cookies, Chrome does not. Both are derived the same webkit core (yes, I know there is different code now), but when Google decided to create Chrome, they went with a different default than the one that Apple had already used -- one that hasn't led to websites breaking for Apple users.
Chrome's cookie code isn't derived from other code in WebCore; it's implemented in the platform layer. And it's intended to be as compatible as possible with the majority of the web. As for the privacy implications of third-party cookies, I think Michal covered the reality of the situation extremely well: http://lcamtuf.blogspot.com/2010/08/cookies-v-people.html
As a Firefox user who disables 3rd party cookies, this actually does break some sites. Signing in with your Google account to various blogs becomes impossible. Buying tickets online to the local puppet theater becomes impossible. That sort of thing.
If you don't like third party cookies then I encourage you to go to chrome://flags/ and Enable the 'Block all third-party cookies' experimental feature.
The DNT header is to be implemented by website developers (and they have nothing to gain by doing it). I understand that Google is better off without implementing this header, but I don't really think it would change anything if Chrome had it.
I agree on the cookies issue, though. Things like "Allow local data to be set (recommended)" make me kind of sad.
I tried to look at what chrome sends to google with wireshark, and there are quite a lot of connections made to google servers, but it's all encrypted (ssl). So I actually have no way to know what is sent to google.
Did someone make a detailed analysis of what info gets sent to google on a default install of chrome?
I noticed awhile back that even if you disable Chrome's safe browsing feature, Google still sends data to their server. I'm not sure if this is still the case today.
wow, I was assuming that everything is stored encrypted on Googles servers. Would be cool if someone could clarify this, as the explanation in the Google help is a bit vague IMHO.
Wow, that was an amazingly skillful non-denial denial. Notice how he never said Chrome does not collect user information. Because, as we all know, it does. I've often wondered how much it collects, by what mechanisms (including via third parties or analytics added by third parties) and to whom the information is available and under what circumstances. The statement from Mike West does not appear to shed any additional light on this; maybe it's answered elsewhere -- does anybody know? I've seen the Google Chrome TOS and wasn't able to get a clear picture from that.
BTW anyone in Mike's position still may not be privy to everything that is done with the data, as some data collection and sharing may be subject to national security orders that that most employees are not allowed to know about. So any statement his team makes about this should be couched with "to the best of our knowledge."
Chrome does not collect user information, unless you explicitly opt-in to sharing aggregated usage information and crash reports with Google. If you do opt-in to these metrics (and you have to opt-in, it's disabled by default), you can opt-out at any time via chrome://settings/advanced#metricsReportingEnabled
The data collected is available for you to peruse at chrome://histograms/
Fingerprinting is a problem, and it's difficult to address. There's been some discussion around mechanisms for disabling features to make the browser signature less unique, but it's a very tough problem.
Enabling click to play for plugins in Chrome is already possible and makes you much less trackable. You will get much less bits of identifying information in panopticlick because your fonts and some other things can't be read out without Flash or Java.
This is just a thing Chrome has to live with, it's a browser developed by a company that makes money selling user behavior to advertisers. You'd have to be stupid not to think this is a possibility.
Must be frustrating to the developers who know what it does and doesn't do though.
The trouble with privacy comments like this blog post is always the same: no matter what the current situation is or how good the intentions of the person making the comment may be, unless they are an executive with the authority to legally bind the company in question to a privacy policy that has real repercussions if subsequently violated, in the end anyone can still be screwed over on the whim of whoever has the data.
In this case, that "whoever has the data" has been publicly dismissive of fundamental privacy concerns up to and including CEO level, and has a business model built around extracting as much value as possible from that private data without regard for the privacy concerns of any individual.
The main dev on the WebRequest API sits right behind me, and is making steady progress. It's the first synchronous extension API that interacts with the network stack, and it's a nontrivial effort to get it running. I can assure you, however, that making life hard for privacy extensions is the exact opposite of what we're being paid to do.
Look at the progress on privacy-related APIs over the last year: WebRequest is coming along nicely, WebNavigation and ContentSettings are feature complete and in the final stages of polish, and Proxy went out to stable in Chrome 13. Privacy and Clear just landed in experimental, and we're iterating on them rapidly.
Engineers are actively working on APIs for this, but it's quite a bit more complicated than it may seem at first. Low-level capabilities like these need to be implemented such that they don't conflict with our extension permission model and general security posture. For instance, we don't want an extension with the WebRequest API to be able to prevent you from uninstalling it, or to manipulate other extensions and internal browser configuration.
At the end of the day Google is really not the company you have to be worried about - it's the ad networks. They are the ones implementing zombie cookies using the 10 or so methods of storage and the ones that directly sell your information to even seedier companies. I used to work for one so I know what goes on. This will always be a dance between smart developers usurping tracking efforts and smart developers coming up with new tracking methods.
I really don't understand the extreme sentiment that your info via cookies is the worst form of privacy breach there is. Why would you not be more concerned with the companies that charge $.50 per call to access an API that can fetch information on anyone that fills out a form ("Oh I never knew my neighbor only makes $48k a year")? I guarantee you these companies know more about you than Google, Twitter and Facebook (unless you post every thought ever, of course). Case in point, they knew my coworker's wife at the time was 4 months pregnant. Unless you can derive such information from searches (doubtful and completely not worth the effort) then this information obviously came from elsewhere. Perhaps, for instance, like the doctor's office.
I'm pretty sure Chrome send URLs to Google at least for indexing purposes. I've put up random pages on my websites, not linked to them anywhere at all but visited them in Chrome and then BAM - indexed soon after in search.
Chrome does not arbitrarily send URLs to Google. We go out of our way to avoid doing that, actually.
Look at the implementation of SafeBrowsing, for instance, which does some clever work with hashes to ensure that Google never knows exactly what URL you visited that triggered the warning. It would have been _much_ simpler to just send the URLs, I assure you.
When I had this happen, or when I heard this happen, there was always a reason that was far less sinister than initially thought.
* Public referrer logs created a backlink
* Somebody (else) published the URL
* Somebody (else) shared the URL
* You pinged the URL to search engines or other services.
* The URL appeared in your RSS feed
* The URL appeared in your sitemap
* Your pages URL ranges are easily guessable (/item.php?id=1007, /item.php?id=1008) and traversed by a search engine.
And more recently, something less innocuous: You simply added a Google +1 button to your pages.
When you add the +1 button to a page, Google assumes that
you want that page to be publicly available and visible
in Google Search results. As a result, we may fetch and
show that page even if it is disallowed in robots.txt.
IIRC, it has components of Google Toolbar built in. If you accessed those pages with a browser with the Google Toolbar you'd have experienced the same.
Usage statistics and crash reporting are strictly opt-in (and the default at install is opted out). There's also sync, but you must explicitly enable the feature and log in.
That leaves five other places where data is sent back to Google for things like search suggestions and malware detection. You can find an explanation of those features and instructions on disabling them here: http://www.google.com/support/chrome/bin/answer.py?answer=11...
If you don't like third party cookies then I encourage you to go to chrome://flags/ and Enable the 'Block all third-party cookies' experimental feature.
[+] [-] csoghoian|14 years ago|reply
1. Chrome is the only major browser not to support the Do Not Track header. Google is also the browser vendor whose bottom line would be most impacted if users could easily opt out of tracking. Coincidence?
While I welcome folks from the Chrome team to weigh in on the reasons for this, my own understanding is that adoption of this feature is being blocked by Google's Mountain View based policy team, and is not a decision that is in the hands of engineers.
Compare this to Chrome's absolutely spectacular record in the area of security, where folks like Adam Langley and Chris Evans have been able to ship innovative features that haven't worked their way through the standards process. Examples include HTTPS certificate pinning (that recently led to the discovery of MiTM attacks against Iranian users using the DigiNotar certs).
In the area of security, Chrome's engineers deploy whatever they think will help users. In the area of privacy, Google's lawyers and lobbyists are calling the shots.
(Also, there still isn't a working API to let others support DNT in Chrome. An API exists, I think, but it is quite buggy, AFAIK)
2. Blocking 3rd party cookies by default. Apple defaults to blocking 3rd party cookies, Chrome does not. Both are derived the same webkit core (yes, I know there is different code now), but when Google decided to create Chrome, they went with a different default than the one that Apple had already used -- one that hasn't led to websites breaking for Apple users.
Again, which browser vendors' bottom line would suffer if Chrome users could not easily be tracked? Google.
Let me be clear - I don't think that Chrome is engaging in any sneaky shenanigans to directly track users. No, that would be too obvious. Instead, Chrome just makes it easy for Google's other services to track users, when they stick with the deaults.
[+] [-] patrickaljord|14 years ago|reply
The Chrome team has already addressed this issue. The problem with Do Not Track is that it isn't clear what it blocks and what it does not. It is also pretty useless as most websites that survive using ads will never support the Do Not Track headers, so it's a faux solution to the problem. Google already offers a browser extension (Firefox, Chrome and IE) to block Google Analytics. Last but not least, there is a dashboard on Google to know what Google ads know about you and the possibility to delete this information.
I think what's really bad is that DNT headers offer a false sense of privacy when in fact no websites respect the headers. Google's alternative solutions have the upside of being very clear about what they accomplish for your privacy.
[+] [-] justinschuh|14 years ago|reply
Chrome's cookie code isn't derived from other code in WebCore; it's implemented in the platform layer. And it's intended to be as compatible as possible with the majority of the web. As for the privacy implications of third-party cookies, I think Michal covered the reality of the situation extremely well: http://lcamtuf.blogspot.com/2010/08/cookies-v-people.html
[+] [-] bzbarsky|14 years ago|reply
As a Firefox user who disables 3rd party cookies, this actually does break some sites. Signing in with your Google account to various blogs becomes impossible. Buying tickets online to the local puppet theater becomes impossible. That sort of thing.
[+] [-] cskau|14 years ago|reply
Simple as that.
[+] [-] Wilya|14 years ago|reply
I agree on the cookies issue, though. Things like "Allow local data to be set (recommended)" make me kind of sad.
[+] [-] y0ghur7_xxx|14 years ago|reply
Did someone make a detailed analysis of what info gets sent to google on a default install of chrome?
[+] [-] buddydvd|14 years ago|reply
http://superuser.com/questions/236637/how-to-disable-google-...
[+] [-] wslh|14 years ago|reply
This is hooking the application so you don't have issues with sniffing SSL.
[+] [-] pagekalisedown|14 years ago|reply
http://www.tcpcatcher.org/
http://www.tcpcatcher.org/monitoring_SSL.php
It effectively helps you to man-in-the-middle-yourself.
[+] [-] dchest|14 years ago|reply
Edit: in Chrome 15 (beta) just found an option "Encrypt all synced data". Yay!
[+] [-] mike-cardwell|14 years ago|reply
[+] [-] codecaine|14 years ago|reply
[+] [-] natch|14 years ago|reply
BTW anyone in Mike's position still may not be privy to everything that is done with the data, as some data collection and sharing may be subject to national security orders that that most employees are not allowed to know about. So any statement his team makes about this should be couched with "to the best of our knowledge."
[+] [-] mikewest|14 years ago|reply
The data collected is available for you to peruse at chrome://histograms/
All the data that Google collects is subject to the privacy policies at http://www.google.com/intl/en/privacy/, and Google of course complies with SafeHarbor regulations (http://en.wikipedia.org/wiki/International_Safe_Harbor_Priva...)
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] fjarlq|14 years ago|reply
Can Google do anything to help make browsers appear to be less unique, and thus less trackable?
I'm talking about http://panopticlick.eff.org/
I'd much rather find a technical solution to that than a political non-solution.
[+] [-] mikewest|14 years ago|reply
Take a look at https://trac.webkit.org/wiki/Fingerprinting for some discussion around what would be required. It's very, very nontrivial.
[+] [-] jannes|14 years ago|reply
[+] [-] freshhawk|14 years ago|reply
This is just a thing Chrome has to live with, it's a browser developed by a company that makes money selling user behavior to advertisers. You'd have to be stupid not to think this is a possibility.
Must be frustrating to the developers who know what it does and doesn't do though.
[+] [-] Silhouette|14 years ago|reply
In this case, that "whoever has the data" has been publicly dismissive of fundamental privacy concerns up to and including CEO level, and has a business model built around extracting as much value as possible from that private data without regard for the privacy concerns of any individual.
[+] [-] justinschuh|14 years ago|reply
[+] [-] notbitter|14 years ago|reply
"As Chrome's resource blocking API is not yet comprehensive, some elements may execute." - http://www.ghostery.com/download
[+] [-] mikewest|14 years ago|reply
Look at the progress on privacy-related APIs over the last year: WebRequest is coming along nicely, WebNavigation and ContentSettings are feature complete and in the final stages of polish, and Proxy went out to stable in Chrome 13. Privacy and Clear just landed in experimental, and we're iterating on them rapidly.
(Details on the state of each are available at http://code.google.com/chrome/extensions/trunk/experimental....)
[+] [-] justinschuh|14 years ago|reply
[+] [-] yellowbkpk|14 years ago|reply
[+] [-] methodin|14 years ago|reply
I really don't understand the extreme sentiment that your info via cookies is the worst form of privacy breach there is. Why would you not be more concerned with the companies that charge $.50 per call to access an API that can fetch information on anyone that fills out a form ("Oh I never knew my neighbor only makes $48k a year")? I guarantee you these companies know more about you than Google, Twitter and Facebook (unless you post every thought ever, of course). Case in point, they knew my coworker's wife at the time was 4 months pregnant. Unless you can derive such information from searches (doubtful and completely not worth the effort) then this information obviously came from elsewhere. Perhaps, for instance, like the doctor's office.
[+] [-] asadotzler|14 years ago|reply
Google is the largest ad network on the Web.
[+] [-] chico_dusty|14 years ago|reply
[deleted]
[+] [-] philfreo|14 years ago|reply
[+] [-] mikewest|14 years ago|reply
Look at the implementation of SafeBrowsing, for instance, which does some clever work with hashes to ensure that Google never knows exactly what URL you visited that triggered the warning. It would have been _much_ simpler to just send the URLs, I assure you.
[+] [-] blauwbilgorgel|14 years ago|reply
* Public referrer logs created a backlink
* Somebody (else) published the URL
* Somebody (else) shared the URL
* You pinged the URL to search engines or other services.
* The URL appeared in your RSS feed
* The URL appeared in your sitemap
* Your pages URL ranges are easily guessable (/item.php?id=1007, /item.php?id=1008) and traversed by a search engine.
And more recently, something less innocuous: You simply added a Google +1 button to your pages.
http://www.google.com/support/webmasters/bin/answer.py?answe...[+] [-] scott_s|14 years ago|reply
[+] [-] danmaz74|14 years ago|reply
[+] [-] beaumartinez|14 years ago|reply
[+] [-] Mithrandir|14 years ago|reply
[+] [-] kierank|14 years ago|reply
[+] [-] kierank|14 years ago|reply
[+] [-] Slimy|14 years ago|reply
Disclosure: I use Chrome (default) and IE9 (whenever Chrome fails).
[+] [-] justinschuh|14 years ago|reply
That leaves five other places where data is sent back to Google for things like search suggestions and malware detection. You can find an explanation of those features and instructions on disabling them here: http://www.google.com/support/chrome/bin/answer.py?answer=11...
[+] [-] fhewifewfjewao|14 years ago|reply
[+] [-] poona|14 years ago|reply
Simple as that.
[+] [-] budman|14 years ago|reply
http://www.srware.net/en/software_srware_iron_chrome_vs_iron...
[+] [-] aboodman|14 years ago|reply