谷歌将允许用户在无需验证的情况下侧载(sideload)安卓应用

今日起,我们欣然邀请开发者参与Android开发者控制台的开发者验证早期体验计划(仅限非Play商店分发的开发者),Play商店开发者的控制台体验邀请也将很快发出。我们期待您对优化所有开发者体验提出问题与建议。

Android Developers Blog

(发布者:Android应用安全产品管理总监——马修·福赛思)

Android开发者验证:现已开放早期访问通道,我们将持续根据您的反馈完善方案

我们近期宣布了新的开发者验证要求,这是我们为保障Android用户安全所采取的额外防护措施。我们深知,安全措施唯有充分考虑用户多样化的使用场景才能发挥最佳效果。正因如此,我们提前公布此次变更:旨在收集各方意见,确保解决方案的平衡性。我们感谢社区的积极参与,并已收到早期反馈——特别是来自需要便捷学习途径的学生和业余爱好者,以及更愿意承担安全风险的高级用户。我们正在调整方案以满足这两类群体的需求。

元素周期表

要理解这些更新如何契合我们的整体使命,首先需明确我们正在应对的具体威胁。

验证机制的重要性

保障Android用户安全始终是我们的首要任务。打击诈骗与数字欺诈并非新举措——多年来这始终是我们的核心工作重点。从Google Messages的诈骗检测功能,到Google Play Protect及诈骗来电实时预警,我们始终致力于维护生态系统安全

然而网络诈骗与恶意软件攻击正日益猖獗。在安卓全球规模的覆盖下,这意味着全球用户正遭受切实伤害——尤其在快速数字化的地区,许多人正首次接触互联网。技术防护固然重要,但无法解决所有用户受诱导的情境。诈骗者运用高压社会工程手段,诱骗用户绕过本应保护他们的安全警示。

例如我们在东南亚追踪到的常见攻击模式就清晰揭示了这种威胁。诈骗者致电受害者谎称其银行账户遭入侵,通过制造恐慌和紧迫感诱导对方侧载“验证应用”以保护资金,并指导其忽略常规安全警告。该应用实为恶意软件,安装后会拦截受害者通知。当用户登录真实银行应用时,恶意软件会截取双因素认证码,使诈骗者得以清空账户资金。

尽管我们已建立先进的防护机制来检测并清除恶意应用,但若缺乏身份验证机制,不法分子仍能瞬间制造出新的有害应用。这如同永无止境的打地鼠游戏。身份验证机制改变了游戏规则——迫使攻击者使用真实身份分发恶意软件,使攻击行动的规模化实施难度倍增且成本激增。谷歌应用商店已验证该机制的有效性,现正将经验推广至更广泛的安卓生态系统,确保您安装的软件背后存在真实可追溯的身份主体。

支持学生与业余开发者

我们收到开发者反馈,担忧面向亲友等小众群体的应用开发存在准入门槛。我们正根据反馈设计专属账户类型,让学生和业余开发者能向有限设备分发作品,无需完成完整验证流程。

赋能资深用户

安全固然重要,但我们也收到开发者和资深用户反馈,他们风险承受能力较高,希望能够下载未经验证的应用。

基于这些反馈及与社区的持续对话,我们正在构建全新高级流程,允许经验丰富的用户主动承担安装未验证软件的风险。该流程特别设计了抗胁迫机制,确保用户不会在诈骗者胁迫下误操作绕过安全检查。流程中将包含清晰警告以确保用户充分理解风险,但最终选择权仍掌握在用户手中。我们正在收集该功能设计的早期反馈,并将在未来数月分享更多细节。

抢先体验通道开放

今日起,我们欣然邀请开发者参与Android开发者控制台的开发者验证早期体验计划(仅限非Play商店分发的开发者),Play商店开发者的控制台体验邀请也将很快发出。我们期待您对优化所有开发者体验提出问题与建议。

请观看下方视频了解新版Android开发者控制台操作指南,并查阅指南获取更多详情与常见问题解答。

https://www.youtube.com/embed/jEATR5sF5Lo

我们将与您携手合作,在完善系统的同时保障生态系统安全。

元素周期表抱枕

