> Here's a very recent example of this system at work: Chromium sneaks a binary blob which secretly listens to your microphone and sends data to Google: https://lwn.net/Articles/648392/
Downloading a binary blob in the first place was the real issue. However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature.
Getting back on topic, Android handles similar problems in a different way, via the permission system (esp. the improvements in Android 6.0+).
> However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature.
So says someone, but you don't know what else the binary blob (which can be "updated" at the will of Google, without asking anything to the user) does for sure, do you? If you're content with that explanation, you're essentially taking their word for it with blind trust. For example, will it push a new binary and/or suddenly start listening to you or send certain files from your computer if someone three-letter government agency tells Google to do so? Would you bet your life on it?
Trust in software may not be that serious for you, but there are people out there whose lives depend on it.
The issue here is twofold, and in terms of security, it being a binary blob is the lesser one: 1) this is a binary blob which hasn't been vetted by the eyeballs of FOSS world 2) Google circumvents the package manager (along with package reviewers and FOSS community) and secretly and freely installs (and updates) a binary blob on your system, which is essentially a closed-source backdoor singularly controlled by a US company.
A program that silently pushes programs on users' systems (and silently executes them!) at the pleasure of a company never had any place in Debian or any distro with similar principles. It wouldn't matter if they pushed the source code and compiled it on your system (in fact, some rootkits work just like that).
> Getting back on topic, Android handles similar problems in a different way, via the permission system (esp. the improvements in Android 6.0+).
You're talking about a totally different problem/class of permissions here though (accessing network/video/audio/filesystem etc vs ability to install packages as a non-root user).
Oh please. If google wanted to record from Chrome users, they could do it easily. If you actually trust packagers to know what Chrome is doing, you're crazy.
I trust the package managers to build software in a way that I can be sure matches with the published source package. That's the important difference. Projects bundle blobs into their binaries that aren't in the source code all the time (cf. chromium as discussed, but firefox did (does?) this too).
Of course you could say in a large codebase like chromium, bad things can be hidden. But at least there's a better chance such things are found, and it's more risky to put it there in plain sight.
In a perfect world, all software would have reproducible builds and there would be no issue with trusting that binaries contained no hidden functionality not in the source, as there'd be third parties to rebuild and compare the result against the published binaries. We're a ways away from that.
You can't use it to deny specific permissions, only groups of them. If an all wants to write something your contacts, you also have to allow it to read them. This even though the core permissions system allows that level of granularity.
also, network access is deemed safe (by Google) and is thus in a group of permissions the user has no control over.
Downloading a binary blob in the first place was the real issue. However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature.
Getting back on topic, Android handles similar problems in a different way, via the permission system (esp. the improvements in Android 6.0+).