12 ms·

Starting in August, Google will require that they sign apps, not you

225 points by mritzmann 5y ago

dheera 5y ago
https://developer.android.com/studio/publish/app-signing https://developer.android.com/studio/publish/app-signing 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."
- GauntletWizard 5y ago
  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] [1] https://developer.android.com/guide/app-bundle https://developer.android.com/guide/app-bundle
- throwuxiytayq 5y ago
  Yes, that's apps. https://developer.android.com/distribute/play-policies#RequirementForNewApps 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."
  - dheera 5y ago
    Okay, shit.
- deleted 5y ago
  [deleted]
- jeroenhd 5y ago
  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. [1] https://developer.android.com/studio/publish/app-signing#opt-out https://developer.android.com/studio/publish/app-signing#opt...
  - saurik 5y ago
    ...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.
GauntletWizard 5y ago
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.
- eganist 5y ago
  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.
  - MattGaiser 5y ago
    Fulfilled by Amazon does that, although it is more than a shipping company there.
    - rblatz 5y ago
dredmorbius 5y ago
Is cosigning / joint signing not an option?
- vesinisa 5y ago
  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!)
  - Avamander 5y ago
    Actually signature scheme V3 supports multiple keys.
- quotemstr 5y ago
  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. [1] https://developer.android.com/google/play/filters https://developer.android.com/google/play/filters
  - dredmorbius 5y ago
    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.
userbinator 5y ago
It's still more open than iOS, but you can feel the walls rising on Android with moves like this.
will4274 5y ago
In the Play Store. Kinda a key detail. You can still sign your own packages on alternate stores or from your website.
- slim 5y ago
  It's not a detail. Google could easily change my app. I can't verify it's the app I compiled
  - jhasse 5y ago
    They can do that already. The Play Store has root.
    - asddubs 5y ago
      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
    - cesarb 5y ago
      > The Play Store has root. 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.
- bogwog 5y ago
  > You can still sign your own packages on alternate stores or from your website. Not if you want customers.
sschueller 5y ago
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.
- jonplackett 5y ago
  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.
  - dijit 5y ago
    The judgement was because you literally could not buy a PC without windows on it, and they had a >98% market share.
  - tobylane 5y ago
    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.
    - fakedang 5y ago
      Correction. There was no judgement. The case was settled, which is why they can continue to do so. I was clarified on the same here on HN too.
      - jonplackett 5y ago
        The proper answer! thanks.
Igorvelky 5y ago
So essentially google will backdoor your odometer app instead of backdooring your mobilephone which can provide, video, audio, location,.... MAKES SENSE, PLEASE BOYCOTT GOOGLE EVERYONE... SARCASM
jsnell 5y ago
Discussion from 2 weeks ago: https://news.ycombinator.com/item?id=27010463 https://news.ycombinator.com/item?id=27010463
Guest42 5y ago
Question, does this hinder a persons ability to create APKs from their own code without any intention of publishing to the play store?
- vesinisa 5y ago
  It does not, but if they choose to publish through Play Store it makes it more difficult to use alternative stores.
- eplanit 5y ago
  Not _yet_, but surely that's on the horizon. We (developers) need a truly open mobile platform, soon!
  - Google234 5y ago
    That platform will not doubt be infested with malware.
    - bogwog 5y ago
      Unlike what? Android? iOS? 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.
    - yjftsjthsd-h 5y ago
      Pinephone just runs Linux distros, which have a good track record.
    - eplanit 5y ago
      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
rocqua 5y ago
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.
- roody15 5y ago
  No tinfoil needed here. This is exactly what is happening.
  - dredmorbius 5y ago
    Source?
    - selfhoster11 5y ago
      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.
      - dredmorbius 5y ago
        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 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 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_official) 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-blower-russ-tice-may-be-right.html 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) 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 https://en.wikipedia.org/wiki/MAINWAY Project ECHELON, with disclosures of varying aspects from 1972 -- 2000. https://en.wikipedia.org/wiki/ECHELON 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 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 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.
nodamage 5y ago
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.
- Thorentis 5y ago
  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.
  - izacus 5y ago
    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.
    - sltkr 5y ago
      Apps have control over which data they allow to be backed up, and this is controlled by the OS, not the Google Play Store.
  - nodamage 5y ago
    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: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
secondcoming 5y ago
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.
- quotemstr 5y ago
  Symbian also charged developers high fees to access certain special APIs, doubly ensuring the death of their platform.
  - secondcoming 5y ago
    Yes and some API required permission from the phone manufacturers. However, it stopped shitty apps from being able to slurp all your contacts, etc.
- Mountain_Skies 5y ago
  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.
