• 1 Post
  • 54 Comments
Joined 2 years ago
cake
Cake day: June 8th, 2023

help-circle



  • The graphics stack is better, but the security isolation is IMHO solving a problem no one really had, at the cost of breaking a bunch of integration mechanisms people actually used.

    You want UI security isolation for something like Android, where most software being run is fundamentally opposed to the interests of the user and wants to steal anything not nailed down, and you also contain things at the file system level. If Facebook could screenshot every other app all the time it absolutely would, and people would download it anyway. To some extent the enforceable promise that it can’t do that is why people are still willing to download it anyway and let it do all the other things it does to compromise a system.

    In a distro shipping legitimate software, isolation at the desktop UI level is nice for defense in depth, but not really drawing a real security boundary around any program to the point where a user can trust a machine with malicious software running. It doesn’t matter if I can’t steal Firefox’s pixels if I can echo "export PATH=$HOME/.evil-firefox/bin:$PATH" >>~/.bashrc.



  • This sounds like a bug in the distro packaging of the module, or maybe in Grub. You don’t want to try and install any kernel package, or make your default boot option any kernel package, that the wifi driver package doesn’t declare compatibility with.

    But nobody’s package manager knows to do this by default when the driver package is installed, and most packaging systems might not even be able to articulate that constraint.






  • But they aren’t even showing collection of data in the article. For the data to be collected, it needs to leave the phone, not just be touched by Play Services.

    Play Services does collect data it shouldn’t collect, by sending it back to Google. But the difference between “I am collecting your data” and “I wrote software you are running” is important and needs defending, because obscuring it is one way that independent developers are prevented from publishing and marketing actually-privacy-preserving software. If I am deemed to have “collected” your personal data every time you type it into a text editor I wrote, I can no longer distinguish my local-only encrypted text editor from Google’s one that stores all your data unencrypted on their cloud. We both have to say we “collect” your data, and nobody non-technical can tell the difference.




  • The SensorVault data is “just” the Google Maps Timeline data though, right? Which people have always been able to turn on and off, if they knew about it.

    I feel like Google not really respecting a concept of user consent and pretending people agree to poorly-publicized and often-modified tracking programs is a different, and, frankly, weirder, privacy problem than there being closed source stuff running with high permissions. If you could revoke permissions from Play Services, or if it was source available or even free software, that wouldn’t solve the problem because it would still be able to do stuff Google had manufactured consent for it to do.



  • The article seems to go directly from “this piece of software talks to all the sensors and isn’t well sandboxed” to “Google has directed this software to profile and surveil users” without actually providing evidence to support that leap. Is Google Play Services sampling your location so that it can send it in to Google HQ as part of a secret location tracking operation that runs without user consent or knowledge, or so that it can detect if the device has been stolen by the cops and use its proprietary ML model to activate anti-theft mode to protect the user’s privacy?

    If we can actually show mismanagement of user data by Google Play Services, we need to shout it to the hills, because those sorts of scandals are important arguments for increased privacy protections. But we need to actually find that mismanagement occurring, not just assume it must be because Google wrote the code and it isn’t open source.