On Wed, Jun 17, 2020, at 19:08, Nathan of Guardian wrote: > > I am sincerely hoping that I'm forgetting something that prevents this. > > I don't think you are. If there was some kind of binary transparency > where you could see all the builds that were done and released, that > might be a small step... But still, once they have your private signing > key, they can do anything they please.
Yeah, I thought so. So, I'm going to poke the bear and see what happens. If anyone has any feedback on the attached draft blog post, I am up for any suggestions! Note: I mention F-Droid, as their policy had been to sign apps with their own signing key. It looks like now that there are some options for avoiding this, but I felt the need to address this head on. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy
In 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.
What’s Old is New Again
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. And whether the alterations are positive, neutral, or negative is immaterial.
This is nothing new, even within the Android world. As noted earlier, Amazon AppStore for Android has been doing this sort of thing for years. F-Droid, a popular open source app distributor, long required apps to be signed by their signing key, though they seem to be a bit more flexible nowadays. We trust F-Droid, and it seems very unlikely that they would ever voluntarily ship altered apps, as that goes against what F-Droid is about… but they could be coerced. Amazon, by contrast, intentionally ships altered apps, and we can only hope that their alterations are not harmful.
But, with all due respect to Amazon and the F-Droid team, 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