deleted 5y ago
[deleted]
ultrablack 5y ago
How does this play with alternative app stores? Could you then upgrade your app from them?
bogwog 5y ago
What if instead, Google makes it optional? 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)
rockwotj 5y ago
One thing that's super annoying about this is Google's own build tool Bazel can't create app bundles: https://github.com/bazelbuild/bazel/issues/11497 https://github.com/bazelbuild/bazel/issues/11497 I wonder if internally they either have this ability or this constraint is only required for non Google app developers?
massung 5y ago
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.
- Skunkleton 5y ago
  Yes. But they could conceivably already modify Apps at install time or run time, so this is only a new vector for an existing attack.
- izacus 5y ago
  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).
  - dbrgn 5y ago
    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.
dvh 5y ago
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.
jrockway 5y ago
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?
- yjftsjthsd-h 5y ago
  Trust but verify: I trust Debian more to start, and reproducible builds mean I can verify.
- w4rh4wk5 5y ago
  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.
  - izacus 5y ago
    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.
    - Avamander 5y ago
      > There's nothing guaranteeing that Deb contains the same thing as source Deb. That's blatantly understating how many packages are reproducible.
      - izacus 5y ago
        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.
crazypython 5y ago
This is the same thing as the Chinese government forcing everyone to install an HTTPS Certificate Authority (CA) so they can backdoor HTTPS traffic.
nashashmi 5y ago
It seems this is only for app bundles and not for individual apks.
- ajnin 5y ago
  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.
thayne 5y ago
What is the impact of this on alternative installation mechanisms such as f-droid or side loading
- bogwog 5y ago
  Nothing. This only affects apps on Google Play.
HDMI_Cable 5y ago
I'm sorry if this is a noob question, but will package repos like FDroid still work? Or will operating system reject non-Google / self-built packages?
- dbrgn 5y ago
  They will still work.
- Aulig 5y ago
  Those will still work.
- rocqua 5y ago
  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.
  - HDMI_Cable 5y ago
    Okay, Thanks!
caseymarquis 5y ago
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.
Kenji 5y ago
People who use Android or iOS are slaves.
tareqak 5y ago
Why not require both Google and the software creators to sign the app?
- detaro 5y ago
  Google wants to assemble packages of the software optimized for the specific device, and presumably doesn't want to wait until all devices are updated to some future version of Android that understands a format that allows still verifying the creators signature on modified packages. (or wants to do modifications that go beyond picking parts of a pre-signed set)
srg0 5y ago
Question, in the iOS/AppStore world, who does sign the apps? Is it Apple, or is it the original developer?

225 points by mritzmann 5y ago

https://developer.android.com/studio/publish/app-signing https://developer.android.com/studio/publish/app-signing 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."

GauntletWizard 5y ago
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] [1] https://developer.android.com/guide/app-bundle https://developer.android.com/guide/app-bundle
throwuxiytayq 5y ago
Yes, that's apps. https://developer.android.com/distribute/play-policies#RequirementForNewApps 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."
- dheera 5y ago
  Okay, shit.
deleted 5y ago
[deleted]
jeroenhd 5y ago
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. [1] https://developer.android.com/studio/publish/app-signing#opt-out https://developer.android.com/studio/publish/app-signing#opt...
- saurik 5y ago
  ...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.

GauntletWizard 5y ago

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.

eganist 5y ago
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.
- MattGaiser 5y ago
  Fulfilled by Amazon does that, although it is more than a shipping company there.
  - rblatz 5y ago

dredmorbius 5y ago

Is cosigning / joint signing not an option?

vesinisa 5y ago
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!)
- Avamander 5y ago
  Actually signature scheme V3 supports multiple keys.
quotemstr 5y ago
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. [1] https://developer.android.com/google/play/filters https://developer.android.com/google/play/filters
- dredmorbius 5y ago
  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.

userbinator 5y ago

It's still more open than iOS, but you can feel the walls rising on Android with moves like this.

will4274 5y ago

In the Play Store. Kinda a key detail. You can still sign your own packages on alternate stores or from your website.

slim 5y ago
It's not a detail. Google could easily change my app. I can't verify it's the app I compiled
- jhasse 5y ago
  They can do that already. The Play Store has root.
  - asddubs 5y ago
    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
  - cesarb 5y ago
    > The Play Store has root. 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.
bogwog 5y ago
> You can still sign your own packages on alternate stores or from your website. Not if you want customers.

sschueller 5y ago

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.

jonplackett 5y ago
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.
- dijit 5y ago
  The judgement was because you literally could not buy a PC without windows on it, and they had a >98% market share.
- tobylane 5y ago
  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.
  - fakedang 5y ago
    Correction. There was no judgement. The case was settled, which is why they can continue to do so. I was clarified on the same here on HN too.
    - jonplackett 5y ago
      The proper answer! thanks.

