Massive spying on users of Google's Chrome shows new security weakness

It's really funny that on native there are all sorts of well-established models for communication between applications, sharing of files, etc. There are per-file and per-folder permissions systems, there's per-user permissions, and programs can be run with differing levels of access. If an app running in an App Store style sandbox (available on both OS X and Windows) wants to get its paws on my Outlook inbox files, it has some hard work ahead of it, and that's pretty nice. Even outside of a sandbox, the tools available to a regular (non-administrator) process are relatively restricted which helps limit the mischief they can easily get up to.

And then on the web, you just load pages. Pages are pages, except ones that come over https get Special Privileges because the Chrome team decided that was the best way to decide whether user content could be trusted. And pages that load from the local filesystem are less trusted, because it's only safe if it's coming through a socket. Any content hosted on a given domain is just as trustworthy as other content on that domain, and most importantly - very importantly - if the end user installs an extension, it's very essential that the extension be able to easily exfiltrate every single byte of your gmail inbox. After all, pages are pages - why should gmail or my bank be special compared to any other website?

Nobody put any real thought into how to structure the permissions model to combat real security threats. WebExtensions (the de-facto Worse is Better standard) basically dumps a bunch of different features into the 'do anything' permission bucket and leaves it up to the user to decide whether to trust an extension, despite the fact that an extension's ownership can change at any time. If an extension starts out without requesting any permissions, requesting a new permission (to do something useful) will silently disable your extension for all your customers - so naturally, what people do is request every single permission from the beginning, and users click Install anyway.

It's positively grotesque that the warning for this is still "read and change all your data on the websites you visit", and that so many trivial things require it. Chrome still makes no effort to draw your attention to how very, very dangerous this permission is. Say what you will about the UAC trainwreck but at least the SmartScreen 'this software is suspect' popups are suitably scary Red or Yellow and large, legible text.

It is almost a 'stopping problem'. You can send any data by sending GET with data encoded in url path, without any query string. How is any sandbox supposed to detect if you are sending data or really just getting information (like updating adblock list).

It seems pretty reasonable. https://en.wikipedia.org/wiki/Download_Valley

> Hence the ambiguous PR statement.

There's nothing ambiguous about "is not used to identify or track individual users.". Any form of personalized ad tracking would require tracking individual users, by definition. So there's your answer. Your attempts to create weaseling where there isn't any, so that you can continue to exclaim about the potentials for tracking don't actually change the ambiguity of the statement.

> How do you know they're not using it for tracking

Well I mentioned upthread I work at Google, right? Let me ask a question:

Google has historically been notorious for not being able to keep things secret, especially controversial things. How is it that Google is managing to keep this major component of tracking, that has to touch multiple major products and involve various teams a secret?

> What is the "tracking" aspect?

See this post I made when X-Client-Header was introduced.

> But they claim [1] this X-Client-Data header is used for experimenting with Chrome, not for tracking.

They claim a lot of things. Sometimes they even modify their claims years after they first made them. Even if they were making 100% innocent claims now, they are not guaranteeing[2] they won't change how they use the data in the future.

> But you're claiming they're using it for tracking, so you're claiming they're lying...

Not at all - as I point out in [1], Google is saying they are tracking people with that header, but the claim is obfuscated by some blatant doublespeak and the hope that you only consider the X-Client-Header (or any other field with >0 bits of fingerprintable entropy) in isolation. That is never true, which Google also admits when e.g. they casually mention they can deduce a HTTP request's country of origin.

Asking if the X-Client-Data is "used for tracking" is the wrong question. They are tracking people using the combined set of all of the tiny pieces of data they are able to exfiltrate from you. Any specific piece of data isn't important; if that header was missing or corrupt, it's just a small amount of noise added to the already noisy correlations they do to fingerprint you to infer whatever they are interested in about your pattern-of-life.

[1] https://news.ycombinator.com/item?id=22236778

[2] https://news.ycombinator.com/item?id=18466647