Full disclosure, I have some rather strong feelings about telemetry on gitlab and the implementation process itself.
-----------------------
I originally posted a different issue labeled "Pseudonymization MVC Rollout Plan"[1] but that issue went private rather quickly after appearing here. Sadly it wasn't archived.
As a counter point to this. Facebook has (tried and mostly succeeded) to replace community forums that used to be either public or with open registration and without the negative effects of facebook.
Stuff that's running phpbb or other similar software.
the way it should be done is not just crossing it out. You also add the signatures of both sides to the redaction. One copy stays with you, the other with the employer.
In digital terms, it's easier just to amend the whole file.
Someone linked "little brother" in another thread, which is a fiction novel of a very similar situation. I found it a good read sprinkled with realistic descriptions of the tech & countermeasures.
I think the real question is what mechanism allows them to push a random app to some phones? google play services is actively listening for remote installation requests?
that's essentially a remote-code-execution backdoor to all android phones?
>google play services is actively listening for remote installation requests?
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".
That's not the behaviour of what happened here, where an app was downloaded without user initiation or intervention. There was no authorization from the user of the actions that were taken by Google or the app's vendor.
From a technical standpoint, it is the same. The phone maintains a connection to a Google server and listens for "authorized" installation requests - where "authorized" means "authorized by Google". When you click "install" on the Play Store on your laptop, you're not talking directly to your phone (how would that even work?) - you're talking to Google, who then speaks to your phone on your behalf.
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.
This subthread is about the technical issue. The root comment asks "the real question is what mechanism allows them to push a random app to some phones?".
From what you've written, it appears that you are guessing as to the implementation details that correspond to the mechanism for pushing random apps to phone, which is in this case means un-authenticated apps. There may be an entirely different method used than the standard push method from selecting an app on the website.
A corollary of your question. If Google can lawfully install arbitrary apps on ordinary users' phones, can it also run arbitrary code on the personal devices of government officials investigating it for price fixing in the ad market?
"Arbitrary" is doing a lot of sneaky work here. You're implying that the law would somehow allow Google to manipulate investigators. But the law has broad allowances and exceptions in lots of areas, and competing permissions/denials that together weave specific allowances. There's little reason to think that the law couldn't allow app installation in general and also disallow either targeting of individuals or collection/manipulation of certain kinds of data.
>You're implying that the law would somehow allow Google to manipulate investigators.
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.
Another question worth asking is "what is the governing law?" It is almost certainly contract law via Google's ToS. Government phones probably have different ToS, but government employee' personal phones have the same ToS we have.
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.
[Edit: the comment originally said their question wasn't implying anything] Of course you're implying something. If nothing else, you're implying the one might imply the other, and that the implication is worth attention.
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.
If you've got a stock Android device you've obviously consented to Google running some code, and even updating to add new code after you bought it. On the other hand, apps are restricted based on permissions, and Google bypassing that would belie a consent theory.
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.
> If Google can lawfully install arbitrary apps on ordinary users' phones
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.
That also means it's going to be hard to sue over this, because the courts where you might do so are part of the same Commonwealth that authorized the action. Even if you could get a case on the docket, they'd just say the magic words "sovereign immunity" and it would disappear.
I thought this was well-known, Android is not private at all until you degoogle. Unlock your bootloader then install a ROM without Google Play Services such as GrapheneOS, CalyxOS or LineageOS.
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.
The factual basis of your assertion is absolutely true, but your attitude is unhelpful and defeatist.
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.
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.
Do any of the privacy oriented custom ROMs protect against that? I can't imagine their maintainers seeing code that just installs any app the ISP wants and be okay with it.
The problem is, its usually cheaper the more things you can shove into the 1 hardware item, so you have your cellular hardware in the same chip as your CPU and GPU. Not much a ROM can do about this unless the chip itself supports disabling direct memory across the two items, + does it correctly, + doesn't allow it to be reversed from the other side, + you would also need the datasheet to find out how to implement this.
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
A core issue is that building Android ROMs is very difficult to do so in a simple and accessible manner. The build systems generally all require enterprise server level of memory and a build can easily take hours. Every device has a unique configuration, imagine if every brand of laptop ran their own variant of Ubuntu. For most "ROMs" that you find on obscure places like XDA, the builds by random people across the globe are a much greater security risk than good first-party updates.
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.
WU allows hardware manufacturers to silently install literally anything based on hardware ID matching and the only way to prevent that is to disable WU driver updates entirely (via GPC/registry).
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.
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?
Not a resident. I just found it installed due to HN. I am in MA at this time.... and have no idea when it was installed. (Of course I uninstalled it immediately)
If they're also hitting phones that were only in the state temporarily it must be using cell tower locations right? I use an always on VPN and it still auto installed (without opting in) but I have my E911 address set here so I'd have guessed that otherwise.
Not exactly. On the Android store you can choose exactly which device to install an application on.
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.
Ok, but my point was that on Android and iOS it is possible to install apps without touching your phone. This qualifies as remote code execution. You need your credentials for doing this, but google and Apple apparently don't need them.
Thank you, I've even used this functionality some years ago but didn't remember it existed.
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.
My guess is that it's the Play Store app itself that does this (con.android.vending). That app is responsible for both updating itself regularly and installing/updating other apps.
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.
They don't have to add any code or push a Play Store update or wait for a daily cronjob. Listening for remote installation requests is a core feature of Google Play Services. It is not a mystery how this was done.
smaller, local(to me) sites have started to have cookie banners that have an effect. My bank, 1/3 of the bigger news sites here etc...
They all started with a single "agree" button, then went to "agree/disagree" with no effect and are finally starting to come around to a functioning disagree button.
GDPR also helps here, as it defined what identifies an individual and that made most of the tracking PII even when it's all merged by a random ID that stays with the user. The effect is slow, but it's starting to work.
Hopefully the next step will be abandoning cookie banners and only using technically required cookies(don't need conset) and/or non-identifying tracking for aggregate results. This is a massive improvment on UX and actually gives the company more quality data that doesn't identify any single individual.
I'm personally pushing for aggregated tracking in my current company. It's an uphill battle, but one that can be won I think.
This works really nice with a docked/undocked setup. When the additional monitors are disconnected, all workspaces move to the main(laptop) display.
eg, I have workspaces 1,2,5,9 on monitor 1 and screens 3,4,6,7,8,10 on monitor 2. When undocked all 10 workspaces move to the laptop screen.
* https://i3wm.org