Igorvelky 5y ago

So essentially google will backdoor your odometer app instead of backdooring your mobilephone which can provide, video, audio, location,.... MAKES SENSE, PLEASE BOYCOTT GOOGLE EVERYONE... SARCASM

jsnell 5y ago

Discussion from 2 weeks ago: https://news.ycombinator.com/item?id=27010463 https://news.ycombinator.com/item?id=27010463

Guest42 5y ago

Question, does this hinder a persons ability to create APKs from their own code without any intention of publishing to the play store?

vesinisa 5y ago
It does not, but if they choose to publish through Play Store it makes it more difficult to use alternative stores.
eplanit 5y ago
Not _yet_, but surely that's on the horizon. We (developers) need a truly open mobile platform, soon!
- Google234 5y ago
  That platform will not doubt be infested with malware.
  - bogwog 5y ago
    Unlike what? Android? iOS? 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.
  - yjftsjthsd-h 5y ago
    Pinephone just runs Linux distros, which have a good track record.
  - eplanit 5y ago
    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

rocqua 5y ago

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.

roody15 5y ago
No tinfoil needed here. This is exactly what is happening.
- dredmorbius 5y ago
  Source?
  - selfhoster11 5y ago
    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.
    - dredmorbius 5y ago
      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 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 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_official) 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-blower-russ-tice-may-be-right.html 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) 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 https://en.wikipedia.org/wiki/MAINWAY Project ECHELON, with disclosures of varying aspects from 1972 -- 2000. https://en.wikipedia.org/wiki/ECHELON 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 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 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.

nodamage 5y ago

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.

Thorentis 5y ago
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.
- izacus 5y ago
  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.
  - sltkr 5y ago
    Apps have control over which data they allow to be backed up, and this is controlled by the OS, not the Google Play Store.
- nodamage 5y ago
  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: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

secondcoming 5y ago

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.

quotemstr 5y ago
Symbian also charged developers high fees to access certain special APIs, doubly ensuring the death of their platform.
- secondcoming 5y ago
  Yes and some API required permission from the phone manufacturers. However, it stopped shitty apps from being able to slurp all your contacts, etc.
Mountain_Skies 5y ago
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.

deleted 5y ago

[deleted]

ultrablack 5y ago

How does this play with alternative app stores? Could you then upgrade your app from them?

bogwog 5y ago

What if instead, Google makes it optional? 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)

rockwotj 5y ago

One thing that's super annoying about this is Google's own build tool Bazel can't create app bundles: https://github.com/bazelbuild/bazel/issues/11497 https://github.com/bazelbuild/bazel/issues/11497 I wonder if internally they either have this ability or this constraint is only required for non Google app developers?

massung 5y ago

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.

Skunkleton 5y ago
Yes. But they could conceivably already modify Apps at install time or run time, so this is only a new vector for an existing attack.
izacus 5y ago
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).
- dbrgn 5y ago
  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.

dvh 5y ago

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.

jrockway 5y ago

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?

yjftsjthsd-h 5y ago
Trust but verify: I trust Debian more to start, and reproducible builds mean I can verify.
w4rh4wk5 5y ago
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.
- izacus 5y ago
  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.
  - Avamander 5y ago
    > There's nothing guaranteeing that Deb contains the same thing as source Deb. That's blatantly understating how many packages are reproducible.
    - izacus 5y ago
      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.

crazypython 5y ago

This is the same thing as the Chinese government forcing everyone to install an HTTPS Certificate Authority (CA) so they can backdoor HTTPS traffic.

nashashmi 5y ago

It seems this is only for app bundles and not for individual apks.

ajnin 5y ago
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.

thayne 5y ago

What is the impact of this on alternative installation mechanisms such as f-droid or side loading

bogwog 5y ago
Nothing. This only affects apps on Google Play.

HDMI_Cable 5y ago

I'm sorry if this is a noob question, but will package repos like FDroid still work? Or will operating system reject non-Google / self-built packages?

dbrgn 5y ago
They will still work.
Aulig 5y ago
Those will still work.
rocqua 5y ago
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.
- HDMI_Cable 5y ago
  Okay, Thanks!

caseymarquis 5y ago

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.

Kenji 5y ago

People who use Android or iOS are slaves.

tareqak 5y ago

Why not require both Google and the software creators to sign the app?

detaro 5y ago
Google wants to assemble packages of the software optimized for the specific device, and presumably doesn't want to wait until all devices are updated to some future version of Android that understands a format that allows still verifying the creators signature on modified packages. (or wants to do modifications that go beyond picking parts of a pre-signed set)

srg0 5y ago

Question, in the iOS/AppStore world, who does sign the apps? Is it Apple, or is it the original developer?