共有{124}精彩评论

  1. 自首次宣布此消息起,谷歌就暗示此举是迫于若干国家政府的压力。(我记不清首次公告的URL,但https://android-developers.googleblog.com/2025/08/elevating-…发布于2025年8月25日,提及“这些要求将在巴西、印度尼西亚、新加坡和泰国生效”) 该博文的“验证机制的重要性”章节有更详细说明(另见 我们专门设计此流程以抵御胁迫,确保用户在诈骗者施压下不会被诱骗绕过安全检查 ),但核心要点在于:

    对于普通非技术用户而言, 绝不允许 存在便捷途径安装“未经验证的应用程序”(无论该术语具体指代什么),因为在诈骗泛滥的国家,政府将追究谷歌的责任。

    然而这一事实本身似乎令许多人无法接受,因此我认为相关争议将永无休止。

    1. 我完全不认同所谓政府施压导致此方案的论调——若问题确系恶意软件窃取个人数据,最根本的解决方案本应是确保应用程序无法访问此类数据!应用程序为何需要访问用户的短信/RCS?(没错,我明白这能简化注册/验证流程,毕竟应用能获取一次性密码很方便。但这种便利性微不足道,若同时被恶意软件用于诈骗,完全可以舍弃)。

      但这种基于隐私的安全模式对谷歌而言是禁忌,因为其整个商业模式就建立在侵犯用户隐私之上。正因如此,他们才推出如此复杂的方案,进一步掌控用户设备。显然某些政府也可能青睐这种做法,因为他们同样能借谷歌或苹果之手控制公民(通过审查或服务中断)。

      需注意的是,虽然谷歌(暂)未完全禁止旁加载,但正引入更多限制措施,包括由其实施的门控机制。这正是典型的“温水煮青蛙”策略。待此举常态化后,未来他们必将采取彻底封禁旁加载的举措。

      1. > 应用程序为何需要访问用户的短信/RCS?

        可能是类似TextSecure的替代短信应用。Android最出色的特性之一在于,即便是键盘、浏览器、启动器等系统默认应用,也能被第三方替代方案取代。

        也可能是短信备份应用(可将完整短信记录迁移至新手机)。

        或是KDE Connect这类服务,让短信通知同步显示在用户电脑上。

        1. 以上推测均属合理。

          > 安卓最突出的优势在于,即便是键盘、浏览器、启动器等系统默认应用,也能被第三方替代方案取代。

          一旦禁止第三方应用安装,这一切都可能轻易改变。若强制用户仅通过Google Play商店安装应用,谷歌便能以“安全”之名轻易封杀这些功能——第三方键盘可能窃取密码,浏览器可能植入广告/恶意软件,启动器可能执行各种恶意操作等等。

          需注意的是,若应用访问短信/RCS数据功能确实如此重要,谷歌本可通过设置访问门槛来增强安全性,而非限制第三方应用安装。例如其当前方案允许使用特殊谷歌账户进行第三方安装,但为何不直接规定:仅当用户使用特殊谷歌账户且明确授权时,应用才能访问短信/RCS数据?

          关键在于,他们刻意避免设置任何阻碍用户 轻松 访问私人数据的屏障。

    2. 谷歌自有其考量。他们 极力 想要扼杀YouTube ReVanced等破解客户端——这些免费提供功能的工具,恰恰是谷歌希望通过订阅收费的领域。

      看看他们为反复破坏yt-dlp所做的一切就知道了。事实上,他们最新的反制措施就在本文旁边的头条新闻里:https://news.ycombinator.com/item?id=45898407

      1. 我完全相信谷歌的 YouTube 团队若能显著削减(比如≥1%)营收,定会乐于消灭这类应用。(毕竟通过观看量盈利是YouTube向“创作者”承诺的核心功能特性,若让规避手段过于容易,将严重损害该承诺。)

        但鉴于我对包括谷歌在内的大型企业运作机制的了解,谷歌的 安卓 团队不太可能在分配资源或制定重大政策决策时考虑YouTube团队的意见。:-)(当然,若安卓团队的某项变更损害了YouTube收益,事态可能升级并导致变更撤回——正如臭名昭著的Chrome与广告系统之争,但此类情况极为罕见。)若按其解释字面理解(反恶意软件团队力不从心: 恶意行为者能瞬间制造新威胁应用,形成永无止境的打地鼠游戏。验证机制通过强制使用真实身份改变了博弈逻辑 )在此情境下确有其理。

        但我的核心观点是:无论最终稳定的均衡状态如何,普通用户能轻松安装的应用集必然受到某种限制 ——我认为谷歌提出的解决方案(业余开发者可制作用户量有限的应用,“资深用户”可选择退出安全措施)实为“最不坏”的折中方案,但对于渴望实现“人人可编程、人人可安装”理想状态的人而言,这仍非理想结局。

        1. 我向往这样的世界:购买某物即意味着你拥有对其运行方式的最终决定权,即便这可能导致危险/有害/非法的行为。

      2. yt-dlp的日子屈指可数,因为谷歌握有终极王牌:所有内容都将被DRM技术封锁。据我所知,YouTube内容尚未完全通过DRM传输的唯一原因,是为兼容智能电视等旧款硬件。

      3. 你仍在佐证上述观点,却忽略了限制措施仅针对少数国家的事实。谷歌同时为高级用户推出应用安装流程。相关细节尽在链接文章中(显然那些擅自臆断的人根本没读过原文)。

        谷歌推行此举并非为防范YouTube ReVanced,且仅限少数国家。这种结论与事实完全不合逻辑。

        1. 这是我的设备,不是谷歌的。试想谷歌限制你通过终端安装NPM/PIP包的情形。

          况且这并非侧载,而是应用安装。

          1. 唉…要是真能这样就好了,但仔细读了服务条款,这更像是使用许可而非“所有权”,可惜了 🙁

          2. 没错,我们去问问Debian团队关于从第三方仓库安装包的事吧。

            我并非支持封锁用户,但这个论点实在站不住脚。

            1. > 是啊,我们去问问Debian团队如何从第三方仓库安装软件包吧。

              Debian系统本身就是借助微软UEFI引导加载程序密钥实现的侧载安装。若没有该密钥,除微软Windows外任何系统都无法安装。

              正因如此,你根本没意识到这个论点有多站得住脚——你甚至在不知不觉中自欺欺人。

              若讨论Qubes等真正注重安全的发行版(例如通过firejail、强化内核或用户命名空间实现应用沙箱化),这个论点就更站不住脚了。

          3. 我同意,但不明白为何谷歌比iPhone或Xbox更受批判关注。

      4. 你依然能通过adb安装应用,它们不会消失。

        1. 总觉得必须使用ADB而非F-Droid这类自动更新工具,会让体验大打折扣。

        2. 若最大用户群体仅限于少数会用ADB的人,这些应用的开发者将失去动力。整个生态系统终将消亡。

          1. 或者有人开发出便捷的ADB封装工具,届时它就会成为安装应用的首选方式。

        3. 但实际操作的人会有多少?若强制执行,现有用户转化率恐怕不足1%。

    3. 我购买了硬件,因此拥有修改和维修的权利。这是天赋人权,毋庸置疑。当然,正如俗语所说,这种权利止于你的鼻尖。

      1. 不妨想想你的天赋权利论在其他国家法律体系中可能站不住脚。

        美国企业用本土常识性原则统治全球的时代即将终结。

        1. 没错,但现实恰恰相反:美国企业正强行将少数法律体系的原则强加于全世界。

      2. 那你大可选择不买锁定硬件,你没有权利要求谷歌提供开源硬件。

        当然开源硬件确实缺乏优质选择,但这是相关却独立的问题。

        1. 这并非孤立问题,谷歌正在积极扼杀开放式移动硬件的任何可能性。他们强迫硬件制造商保密规格,迫使他们只能选择谷歌生态系统或其它生态系统,而不能兼得。这存在巨大的利益冲突,且他们正在滥用其垄断地位。

      3. 我认为用户对手机的自由处置权不应受限。但这并不意味着谷歌有法律义务提供便利甚至支持此类操作。从道德层面而言,他们理应允许用户自主改装;考虑到其近乎垄断的地位,更应强制要求其保持开放。事实上还应制定维修权相关法律。

      4. > 天赋权利,句号。

        你仍未理解评论核心:在那些政府执意要求谷歌为用户手机行为负责的国家,你自认的天赋权利毫无意义。这些国家政府已明确责任归属,而谷歌根本无意为这种责任敞开大门。

        你当然可以随心所欲地使用自己购买的硬件设备,但别把这与强迫其他公司为你提供实现任意操作的便捷工具混为一谈。

        1. 这是转移话题。谷歌确实阻止用户安装应用,而楼主暗示这可能是政府胁迫所致,但毫无证据支持。诈骗者付费让谷歌展示广告诱导安装应用——这正是各国政府追究谷歌责任的根源,禁止安装应用也改变不了本质。

    4. 普通非技术用户不可能存在便捷途径安装“未经验证的应用”(无论此术语具体指代什么),因为在诈骗泛滥的国家,政府会追究谷歌的责任。

      这也可视为“公地悲剧”的典型案例。当前诈骗分子正肆意滥用未经验证的应用和旁加载功能。

      > 然而这一现状本身对许多人而言根本无法接受,因此我认为相关争论将永无休止。

      我理解这种观点,也非常庆幸现已存在退出机制(且验证机制被滥用的风险确实存在),但确实需要提供更多防范诈骗者的具体指导。

    5. 不可能设计出既能满足高级用户需求,又不会被愚蠢之人误用的路径。

      同样不可能设计出既能满足高级用户需求,又不会被愚蠢之人误用的路径。

      正是这些因素导致高级用户路径屡屡缺失。强制行为与误操作无法杜绝,这根本不可能实现。任何不愿承担风险的企业,只能彻底放弃进阶用户群体。除此之外别无他法。

      谷歌终将无法阻止该功能的滥用,而当谷歌意识到无法安全地满足进阶用户需求时,这些用户终将被彻底抛弃。这是必然趋势。

      1. 例如Android本可设置24小时“冷静期”来审批侧载操作,类似某些解锁引导程序的延迟机制。

        这能立即缓解用户因银行信息面临即时风险的焦虑。

        1. 那些轻信此类骗局的人,同样会在24小时后继续轻信后续指令。我认为可强制用户接听电话,由人工客服或AI对话确认无欺诈风险后,再根据设备ID等信息发放解锁码。但这需要成本投入,且诈骗者终将找到绕过手段。

        2. > Android可设置24小时“冷静期”来审批侧载操作。

          为防止诈骗者在24小时后直接回拨,应随机弹出多次警告(时间不可预测)说明问题,若用户拒绝警告则冷却期计时器重置 (因此重新启用需等待完整24小时)。

    6. 这是个无法调和的矛盾

        安全 = 1/便利性
      

      或在此情境下:

        安全 = 1/自由度 或自主权
      
    7. > 因为在诈骗泛滥的国家,政府会追究谷歌的责任。

      试图让大公司为用户设备行为负责的后果并不意外:唯一合理的应对方式是削减设备自由度,或直接退出相关国家市场。

      在《通用数据保护条例》(GDPR)实施初期,由于具体法律条款尚不明确,许多公司发现彻底屏蔽这些国家更安全,此类情况屡见不鲜。尽管这种现象反复上演,但红迪网(HN)上仍不断有人呼吁企业对用户提交的内容负责、强制身份验证等。

      1. 确实。支付处理领域亦是如此。我对Visa/万事达卡的厌恶程度不亚于任何人。但若法院判定它们需为用户购买毒品/枪支/儿童色情制品承担责任,那么它们预先限制用户交易范围的做法似乎相当合理。

        政府必须将中间商视为普通中介。否则他们将被迫充当守门人。

      2. 这两者截然不同。GDPR赋予了普通民众权利。那些选择撤出的公司,正是那些滥用本不属于他们的数据却无法继续为所欲为的企业。

    8. 这实属狡辩:他们之所以占据垄断地位,正是因为主动选择成为“普通用户”在设备上安装软件的唯一途径。若非如此,各国政府根本无从施压。

    9. 莫非谷歌对人们因诈骗损失数百万美元深表同情?

      1. 不,否则谷歌搜索结果就不会让诈骗网站排在官方网站之上。谷歌对人们上当受骗毫不在意——只要他们能分得一杯羹。大企业本就没有同情心。

      2. 据我所见,诈骗损失多源于社会工程学手段:冒充官方机构的冷电话、钓鱼攻击、杀猪盘;Play商店里也有大量窃取数据的诈骗应用,但现实中从未发生过在官方平台外安装恶意软件的案例。

      3. 难道不是谷歌广告网络助长了这些诈骗,而谷歌又从中获利?

  2. > 我们正在构建全新高级流程,允许资深用户主动承担安装未验证软件的风险。该流程专门设计为抵御胁迫,确保用户不会在诈骗者压力下被诱骗绕过安全检查。流程中将包含清晰警告以确保用户充分理解风险,但最终选择权仍掌握在用户手中。

    只要这是单次操作流程:没问题,没问题,我愿意滑动任何数量的提示框来启用旁加载。我理解风险!

    但我担心这不会比苹果在macOS中安装未签名二进制文件的流程更好。

    请务必做得更好。

  3. 谷歌至今未作任何改变,却借机在首条标题《验证为何重要》中再度侮辱用户。

    谷歌继续宣称剥夺你最后剩余的权利对你有益,无论你是否认同。

    谷歌为何与全球政府合作剥夺我们的应用安装权限,答案昭然若揭。法律并不站在你这边,必须重新评估个人层面的决策才能前进。你掌握着决定权,你拥有力量。

    唯有我们同心协力才能阻止这一切。

  4. 编辑注:请务必阅读下方geoffschmidt的回复/编辑

    被埋没的关键信息:

    > 为学生和业余爱好者设立专用账户类型。这将允许你在无需完整验证流程的情况下,向有限数量的设备分发创作成果

    这自然限制了业余项目的规模。他们举例说明:验证机制将迫使诈骗者烧毁身份才能构建新应用,而非像当前那样在应用被检测为恶意软件时直接重新打包。这恰恰表明低安装量的应用才是风险所在。该措施根本站不住脚

    1. 当然还有:必须注册账户,而非简单告知操作系统“我清楚自己在做什么”。

    2. 但请参阅下一节(“赋能资深用户”):

      > 我们正在构建全新高级流程,允许资深用户主动承担安装未验证软件的风险

      1. 哦!我以为在~500字后终于找到关键点,但后续章节确实有更积极的消息!感谢分享,现在可以带着更乐观的心情入睡了 🙂

        此外这将扼杀Linux手机开发领域正在萌芽的动力,无论好坏。我们还能在这个生态圈里多待一阵子,且看人们是否会谨记这把悬在头顶的达摩克利斯之剑——或许我们能看到更多跨平台构建的努力。

        1. 先把这个“胜利”收下吧!这确实是个好消息!

          1. 我不是英语母语者。是否“The W”是“A Win”的同义词,指比赛后的积极结果?它是否还有更深的含义或特定语境?

          2. 这虽非“胜利”,但目睹众人质疑谷歌,我从中获得了自己的“胜利”——这提醒我继续支持并寻找谷歌的开源替代方案。

      2. 可能只是藏在开发者选项的“秘密菜单”里

      3. 所以…所有风波都因一个确认框(是/否)?

        哇,这真是揭开了真相。这个供应商(谷歌)只顾着自己利益。

        1. > 所以…所有风波都因一个确认框(是/否)?

          一个简单的确认框根本不是“[…]专门设计来抵御胁迫,确保用户不会在诈骗者施压下被诱骗绕过安全检查”。事实上据我所知,我们早就有了这种确认框。

          不,他们想要的是某种极其复杂的机制,让普通人无论意外操作还是电话指导都无法启用。

          1. 我猜他们要搞的方案会加入延时机制,让诈骗者无法在电话里守着受害者操作。

        2. > 所以…这番大动干戈就为了个确认框(是/否)?

          社交媒体上充斥着愤怒的论调,人们都在对事件强加自己的臆测。

          从一开始就很明确:这绝非侧载功能的终结。但比起撰写“谷歌剥夺用户权利”的标题党文章,真相显然更难获得点击和转发。

          1. > 社交媒体上充斥着愤怒的论调,人们不断在事件中插入自己的臆测

            某些案例或许存在夸大成分,但正是那些含糊其辞的回应——诸如“你仍可做X操作,只是不能做Y,而Z现在是强制要求”或“你总能使用Y方案”——才导致了当前局面。

            这不过是SafetyNet与Play完整性API的进化版本。还记得多少人建议用替代方案吗?并非否定SafetyNet的价值,但我确信他们的意图绝不止于此。

          2. 抱歉?他们最初的计划绝对是终结未经谷歌许可的设备侧载。那些让你恼火的社交媒体论调不就是这么说的。现在任何纠结于“adb安装依然可行,侧载并未消失”的吹毛求疵者都该滚蛋了。

          3. 你在说什么?这项针对“资深用户”的变更刚公布,此前从未有过任何预告。从一开始就毫无透明可言。

          4. 你是不是完全没看懂重点?这简直荒谬

      4. 让我猜猜——难道是弹出警告框要求我授权应用从第三方来源安装?这难道还不够明确地证明我清楚自己在做什么吗?/s

  5. 中国现实中存在大量侧载滥用案例。攻击者常编造可信故事(如谎称航班延误)诱骗受害者侧载应用(远程会议或控制工具)共享屏幕。一旦安装,攻击者即可查看受害者屏幕并截取网银等敏感账户的短信验证码。

    其他骗局包括冒充性工作者诱骗受害者进行裸聊,随后诱导其安装窃取私密内容和联系人信息的应用进行敲诈。

  6. > 保障安卓用户安全是我们的首要任务。

    我严重怀疑这是否真是你们的“首要”任务。若真是如此,那你们必然是完全忽视了谷歌账户安全才得出此结论。

    > 拦截受害者通知

    那么究竟是谁掌控着这些通知权限,并强制应用开发者使用特定服务?

    > 恶意行为者可瞬间创建新型恶意应用。

    就像那些使用推送或短信进行双因素认证的银行应用。你们似乎毫不犹豫地批准了这些应用。看来你们的“首要”任务取决于具体情况。

    1. > > 拦截受害者的通知

      > 那么究竟是谁控制着这些通知,并强制应用开发者使用特定服务?

      难道只有我对此感到震惊?他们是否承认应用沙盒机制如此脆弱,以致恶意应用能窃取无关应用的数据?而他们只能依赖集中控制在犯罪发生后 事后 禁用这些应用?那么…沙盒机制有何意义——若其隔离能力仅相当于桌面级别的防护?

      对这个“细节”轻描淡写令人难以信服。要么这是社会工程学攻击,那么应用程序相较于网页/邮件/社交媒体冒充等传统通信方式并无实质优势;要么是漏洞修复不彻底的问题,那么谷歌和/或供应商就该在恶意软件大规模传播前迅速推出补丁。

      在我看来,谷歌唯一站得住脚的理由是那些需要极高权限的应用,比如数据包检测或操作系统控制类应用。或许某些特殊应用确实需要验证或特别审批机制。但所有随机应用都需要吗?

      1. > 他们是否承认自家应用沙盒机制如此脆弱,以致恶意应用能窃取其他无关应用的数据?

        应用在获得相应权限后可读取通知内容,包括短信或邮件发送的双因素验证码。这些验证码传输方式本身存在缺陷是另一个问题。

        我希望保留该权限。例如我使用KDE Connect在笔记本上显示通知。尽管名称如此,它不仅限于KDE或Linux系统——Windows和Mac版本同样存在。

      1. 说得太对了!谷歌根本不在乎用户安全。

        – 就在昨天,这里还报道了谷歌如何在FFMPEG中发现冷门漏洞,却让志愿者去修复。
        – 另一个经典案例是谷歌允许YouTube刊登诈骗广告——明知是骗局却置之不理,只因缺乏监管要求。

        1. > 就在昨天,这里还有篇报道说谷歌发现了FFMPEG中的[安全漏洞,任何运行ffmpeg -i <不可信文件> ... 命令可能遭受]攻击,并[在向ffmpeg开发者通报漏洞以便他们修复后]向全球披露该漏洞,让用户能在黑客发现并利用前采取防护措施。

          谷歌的公共服务既完全恰当又值得高度赞赏。

      2. 盈利与守法是双重义务。在多数国家,法律依然具有约束力。

        为保护应用商店收入而限制竞争,反而会招致反垄断监管机构审查,可能适得其反。

        许多政府正推动科技公司实施用户身份验证,限制特定软件服务访问权限,或强制要求软件限制某些功能(如端到端加密)。科技巨头中的某些重要人物强烈支持监控国家理念,我们看到跨政治光谱的广泛认同——这可能源于行业游说。允许安装未经批准的软件将削弱监控技术效力,并影响相关销售者的收益。若合规风险是推动因素,这应由选民而非谷歌来解决。

    2. 世间唯有三件事永恒不变:死亡、税收和企业官话。

      1. 嘿,有时最受愚弄的恰恰是那些掌握决策权的人。这真是个奇妙的世界啊。

    3. 这番抱怨荒谬至极。他们投入数十亿资金保障安全。虽非完美无缺,但所谓“完全忽视”纯属笑话。若有实质诉求请明确提出,这样我们才能真正支持你,而非翻白眼。

      1. 他们绝对会完全忽视许多安全和隐私问题,因为他们对关注点极其挑剔——尤其关注这些问题如何影响广告收入。

        投入资金多少根本无法反映资金的具体用途,因此根本算不上有力论据。

      2. 我不是楼主,但众所周知短信并不安全。谷歌应该先尝试禁止这种方式。

  7. > 当用户登录真实银行应用时,恶意软件会截取其双因素认证码

    这似乎是Android API、沙箱机制或其他环节的严重安全漏洞。

  8. * “Android开发者验证讨论” 由 agnostic-apollo (https://github.com/agnostic-apollo) 发起,Termux应用 (https://github.com/termux/termux-app) 开发者: https://gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a… (gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a6bef53d417a6) 以及 https://old.reddit.com/r/termux/comments/1ourtxj/android_dev… (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)

    * “Android开发者验证提案变更” 由agnostic-apollo提出 (https://github.com/agnostic-apollo),Termux应用 (https://github.com/termux/termux-app) 开发者: https://issuetracker.google.com/issues/459832198 经由 https://old.reddit.com/r/termux/comments/1ourtxj/android_dev… (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)

    1. Android调试桥(https://developer.android.com/tools/adb)使用两部安卓智能手机和Termux(https://github.com/termux/termux-app):

      * 在“摩托罗拉moto g play 2024智能手机、Termux、termux-usb、usbredirect、Termux下运行的QEMU及Alpine Linux:采用全局唯一标识符(GUID)分区表(GPT)的磁盘分区”中搜索“智能手机-1到智能手机-2” “adb tcpip 5555”: https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot… (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)

      * 在“摩托罗拉 moto g play 2024 智能手机,Android 14 操作系统,Termux,以及 cryptsetup:无需 root 权限、无需 proot-distro、无需 QEMU 即可实现 Linux 统一密钥设置 (LUKS) 加密/解密及 ext4 文件系统”中搜索“termux-adb”: https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot… (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)

  9. 对我而言关键问题在于,这种“高级流程”是否允许实际使用完全独立的应用商店(如F-Droid),还是会为每个单独应用安装设置重重障碍。

    1. 若由我设计高级流程,会要求用户在手机初始化时做出选择。后续改变主意需进行工厂重置。

      真正的侧载用户(F-Droid用户等)在设置时就清楚自己将如何使用手机,因此这种机制对他们有效。但对于普通用户——即侧载恶意软件的攻击目标——若攻击者必须诱使他们抹除手机数据才能完成强制操作,这类用户将变得极不具吸引力。

      阿里巴巴旗下平台采用类似策略防范账户劫持:若用户修改或遗忘密码,所有保存的支付方式将被清除。此举虽给合法用户带来些许不便,却能显著降低账户对攻击者的价值。

    2. 存在第二种路径:F-Droid可注册为“替代应用商店”——这是Epic Games诉谷歌案[0]后新增的应用类别。其独特性在于适用于所有地区,且必然需要比当前普遍使用的REQUEST_INSTALL_PACKAGES权限更高级别的权限。谷歌将对这类应用施加何种要求尚不可知。

      [0]: https://en.wikipedia.org/wiki/Epic_Games_v._Google

    3. 若F-Droid不再属于安卓社区,我亦将退出。

      我倒不太担心。不过我的雇主应该担心。

    4. 这完全取决于流程的具体实现方式。

      若是类似开发者模式的单次解锁,希望它能直接生效。

      若是每次安装都需要冗长流程… 哎呀,这和 adb install 也没好到哪去

    5. 纠正我如果我错了,但欧盟数字市场法案不是强制要求这个吗?

      1. 苹果在强制推行公证机制的同时,技术上不也符合这个要求吗?谷歌似乎也能用同样的方案蒙混过关。

        1. 苹果自称合规,欧盟认定不合规。双方正在为此争执。

  10. 我不愿看到“允许”这个词出现在我自有设备的描述中。

    1. 这确实是你拥有的设备,但软件只是授权使用。

      1. 这种说法具有误导性。若想使用主流应用程序,用户别无选择。可以论证(我认为此论点成立)任何协议因在胁迫下接受而无效。

        用户天生拥有合法权利,可无条件使用所购设备全部宣传功能。此后的任何协议本质上都值得怀疑,若真诉诸法庭,我毫不意外它会被判定为不合理条款。

      2. 若存在无需特殊操作即可在设备上运行的替代软件,我或许认同其存在许可关系。

        但若别无选择,购买硬件与获取软件许可实为一体两面。本质上就是购买设备。

      3. 我们需要自由软件意义上的Android版本。

  11. 核心问题在于F-Droid无法满足验证要求——他们需重建每个应用,这意味着必须掌握所有密钥。

    此次变更对F-Droid有何影响?

  12. 欣慰看到谷歌就此问题恢复理性。彻底禁用该功能基本会导致高级用户集体流向iOS。若只能在封闭生态中选择,不如选最便捷美观的那个。

  13. 8天前谷歌与Epic宣布达成和解协议,拟修改Epic胜诉获得的永久禁令。我认为该协议很可能禁止谷歌实施禁止安装第三方应用的计划(将应用商店排除在应用定义之外),除非这些应用开发者向谷歌缴纳注册费。和解协议详见[1],相关条款如下:

    > 13. 自生效日起至2032年6月30日期间,谷歌将[…]并继续允许用户直接从开发者网站及第三方商店下载应用,且不收取任何费用——除非该下载行为源自谷歌应用商店安装/更新的应用程序中的跳转链接(网页浏览器除外)。

    6天前法院对该方案表示质疑,宣布将举行听证会,通过专家证人证词评估其能否消除原禁令旨在纠正的市场损害[2]。

    谷歌今日宣布此项调整,实质上确认放弃要求第三方应用开发者在分发应用前向谷歌付费的条款。

    目前尚无明确证据将两者关联,但我不得不怀疑此举很大程度上是为了向法院证明:尽管Epic几乎没有理由强制执行该条款,谷歌仍打算切实履行禁令提案中的这一部分。

    [1] https://storage.courtlistener.com/recap/gov.uscourts.cand.36

    [2] https://storage.courtlistener.com/recap/gov.uscourts.cand.36

    1. 我们读的是同一篇文章吗?我认为谷歌这里说的是每位开发者需支付25美元费用(针对无法满足其限定分发类别的开发者)。虽然这比按付费安装次数收费要好得多,但也不是小数目。

      1. 请看“赋能资深用户”部分。

        他们早前就公布了25美元的“验证”计划。本文的新内容在于:未来仍允许安装未通过该“验证”的软件。

        > 基于这些反馈及与社区的持续沟通,我们正在构建新的高级流程,允许经验丰富的用户接受安装未验证软件的风险。

  14. 最终在为家庭中非技术人员提供支持时,我真正想要的是设置他们的设备:允许在F-Droid安装任意软件,但禁止从谷歌应用商店(除非经我批准)或直接安装APK文件。

    1. 这正是我的做法,效果相当不错。我从未限制过Play商店,只是直接告知他们不要使用。

    2. 不知移动设备管理(MDM)能否实现这种控制。

  15. 听起来他们正在撤销强制验证流程:

    基于这些反馈以及我们与社区的持续沟通,我们正在构建一个新的高级流程,允许经验丰富的用户主动承担安装未经验证软件的风险。该流程专门设计为抵御胁迫行为,确保用户不会在诈骗者的压力下被诱骗绕过安全检查。流程中将包含明确警告以确保用户充分理解风险,但最终选择权仍掌握在用户手中。目前我们正在收集该功能设计的早期反馈,未来数月将公布更多细节。

    1. 若安全真是他们的首要考量,早就该这么做了,当初何必搞什么强制签名这套…

      不过这似乎是个好消息,姑且接受吧。

  16. 若ADB不受限制且能与Linux命令行交互(我记得曾读到过相关信息; 需开启开发者模式才能使用),这显然是独立系统却运行于同一设备。若它能通过adb与主安卓系统通信(出于安全考虑,或许应通过其他设置明确启用该功能,以防用户未使用adb),这将极大便利操作——毕竟无需另寻兼容adb的电脑即可实现。

    不过我认为若想提升安全性,他们还应采取其他措施(除现有方案外),例如审查Google Play应用是否存在恶意软件(据称确实存在部分恶意应用;但官方表示已设置防护机制,希望有所帮助),并优化权限系统(例如明确标注应用可拦截通知的权限; 此类操作确有正当理由,但应通过明确的权限设置予以提示)。

  17. 这对我而言是天大的好消息。我要为此庆贺一番。尽管众人皆视其为邪恶,但此次他们做出了正确抉择。感谢谷歌。

  18. 这让我想起当年那句“当然可以刷机,但刷机后支付类安全应用就无法运行了”

    1. 我猜允许运行“未验证”应用时,支付/银行类应用也会被禁用。毕竟安全第一嘛,都是为你们好。

  19. 他们没说不会调整政策,只是承诺会解决爱好者和学生的诉求。

    别急着欢呼,我们需要等待技术层面和流程层面的具体变更细节。必须要求更清晰的说明,绝不能等到政策实施后才发现问题——届时再抗争几乎不可能。

    我们绝不能陷入这种境地:他们技术上允许安装非Play商店应用,实际却设置重重障碍。

  20. 所以通过F-Droid分发应用还是有问题?现在我必须付费才能通过F-Droid向所有人开发开源应用?

    这个标题具有误导性。他们仅允许在少数设备上侧载未经验证的应用。

  21. 想象你能随心所欲地使用硬件。勇敢。创新。革命性。

    /老家伙嘲笑“云”——那可是我的裸机。

  22. 长远来看这或许能极大助力安卓生态

  23. "基于用户反馈及与社区的持续对话,我们正在构建全新高级流程,允许资深用户主动承担安装未验证软件的风险。该流程特别设计为抗胁迫机制,确保用户不会在诈骗者胁迫下误操作绕过安全检查。流程中将包含明确警告以确保用户充分理解风险,但最终选择权仍掌握在用户手中。目前我们正在收集该功能设计的早期反馈,未来数月将公布更多细节。"

    所以他们实际上尚未做出任何改变,但声称将在“未来数月”实施。

  24. 我们真该废除“侧载”这个术语。在终端设备上安装应用本就是如此,至少在Windows和Linux系统中向来如此。

    谷歌提到用户在通话中可能被诱骗交出验证码。为何不采用信号识别和启发式算法来判断?

    若用户正在通话,应立即封锁可疑应用的安装权限,并设置功能恢复冷却期(例如24小时)。系统还可结合用户地理位置实施额外防护(如强制要求在应用激活前通过Play Protect扫描,并附加独立冷却期)。

    保护用户的方法有很多,但最终控制用户是错误的。现实世界充满令人恐惧的危险,技术试图解决这些问题,却反而使情况恶化(例如汽车中的计算机化安全系统)。

    归根结底,用户应承担责任。虽然谷歌显然希望以此方式减少危害,但我们也清楚专制政府同样渴望掌控民众可运行的软件。这种做法对民主制度的损害远大于节省少数人开支的收益。

  25. 啊哈,慢火炖煮仍在继续。

    那么若我想发布免费安卓游戏,选择如下:

    A:祈祷谷歌不再变卦
    B:向谷歌提交公寓租赁合同
    毕竟要真正实现沙盒隔离来阻止这种情况,对他们来说实在太难了。

    除完全获取引导加载程序权限外,其他任何方式都意味着我在租用自己的设备。

    不过现在为时已晚。

  26. “我们意识到如此快速煮沸青蛙会导致它跳出水面。因此我们放缓了速度,但仍坚定不移地致力于煮熟这只青蛙”

  27. 欣慰看到他们变得不那么邪恶了。

    1. 这样他们就能对更多人少作恶,而不是把人逼向非邪恶平台。

      1. 非邪恶手机平台是什么?第三方安卓ROM吗?

  28. 现在该允许个人再次发布应用了。

  29. 我得承认连这个问题都看不懂,因为对我来说“原生系统”早已不堪忍受,根本不可能使用——我从未用过超过一小时…

    1. 核心问题在于网络效应。例如限制F-Droid等第三方应用的侧载功能,会让本就狭小的市场进一步萎缩,导致可用应用减少。这还迫使那些出于正当理由不愿公开应用的开发者(试想在沙特开发色情应用,或在美国开发堕胎支持应用),不得不向谷歌(即美国政府)进行验证。

      1. 我只是提出另类观点——既然开发者验证仅适用于“原生系统”(我认为这很糟糕),那么刻意规避该机制反而能促进LineageOS/GrapheneOS等替代系统的使用,这反而是好事。

        当然我指的是非商业应用,商业应用开发者本就会选择谷歌应用商店。

    2. 试想若他人发表此评论,你会觉得它有多相关有趣?

      1. 我赞同,因为我也这么想 🙂

        至于与文章的相关性——我没那么兴奋,因为如果谷歌把“原生系统”搞得更糟,或许更多用户会涌向LineageOS/GrapheneOS,这反而会阻碍Play Integrity的推广,反而是好事。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的: