
Chrome Privacy - czottmann
http://mikewest.org/2011/09/chrome-privacy
======
csoghoian
2 responses:

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
> 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.

~~~
csoghoian
Some ad networks already respect DNT. But you are right, many of the big ones
don't. While Google can't force most of the ad networks to respect DNT, Google
can choose to respect the header, which is currently sent by 5% of Firefox
users, when it is received by the Doubleclick and Google Analytics servers.

Instead of supporting a header that millions of consumers are already sending,
you instead offer a browser add-on for analytics, and "keep my opt outs" for
ad network opt out cookies.

The signal sent by a consumer setting the DNT flag in their browser is just as
clear as a consumer installing your analytics opt out plugin, or obtaining the
doubleclick opt out cookie.

You could, right now, respect the DNT header as you currently respect your own
opt out mechanisms, but you don't.

I get that Google is not a charity. I get that Do Not Track (or any other
mechanism that makes it easy for consumers to avoid tracking) threatens your
bottom line. What I would prefer though, is honesty.

Please just admit that you want to make it difficult for consumers to opt out,
and that a single, easy to use mechanism built into the browser is something
you want to avoid at all costs, even if that means you are ignoring millions
of consumers' intent.

~~~
mikewest
1\. I wrote Keep My Opt-Outs. It has exactly the practical effect you're
looking for with regard to DoubleClick and about 60 other ad networks _right
now_. Installing it opts you out of interest based tracking in exactly the way
that clicking the DNT box in Mozilla doesn't (yet):
[https://chrome.google.com/webstore/detail/hhnjdplhmcnkiecamp...](https://chrome.google.com/webstore/detail/hhnjdplhmcnkiecampfdgfjilccfpfoe)

2\. Google's participating openly in <http://www.w3.org/2011/tracking-
protection/> to work out what DNT means in a detailed sense, so that when
users send a header, either via a checkbox or via an extension, there's
agreement about what the practical impact is. I'm not sure it's reasonable to
expect much more than that right now.

~~~
csoghoian
1\. Keep my opt outs is not a serious privacy enhancing technology. If it
were, it would be built into the browser by default, and enabled via a simple,
easy to discover UI (or better, enabled by default).

Keep My Opt Outs is largely political propaganda, or if you will, privacy
theater. It gives your DC people something to talk about when they testify
before Congress or the FTC. It allows them to say, "look, we do offer users
the ability to opt out", while knowing that few users will seek it out and
turn it on.

Compare, for example, the 5% of Firefox users who have enabled DNT, vs. the
62k users of KMOO. That number of users is pathetic, given how many people use
Chrome.

2\. Since when does something need to have gone through the standards process
for Google to ship it in Chrome?

Consider, for example, what Adam Langley wrote when he added support for
DNSSEC certificates to Chrome:

"I'm also going to see how it goes for a while. The most likely outcome is
that nobody uses [this feature] and I pull the code out in another year's
time." See: <http://www.imperialviolet.org/2011/06/16/dnssecchrome.html>

Google's approach to security (and in many other areas) is to iterate,
quickly, see what works, and if it doesn't, kill it off.

Likewise, Chrome supports an early draft of WebSockets. The spec isn't
finalized yet though. Google added support to a draft spec, and then will
update Chrome to the final spec once it is done. See:
[http://blog.chromium.org/2010/06/websocket-protocol-
updated....](http://blog.chromium.org/2010/06/websocket-protocol-
updated.html)).

It seems to only be in the area of privacy where Google wants to wait until
technologies have gone through the slow standardization process. In the mean
time, while you wait for things to work their way through the W3C, Google's ad
business continues to build detailed behavioral profiles on Internet users.

The longer the W3C takes, from Google's perspective, the better.

Look - I get that it must be frustrating to be a privacy engineer working on
Chrome, when upper management won't let you deploy serious privacy enhancing
features to users. I get that it must be embarrassing to work on the only
browser that doesn't support Do Not Track (usually, IE is last to the party).
What I don't get, is why you tout features like KMOO and Google's involvement
in the W3C process as though you expect them to be taken seriously.

