I don't know if this is something that can be "fixed". FWIW: https://www.privateinternetaccess.c...s-the-importance-of-privacy-defense-in-depth/ https://code.google.com/p/chromium/issues/detail?id=500922#c6
Well, this specific case can be fixed as the Chromium developers added a build flag to disable hotwording (which is, e.g., used for the Arch Linux Chromium package). But I agree that this is probably a general problem. I assume the best counter-measure right now is blocking behind-the-scene requests in uMatrix. I've seen a similar case mentioned in the uMatrix thread some weeks ago.
I just went through all the Chrome extensions (on Fedora) and there was a Google Wallet extension - not listed as an app or extension anywhere and a "hotword" extension /home/opm/.config/google-chrome/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg - hotword /home/opm/.config/google-chrome/Default/Extensions/nmmhkkegccagdldgiimedpiccmgmieda google wallet The next time I update stable I will check the extensions to see if they automatically return, most likely they will. There are no flags in Chrome to disable these.
Yes, the Google Wallet extension was the one mentioned in the uMatrix thread. And it couldn't install because behind-the-scene requests were blocked. This confirms that one should block those requests by default. Let's not forget, though, that Mozilla does something similar in Firefox with the OpenH264 video codec plugin from Cisco which is installed automatically, too. If you don't want to use it you have to disable it manually.
Also see http://www.ghacks.net/2015/06/19/go...r-dropping-binary-code-in-chromium-for-linux/ How is this not spyware? Edit: How is “Ok, Google” not spyware in Chrome? That's a much larger issue than Chromium.
I'm not sure if it qualifies as spyware if "OK Google" is unchecked by default but I agree that this shouldn't have happened in Chromium. Regarding Chrome: I don't see this checkbox at all. Is it only visible if that extension was downloaded and installed? This was probably prevented in my case by blocking behind-the-scene requests in uMatrix.
I deleted these two hidden extensions last night and the memory for a tab being open skyrocketed so I removed it and removed the files that stay behind (with those remaining the same problem replicated) & reinstalled Chrome - it's back to normal now. I always have hyperlink auditing off in Chrome:Flags but I checked them off in uMatrix & ublockO now also. Do I/we trust that disabling that in Chrome:flags actually disables it? Google should just allow them to be disabled from the get go. Regardless Gorhill's extensions have this covered. They are in a league all by themselves for Chrome/Chromium.
As I read comments from Google staff, there is no checkbox in Chrome because "OK Google" is baked into the closed-source binary, and there's no way to turn it off. I don't know uMatrix. But it's easy enough to test for "OK Google" with Wireshark. Mostly it just confirms my belief that no software touched by Google can be trusted, even "open-source" derivatives. Google blindsided Linux maintainers about "OK Google", and were totally dismissive after getting caught. What else have they done?
Not to get off topic, but where can I find out about what Chrome and Chromium does for their Windows releases that is privacy related? I'm assuming Google pushes the edge of the envelope as far as possible with their Chrome and Windows.
Yes, that's possible. I can't see it in Chomium either but that's probably because the Arch Linux version is now built using that build flag. Perhaps the Chromium developers didn't see the issue as hotwording was disabled by default? Anyway, as mentioned above Firefox also installs the OpenH264 video codec plugin from Cisco automatically, and from v. 38 the Firefox Windows version automatically downloads Adobe Primetime Content Decryption Module (CDM) for DRM playback through Encrypted Media Extension (EME) which is enabled by default. Is installing those binaries really better privacy-wise compared to what happened in Chromium? I don't think so.
Does PaleMoon do the same thing since it is a firefox derivative? What about k-meleon? I'd like to find a decent web browser that does not pull these sorts of stunts, if possible.
Hmm. I find myself wondering what TCP or UDP port the communications are on. If it's via Google's new protocols, it would be UDP 443 and 5228 (IIRC), in the background, and could be blocked by a router. If it's port 80, one could use a transparent proxy to block it. For SSL traffic on 443 it would be more difficult though. (Note that I would not trust a local software firewall to block this stuff on Linux; Chromium uses setuid binaries for the sandbox, which could theoretically undo firewall settings, and anyway I think the Chrome devs are more clever than I am...) Have to say BTW that I find this a bit shocking. Which, now I think of it, might be a good measure of how effective Google's PR is. I mean, they're a freaking ad company, why should they be considered any more trustworthy than DoubleClick? (Oh wait, they own DoubleClick now. Hurray.) I'd also question how kindly Uncle Sam would take to this (illegal wiretapping by someone else, hello?) but I'm not optimistic; historical actions against such large companies have basically amounted to slaps on the wrist.
I rejected Chrome years ago due to bad behavior. My judgment of it hasn't changed much. It is seductive on the outside but completely untrustworthy from a privacy perspective.
Meh.... I don't think so. Once a company does something REALLY stupid it automatically loses all my trust. IMO, the Debian development team should pull Chromium out of "Main" repo and move it to "Contrib" or (better) "Non-free" repositories.
Iceweasel does not download this binary blob from cisco. That's possibly the case with GNU Icecat. They are all fully functional firefox derivative with rebrandings and certain modifications like not allowing the cisco binary to be even downloaded. Ofcourse, they are options if you use Linux. Delete ~/.mozilla/firefox/*/gmp-gmpopenh264/ directory and changing "media.gmp-manager.url" value to "data:text/plain," for not downloading the binary again.