Dear Google Play Team:
Recently, you stated:
we intend to require new apps and games to publish with the Android App Bundle on Google Play in the second half of 2021
(emphasis yours)
To publish an App Bundle, we must use App Signing:
it is a requirement to use Play App Signing in order to publish with App Bundles on Google Play.
This gives you signing authority over the APKs that are delivered to people. As far as I can tell, this means that you can do whatever you want with the contents of those APKs, including adding to and replacing the original code supplied by the app’s developers. Worse, this requirement for new apps feels like a trial run for eventually requiring all developers to opt into App Signing.
Given that… we need to talk.
Some people may be worried about you modifying apps for your own benefit, such as degrading performance for apps that compete with Google properties. That does not keep me awake at night.
This does:
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 certain apps to people of our choosing. We will supply you with the altered apps, and we will supply you with the identities or criteria for choosing the people who should receive these altered apps. That criteria might be narrow or wide, up to and including all people within our country.” They then supply Google with the identities of leaders of the minority group, along with altered versions of next-generation end-to-end (E2E) encrypted messaging apps. These altered apps capture communications by grabbing the data out of the app’s UI directly and sending them to a regime-controlled server, bypassing the encryption. Google gives the regime each version of the targeted apps as they get released and postpones those releases on the Play Store, under the guise of the app review process, so the regime can make its changes to those apps. 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 many options to choose from.
App Signing, and your upcoming moves to make it mandatory for new apps, opens you up to this sort of coercion. Right now, you have “plausible deniability” — you can claim that certain apps simply did not opt into App Signing. Your new requirement removes that defense for new apps after your chosen date for that requirement. If you eventually force all developers to opt into App Signing, then this form of coercion seems inevitable.
Project Dragonfly, is a depressing demonstration of executive intent. However, there seemed to be some internal push-back within your firm to Project Dragonfly, at least among engineers.
I am hopeful that those of you who are being forced to implement this new policy have a plan for how to block this sort of coercion or otherwise prevent my scenario from playing out. It would be good if we knew what that plan was, as it is much easier for us to help with plans that way.
So… what’s the plan?
Right now, publicly, the plan appears to be to claim that this just will not happen.
For example, in a Medium post about app signing, a Google developer advocate 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, this person used “don’t” and “will not”… as opposed to “can’t” and “cannot”.
However, you readily admit that you modify the app from what we give you as the App Bundle. For example, that same Medium post includes:
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.
That sort of metadata change apparently has been going on for a couple of years.
Besides, Amazon has been doing this sort of thing for the better part of a decade:
Amazon wraps your app with code that enables the app to communicate with the Amazon Appstore client to collect analytics, evaluate and enforce program policies, and share aggregated information with you. Your app will always communicate with the Amazon Appstore client when it starts [To do this], 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.
You admit that you can do the same sort of re-signing for apps distributed via App Signing, even those shipped as APKs:
Google verifies and strips your signature from the APK, and then resigns the APK with the app signing key
So, it seems like “don’t” instead of “can’t” represents a policy of forbearance. You appear to be capable of doing much more, but you 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.
So, one possible plan is for you to have teeth behind the “don’t modify and distribute your application code without your knowledge and approval” claim.
So:
-
Is your claim that modifying the code is impossible? It seems like it is possible, but perhaps I am missing something. I would love to see a technical explanation of how you would be unable to change the bytecode or resource content prior to signing the APKs.
-
Are you pursuing legislation to ban this practice? Perhaps you are working with lawmakers in major countries to ban this sort of behavior, with suitable penalties for firms (and their executives) that participate in it. That might cover more than just app modifications — it might also ban modifications made to Web content in transit by ISPs, such as the various “super-cookie” sorts of changes that crop up from time to time. If this is your plan, it would be nice if a wide range of participants, including those from organizations advocating for civil liberties, would be involved.
Perhaps the plan is that you really will not require App Signing for App Bundles. After all, just because one of your staff members said that App Bundles require App Signing does not mean that this requirement will hold indefinitely. Perhaps it will be relaxed before the App Bundle mandate comes into play. Or, perhaps the App Bundle mandate itself might be relaxed.
After all, App Bundles are not a technical requirement. We have been distributing APKs for over a decade, and in that time, the dead have not risen, kaiju have not laid waste to major cities, and aliens have not invaded.
(then again, it is 2020…)
Also, App Bundles would not appear to be necessary to achieve your technical objectives. Your
goal is to deliver the right subsets of an app to a device based on device characteristics.
To do that, you generate a sliced-up app out of an App Bundle and deliver a
few APKs that, when combined, implement the app without extraneous resources and
stuff. We know this because bundletool lets us generate those APKs, and we can
even install those APKs ourselves to demonstrate that they work. bundletool will
even sign them with our signing key.
That means that we do not need to send you an App Bundle for you get
the benefits of one. We could send you the signed APKs created by bundletool instead. For
example, we could ZIP those up into an “App Assortment” and upload that to the developer
console instead of the App Bundle. You appear to get everything that you need to achieve
your technical objectives, just without the ability to sign. Instead, we sign
the APKs, just as we do today, albeit perhaps via bundletool.
This is not to say that you should stop offering App Signing, just that it should be a choice, as it has been since you introduced it.
Perhaps something along these lines is how you intend to avoid coercion — you can claim that any app that regimes want to alter is still being signed by the app’s developers, not you. So:
-
Will you extend App Bundles to allow for developer-signed artifacts and no App Signing? This seems to be fairly trivial, given the existing capabilities of
bundletool. But, if there is some reason whybundletooloutput that seems to work does not actually work… that would be good to know, with adequate details, of course. -
Will you rescind the App Bundle requirement, and allow for developer-signed APKs indefinitely? After all, you are the one announcing that App Bundles are going to be required. You can change your mind on that.
Perhaps you can modify apps prior to signing, and the reason that you are requiring signing authority is because you think that you might want to modify apps in the future, even though you claim that you are not doing so right now.
Maybe your plan is that we would detect any nefarious modifications, should you ship some.
If so, I would be interested to know how you would like us to go about doing that.
Technically, the regime-hack scenario could happen today, even with developer-signed APKs. However, in that case, you 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 you are distributing an altered app. Plus, the risk would be limited to new installs of the app — any user with an existing app installation with the developer’s signed app would refuse to install the altered app, 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 apps. And a regime has a much more difficult time coercing an app developer, because that developer does not distribute the app, so everybody has to get the alterations, making them more likely to be discovered.
But, with App Signing, we cannot just check an app’s signature. The signature will be valid; the contents of the APKs are what is in question, because you can modify them based on the demands applied via the coercion.
Perhaps you are counting on the new App Bundle explorer:
You can download and attest the exact APKs that Play generates for delivery
The problem is that we have no way to know if these are the actual APKs that Play will distribute. After all, you are perfectly capable of distributing one set of APKs through the explorer and another to Android device owners.
Perhaps your vision is that we would use hashes or something to confirm that the APKs delivered to people match those from the explorer. The implication is that it would be up to us developers to:
-
Confirm that the explorer APKs match
bundletooloutput, as we can see whatbundletooldoes and confirm that it is not doing anything malicious; then -
Publish hashes of the
bundletool/explorer output in such a way that security apps (and perhaps our own apps) could validate that the installed APKs are valid; and -
Ensure that those hashes themselves are not able to be modified by some attacker
That is not out of the question. However, it is a fair bit of infrastructure.
More importantly, though, it gets back to the root concern outlined in section
of this letter: if your plan is that you want to modify the apps,
then presumably someday you will do just that. So now we’re in a situation
where bundletool output intentionally does not match what you are shipping to people.
Detecting changes would be insufficient — we would need to determine (somehow)
whether those changes are malicious or not, and do this on a massive scale (one
that precludes manual inspection).
So, how are you expecting us to “attest” these APKs, for real? What is the process by which you are expecting us to confirm that, while you have made changes to the APKs, that those changes are beneficial and not harmful? And how do you expect us to do this for everyone who is using the app, given that you could modify the app for some people and not for others?
When App Signing came out, I was concerned for the reasons that I outlined in this letter. However, it was opt-in, and so while I would quietly steer developers away from it, that is all that I did. Now that you are making it mandatory for some apps — and appear have the ability to make it mandatory for all in the future — I think that it is time that we figure out how to minimize the risk to the ~2.5 billion Android device owners.
So… what’s the plan?
Sincerely Yours,
Mark Murphy (a Commons Guy)