Google is not committed to enabling users to easily protect themselves from
Google's widespread collection of their private data. To argue otherwise is
foolish.

~~~
StephenPurpura
DNT is privacy theater too. It encourages a business model shift and research
into data mining that has the same effect as tracking but without an
implementation that would violate DNT. DNT does not solve the problem of
ubiquitous online tracking. That problem is most likely unsolvable.

On my home network, Google, Facebook, and Twitter compete for the most web
tracking next to my ISP's own capabilities. Traffic weighted, Facebook is now
the leader in my household.

------
y0ghur7_xxx
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?

~~~
buddydvd
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.

[http://superuser.com/questions/236637/how-to-disable-
google-...](http://superuser.com/questions/236637/how-to-disable-google-
chrome-from-sending-data-to-safebrowsing-cache-google-com-a)

~~~
huhtenberg
Yep, this still appears to be the case. It establishes a long-lived SSL
connection to one Google's servers few seconds after the start. If the
connection is forcefully killed (e.g. with SysInternal's TcpView), it won't be
re-established, but needing to kill it every time I need to use Chrome is
really annoying.

It is also _the_ reason why I have Chrome updates permanently disabled - I
don't trust Chrome enough to let it run anything in a background.

~~~
mikewest
Can you file a bug at <http://new.crbug.com/> please? That doesn't sound like
the behavior I'd expect.

~~~
huhtenberg
Sorry, I can't. It wants me to log in with Google ID which I don't and won't
have.

~~~
mikewest
Ok. Would you mind dropping me an email (mkwst@chromium.org) with details? I'm
happy to file the ticket for you.

~~~
huhtenberg
Well... :) That would require setting up a dummy email account and what not,
and that's a bit too much hassle. It'd be far more prudent if you'd remove
Google ID requirement in front of the bug repository. I frankly don't
understand why it is needed in the first place, at least for browsing the repo
that is.

~~~
magicalist
you can browse just fine: <http://code.google.com/p/chromium/issues/list>

I'm pretty sure all the browser bugtrackers require an account to file a bug.

------
dchest
According to Chrome help
([http://www.google.com/support/chrome/bin/answer.py?hl=en&...](http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=165139&from=165138&rd=1)),
only passwords are encrypted, not bookmarks, autofill data, apps, extensions,
history, preferences, and themes. Is this still true?

Edit: in Chrome 15 (beta) just found an option "Encrypt all synced data". Yay!

~~~
mike-cardwell
Confused at why no-encryption would even be an option for this data.

~~~
fjarlq
Hmm, this feature seems buggy. I just tried enabling the option and it never
finished. Had to kill it.

Filed a bug report: <http://crbug.com/97939>

~~~
mikewest
Thanks. It's now sitting in the Sync team's queue.

------
natch
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."

~~~
mikewest
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/

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...](http://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles))

~~~
asadotzler
"Chrome does not collect user information, unless you explicitly opt-in to
sharing aggregated usage information and crash reports with Google"

OR if you don't opt in to anything and you simply type some things into your
Chrome Omnibox which get sent to Google for suggestions, or if you don't opt
in to anything and you simply mistype a URL and that send data to Google for
more helpful error pages, or if you don't opt in to anything and Google's
phishing and malware service collects sites you're visiting. Oh, and where you
don't opt in to RLZ, but you get it anyway.

As I said on Twitter, I'm not really bothered by these things, but it's
disingenuous to pretend they don't exist or to respond to peoples' privacy
concerns by insisting that aggregate usage stats is the only information
Google collects.

~~~
magicalist
I see (what I imagine to be) both perspectives. If you're a programmer, you
think _of course_ suggest is talking to google -- that's pretty much the only
way it can work. That doesn't really fall under whatever mysterious third-
party bodies collecting your browser history that the OP was trying to FUD up
the place with.

On the other hand, most people _don't_ stop to think that search suggest is
sending each character to get new suggestions, which _is_ "user information"
that is collected (though admittedly the privacy policy does say the logs are
anonymized within 24 hours). So it really should be in the list of information
that Chrome collects, even if it feels self evident to some.

> As I said on Twitter, I'm not really bothered by these things

Well I hope not, considering if you replaced parts of your comment:

"if you don't opt in to anything and you simply type some things into your
[Firefox search bar] which get sent to Google for suggestions, or if you don't
opt in to anything and you simply [type a malformed] URL [into the AwesomeBar}
and that sends data to Google for [a search page], or if you don't opt in to
anything and [Firefox queries of] Google's phishing and malware service
collects sites you're visiting"

it still applies. _and_ Mozilla essentially sells that information by
selecting a third party default based on some non-transparent bid process :P

Personally, I'm just sick of the FUD, especially in comments on an article
asking to stop the insinuations and actually list problems so they can be
fixed. There are and probably always will be defaults some people disagree
with (and feel are doing users a disservice since users rarely change
defaults), but there is a world of difference between that and "I don't need
to give evidence, I can just feel it. We all know Chrome is etc etc"

~~~
bzbarsky
There is no bid process. Mozilla sets the default search engine to whatever
search engine provides the best search results for its users, as far as that
can be determined.

This is why the search engine is different in different locales; for example
Yandex has way better Russian search results than Google, and hence is the
default search engine in the Russian localization of Firefox.

~~~
blasdel
Mozilla makes a 9 digit income in referral fees from setting search engine
defaults, almost exclusively from Google.

At least they no longer solicit donations, but for them to pretend they're
viable without that _omg privacy violating_ teat to suckle at is just gauche.

~~~
bzbarsky
The major search engine providers all have referral fee programs.

So while Mozilla does make money from those, it would do that no matter which
of the major search engines it defaulted to, no?

And note that there is a reason the search field is not merged with the url
bar in Firefox. Precisely because it would be a privacy violation.

------
fjarlq
Question for mikewest:

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.

~~~
jannes
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.

~~~
fjarlq
You sure about that?

I already do click-to-play for plugins in Chrome, and it doesn't seem to help
much. According to Panopticlick, there are 19.75 bits of data in my Browser
Plugin Details, and for the "value" it describes all the plugins I have
enabled.

Also with click-to-play enabled, Panopticlick can see my system fonts (20.75+
bits of data, one in 1,769,122 browsers has this value). Apparently
Panopticlick is not using one of my plugins to get that data... I haven't
whitelisted eff.org or otherwise enabled plugins there.

Looks like Panopticlick is using JavaScript/CSS font detection methods:
<http://www.lalit.org/lab/javascript-css-font-detect/>

Hmm... Panopticlick reports "No Flash or Java fonts detected" when I try it
with IE9 on the same system. Is IE9 doing something to block Javascript/CSS
detection of those fonts, or does Panopticlick have a bug with IE9 or what?
Looks like that method worked for IE6/7...

~~~
fjarlq
Whoops, I have to take back what I wrote above.

Somehow my Chrome had lost its click-to-play setting. I don't remember
unsetting that... hrm.

Anyway, with click-to-play enabled you are correct: Panopticlick cannot see my
fonts. Sorry about the confusion.

However, with click-to-play definitely enabled, Panopticlick can still see my
Browser Plugin Details.

------
freshhawk
Ah, the old "no no, just trust us" defense.

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.

~~~
justinschuh
We put the source out there and try to be as transparent as we reasonably can.
In the end though, people make their own decisions.

~~~
azakai
One problem is that Chrome is not open source - Chromium is. But 99% of people
use Chrome, and there is no way to build Chrome from source to be sure what
code is running.

We have to take Google's word for it that Chrome is identical to Chromium as
regards privacy, and as others stated, Google's business interest is clearly
to track user information, not to respect their privacy.

~~~
justinschuh
I've already explained why this framing is incorrect:
<http://news.ycombinator.com/item?id=3034628>

So, go ahead and check out a release branch, set the "Official" build flag
yourself, wait anywhere from 2-8 hours for the binaries to get built, and
verify it against the bits we ship.

~~~
azakai
Thanks for the information, I have never seen this stated officially anywhere.

So one can build Chromium with "Official", then add some DLLs (Flash, etc.),
and get something 100% identical to Chrome?

Edit: And is there an official statement of this somewhere?

~~~
justinschuh
I went through it and there's still some ugly hackery involved on Windows.
These are technical issues (e.g. how ffmpeg is compiled via MinGW), but they
make it complicated to generate a non-branded, psuedo-official build. That
said, all the pieces you need (minus the closed-source plugins) appear to be
in the repository and can be built and compared against an official release.
It could definitely be made easier, but would require some non-trivial
engineering to do so.

------
notbitter
For whatever reason, Chrome does seem to make life hard for privacy extensions
like Ghostery:

"As Chrome's resource blocking API is not yet comprehensive, some elements may
execute." - <http://www.ghostery.com/download>

~~~
mikewest
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.

(Details on the state of each are available at
[http://code.google.com/chrome/extensions/trunk/experimental....](http://code.google.com/chrome/extensions/trunk/experimental.html))

~~~
qjz
Is it possible to restrict requests to the host in the URL I'm visiting? XSS,
DNT, etc. become much less of an issue when you can block all external
resources requested by a page.

~~~
mikewest
That will be possible with the WebRequest API, yes:
[http://code.google.com/chrome/extensions/trunk/experimental....](http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html)
For example, you'd be able to intercept and block network requests from a
particular tab that didn't hit the same domain.

The API in experimental now, so download a dev release of Chrome/Chromium,
enable experimental APIs via `about:flags`, and start filing bug reports. :)

------
methodin
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.

~~~
asadotzler
"At the end of the day Google is really not the company you have to be worried
about - it's the ad networks."

Google is the largest ad network on the Web.

------
philfreo
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.

~~~
beaumartinez
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.

~~~
aboodman
You recall incorrectly. Chrome does not send the URLs of pages you visit to
Google for indexing, or for any other reason.

Please see the privacy policy. It answers these questions quite clearly:

<http://www.google.com/intl/en/privacy/>

~~~
WalterGR
<http://www.google.com/chrome/intl/en/privacy.html>

...

> When you type URLs or queries in the address bar, _the letters you type are
> sent to your default search engine_ so the Suggest feature can automatically
> recommend terms or URLs you may be looking for. If you choose Google as your
> search engine, Google Chrome will contact Google when it starts so as to
> determine the best local address to send search queries. _If you choose to
> share usage statistics with Google and you accept a suggested query or URL,
> Google Chrome will send that information to Google as well_. You can disable
> this feature as explained here.

...

> If you navigate to a URL that does not exist, _Google Chrome may send the
> URL to Google_ so we can help you find the URL you were looking for. You can
> disable this feature as explained here.

...

> If you enable the optional AutoFill feature, which automatically completes
> web forms for you, _Google Chrome will send Google limited information about
> the structure of pages that have web forms and information such as the
> arrangement of the form_ so that we can improve our AutoFill service for
> that page.

(end excerpts)

Could you give us more information about the AutoFill feature? Does it send
the URL along with the listed information? Does it do this for every URL that
contains a web form?

------
Mithrandir
Why not just use Chromium?

------
kierank
The same thing also applies to Android.

~~~
kierank
Not entirely sure why I'm being downvoted but the same privacy concerns should
apply to Android as well as Chrome.

------
Slimy
I thought it was general knowledge that the closed-source Chrome sends (some)
data back to Google while the open-source Chromium does not.

Disclosure: I use Chrome (default) and IE9 (whenever Chrome fails).

~~~
fhewifewfjewao
chromium contains RLZ identifier

~~~
justinschuh
The RLZ identifier is present only if Chrome is installed through some sort of
third-party deal like a system or software bundle. If you install the stock
Chrome from Google it's not present. You can find a good overview of RLZ here:
<http://blog.chromium.org/2010/06/in-open-for-rlz.html>

------
poona
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.

Simple as that.

------
budman
Just use Iron.

[http://www.srware.net/en/software_srware_iron_chrome_vs_iron...](http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php)

~~~
aboodman
<http://chromium.hybridsource.org/the-iron-scam>

~~~
budman
Interesting. Thanks

