It seems this is only required for "Android App Bundles", whatever the hell that is, and not apps.
"Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. If you use Android App Bundles, you need to sign only your app bundle before you upload it to the Play Console, and Play App Signing takes care of the rest. However, you can also manually sign your app for upload to Google Play and other app stores."
"And, because app bundles defer building and signing APKs to the Google Play Store, you need to opt in to Play App Signing before you upload your app bundle."
As of August, the play store only accepts "Android App Bundles"; "From August 2021, new apps will be required to publish with the Android App Bundle on Google Play"[1]
"Android App Bundle requirement for new apps and games"
"After August 2021, all new apps and games will be required to publish with the Android App Bundle format. New apps and games must use Play Asset Delivery or Play Feature Delivery to deliver assets or features that exceed a download size of 150MB."
Looks to me like you can still opt out of uploading your keys to Google [1]. You can't opt out of Google-side signing after opting in, though.
That does make kind of sense, because once you hand over your key and the first user installs your app, you need to use the same key or the user wouldn't be able to update the app. Opting out of Google-side app signing would be kind of useless because Google can keep the keys and sign malicious code in your name regardless, unless you're willing to wipe out your entire install base through a new app.
...only until August, which is the entire point of this post. The very documentation you link to says "Additionally, your app will not be able to support Android App Bundles, Play Feature Delivery and Play Asset Delivery."; but, starting in August, all new apps must use bundles, and thereby will no longer be compatible with opting out of sending Google your signing key.
Google, I demand you immediately roll this back and fire all parties that argued for the current decision. This change in policy and change in security model is an unacceptable break in your promises. It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that.
There are two possibilities here: Malice or Incompetence. We'll take Hanlon's razor and assume Incompetence, but it is gross incompetence. It is unacceptable.
I don't understand the intent of this comment, but one sentence stood out:
> It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that.
The closest analogy would be a universe in which UPS insists you delegate the packaging of your product to them. Your product remains unchanged, but it's packaged with UPS's packaging which (for the sake of this example) may come with better assurance guarantees relative to your own packaging of the product you're shipping.
Point being: (edit: assuming no malicious supply chain interference; I'll get to this) the app is unmodified. Even with Google doing the signing.
I don't inherently see anything wrong with this, though I also don't think any physical carriers have tried this. Anyone have any examples? Even from other subdomains within logistics?
---
Edit: with supply chain interference (compromising build pipelines, etc), who signs the app doesn't really matter; the app is still tampered before it gets to Google's marketplace. The trade with Google compelling their own signing infrastructure is that it reduces the risk of compromised keys for individual development shops enabling malicious actors to sign builds on behalf of the developers.
---
Edit 2: Some pretty great answers and counterpoints here, such as FBA and the resulting uptick in counterfeit goods. Unexpected but good food for thought.
Amazon's commingling of inventory is actually fraud, and the fact that they've not been charged for it is the slowness of the legal system.
It is fraud in two ways: It misrepresents the seller, and it misrepresent the origin.
That it misrepresents the seller is simple: You don't know who provided you the inventory that Amazon is shipping you. You will often get inventory provided by company B when you receipt says company C. When and if you get a defective product, you have a legal case for compensation against company C, but when they didn't provide the product in the first place (company B did), the waters get muddied. You still have a legal case against company C (They're the seller of record, and you got a faulty product). Company C has a legal case against Amazon (they sent a faulty product on behalf of Company C), and Amazon has a legal case against Company B (They were provided a product that was misrepresented)
There's an alternate line of legal reasoning: Make Amazon the seller of record. This cuts the gordian knot quite nicely, but Amazon has repeatedly rejected it, because:
Sending you commingled product is fraud when the product is not represented correctly: When you buy a "Genuine Apple Charger" and you get a cheap piece of junk in similar packaging, you are being defrauded. Whenever Amazon commingles a non-genuine product with a genuine product and sends it on to the consumer, that's fraud.
This is a legal monty-hall problem. If you lay it all out and examine all of the branches individually, it is quite clear: At some point down each of the lines, Amazon has committed fraud. Either fraud against the consumer, or fraud against it's partners, but regardless: Harm has been done to the consumer and that harm was introduced by Amazon. The harm was introduced when Amazon bucketed the faulty products with the non-faulty products, and thereby destroyed the chain of custody of where it came from. IFF Amazon took careful notes and marked each item with it's origin, then they could pass the blame on to Company B (Where it really belongs), but they didn't, and as such are liable for Company B's misdeeds that they have laundered.
The signing key is what allows for upgrades that still gives you access to all of the data from the app; if you have an app with a pin code that is protecting a signing key or a password database, this means Google can now help people upgrade the app without it being an official upgrade from the source you chose. You might try to argue that Google can already just change the operating system out from under you in similar situations, but that forgets that Google doesn't actually control Android: the manufacturer of your phone is the only person who can ship updates for your phone (not Google). Even mitigations focused on this behavior for just Google's store are disappointing, as the current signing key approach is designed to better support multiple competing app stores and platforms: your app, as distributed for every device by ever vendor through any store is signed by the same key... that's what makes it "your app". It should be the case that the app is end-to-end encrypted through any store and that any store is then able to securely upgrade the app you for from any other store... this all is eroding that as it is giving Google too much power over authenticity.
> Point being: the app is unmodified. Even with Google doing the signing.
The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact.
Now they can, they just say they won’t and expect you to trust their word.
> Now they can, they just say they won’t and expect you to trust their word.
In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything.
The reason they are doing this (keeps getting buried) is because they want to change distributed APKs, shims, etc. so they have the right packages and deps per device, and can ensure that what they build is what is accepted on the device and not some other random thing.
So it is working as intended if what is installed on some device is not what the Dev built.
This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work.
There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped.
But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys).
I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
> The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work.
I used to do J2ME app development back in the day. It wasn’t unusual for our apps to have 200+ builds. These weren’t just different assets, they also included workarounds for device specific bugs (j2me phones were buggy as hell, especially Samsung phones). In some cases we even had multiple builds for one phone, because carriers liked messing with the firmware. Vodafone was notorious for this.
When Android and iOS took over we finally could leave that behind, at least for a while, then Android started fragmenting like crazy and now we’re almost back to square one.
> "too cumbersome" and require re-uploading the same app package repeatedly, but it would work.
This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device.
When specifically targeting a single device you have multiple axes to target:
* 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a]
* 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years).
* 80+ individual languages
If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs.
Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.
You do know that the US has been caught intercepting Cisco switches and routers… installing comprised versions of ios and then repackaging and resending to the original destination.
Think the worry is google (and perhaps certain US agencies) will use this new requirement to do essentially the same approach with certain apps.
Not sure what you are referring to exactly, but Android on the phone only supports signing by one specific key. In the Play Store signing scheme, Google verifies the publisher by requiring that you sign the app first with a specific "upload key". Google then replaces (not co-signs) this with a key they control, and the handset verifies only against this Google-controlled key.
For apps not enrolled in the Play Store signing scheme, the phone actually verifies directly against the publisher's key, that Google now wants to relegate just as an "upload key". I am saddened by Google's efforts to undermine this fundamental OS security feature. The ultimate goal is clearly to kill off any chance of competing app stores, as developers of new apps distributed through Play Store can now actually never access the key that's supposed to show they control the app, no matter what channel it was delivered through (e.g. Play Store vs. F-Droid.. Really bad for new Open Source apps!)
Any secure co-signing approach would require putting app developers in the loop. Are app developers going to do that? If developers want to provide device-optimized APKs, they can do that already without this Google-signs-the-APK stuff.
Disclaimer: I know next to nothing about Android development.
I do know a bit about PKI. And one option might be that the workflow be something like:
Dev signs bundle => Google signs bundle (including dev signature) => User/Client verifies both signatures.
Google are still signing here, but if the dev signature doesn't verify (or isn't present), there's a post-build modification occurring, which is the principle issue raised in the tweet thread.
The entire reason this exists is because of post-build modifications. A huge portion of an APK file is not useful on a given device. To save disk space and bandwidth and improve load times, Google will automatically remove content from APK files that aren't relevant for the particular device downloading the app. But doing this would break the signature unless Google possesses the signing keys.
One the one hand yes, but on the other hand unfortunately it also complicates backups and makes them somewhat non-portable.
While APK backups aren't officially supported and therefore might not factor into the decision making, curiously enough Google itself only recently added a feature to the Play Store which apparently allows direct sharing of APKs between nearby devices.
Split APKs however mean that you can only sensibly share apps with devices having the same screen density, language, etc. as your own device, somewhat devaluating that feature again.
this is a lot more subtle though. I wonder what the legalities are of the government asking google to add in a backdoor that spoofs an app at runtime. certainly it's more complicated than just delivering an app provided by the government as a replacement for one on the app store
AFAIK, no, it doesn't; the component which has root is part of the operating system image, and the Play Store merely has the permissions to tell that component to silently install or upgrade a package. However, when upgrading a package, that component will only allow the upgrade if the package is signed by the same key as the previous release. This has more than once led to a package no longer being able to be updated, because the developer was not careful enough with backups and lost the private key.
Excellent, more evidence for the EU anti trust case against Google's and Apple's monopoly on app stores.
Remember, Microsoft got in trouble for just pre installing internet explorer. There was no blockage or anything preventing you from installing any other browser and use it without any limitations.
What happened with that ruling? I just updated windows and it did a pretty hardcore dark pattern sell on making me install edge and make it my default browser. And apple have been permitted to install safari and prevent any default browser switching on iPhone. I don’t understand why that judgement hasn’t been carried forward and applied to other things.
The judgement was against Microsoft, that ruling can’t be applied to the rest of the industry. As for Apple, there’s too many caveats needed to describe the market they have a monopoly in.
My Linux environments are open -- I am free to obtain and run software from wherever and whomever I please, and they're not infested with malware. I apply my own reasoning and decision-making, which includes considering the reputation of the source(s). It has worked out fine for many years now.
We can have openness and still be thinking of the children. /s
If I put an extra bit of tinfoil on my hat, I might speculate this is actually encouraged by the CIA/NSA/FBI or similar parties.
Certainly, they now have the option of trying to force google into delivering modified apps to certain people. This situation changes the trust model for e.g. signal from "do you trust the app developer" to "do you trust google" against the pressures of hacking and legal requirement of cooperation. The fact that reproducible builds become _that much_ more difficult with this is extra bad. It takes away a rather effective "after the fact" detection mechanism for these kinds of abuses.
It seems obvious to me there are plenty of important app developers (like signal) that are less likely to bow before the long arm of the US than the google play store. Also because for a principled developer, their app is likely 100% of their business. Whereas for google, any app is only a small part of their business. Google simply has much less incentive to defend the users of a single app that the developer.
Hence, it seems to me that this situation is realistically going to lead to more ways for law enforcement to access secret data on your devices. Whether this is part of the motivation for this change or not, the effect seems unavoidable.
Did you need any source for NSA/CIA spying before the Snowden revelations? It was an open secret. No quotable sources, but lo and behold, they were doing it.
A simple "no" would be sufficient. Do you, or OP, have any sources?
Regards pre-Snowden, the situation was far more than an "open secret", there were multiple documented projects and methods employed. Among them:
- 2013: Hemisphere, an AT&T call records database dating to the 1980s accessible by the US DEA. (This was publicised near-simultaneously with Snowden's own 2013 disclosures.) https://www.eff.org/cases/hemisphere
There were very strong suspicions around the TIA (total information awareness) and USA PATRIOT ACT (2003, 2001). I recall much chatter about this at the time, and the related FISA court, though little by way of specific details of technological measures and methods involved.
There are telephnic data retention programmes, including MAINWAY (revealed in 2006), containing an estimated over 1.9 trillion call-detail records, and
There are earlier periods, notably addressed by the FBI's own COINTELPRO archives (https://vault.fbi.gov/cointel-pro), though for my purposes I'm considering "modern" projects to be circa 1990 onwards. (COINTELPRO and the Church Committee hearings resulted in substantial changes, at least publically, to US domestic surveillance).
And I've compiled a long list of pre-1990 references of concerns regarding significant technologists who'd warned of the risks of information technology as a tool of surveillance and control, largely as no such list seemed extant: https://toot.cat/@dredmorbius/105074933053020193
I'm well aware that documentation of clandestine and national security issues is difficult to come by, see the TK case for one reason why that is.
But that's also why specific documentation is so valuable and why I'd requested that.
The OS and App Store already control the code you download. If the App Store replaces one binary provided by the developer with another that isn’t, it already can. Whether it is signed by the developer or the store doesn’t change that.
Of course whoever controls the OS and app stores can already access all device data. They don’t need to fiddle with the apps to do that.
The difference in the ability to detect it and the fact that if Google Play locks your access to publishing, you can't update the app any more because you don't have the keys.
They control the UI that shows you the certificates too.
Signing gives some semblance of control between the untrusted developer and the trusted App Store. It doesn’t do more that stop 3rd party app stores on the link between store and phone.
> They control the UI that shows you the certificates too.
Sure, but if they lied about that isn't it an open-and-shut case of fraud? What they're doing here instead is obfuscating away everything behind an announcement, so there is no legal recourse for the consumer against their bullshit. The best we can do is hope an anti-trust suit is brought against Google (I have approximately zero hope of it happening because of this, though).
You’re in a thread that starts with the premise that this is a vehicle that the fbi/cia are going to use to distribute backfired versions of apps like signal, in which case no, it’s not an open and shut case of fraud.
That's actually a good point. If the US government issues a National Security Letter or uses the All Writs Act to force Google to distribute a backdoored version of an app to a target of a criminal investigation, then it might be an open and shut case of compelled speech (challenged under the First Amendment, assuming the target had standing), but it's not obvious that actions done by a private company to fulfil a legal obligation from the government can ever be prosecuted as fraud.
It might be helpful to consider a simpler situation, where an FBI agent pretends to have a shipment of drugs which a drug dealer attempts to buy. If the dealer hands over money and doesn't receive the drugs, my non-expert understanding is that they can't then sue the government for fraud, presumably because of qualified or sovereign immunity.
The reason the government won't give back the money is that it will initially be evidence, and then subject to civil asset forfeiture. I don't believe that it matters that the item being bought was illegal, as if property law doesn't apply to illegal goods, since, in theory, if one drug dealer stole drugs from another drug dealer, the government could prosecute the perpetrator for both the theft and the possession of the drugs.
If it were ever presented in front of a judge it would be considered fraud. The FBI and CIA will go to extraordinary lengths to never actually have to face a judge, because they know what they are doing is illegal and their entire defense is obfuscation of the law. Even the police are doing this today to avoid ever having to face scrutiny over their use of STINGRAY devices. And when it does find its way in front of a judge, the judge gives them the proverbial "fuck you"
> They control the UI that shows you the certificates too.
Really? They wrote the code for a part of it, sure. But that code was compiled by my OEM, and modified to put the OEM's extra little bit of sauce on there. Besides, the certificates aren't shown to me. They are used by the OS itself to verify updates to the app.
Currently, signing gives control between a trusted developer of an app and any updates reaching my phone. This is enforced at the OS level. That means that the app store cannot just ship my phone false updates. At least, unless they can exploit the currently installed OS.
With google play store, an _update_ to an app needs to be signed with the same keys as the original app.
Hence, google play store cannot just give my an updated backdoored version of signal or whatsapp unless they can get those developers to sign it. With this new system google could unilaterally decide to push such an update. Either to everyone, or just to a few select people.
> Who signs what doesn’t change the threat models.
It very VERY much does. He who signs is he who is able to modify code. If it did not, what value do signatures even have?
It seems you are arguing that, since google already controls android, they already control this data anyway. Thing is, the OS on my phone is already on there. Updates need to go through the manufacturer, and are hard to target. The play-store itself cannot read my signal messages.
Hence, for google to read my signal messages, right now, they would need to have a pre-existing backdoor in android, or run an exploit through the play-store.
With the new system, they could just push an update to my signal app. (If signal were to use the new system).
That, in my opinion, warrants changing the threat model quite a bit.
> With google play store, an _update_ to an app needs to be signed with the same keys as the original app.
Sure, just like how if you let's say own Google Play Store and own those updating keys, you can change it (selectively most likely) to skip checking the signed updates.
They own the full pipeline so if they want, you really stand no chance unless you're running your own OS.
> Sure, just like how if you let's say own Google Play Store and own those updating keys
The ENTIRE POINT, of this scare is that currently, google does not have access to those keys, developers do. And the signatures on these apps are checked by the OS, not the play store.
Notably, google can't change the OS on my phone at their whim. They'd need to release a new version and get Samsung (and maybe my carrier) to ship that OS to me.
Even outside of the Play Store, an APK cannot be updated by another one using a different signature.
It's a verification made by the OS itself. F-Droid themselves compile and signs the binaries offered by their repository, which everyone seems to be fine with. I believe they're also working towards reproducible builds to let others independently verify the compilation matches the source code.
Thing is, Google wants to repackage the apps to lower and optimize download sizes. The developer can't know what SHA hash of an optimized partial bundle is.
If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission.
[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
I've only mentioned one example of how such a tool could work. There are many ways this typ0e of system could be designed. For an alternative that doesn't depend on the number of output combinations, see GauntletWizard's example[1] that uses a signed manifest of files.
The point is, if you build a signed app meant to run on any device, you are going to include code/assets for all of them. What Google wants to do is basically "tree-shake" the APK so that when you download it, it only contains what you need for your device.
Google could publish the code they're going to use to do the transformation step (as e.g. a Docker image), and the developer could audit the result by optionally independently running the same code themselves, at any time after publication. As long as the code Google published was deterministic, the developer should be able to use it to reproduce a binary with the same the SHA as the one offered centrally.
This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.
"optimizing download size" is a lazy distraction when an OS update can be 1 GB. Goggle really wants to modify the apps for selected individuals. To sugar coat the pill, they came up with the size optimizing story (and reducing carbon footprint, probably).
Nope, because the delivered bundle is going to be different from the APK the developer uploaded. This is the actual goal of this system. And when used for good, it allows much smaller app downloads.
However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.
The logical next step is for the developers of Signal, etc, to
begin bundling instrumentation code that checks and monitors app execution. I wonder if Google will allow that level of runtime profiling, or if it will become against the Play store rules?
This sort of thing is incredibly common and has been for years, especially in Chinese markets. Because you can just extract bytecode from downloaded apps, people try to protect their IP by doing all sorts of runtime inspection to look for repacking.
One of the alphabet agencies is incompetent. I recently looked at my iPhone to see battery usage per app - and Facebook nearly used all of my battery for two days. Weird thing, Facebook is not installed, nor any subsidiary on my phone (Instagram, Whatsapp).
At this point I am convinced this entire line of thought is just FUD.
> This means that Google can (or can be forced to) distribute backdoored versions of popular apps to targeted people. The app you are downloading may be different from the app your neighbour is downloading. And the app signature will be perfectly valid for both of them.
Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain. Retaining your own signing keys does not eliminate this potential threat, so you still have to trust them. If you don't, then you should avoid using Android entirely.
Disagree. If a developer signs a build, then I can verify the build came from the developer. If it is signed by Google, then who knows what may have been inserted into the app. This is especially bad for open source and security conscious apps.
Google literally controls the software delivery platform and silently updates a highly privileged service called Play Services on every phone. That service can access and backup data from apps private storage.
They really really don't need to touch your APK to get any user or app data. If you don't realize that, you may have been thinking of wrong threat models.
Verifying that the build came from the developer tells you nothing about whether the app has been backdoored when your adversary controls the compiler used to build the app and the operating system used to execute the app. Reflections on Trusting Trust explains why:
If the SDK was backdoored it would show up on everyone's downloads, which greatly increases the chances of detection. Conversely, if the binaries were uploaded to an app store and were only signed by the app store itself, it's impossible to know whether you got a backdoored version or not.
What do you mean it would "show up in everyones downloads"? Google Play Services are constantly being updated on peoples phones. Literally nothing besides Google's decision not to prevents these updates from containing a backdoor.
Can it? Does it run with root permissions? (Honest question, I don't know.)
If it's bound by the OS permission system and doesn't have full root, it might be able to replace apps with another version that is signed by a different key (using the "programmatic app installing" permission). However, that would wipe the app data and break app updates. Not even adb can replace an app with one that is signed by a different key without data loss (adb install -r). And I'm sure a lot of developers ask for this feature.
I have no idea whether there are any APIs the Play Store has access to which expose that feature, but through ADB (or directly calling the package manager from the shell of a rooted device) you have been able to instruct Android to keep the app data even after uninstalling for a long time already.
(I haven't actually tried whether you can really successfully switch signatures on an APK that way without losing all user data, tough)
> If the SDK was backdoored it would show up on everyone's downloads, which greatly increases the chances of detection.
I think you have far too much confidence in this. How exactly would the average Android developer check to see if the SDK they downloaded from Android Studio doesn't have a targeted exploit in it? Or Android Studio itself for that matter?
Have you checked? Because people here are claiming that Google is an adversary in their threat models. So you can't just assume that the OS actually did verify the signing key.
Or perhaps it makes more sense to not consider the developer of your operating system to be adversarial.
Yes, I've stripped, patched and re-signed apps and verified that installing them as an update failed.
For various reasons I think it's reasonable to assume it's more difficult to be running a phone with a compromised OS (particularly given the bootloader is unlockable and you can install a 100% OSS ROM) than to assume the Play store is not serving something malicious.
Google is not some monolithic entity. And my android install is not under direct control by google (barring some back-door they installed). If google wants to change my android OS, they need to go through the play-store, or through Samsung to push an update. Those are difficult things to do. The play-store should still be bound by the OS, as it is simply an application. And going through samsung to deliver me a targeted update seems quite difficult and involves another party.
Besides, the worry is not "Google Evil". The worry is "Google might be coerced into compromising a specific user". For that usecase, presuming google is _not_ evil and has not backdoored pre-existing android installs, signed updates to apps actually help a lot.
As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app.
This is not about "protecting ourselves from Google". This is about making it as hard as possible for google to do bad things, so it is harder for outsiders to influence Google.
I think that, for the argument you are making, the play-store is the strongest point. I am unsure of how deep the privileges of the play-store run, but it has more control than most apps, and is easily google controlled. I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
But that is the whole point. People are apparently concerned about a backdoor using one channel and not in another, which makes little sense. Either you trust Google or you don't. "It would be a little trickier to ship a bad OS version / WebView implementation / GMS implementation" isn't an especially meaningful approach.
> As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app.
I don't believe there is any evidence for this.
> I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
If you are specifically worried about Signal then this change does not affect you because this is only a requirement for new apps. This is one reason why I find the argument that this is all a backdoor for the NSA so ridiculous. People seem to be claiming that the NSA has the strength to strongarm Google to implement a feature like this and roll it out for years (App Bundles have been around for a long time as an option) and is willing to wait for basically the entire market to turnover so that privacy-critical apps are all using this feature but can't force a change at the OS level that works universally.
>Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain.
It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors. AFAIK the play store doesn't have a custom installer to handle installs, that's handled by the operating system itself. The play store has special permissions to install apps programmatically, but AFAIK it doesn't have ability to bypass the signature check, which is why this change is being made in the first place.
Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.
As it stands if you buy a normal android phone, then you must trust Google.
>Portions of the SDK are open source, portions are not. Android also does not have reproducible builds, so you cannot audit that the open source you are viewing relates to the binaries on your phone. Android also widely depends on binary blob firmwares which also cannot be audited.
1. you still need way more parties involved (eg. OEMs, chipset makers), unlike google which probably has acesss 95+% of the non-chinese android phones.
You're completely ignoring existence of silently updated Play Store and Play Services which are controlled by Google and have enough permissions to do exactly what you think they can't.
Google has been decoupling things like Play Services from the BSP for a long time now. They could certainly push a backdoored version to a specific set of phones if they so wished.
If you wanted to add the exploit to the kernel, there are plenty of hooks to do so that would not require the kernel to be recompiled (e.g. a loadable module, or BPF). Again, these could be targeted at specific individuals, or groups of individuals.
Still, Google is extremely unlikely to add any backdoor willingly, and unlikely to add one in general. And more to the point, controlling the signing keys for a specific App does not make it easier to backdoor someones phone.
The Play Store is a closed binary which had privileged permissions to silently install, uninstall or update APKs. The Play Services have silent permissions to backup and restore app data. Both of those update themselves silently.
Open source doesn't protect you at all against Google.
The Play Store cannot update an app to a version that is not signed by the original developer. At best it can uninstall and reinstall the app with a different signing key, in which case all app data gets wiped.
edit: Actually I don't even know that the App Store has permission to uninstall apps. If it doesn't, then it can only update apps that are signed with developer keys.
As for backups, apps have control over which data can be backed up. Google cannot access app data if the app doesn't consent to it, assuming the Android OS itself is not somehow compromised.
> It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors.
Not for devices running Google Play Services. If your device is running AOSP with absolutely zero Google services then maybe that's the case (although I'm not even sure that's true at the firmware/driver level), but if you'll never use the Play Store then Play Store restrictions don't really affect you in the first place.
I also think you're seriously underestimating or misunderstanding the potential attack vectors here. You don't need to deliver a blatantly obvious backdoor that can be easily found in the AOSP source code. Consider the history of 0-day RCE exploits on the Android platform and then consider the fact that such exploits can be subtly introduced in a non-obvious way that gives you plausible deniability if discovered. Now consider that you have your own closed-source and privileged code running on billions of Android devices that could take advantage of the 0-days you introduced yourself.
What happens if google gets a "national security letter" that says "hey, we wanna read $NAME's whatsapp messages".
In the scenario without this system, google needs to use their control over the OS, the installer and the SDK to somehow deliver a changed version of the app, or run an exploit / backdoor against that app from other code they control. Excluding the exploit and pre-existing backdoor, that is something they could refuse to do somewhat easily.
Compare that to if google has the signing keys for updates to whatsapp. Then the national security letter could just state "hey, here is an update to whatsapp, please sign it with the appropriate keys". That is so much harder for Google to refuse.
I have a lot more faith that google would not comply with the first national security letter than with the second.
I don't really see a meaningful difference between those two scenarios. In both cases Google has the ability to exploit your app and you have to trust them not to do it. Whether one approach is more politically acceptable than the other is an interesting question but I don't know if it matters that much in the end.
> Whether one approach is more politically acceptable than the other is an interesting question but I don't know if it matters that much in the end.
It seems to me that if one approach is so politically unacceptable as to be quite unlikely, and the other approach is so politically acceptable as to be feasible, that is highly relevant.
In the first scenario, this is just a hypothetical attack google could do if they were evil. In the second scenario this is a realistic attack we need to consider could happen. The difference between "hypothetical" and "realistic" matters quite a bit.
Compare the NSA asking Google "please sign this update to signal". To the FBI asking Apple "please sign this this new OS that allows brute-forcing".
The second case was apparently feasible enough that the FBI thought it was worth trying in open court. I don't think the first case is that dissimilar. And I think there is a decent chance that the NSA/CIA has stronger pressure methods than what the FBI tried in the San-bernedino case.
And if not, it seems quite a bit more feasible for new legislation to be written that could be used to force google to cooperate with malicious update signing. It certainly fits with the theme of recent "we should be allowed to read your messages" legislation attempts. Heck, I think it would be one of the more reasonable ways to implement such legislation.
If these cases are structurally the same and you assume (without evidence) that Google resists less than Apple - then why aren't you worried about OS updates for Android? You've never been able to trust any code running on an Android phone in this case.
Hypothetical new legislation could require you to download a NSA rootkit on all of your devices too. Nothing about this feature is uniquely weak to arbitrary legislation.
Well, google doesn't control all of the android OSs currently installed so they'd have to jump through quite some hoops to not accidentally make such a backdoor obvious to a small but sizeable group of people.
Symbian used have something like this called Symbian Signed. It was a complete pain in the arse and probably one reason why hobbyists barely ever wrote programs for it.
RIM used to do the same thing for Blackberry development. It never worked very well and the signing server was often offline. After one of their rounds of layoffs, it was offline for over a week, perhaps two weeks (it's been a while). I'm not sure if they laid off the person responsible for that server and it happened to go down or if they knocked it offline as a parting gift. Either way, we couldn't make even spelling corrections in our apps until it came back up. Absolutely terrible process.
Out of curiosity, would this allow Google to perform the signing _at the moment of download_?
By that I mean, would it be possible that 2 different people download the app from the Play store, one of them gets an unmodified version of the app and the other (perhaps based on the user's race, country of origin, etc.) gets an on-the-fly modified version of the app.
The developer - and likely 99+% of all users - would never know or even be able to tell because most copies of the app in existence are 100% what the developer created. But, for a few rare birds, backdoors are aplenty.
Regardless, I'm 100% against this. But, my thinking above is this is possibly far worse than I initially imagined.
The is pretty much the main stated reason for this approach - you'll get a customized bundle for your device which only carries native libs, languages and resources for your current configuration. It's explicitly stated as the main goal for this resigning.
Apple calls this approach "app thinning".
Also remember that Google Play Store could serve whichever APK it liked right now - the signing keys aren't surfaced in UI on Android (or iOS for that matter).
The keys aren't surfaced, but a TOFU (trust on first use) model applies. If a new APK is signed by a different signing key, the OS will reject the update. To my knowledge, the only way to force-install an update signed with a new signing key would be to uninstall-and-reinstall the app. (This is what "adb install -r" does.) This will result in the loss of all app data.
It makes absolutely no sense to do it this way. So either let me sign the app and check it in Play store app, or recompile and modify my app as you wish and tell Play store app to not check the signature.
Everyone seems kind of mad about this. Doesn't Debian do the same thing? The original developer doesn't build and sign Debian packages, the Debian project does that. Now Google does the exact same thing, and the conspiracy theories abound about how the NSA is making them do it or something. Is the NSA also making linux distributions sign packages?
In Debian you can still get the sources, including the Debian specific patches, and build it yourself. There is no hard requirement to blindly trust the Debian maintainers.
There's nothing guaranteeing that Deb contains the same thing as source Deb. At the end of the day you still need to trust the organization building your OS so they don't push a backdoor in your root installed package.
No it's not - reproducibility doesn't defend you against malicious repository at all. You still need to trust every single maintainer of your packages and the repository owner to not serve you backdoored package.
Yes and no. Just having reproducibility does not automatically prevent bad things from happening. But it's certainly easier to defend against them.
Multiple people can grab the sources from the developer, review and apply the patches, build the package and publish the resulting hash. With reproducible builds, all people end up with the same hash, which should also be the same for the pre-built package in the repository.
In other words, instead of trusting one single person (the maintainer) you split the trust across multiple people. This is definitely an improvement thanks to reproducible builds.
You can do the same thing here. There is no hard requirement that you use Google Play. If the app developers publish their source you can build an apk yourself.
No, it's the developer's _choice_. The problem is that there are instances where you trust the developer but not the way it is distributed (commonly through Google's app store). I signature from the developer is enough to verify that the app has not been tempered with.
With the upcoming change, we loose this verification when using Google's app store.
This has nothing to do with the developer publishing the source and allowing you to build from source or publishing through other channels (the topic of this subthread).
Developers can still create key pairs themselves and upload them to Google. So they can still publish their public key if they want and you can be certain that APKs distributed from somewhere other than Play were definitely signed by the developer.
Yep, Debian, Apple, F-Droid all sign binaries themselves. The posters here mostly mistakenly believe that they can fight against the owner of their operating system without replacing the whole thing.
In the case of Debian and F-Droid, they do so transparently, often with reproducible builds. The fact that packages are signed by those groups is one of the reasons why they are trusted. I would not consider "signed automatically by Google" to be an improvement in trustworthiness.
In the case of Apple, I agree. It doesn't make sense to use their ecosystem without trusting them fully.
However, in the case of Android / Google Play, right now the developers have the option to choose between APKs and App Bundles. Why take away that choice? If App Bundles are superior, then developers will choose that option freely. (Google Play is already really pushy when recommending to use App Bundles.)
Debian builds and signs which is rather different from just signing what someone else builds. This makes sense for Debian since they often make changes to the upstream code a bit, primarily for consistency with the rest of the distro, which you can see in the source packages. It's good for the signing party to be the one who built it asserting 'this is what we intended to ship'. It's also very clear that they are Debian packages, rather than anything originating from the upstream author(s). That's a very different thing than Google's new policy.
It sounds exactly the same to me - the repository owner is the one signing packages and has to be trusted not to modify it before delivering data. Where's the difference?
I think to me it boils down to need and trust. Debian needs to do things this way and has earned trust over decades not to abuse its power. Google doesn't have the need and is burning trust in enough other areas where it doesn't instill a lot of confidence that they will not abuse the increased control.
That I agree with and is actually my point - you NEED to trust your platform. There's just no other way. There's no sensible way for you to keep using Googles platform if you use Googles OS.
There are cases in which upstream (the original developer) and the Debian packager (Debian Developer) are one and the same. Not many but some. Debian is also the developer and packager of a large set of the core packages.
Upstream can sign or otherwise indicate integrity (e.g., Git revision checksums) of all individual source files. This ... becomes tedious to check, but can be checked against Debian sources to identify where any changes might reside. Note that this still applies only to sources rather than builds, though it's an option. It's likely not an option in wide use.
Debian also ships sources rather than builds, which can be built directly on your own systems (or within your own build-and-distribution network). Debian's had a "reproducible builds" initiative for some years (https://wiki.debian.org/ReproducibleBuilds), and this covers a fair number of packages (I don't have a count offhand), though there are notable exceptions of packages which are simply too complex to build reproducibly. I think the September 2020 summit notes are the best current overview of status, tools, and issues: https://reproducible-builds.org/reports/2020-09/
And, unlike Google Play, it's possible to download from any arbitrary Debian mirror without authentication. Authentication-prior-to-download could lead to branching logic for user-specific modified packages being delivered. Another option of course being for a generically-modified package that targets a single user or specified set of narrow criteria.
Debian does everything in the open. You can download the source of a package and build it yourself, compare checksums, run diffs. Most packages have reproducible builds so you can confirm what you're getting! Debian also doesn't require or use an "account" for downloads, and if they release a version of something, it's on the public mirrors that many people will be able to access.
With Google the entire process is completely opaque, they do everything behind closed doors, and can hand different users different blobs on demand.
Ultimately with Google, you only have Google's word for what they're doing, and you know they have the capability to provide different versions to different users on demand of an NSL. With Debian, they have no way to attack a specific user, and you fully have the ability to "check their work."
I trust Debian hell of a lot more to only make the changes that are in my interest and to pass the code through unmodified otherwise. Google doesn't get any trust in my book. The only reason I'm on Android is because alternatives aren't viable yet and I loathe iOS more than Android.
They're also requiring all new apps to be published in the Android App Bundle format instead of APK. Likely it will soon after also be required for updates to existing apps.
This is a change to google's policy for access to the play-store. This does not affect the android operating system. Hence anything that is not installed through the play-store is unaffected.
Signing in a distributed environment with a (sometimes required) hardware based key is really annoying. You basically have to build your own system for it. I've actually wanted inexpensive signing as a service (for Windows) for some time. Haven't been actively watching for it though.
Maybe they can release a tool to create APKs from App Bundles locally (maybe call it, idk, 'bundletool' or something like that). They could also make it so the Google Play Console allows developers to choose between uploading APKs or an App Bundle, and communicating the pros/cons of both methods. That way, a developer (not Google) can choose which option is best for their business and their customers!
Sound good to me at least (although to be fair, I don't have an ulterior motives or bad intentions)
187 comments
[ 0.28 ms ] story [ 246 ms ] threadIt seems this is only required for "Android App Bundles", whatever the hell that is, and not apps.
"Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. If you use Android App Bundles, you need to sign only your app bundle before you upload it to the Play Console, and Play App Signing takes care of the rest. However, you can also manually sign your app for upload to Google Play and other app stores."
"And, because app bundles defer building and signing APKs to the Google Play Store, you need to opt in to Play App Signing before you upload your app bundle."
[1] https://developer.android.com/guide/app-bundle
https://developer.android.com/distribute/play-policies#Requi...
"Android App Bundle requirement for new apps and games"
"After August 2021, all new apps and games will be required to publish with the Android App Bundle format. New apps and games must use Play Asset Delivery or Play Feature Delivery to deliver assets or features that exceed a download size of 150MB."
That does make kind of sense, because once you hand over your key and the first user installs your app, you need to use the same key or the user wouldn't be able to update the app. Opting out of Google-side app signing would be kind of useless because Google can keep the keys and sign malicious code in your name regardless, unless you're willing to wipe out your entire install base through a new app.
[1] https://developer.android.com/studio/publish/app-signing#opt...
There are two possibilities here: Malice or Incompetence. We'll take Hanlon's razor and assume Incompetence, but it is gross incompetence. It is unacceptable.
> It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that.
The closest analogy would be a universe in which UPS insists you delegate the packaging of your product to them. Your product remains unchanged, but it's packaged with UPS's packaging which (for the sake of this example) may come with better assurance guarantees relative to your own packaging of the product you're shipping.
Point being: (edit: assuming no malicious supply chain interference; I'll get to this) the app is unmodified. Even with Google doing the signing.
I don't inherently see anything wrong with this, though I also don't think any physical carriers have tried this. Anyone have any examples? Even from other subdomains within logistics?
---
Edit: with supply chain interference (compromising build pipelines, etc), who signs the app doesn't really matter; the app is still tampered before it gets to Google's marketplace. The trade with Google compelling their own signing infrastructure is that it reduces the risk of compromised keys for individual development shops enabling malicious actors to sign builds on behalf of the developers.
---
Edit 2: Some pretty great answers and counterpoints here, such as FBA and the resulting uptick in counterfeit goods. Unexpected but good food for thought.
Which to drive it home, if Bob included a signed photo with each of his items I would know if I got the item from Bob or someone else.
It is fraud in two ways: It misrepresents the seller, and it misrepresent the origin.
That it misrepresents the seller is simple: You don't know who provided you the inventory that Amazon is shipping you. You will often get inventory provided by company B when you receipt says company C. When and if you get a defective product, you have a legal case for compensation against company C, but when they didn't provide the product in the first place (company B did), the waters get muddied. You still have a legal case against company C (They're the seller of record, and you got a faulty product). Company C has a legal case against Amazon (they sent a faulty product on behalf of Company C), and Amazon has a legal case against Company B (They were provided a product that was misrepresented)
There's an alternate line of legal reasoning: Make Amazon the seller of record. This cuts the gordian knot quite nicely, but Amazon has repeatedly rejected it, because:
Sending you commingled product is fraud when the product is not represented correctly: When you buy a "Genuine Apple Charger" and you get a cheap piece of junk in similar packaging, you are being defrauded. Whenever Amazon commingles a non-genuine product with a genuine product and sends it on to the consumer, that's fraud.
This is a legal monty-hall problem. If you lay it all out and examine all of the branches individually, it is quite clear: At some point down each of the lines, Amazon has committed fraud. Either fraud against the consumer, or fraud against it's partners, but regardless: Harm has been done to the consumer and that harm was introduced by Amazon. The harm was introduced when Amazon bucketed the faulty products with the non-faulty products, and thereby destroyed the chain of custody of where it came from. IFF Amazon took careful notes and marked each item with it's origin, then they could pass the blame on to Company B (Where it really belongs), but they didn't, and as such are liable for Company B's misdeeds that they have laundered.
Problem: you have no way to prove it. Nobody can prove it.
That’s what developer signing proves - that is hasn't been modified.
The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact.
Now they can, they just say they won’t and expect you to trust their word.
In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything.
But your point makes sense.
So it is working as intended if what is installed on some device is not what the Dev built.
There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped.
But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys).
I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
I used to do J2ME app development back in the day. It wasn’t unusual for our apps to have 200+ builds. These weren’t just different assets, they also included workarounds for device specific bugs (j2me phones were buggy as hell, especially Samsung phones). In some cases we even had multiple builds for one phone, because carriers liked messing with the firmware. Vodafone was notorious for this.
When Android and iOS took over we finally could leave that behind, at least for a while, then Android started fragmenting like crazy and now we’re almost back to square one.
I think you are underestimating the number of versions.
And why would developers want to do this? This adds a huge pain in the ass to all deployments.
> Google could come up with a new app format whereupon there were a signed manifest of files
They could. But this wouldn't be backwards compatible. So you are stuck waiting like eight years for the ecosystem to all adopt the new OS versions.
This is true and "too cumbersome" is worth expanding on. Without specific targeting what is delivered to the device, 100s of MB of storage can be wasted after the APK is uncompressed. The data that is unused can't be deleted but is unusable or unneeded on that device.
When specifically targeting a single device you have multiple axes to target:
* 4 native CPU architectures: [x86, x86_64, armeabi-v7a, arm64-v8a]
* resource DPIs: [ldpi, mdpi, hdpi, xhdpi, xxhdpi]
* 6+ SDK targetSdks with meaningful feature variances (basically potential features enabled/disable every year for the last 7-8 years).
* 80+ individual languages
If the goal is to exactly match the device/user in question, you'd need to generate and apply appropriate versionCodes for: 4 * 7 * 6 * 80 = 13440 individually, versioned, signed and uploaded APKs.
Of additional note, the versionCodes must be precisely ordered to ensure the right version is selected. A device will get the highest version which is compatible with the device. So if an x86 version is higher than x86_64 a 64 bit device that can handle both will still get the x86 instead of the x86_64 version. Same goes for DPI ordering and SDK ordering.
Think the worry is google (and perhaps certain US agencies) will use this new requirement to do essentially the same approach with certain apps.
For apps not enrolled in the Play Store signing scheme, the phone actually verifies directly against the publisher's key, that Google now wants to relegate just as an "upload key". I am saddened by Google's efforts to undermine this fundamental OS security feature. The ultimate goal is clearly to kill off any chance of competing app stores, as developers of new apps distributed through Play Store can now actually never access the key that's supposed to show they control the app, no matter what channel it was delivered through (e.g. Play Store vs. F-Droid.. Really bad for new Open Source apps!)
[1] https://developer.android.com/google/play/filters
I do know a bit about PKI. And one option might be that the workflow be something like:
Dev signs bundle => Google signs bundle (including dev signature) => User/Client verifies both signatures.
Google are still signing here, but if the dev signature doesn't verify (or isn't present), there's a post-build modification occurring, which is the principle issue raised in the tweet thread.
While APK backups aren't officially supported and therefore might not factor into the decision making, curiously enough Google itself only recently added a feature to the Play Store which apparently allows direct sharing of APKs between nearby devices. Split APKs however mean that you can only sensibly share apps with devices having the same screen density, language, etc. as your own device, somewhat devaluating that feature again.
AFAIK, no, it doesn't; the component which has root is part of the operating system image, and the Play Store merely has the permissions to tell that component to silently install or upgrade a package. However, when upgrading a package, that component will only allow the upgrade if the package is signed by the same key as the previous release. This has more than once led to a package no longer being able to be updated, because the developer was not careful enough with backups and lost the private key.
Not if you want customers.
Remember, Microsoft got in trouble for just pre installing internet explorer. There was no blockage or anything preventing you from installing any other browser and use it without any limitations.
your odometer app
instead of backdooring your mobilephone which can provide, video, audio, location,....
MAKES SENSE, PLEASE BOYCOTT GOOGLE EVERYONE...
SARCASM
I dare you to close your eyes and install a random free app on the Play Store or Apple App Store. Chances are high you'll download some malware.
We can have openness and still be thinking of the children. /s
Certainly, they now have the option of trying to force google into delivering modified apps to certain people. This situation changes the trust model for e.g. signal from "do you trust the app developer" to "do you trust google" against the pressures of hacking and legal requirement of cooperation. The fact that reproducible builds become _that much_ more difficult with this is extra bad. It takes away a rather effective "after the fact" detection mechanism for these kinds of abuses.
It seems obvious to me there are plenty of important app developers (like signal) that are less likely to bow before the long arm of the US than the google play store. Also because for a principled developer, their app is likely 100% of their business. Whereas for google, any app is only a small part of their business. Google simply has much less incentive to defend the users of a single app that the developer.
Hence, it seems to me that this situation is realistically going to lead to more ways for law enforcement to access secret data on your devices. Whether this is part of the motivation for this change or not, the effect seems unavoidable.
Regards pre-Snowden, the situation was far more than an "open secret", there were multiple documented projects and methods employed. Among them:
- 2013: Hemisphere, an AT&T call records database dating to the 1980s accessible by the US DEA. (This was publicised near-simultaneously with Snowden's own 2013 disclosures.) https://www.eff.org/cases/hemisphere
- 2006: Mark Klein and the Room 641A revelations concerning AT&T's beam splitters: https://en.wikipedia.org/wiki/Room_641A
- 2005, William Binney and J. Kirk Wiebe, NSA whistleblower, warrantless surveillance. https://en.wikipedia.org/wiki/William_Binney_(intelligence_o...
- 2004, Russell Tice, NSA surveillance including of congressional members. https://slate.com/news-and-politics/2006/01/why-nsa-whistle-...
There were very strong suspicions around the TIA (total information awareness) and USA PATRIOT ACT (2003, 2001). I recall much chatter about this at the time, and the related FISA court, though little by way of specific details of technological measures and methods involved.
Carnivore, a WinNT workstation-based tool, disclosed ~2000. https://en.wikipedia.org/wiki/Carnivore_(software)
There are telephnic data retention programmes, including MAINWAY (revealed in 2006), containing an estimated over 1.9 trillion call-detail records, and
https://en.wikipedia.org/wiki/MAINWAY
Project ECHELON, with disclosures of varying aspects from 1972 -- 2000. https://en.wikipedia.org/wiki/ECHELON
There are earlier periods, notably addressed by the FBI's own COINTELPRO archives (https://vault.fbi.gov/cointel-pro), though for my purposes I'm considering "modern" projects to be circa 1990 onwards. (COINTELPRO and the Church Committee hearings resulted in substantial changes, at least publically, to US domestic surveillance).
And I've compiled a long list of pre-1990 references of concerns regarding significant technologists who'd warned of the risks of information technology as a tool of surveillance and control, largely as no such list seemed extant: https://toot.cat/@dredmorbius/105074933053020193
I'm well aware that documentation of clandestine and national security issues is difficult to come by, see the TK case for one reason why that is.
But that's also why specific documentation is so valuable and why I'd requested that.
Of course whoever controls the OS and app stores can already access all device data. They don’t need to fiddle with the apps to do that.
Who signs what doesn’t change the threat models.
Signing gives some semblance of control between the untrusted developer and the trusted App Store. It doesn’t do more that stop 3rd party app stores on the link between store and phone.
Sure, but if they lied about that isn't it an open-and-shut case of fraud? What they're doing here instead is obfuscating away everything behind an announcement, so there is no legal recourse for the consumer against their bullshit. The best we can do is hope an anti-trust suit is brought against Google (I have approximately zero hope of it happening because of this, though).
It might be helpful to consider a simpler situation, where an FBI agent pretends to have a shipment of drugs which a drug dealer attempts to buy. If the dealer hands over money and doesn't receive the drugs, my non-expert understanding is that they can't then sue the government for fraud, presumably because of qualified or sovereign immunity.
The reason the government won't give back the money is that it will initially be evidence, and then subject to civil asset forfeiture. I don't believe that it matters that the item being bought was illegal, as if property law doesn't apply to illegal goods, since, in theory, if one drug dealer stole drugs from another drug dealer, the government could prosecute the perpetrator for both the theft and the possession of the drugs.
https://arstechnica.com/tech-policy/2018/07/judge-slams-fbi-...
People have this notion that the court system just blindly agrees with three lettered agencies, when in reality they tend to hate each other.
The Android system one that comes from the OEM? Or have they compromised the Java installation I have?
The latter being very difficult for Google alone to make output incorrect results.
Really? They wrote the code for a part of it, sure. But that code was compiled by my OEM, and modified to put the OEM's extra little bit of sauce on there. Besides, the certificates aren't shown to me. They are used by the OS itself to verify updates to the app.
Currently, signing gives control between a trusted developer of an app and any updates reaching my phone. This is enforced at the OS level. That means that the app store cannot just ship my phone false updates. At least, unless they can exploit the currently installed OS.
Hence, google play store cannot just give my an updated backdoored version of signal or whatsapp unless they can get those developers to sign it. With this new system google could unilaterally decide to push such an update. Either to everyone, or just to a few select people.
> Who signs what doesn’t change the threat models.
It very VERY much does. He who signs is he who is able to modify code. If it did not, what value do signatures even have? It seems you are arguing that, since google already controls android, they already control this data anyway. Thing is, the OS on my phone is already on there. Updates need to go through the manufacturer, and are hard to target. The play-store itself cannot read my signal messages.
Hence, for google to read my signal messages, right now, they would need to have a pre-existing backdoor in android, or run an exploit through the play-store. With the new system, they could just push an update to my signal app. (If signal were to use the new system). That, in my opinion, warrants changing the threat model quite a bit.
Sure, just like how if you let's say own Google Play Store and own those updating keys, you can change it (selectively most likely) to skip checking the signed updates.
They own the full pipeline so if they want, you really stand no chance unless you're running your own OS.
The ENTIRE POINT, of this scare is that currently, google does not have access to those keys, developers do. And the signatures on these apps are checked by the OS, not the play store.
Notably, google can't change the OS on my phone at their whim. They'd need to release a new version and get Samsung (and maybe my carrier) to ship that OS to me.
It's a verification made by the OS itself. F-Droid themselves compile and signs the binaries offered by their repository, which everyone seems to be fine with. I believe they're also working towards reproducible builds to let others independently verify the compilation matches the source code.
Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)
[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
[1] https://news.ycombinator.com/item?id=27177425
This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.
However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.
> This means that Google can (or can be forced to) distribute backdoored versions of popular apps to targeted people. The app you are downloading may be different from the app your neighbour is downloading. And the app signature will be perfectly valid for both of them.
Google already controls the operating system, the installer, and the SDKs you used to develop your Android app in the first place. If they wanted to backdoor your app there are already plenty of opportunities to do so at multiple levels throughout this chain. Retaining your own signing keys does not eliminate this potential threat, so you still have to trust them. If you don't, then you should avoid using Android entirely.
They really really don't need to touch your APK to get any user or app data. If you don't realize that, you may have been thinking of wrong threat models.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
If it's bound by the OS permission system and doesn't have full root, it might be able to replace apps with another version that is signed by a different key (using the "programmatic app installing" permission). However, that would wipe the app data and break app updates. Not even adb can replace an app with one that is signed by a different key without data loss (adb install -r). And I'm sure a lot of developers ask for this feature.
(I haven't actually tried whether you can really successfully switch signatures on an APK that way without losing all user data, tough)
Additionally, starting from Android 10 it seems that there is a new official feature allowing data to be kept after uninstallation if an app opts-in (https://stackoverflow.com/questions/58750567/how-to-enable-o...).
I think you have far too much confidence in this. How exactly would the average Android developer check to see if the SDK they downloaded from Android Studio doesn't have a targeted exploit in it? Or Android Studio itself for that matter?
Or perhaps it makes more sense to not consider the developer of your operating system to be adversarial.
Yes, I've stripped, patched and re-signed apps and verified that installing them as an update failed.
For various reasons I think it's reasonable to assume it's more difficult to be running a phone with a compromised OS (particularly given the bootloader is unlockable and you can install a 100% OSS ROM) than to assume the Play store is not serving something malicious.
Besides, the worry is not "Google Evil". The worry is "Google might be coerced into compromising a specific user". For that usecase, presuming google is _not_ evil and has not backdoored pre-existing android installs, signed updates to apps actually help a lot.
As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app. This is not about "protecting ourselves from Google". This is about making it as hard as possible for google to do bad things, so it is harder for outsiders to influence Google.
I think that, for the argument you are making, the play-store is the strongest point. I am unsure of how deep the privileges of the play-store run, but it has more control than most apps, and is easily google controlled. I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
But that is the whole point. People are apparently concerned about a backdoor using one channel and not in another, which makes little sense. Either you trust Google or you don't. "It would be a little trickier to ship a bad OS version / WebView implementation / GMS implementation" isn't an especially meaningful approach.
> As a matter of legal theory, forcing google to backdoor android / the play-store is so much harder than forcing google to just sign this one update of an app.
I don't believe there is any evidence for this.
> I suspect that google would still need to run an exploit against android OS to actually get e.g. my signal messages.
If you are specifically worried about Signal then this change does not affect you because this is only a requirement for new apps. This is one reason why I find the argument that this is all a backdoor for the NSA so ridiculous. People seem to be claiming that the NSA has the strength to strongarm Google to implement a feature like this and roll it out for years (App Bundles have been around for a long time as an option) and is willing to wait for basically the entire market to turnover so that privacy-critical apps are all using this feature but can't force a change at the OS level that works universally.
It's less straightforward to backdoor the OS/sdk because it's open source and built by various vendors. AFAIK the play store doesn't have a custom installer to handle installs, that's handled by the operating system itself. The play store has special permissions to install apps programmatically, but AFAIK it doesn't have ability to bypass the signature check, which is why this change is being made in the first place.
As it stands if you buy a normal android phone, then you must trust Google.
1. you still need way more parties involved (eg. OEMs, chipset makers), unlike google which probably has acesss 95+% of the non-chinese android phones.
2. backdoors involving the SDK/OS are far less discriminate and therefore has higher risk of detection by third party researchers. (eg. https://www.xda-developers.com/mediatek-su-rootkit-exploit/)
If you wanted to add the exploit to the kernel, there are plenty of hooks to do so that would not require the kernel to be recompiled (e.g. a loadable module, or BPF). Again, these could be targeted at specific individuals, or groups of individuals.
Still, Google is extremely unlikely to add any backdoor willingly, and unlikely to add one in general. And more to the point, controlling the signing keys for a specific App does not make it easier to backdoor someones phone.
Open source doesn't protect you at all against Google.
edit: Actually I don't even know that the App Store has permission to uninstall apps. If it doesn't, then it can only update apps that are signed with developer keys.
As for backups, apps have control over which data can be backed up. Google cannot access app data if the app doesn't consent to it, assuming the Android OS itself is not somehow compromised.
https://developer.android.com/reference/android/Manifest.per...
Skimming the permissions file shipped with opengapps suggests that play store has it.
AFAIK the OS has checks to prevent "updating" to an APK with different signature.
>The Play Services have silent permissions to backup and restore app data.
It looks like apps can opt out of it. https://developer.android.com/guide/topics/data/autobackup#E... It's unclear whether this is enforced by the OS or google play services.
Not for devices running Google Play Services. If your device is running AOSP with absolutely zero Google services then maybe that's the case (although I'm not even sure that's true at the firmware/driver level), but if you'll never use the Play Store then Play Store restrictions don't really affect you in the first place.
I also think you're seriously underestimating or misunderstanding the potential attack vectors here. You don't need to deliver a blatantly obvious backdoor that can be easily found in the AOSP source code. Consider the history of 0-day RCE exploits on the Android platform and then consider the fact that such exploits can be subtly introduced in a non-obvious way that gives you plausible deniability if discovered. Now consider that you have your own closed-source and privileged code running on billions of Android devices that could take advantage of the 0-days you introduced yourself.
Compare that to if google has the signing keys for updates to whatsapp. Then the national security letter could just state "hey, here is an update to whatsapp, please sign it with the appropriate keys". That is so much harder for Google to refuse.
I have a lot more faith that google would not comply with the first national security letter than with the second.
It seems to me that if one approach is so politically unacceptable as to be quite unlikely, and the other approach is so politically acceptable as to be feasible, that is highly relevant.
In the first scenario, this is just a hypothetical attack google could do if they were evil. In the second scenario this is a realistic attack we need to consider could happen. The difference between "hypothetical" and "realistic" matters quite a bit.
The second case was apparently feasible enough that the FBI thought it was worth trying in open court. I don't think the first case is that dissimilar. And I think there is a decent chance that the NSA/CIA has stronger pressure methods than what the FBI tried in the San-bernedino case.
And if not, it seems quite a bit more feasible for new legislation to be written that could be used to force google to cooperate with malicious update signing. It certainly fits with the theme of recent "we should be allowed to read your messages" legislation attempts. Heck, I think it would be one of the more reasonable ways to implement such legislation.
Hypothetical new legislation could require you to download a NSA rootkit on all of your devices too. Nothing about this feature is uniquely weak to arbitrary legislation.
By that I mean, would it be possible that 2 different people download the app from the Play store, one of them gets an unmodified version of the app and the other (perhaps based on the user's race, country of origin, etc.) gets an on-the-fly modified version of the app.
The developer - and likely 99+% of all users - would never know or even be able to tell because most copies of the app in existence are 100% what the developer created. But, for a few rare birds, backdoors are aplenty.
Regardless, I'm 100% against this. But, my thinking above is this is possibly far worse than I initially imagined.
Apple calls this approach "app thinning".
Also remember that Google Play Store could serve whichever APK it liked right now - the signing keys aren't surfaced in UI on Android (or iOS for that matter).
I am curious what are good solutions to this problem? Compile your OS (and any other software) from source?
You have to rely on a distribution that has a many-eyes review policy and has security conscious users.
That's blatantly understating how many packages are reproducible.
Multiple people can grab the sources from the developer, review and apply the patches, build the package and publish the resulting hash. With reproducible builds, all people end up with the same hash, which should also be the same for the pre-built package in the repository.
In other words, instead of trusting one single person (the maintainer) you split the trust across multiple people. This is definitely an improvement thanks to reproducible builds.
And, there are large tech firms doing this already.
With the upcoming change, we loose this verification when using Google's app store.
Developers can still create key pairs themselves and upload them to Google. So they can still publish their public key if they want and you can be certain that APKs distributed from somewhere other than Play were definitely signed by the developer.
I think this is exactly the bit people don't like. I don't want them to "own" my operating system.
In the case of Apple, I agree. It doesn't make sense to use their ecosystem without trusting them fully.
However, in the case of Android / Google Play, right now the developers have the option to choose between APKs and App Bundles. Why take away that choice? If App Bundles are superior, then developers will choose that option freely. (Google Play is already really pushy when recommending to use App Bundles.)
Upstream can sign or otherwise indicate integrity (e.g., Git revision checksums) of all individual source files. This ... becomes tedious to check, but can be checked against Debian sources to identify where any changes might reside. Note that this still applies only to sources rather than builds, though it's an option. It's likely not an option in wide use.
Debian also ships sources rather than builds, which can be built directly on your own systems (or within your own build-and-distribution network). Debian's had a "reproducible builds" initiative for some years (https://wiki.debian.org/ReproducibleBuilds), and this covers a fair number of packages (I don't have a count offhand), though there are notable exceptions of packages which are simply too complex to build reproducibly. I think the September 2020 summit notes are the best current overview of status, tools, and issues: https://reproducible-builds.org/reports/2020-09/
And, unlike Google Play, it's possible to download from any arbitrary Debian mirror without authentication. Authentication-prior-to-download could lead to branching logic for user-specific modified packages being delivered. Another option of course being for a generically-modified package that targets a single user or specified set of narrow criteria.
With Google the entire process is completely opaque, they do everything behind closed doors, and can hand different users different blobs on demand.
Ultimately with Google, you only have Google's word for what they're doing, and you know they have the capability to provide different versions to different users on demand of an NSL. With Debian, they have no way to attack a specific user, and you fully have the ability to "check their work."
Maybe they can release a tool to create APKs from App Bundles locally (maybe call it, idk, 'bundletool' or something like that). They could also make it so the Google Play Console allows developers to choose between uploading APKs or an App Bundle, and communicating the pros/cons of both methods. That way, a developer (not Google) can choose which option is best for their business and their customers!
Sound good to me at least (although to be fair, I don't have an ulterior motives or bad intentions)
I wonder if internally they either have this ability or this constraint is only required for non Google app developers?