Uh, yes? That is and always has been core functionality. You can click "install" on the Google Play website on your laptop and the app will magically appear on your phone, if both devices are signed in to Google. I triggered this behavior accidentally a good 10 years ago when I got my first Android phone, and it gave me the shivers - it really drove home the point that Google had root on my phone, not me.
In fact, this entire behavior is so normalized on phones we now have a special word for the process of downloading an app and installing it manually, the way we do on PCs: "sideloading".
Yes, of course, but this isn't a technical issue. Look at the webpage that this hn page references. When people say, "an app was installed on my device without my consent or knowledge," the exact method the device used to listen isn't important.
The first issue is that Google software allows non-authorized software installations. The second issue is that a government forced the installation of the app. The technical specifics are just implementation details.
Not the law. Google having root access on 2.5 billion android devices.
The law didn't allow Uber to greyball either. It did though.
This is a risk Google fully recognizes - it's why Google prevents f droid from updating apps one by one without user input. That's a privilege reserved exclusively for google play services.
If Google is asserting non-contractual rights, I'd like to know what they are.
Edit: I edited this comment because it was rude, and that was not my intent.
The governing law that would protect people is a lot of things, and ToS is the least of it. The Wiretap Act applies, for example.
I'm afraid I disagree. Google running code on your phone implies it believes you have consented to that. That consent was not given in the app store, so it must have come from the ToS.
Consent is an exception to virtually every protection that exists: Wiretap Act, state wiretapping laws, the CFAA, and state computer trespass laws. Remember, consent is the difference between a home invasion and a dinner party.
So it seems that Google would have to cook up a pretty implausible stopping principle to argue that whatever allows them to do this does not also enable the hypothetical I described above.
You're making out like code is code and there aren't already existing lines and stopping principles, which just isn't true on its face.
Of the partners in this, I think that the source of authority waa almost certainly the other one. It’s not Google, but the State of Massachusetts, whose authority is likely involved.
Anything in the name of "improving our services".
You can consider installing microG also as an open-source minimal implementation of Google Play Services if some of it's functionality is absolutely necessary for you to keep.
ISPs mandate certain capabilities of the cellular modem + the simcards (remember java cards? that ran java? they still exist as simcards!)
Government RCE is still 100% on the table regardless of whatever software your phone is running
There is a chasm between "a state actor throws an 0day at you" and "Google remotely installs an app on your phone". The latter is done at scale. The former is expensive, risky, and used relatively rarely.
If you're organizing a protest movement, it's totally reasonable to factor government 0days into your threat model. For more boring people, running GrapheneOS is a great way to reduce the attack surface they expose to the advertising and mass surveillance industrial complex.
And this is like, literally a state actor installing an app in this case?
Modems are often isolated by being connected via USB, or if on your SoC the modem has DMA then it's isolated via IOMMU groups.
SIM cards have to implement the E911 feature which allows 911 operators to toggle a cell phone into "stay online no matter what" mode.
Some SIM cards have additional apps installed on them, which allows attacks like SIMjacker and WIBattack.
1) http://ramtin-amin.fr/#nvmepcie, http://ramtin-amin.fr/#nvmedma (the two articles are separate but the first provides incidental context for the second) the iPhone 6 kinda maybe sorta didn't dot the Is and cross the Ts with the MMU side of things. So, USB is awesome in that the failure state is "probably can't RCE".
2) I read a comment on here, which I should be able to re-find, but hn.algolia is not cooperating, suggesting that the system design of a particular AGPS implementation (a few years ago) interposed the GPS in between the CPU and the cellular radio such that the GPS SoC could do HTTP requests to grab its almanac that all of Android, down to the kernel, had no idea about.
IMHO this level of security paranoia is at the end of the day a micro-optimization. For any given device, you're looking at maybe two or three dozen Things Containing ALUs™ (often buried inside subcomponents buried inside other things); one or two concentrations of several billion transistors; and an unknown proportion of manglement, incompetence, cost-cutting, internal compromise (because guarantee there's none), and Agreements™. Honestly: give up, and declare that whatever makes you feel better is enough.
Generally why privacy roms don't support more than 1 or 2 brands total, I guess.
There are also platforms with strict division between the seperate parts of hardware, la pinephone and the librem5
The entire "updates" culture is essentially RCE backdoor (botnet) functionality for "trusted" tech companies.
Consent, where it is actually explicitly obtained, never rises to the level of "informed". That's because even if a user "consents", she still cannot see what is in each update.
In my case the maker of my motherboard installed a persistent “self-repairing” (i.e. difficult to uninstall) from yet another third party. Naturally, I will not buy a product from them (MSI) again.
Another way to put this is: windows update will install malware w/o user approval in the background.
It's a different mechanism from Windows automatically loading drivers and/or the vendor's malware when you plug in a device.
In this case nobody actually installed this app by choice!
How does the thing know you're a Massachusetts resident?
People who have the contact tracing setting disabled are reporting they still got the app, so the obvious answer seems not to apply.
Is it just getting installed on any device that enters MA? New England states are pretty small, and there's a lot of crossover, especially with states like Maine and New Hampshire, which wouldn't take this very well.
Or, if you have a layover at Boston's Logan airport, do you now end up with its contact tracing app?
For Apple as far as I know the most you can do is buy the app on desktop and, if the device is configured that way, it will receive the new app. This means it’s limited to new purchases and by the device’s settings.
I've since de-googled my phone and sacrificed some apps that require google services, but this whole thing shows (to me) that it was the right decision.
One possible way: There is a daily job run in the Play Store called "daily hygiene" that performs various configured tasks based on device state and device targeting. It would not be difficult to add some code to install this app for MA users, then push it with the next Play Store update. I am very unpleasantly surprised that this app was installed from a policy perspective, however.
that's essentially a remote-code-execution backdoor to all android phones?