[HN Gopher] Starting in August, Google will require that they si...
___________________________________________________________________
Starting in August, Google will require that they sign apps, not
you
Author : mritzmann
Score : 154 points
Date : 2021-05-16 20:20 UTC (2 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| [deleted]
| caseymarquis wrote:
| 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.
| dheera wrote:
| 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 wrote:
| 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
| throwuxiytayq wrote:
| Yes, that's apps.
|
| 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 wrote:
| Okay, shit.
| [deleted]
| jeroenhd wrote:
| 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...
| saurik wrote:
| ...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.
| sschueller wrote:
| 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 wrote:
| 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 wrote:
| The judgement was because you literally could not buy a PC
| without windows on it, and they had a >98% market share.
| tobylane wrote:
| 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 wrote:
| 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.
| Igorvelky wrote:
| 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
| GauntletWizard wrote:
| 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 wrote:
| 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 wrote:
| Fulfilled by Amazon does that, although it is more than a
| shipping company there.
| rblatz wrote:
| And Amazon commingles inventory, so when I buy an item on
| Amazon from Bob Amazon may actually ship me Alice's crappy
| fake item.
|
| 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.
| GauntletWizard wrote:
| 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.
| roody15 wrote:
| 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.
| saurik wrote:
| 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.
| falcolas wrote:
| > the app is unmodified
|
| Problem: you have no way to prove it. Nobody can prove it.
|
| That's what developer signing proves - that is hasn't been
| modified.
| Aaargh20318 wrote:
| > 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.
| eganist wrote:
| > 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.
| lazide wrote:
| 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.
| GauntletWizard wrote:
| 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.
| UncleMeat wrote:
| > a few dozen different versions
|
| 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.
| Aaargh20318 wrote:
| > 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.
| cglong wrote:
| UPS does literally this with expensive packages :) If I want
| insurance on the package, they have to be the ones to pack
| it.
| ultrablack wrote:
| How does this play with alternative app stores? Could you then
| upgrade your app from them?
| massung wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jsnell wrote:
| Discussion from 2 weeks ago:
| https://news.ycombinator.com/item?id=27010463
| dvh wrote:
| 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.
| dredmorbius wrote:
| Is cosigning / joint signing not an option?
| quotemstr wrote:
| 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
| dredmorbius wrote:
| 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.
| UncleMeat wrote:
| 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.
| dbrgn wrote:
| Post-build modifications are the whole point of App Bundles
| :) See
| https://developer.android.com/platform/technology/app-
| bundle... for details.
| vesinisa wrote:
| 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 wrote:
| Actually signature scheme V3 supports multiple keys.
| jrockway wrote:
| 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?
| izacus wrote:
| 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.
| sichtlinkair wrote:
| > ... the owner of their operating system ...
|
| I think this is exactly the bit people don't like. I don't
| want them to "own" my operating system.
| dbrgn wrote:
| 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.)
| w4rh4wk5 wrote:
| 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 wrote:
| 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.
| dbrgn wrote:
| This is what reproducible builds try to fix:
| https://wiki.debian.org/ReproducibleBuilds
| zingplex wrote:
| Isn't this exactly why they're doing the reproducible build
| stuff?
| sichtlinkair wrote:
| > 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.
|
| I am curious what are good solutions to this problem?
| Compile your OS (and any other software) from source?
| content_sesh wrote:
| Somewhere a Gentoo maintainer's ears are ringing, but
| they don't know why...
| UncleMeat wrote:
| 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.
| crazypython wrote:
| Most apps on Google Play are proprietary and cannot be
| rebuilt.
| Guest42 wrote:
| Question, does this hinder a persons ability to create APKs from
| their own code without any intention of publishing to the play
| store?
| vesinisa wrote:
| It does not, but if they choose to publish through Play Store
| it makes it more difficult to use alternative stores.
| eplanit wrote:
| Not _yet_, but surely that's on the horizon. We (developers)
| need a truly open mobile platform, soon!
| Google234 wrote:
| That platform will not doubt be infested with malware.
| userbinator wrote:
| It's still more open than iOS, but you can feel the walls rising
| on Android with moves like this.
| nashashmi wrote:
| It seems this is only for app bundles and not for individual
| apks.
| will4274 wrote:
| In the Play Store. Kinda a key detail. You can still sign your
| own packages on alternate stores or from your website.
| slim wrote:
| It's not a detail. Google could easily change my app. I can't
| verify it's the app I compiled
| jhasse wrote:
| They can do that already. The Play Store has root.
| asddubs wrote:
| 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 wrote:
| > 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.
| crazypython wrote:
| This is the same thing as the Chinese government forcing everyone
| to install an HTTPS Certificate Authority (CA) so they can
| backdoor HTTPS traffic.
| thayne wrote:
| What is the impact of this on alternative installation mechanisms
| such as f-droid or side loading
| rocqua wrote:
| 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.
| fallingknife wrote:
| The developer would still be able to post the shasum though,
| right? If so this would still be detectable.
| izacus wrote:
| 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.
| dbrgn wrote:
| Yup, I'm pretty sure this makes reproducible builds totally
| impractical for any apps installed through the Play Store.
|
| Apps that currently provide reproducible builds: Signal,
| Threema, Telegram. (Probably others as well.)
| pdkl95 wrote:
| 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.
| Gaelan wrote:
| That doesn't work if there's a large and possibly growing
| matrix of hardware/OS/whatever combinations they're
| trying to optimize for.
| derefr wrote:
| Google could publish the code they're going to use (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.
| rocqua wrote:
| 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.
| gnfargbl wrote:
| 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?
| willvarfar wrote:
| 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.
|
| Who signs what doesn't change the threat models.
| rocqua wrote:
| 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.
| Avamander wrote:
| 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.
| willvarfar wrote:
| 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.
| Judgmentality wrote:
| > 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).
| roody15 wrote:
| No tinfoil needed here. This is exactly what is happening.
| nodamage wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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_Ref.
| ..
| gruez wrote:
| 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.
| nodamage wrote:
| > _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?
| Skunkleton wrote:
| 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.
| Avamander wrote:
| Google Play Services is still bound by Android's own
| security mechanisms, it can't do _everything_ but it can
| do a lot, yes.
| izacus wrote:
| It can silently replace APKs which is exactly what the
| conversation here is about. It's more than enough.
| dbrgn wrote:
| 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.
| UncleMeat wrote:
| Have you ever checked the signing key on an app downloaded
| from Play? What developers even publish their public keys on
| the web?
| dbrgn wrote:
| This is mostly about updates (TOFU): If the OS installs the
| update, then you know it comes from the same developer.
| gruez wrote:
| >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.
| nodamage wrote:
| > _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.
| Skunkleton wrote:
| 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.
| gruez wrote:
| >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.
|
| 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/)
| Skunkleton wrote:
| 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.
| izacus wrote:
| 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.
| izacus wrote:
| 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.
| sltkr wrote:
| 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.
| gruez wrote:
| >edit: Actually I don't even know that the App Store has
| permission to uninstall apps.
|
| https://developer.android.com/reference/android/Manifest.
| per...
|
| Skimming the permissions file shipped with opengapps
| suggests that play store has it.
| <privapp-permissions package="com.android.vending">
| [...] <permission
| name="android.permission.DELETE_PACKAGES" />
| sltkr wrote:
| Thanks, I suppose that is an avenue of attack then.
| gruez wrote:
| >The Play Store is a closed binary which had privileged
| permissions to [...] update APKs.
|
| 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.and
| roid.com/guide/topics/data/autobackup#E... It's unclear
| whether this is enforced by the OS or google play services.
| rocqua wrote:
| 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.
| HDMI_Cable wrote:
| 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 wrote:
| They will still work.
| Aulig wrote:
| Those will still work.
| secondcoming wrote:
| 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 wrote:
| Symbian also charged developers high fees to access certain
| special APIs, doubly ensuring the death of their platform.
| secondcoming wrote:
| Yes and some API required permission from the phone
| manufacturers. However, it stopped shitty apps from being
| able to slurp all your contacts, etc.
___________________________________________________________________
(page generated 2021-05-16 23:00 UTC)