关于应用程序签名的令人不安的问题
我们打算在2021年下半年要求在Google Play上使用Android App Bundle发布新的应用程序和游戏。
需要使用Play App Sign才能在Google Play上使用App Bunles发布。
据我所知，这意味着你可以随心所欲地处理这些APK的内容，包括添加和替换应用程序开发人员提供的原始代码。更糟糕的是，这种对新应用程序的要求感觉就像是最终要求所有开发者选择加入应用程序签名的试运行。
有些人可能会担心你为了自己的利益而修改应用程序，比如降低与谷歌产品竞争的应用程序的性能，这并不会让我晚上睡不着觉。
一个由专制政权统治的国家正在压迫少数群体。该政权的领导人告诉谷歌：“为了在我们国家做生意，你需要同意将某些应用程序的修改版本分发给我们选择的人。我们将向您提供更改后的应用程序，并向您提供选择应接收这些更改后应用程序的人员的身份或标准。这一标准可能是有利的，也可能是广泛的，包括我们国家的所有人。“。然后，他们向谷歌提供少数群体领导人的身份，以及下一代端到端(E2E)加密消息应用的修改版本。这些修改后的应用程序通过直接抓取应用程序用户界面的数据并将其发送到受政权控制的服务器来捕获通信，从而绕过加密。谷歌在目标应用发布时向该政权提供了每个版本的目标应用，并以应用审查过程为幌子，推迟了这些版本在Play Store上的发布，这样政权就可以对这些应用进行更改。谷歌签署这些修改过的应用程序-与应用程序来自原始开发者的情况没有什么不同-并将这些修改后的应用程序分发给指定的受害者。
您可以为国家和少数群体提供您自己的价值观。有很多选择可供选择。
应用程序签名，以及你即将采取的强制新应用程序签名的举措，都会让你面临这种胁迫。现在，你有“似是而非的否认”--你可以声称某些应用程序根本没有选择加入应用程序签名。您的新要求取消了对您为该要求选择的日期之后的新应用程序的防御。如果你最终强迫所有开发者选择加入App签名，那么这种形式的强制似乎是不可避免的。
“蜻蜓计划”是一个令人沮丧的执行意图的展示。然而，贵公司内部似乎对“蜻蜓计划”有一些反感，至少在工程师中是这样。
我希望你们中那些被迫实施这项新政策的人有一个计划，如何阻止这种胁迫或以其他方式防止我的情况发生。如果我们知道那是什么计划就好了，因为这样我们就更容易帮助制定计划了。
现在，在公开场合，计划似乎是宣称这种情况不会发生。
未经您的知情和批准，我们不会修改和分发您的应用程序代码。
如前所述，Play不会在您不知情和未经您批准的情况下修改您的应用程序的功能。
值得注意的是，这个人用的是“不要”和“将不”…。而不是“不能”和“不能”。
但是，您会欣然承认您修改了我们提供给您的应用程序捆绑包。例如，同一媒体帖子包括：
对于作为应用程序包上传的应用程序，我们将通过引入所谓的源码戳来提高安全性。此源元数据通过bundletool插入到应用程序的清单中。
这种元数据的变化显然已经持续了几年。
此外，亚马逊在过去十年的大部分时间里一直在做这类事情：
Amazon使用代码包装您的应用程序，使该应用程序能够与Amazon Appstore客户端进行通信，以收集分析、评估和实施计划策略，并与您共享聚合信息。当您的应用程序开始[执行此操作]时，它将始终与Amazon Appstore客户端通信，Amazon将删除您的签名，并使用对您唯一、不会更改且对您帐户中的所有应用程序都相同的Amazon签名重新签署您的应用程序。
Google验证并从APK中剥离您的签名，然后使用应用程序签名密钥重新签署APK。
所以，“不做”而不是“不能”似乎是一种宽容的政策，你似乎有能力做得更多，但你现在却决定不做。
但是，策略可以在任何时间、任何原因、没有任何警告的情况下更改。或者，就像某个戴深色头盔的人曾经说过的那样：
因此，一个可能的计划是让您支持“在您不知情和未经批准的情况下不要修改和分发您的应用程序代码”的声明。
您声称修改代码是不可能的吗？这似乎是可能的，但也许我错过了什么。我希望看到一份技术说明，说明如何在签署APK之前无法更改字节码或资源内容。
你是否正在寻求立法禁止这种做法？也许你正在与主要国家的立法者合作，禁止这种行为，对参与其中的公司(及其高管)进行适当的惩罚。这可能不仅仅包括应用程序的修改-还可能禁止互联网服务提供商对传输中的网络内容进行的修改，例如不时出现的各种“超级cookie”式的改变。如果这是你的计划，如果有广泛的参与者，包括那些倡导公民自由的组织的参与者，那就太好了。
也许你的计划是，你真的不需要App Sign for App Bundle，毕竟，仅仅因为你的一名工作人员说App Bundle需要App Signing，并不意味着这一要求将无限期存在。也许在App Bundle命令生效之前，它会有所放松。或者，也许应用程序捆绑包授权本身可能会放松。
毕竟，应用程序捆绑包不是技术要求。我们分发APK已经十多年了，在那段时间里，死人没有复活，怪兽没有对大城市造成破坏，外星人也没有入侵。
此外，应用程序捆绑包似乎不是实现您的技术目标所必需的。你的目标是根据设备特性向设备提供正确的应用子集。要做到这一点，你需要从应用捆绑包中生成一个切片化的应用，然后交付几个APK，当这些APK组合在一起时，就可以在没有外来资源和东西的情况下实现应用。我们之所以知道这一点，是因为bundletool允许我们生成那些APK，我们甚至可以自己安装这些APK来演示它们的工作。Bundletool会用我们的签名密钥给他们签名。
这意味着我们不需要向您发送App Bundle，您就可以享受其中的好处。我们可以向您发送由bundletool创建的签名APK。例如，我们可以将它们压缩成“应用程序分类”，然后将其上传到开发人员控制台，而不是App Bundle。你似乎得到了实现你的技术目标所需的一切，只是没有签约的能力。取而代之的是，我们签署了APK，就像我们今天所做的那样，尽管可能是通过bundletool。
这并不是说你应该停止提供App Signature，只是说它应该是一个选择，就像你引入它以来一直以来的那样。
也许这就是你打算如何避免强迫--你可以宣称任何政权想要改变的应用程序仍然是由应用程序的开发者签署的，而不是你。所以：
您会扩展App Bunles以允许开发人员签名的工件，而不允许应用程序签名吗？考虑到bundletool的现有功能，这似乎是相当微不足道的。但是，如果有什么原因导致看似有效的bundletool输出实际上不起作用，那么…。当然，知道这一点会很好，而且要有足够的细节。
你会取消App Bundle的要求，无限期允许开发者签名的APK吗？毕竟，是你宣布需要App Bundle的，你可以改变主意。
也许您可以在签名之前修改应用程序，您需要签名权限的原因是因为您认为将来可能需要修改应用程序，即使您声称现在没有这样做。
如果是这样的话，我很想知道你们希望我们如何着手做这件事。
从技术上讲，即使是开发者签署的APK，政权黑客的情况也可能在今天发生。然而，在这种情况下，您不能对更改后的应用程序版本进行签名。因此，监控应用程序使用的签名键的开发人员将能够检测到您分发的是经过更改的应用程序这一事实。此外，风险仅限于新安装的应用程序-任何安装了开发者签名应用程序的现有应用程序的用户都会拒绝安装修改后的应用程序，因为签名密钥不匹配。诚然，我们可以在这里做更多的工作来监控这类攻击，但我们得到了很多“免费”的保护，仅仅是让开发人员签署应用程序就可以了。而且一个政权强迫应用程序开发者要困难得多，因为开发者不分发应用程序，所以每个人都必须得到修改，使它们更有可能被发现。
但是，使用应用程序签名，我们不能只检查应用程序的签名。签名将是有效的；APK的内容是有问题的，因为您可以根据通过强制应用的要求修改它们。
问题是，我们无法知道这些是否是Play将分发的实际APK。毕竟，您完全有能力通过浏览器分发一组APK，并将另一组分发给Android设备用户。
也许您的愿景是，我们将使用散列或其他方法来确认交付给人们的APK是否与浏览器中的APK匹配。言下之意是，这将由我们开发人员决定：
确认资源管理器APK与bundletool输出匹配，因为我们可以看到bundletool做了什么，并确认它没有做任何恶意的事情；然后。
发布bundletool/explorer输出的散列，以便安全应用程序(也许还有我们自己的应用程序)可以验证安装的APK是有效的；以及
这不是不可能的。然而，这是一个相当大的基础设施。
然而，更重要的是，它回到了这封信第一节概述的根本问题：如果你的计划是想要修改这些应用程序，那么想必有一天你会这么做。因此，现在我们处于这样一种情况：捆绑包输出故意与您发送给人们的内容不匹配。检测更改是不够的-我们需要(以某种方式)确定这些更改是否是恶意的，然后大规模地执行此操作(这排除了手动检查)。
那么，你希望我们如何真正地“证明”这些APK呢？您希望我们通过什么过程来确认，虽然您对APK进行了更改，但这些更改是有益的而不是有害的？考虑到你可以为一些人修改应用程序，而不是为其他人修改应用程序，你希望我们如何为每个使用这款应用程序的人做这件事呢？
当App Signature问世时，我担心的是我在这封信中概述的原因。然而，它是选择加入的，所以虽然我会悄悄地引导开发人员避开它，但这就是我所做的一切。现在你对一些应用程序强制要求-而且似乎有能力在未来强制所有人-我认为是时候我们找出如何将对大约25亿Android设备用户的风险降到最低的时候了。
您的团队需要接受Android应用程序开发培训吗？马克·墨菲已经训练了数百人！多学点！
