On Sun, Jun 21, 2020, at 22:20, John Sullivan wrote: > Just a quick comment on that last part. It may be worth mentioning for > a fuller picture that F-Droid signs the builds themselves because they > build them themselves. They publish all of the source that they are > building as well as the server software that does the build. Doesn't > mean things are 100% reproducible, but it might be relevant to mention.
The *intent* is for F-Droid to build the apps themselves solely from the
original sources. With sufficient motivation ("those are lovely kneecaps you
got there -- it would be a pity if we had to break them"), F-Droid could be
convinced to deliver altered apps. And, as with the Google App Bundle scenario,
there is nothing to stop them. That then puts the onus on app developers or the
broader ecosystem to detect this, and I don't know if anyone is looking.
Perhaps people are looking and I just don't know about it -- if you know of
people who are, I'd love to hear about them!
That being said, I replaced the section where I mentioned F-Droid with another
one where I don't mention them directly. A revised post is attached.
Thanks for the feedback!
--
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguyIn Milena Nikolic’s “What’s New in Google Play” presentation, she said:
As we continue to improve the App Bundle, we expect it to become a requirement for all new apps sometime in 2021.
I have not talked about the App Bundle much, other than privately steering developers away from it. Technically speaking, I am not opposed to the App Bundle itself. But, I am vehemently opposed to one “feature” of App Bundles: Google signs them. So, if Google is going to going to start forcing App Bundles on developers, we need to focus on the risks inherent in Google signing your apps.
The Folly of Forbearance
In a Medium post, Wojtek KaliciÅski wrote:
we donât modify and distribute your application code without your knowledge and approval
and:
As stated before, Play will not modify the functionality of your application without your knowledge and approval.
Notably, he used “don’t” and “will not”… as opposed to “can’t” and “cannot”.
Google is perfectly capable of changing anything that they want in your app. You are what you sign. If Google signs the app, in reality Google is the developer of the app, controlling what is in it. You just did all the work.
Google readily admits that they modify the app from what you give them as the App Bundle. Most notably, they subdivide the App Bundle into APKs that allow them to distribute a subset of your app, stripping out things that the user does not need, based upon device capability. Mr. KaliciÅski also stated that:
For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the appâs manifest by
bundletool.
So, Google is already modifying your app. They just are claiming that this is all that they modify of your app.
This is a policy of forbearance. They are capable of doing much more, but they are deciding not to do so at the present time.
However, policies can change, at any time, for any reason, without warning. Or, as some guy in a dark helmet once said:
I am altering the deal. Pray I don’t alter it any further.
They could add DRM, or automatically collect analytics, or enforce other rules. The Amazon AppStore for Android does these things, courtesy of them re-signing your app:
Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account.
In other words, Amazon is doing today — and has been doing for nearly a decade — what Google could be doing.
Or, Google could wind up doing things even worse than DRM.
Repression as a Service
Let’s consider a hypothetical scenario:
A country ruled by a repressive regime is oppressing a minority group. The leadership of that regime tells Google: “In order to do business in our country, you need to agree to distribute altered versions of apps to users of our choosing. We will supply you with the altered apps, and we will supply you with the identities or criteria for choosing the users who should receive these altered apps.” They then supply Google with the identities of leaders of the minority group, along with altered versions of Signal, WhatsApp, Zoom, and other end-to-end (E2E) encrypted messaging and conferencing apps. These altered apps capture communications by grabbing the data out of the app’s UI and sending them to a regime-controlled server, bypassing the encryption. Google signs those altered apps — no different than if the apps came from the original developers — and distributes those altered apps to the designated victims.
You can supply your own values for the country and the minority group. There are lots of options to choose from.
Technically, the regime-hack scenario could happen today, even with developer-signed APKs. However, in that case, Google cannot sign the altered app versions. So, developers who monitor the signing keys used for their apps would be able to detect the fact that Google is distributing an altered APK. Plus, the risk would be limited to new installs of the app — any user with an existing app installation with the developer’s signed APK would refuse to install the altered APK, as the signing keys would not match. Admittedly, we could do a lot more here to monitor for this sort of attack, but we get a lot of protections “for free”, just from having developers sign the APKs.
With the current implementation of App Bundles, those protections go out the window. Google can sign the attacker’s altered apps and distribute them as requested.
The only saving grace is that Google is only planning on requiring App Bundles for new apps. Existing apps – such as Signal, WhatsApp, and Zoom – would be exempt. But apps come and apps go, and so over the course of several years, the then-current communications apps might have to be App Bundles, simply because they are new. And, with Google signing them, they could be replaced with altered versions.
Wholesale and Retail
If the distributor of an app also signs the app, the distributor can distribute an altered app. Whether the distributor will do that voluntarily or is coerced to do that is immaterial. The problem with centralized app distributors having signing authority is that they have the ability to ship an altered app and that they know who they are delivering apps to. This allows such alterations to be distributed potentially to a narrow set of targets, but for a wide range of apps.
The coercion could be done on a per-app basis, with the developers who created it. Facebook could be coerced to ship an altered version of WhatsApp, for example. However, that coercion is harder to accomplish:
Rather than having “one-stop shopping” with the app distributor and being able to affect lots of apps at once, the regime needs to coerce individual firms, which takes more resources to do and becomes more likely to be discovered
The altered apps that the developers might be coerced to ship would go to all users, not just a targeted subset, making it more likely that somebody will notice the alterations
Google, via app bundles, is not the only app distributor that both signs and distributes apps. For example, Amazon AppStore for Android does this, as noted above. But, with all due respect to Amazon and other app distributors with signing authority, the Play Store is a bit larger. While the “2.5 billion” Android user figure probably includes people without Play Store access, it is within reason that 15–20% of the world’s population get apps from the Play Store. So, when Google starts forcing developers to let Google both sign and distribute apps, that’s a problem.
What Google Needs To Do
In Ms. Nikolic’s presentation, she also said:
Developers can only be successful on Google Play as long as users trust the platform.
With that in mind, in the next few months, it would be a really good idea if Google did one or more of the following:
Explain in detail — with lots of independently-verifiable proofs — how it is impossible for Google to ship an altered app when developers use an App Bundle. In other words, prove to the world that the hypothetical scenario described above is not possible. In theory, this would help retain users’ trust in the platform by demonstrating that there is no actual risk.
Explain in detail — ideally with lots of example code — how developers can validate that each and every copy of the app distributed by Google has not been modified beyond known and accepted modifications (e.g., the “source stamp”). In other words, admit that the hypothetical scenario is possible, but document the ways that the community can detect when this occurs. Then it would be up to us to ensure that if anyone forces Google to alter apps, it would be detected. This would help retain users’ trust in the platform, so long as they feel that our detection system is helping.
Publish a statement that walks back the claims from the aforementioned presentation or otherwise documents that developer-signed apps will remain an option, for new and existing apps, indefinitely. That could include offering a developer-signed option for App Bundles, perhaps based on
bundletool. This maintains the status quo with respect to the users’ trust in the platform.
I recommend the last one. Let’s work on having flexible delivery without the risks tied to having the signing authority and the distribution system be managed by the same firm.
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
