苹果、Facebook、谷歌打破移动浏览器市场破坏用户选择

乍一看，移动浏览器市场看起来大致正常。 85% 的全球共享操作系统 (Android) 历来促进了浏览器的选择和浏览器引擎的多样性。引擎多样性至关重要，因为它是导致竞争提供更好的性能、功能、隐私、安全和用户控制的机制。当我们进入 iOS 时，将有更多相关内容。技术专家和政策制定者对桌面浏览器的预期形成了相同的看法，并以同样的方式思考移动浏览器的竞争。总结：用户可以自由选择具有不同功能、搜索引擎、隐私功能、安全属性和底层引擎的桌面浏览器。浏览器可以通过集成的自动更新机制或通过快速操作系统更新（例如 ChromeOS）快速更新。与桌面操作系统捆绑的浏览器占浏览器使用量的少数，表明替代品市场健康。流行的原生应用通常会在用户选择的浏览器中打开链接，并且不会破坏链接点击的默认行为。 [1] 每个点都突出了生态系统健康的不同方面。这些特性共同展示了市场运作的运作方式：清晰而有意义的用户选择会产生竞争压力，随着时间的推移改进产品。用户在他们最关心的维度上选择更高质量的产品，推动质量和进步。

移动生态系统似乎保留了这些特性，但相似之处只是肤浅的。了解移动操作系统如何破坏浏览器选择需要对操作系统和浏览器技术有细致入微的理解。难怪很少有评论者将这些点联系起来。 [2] 情况有多糟？您可能会惊讶地发现，直到去年年底，iOS 上的默认浏览器才可能是 Safari。如果您知道竞争供应商仍然无法在 iOS 上提供他们自己的引擎，那么您可能会更加迷惑。同时，在 Android 上，#2 和 #3 的网络流量来源不尊重浏览器选择。用户可以使用任何带有他们喜欢的引擎的浏览器，但不太可能使用它。 Play 商店只不过是浏览器选择的 Potemkin Village；一个充满活力的外观来隐藏腐烂。注册以处理链接点击只是成功的一半。对于充当用户代理的浏览器，它还必须接收导航。 Google 的搜索应用程序和 Facebook 的各种 Android 应用程序以略有不同的方式破坏了这些选择。 [3] 这降低了用户委托浏览器的隐私和安全选择的有效性。开发人员也面临着更高的成本和更少的机会逃离谷歌、Facebook 和苹果的围墙花园。 Web 工程师经常将浏览器称为“用户代理”，这是对他们作为开发人员意图解释器的独特作用的一种认可，它让用户对 Web 体验有最终决定权。浏览器选择有效性的无声侵蚀已将这种权力从用户手中转移，将其重新置于主导平台和应用程序发布商手中。要了解这种售罄是如何在我们眼皮底下发生的（字面意思），我们必须仔细研究移动设备和桌面设备的不同之处。浏览器处理链接，非浏览器将 http 和 https URL 延迟加载到系统，系统又会调用默认浏览器。此流程是提供链接功率和效用的中央事务。如果涉及的任何参与者（操作系统、浏览器或引用应用程序）违反合同的某些方面，用户在浏览器中的选择就会变得不那么有效。 “那么，什么是‘浏览器’？”你可能会问？我有一篇很长的博客文章正在酝酿这个，但跳到最后，一个可操作的定义是：浏览器是一个应用程序，它可以在操作系统中注册以默认处理 http 和 https 导航。

在 Android 上，这通过清单中的特定意图过滤器和可浏览类别中的列表来表达。 iOS 在 2020 年末（晚了十几年）通过一项权利获得了浏览器支持。 [4] Windows 和其他桌面操作系统具有类似（如果不太整洁）的机制。无论操作系统在技术上如何促进用户选择，正是这种选择能力将浏览器定义为一个类。链接将用户引导到其首选浏览器的频率控制了此选择的意义。移动计算的历史始于一个令人难以置信的资源受限点。第一代 iOS 和 Android 智能手机是缓慢的单核、内存不足的事务，导致移动操作系统学习新技巧以促进响应式计算。当资源压力加剧时，Android 和 iOS 采用启发式方法来杀死和回收非前台应用程序使用的 RAM。这种后台任务终止行为为链接密集型应用程序带来了独特的问题。启动用户的浏览器会将链接应用程序置于后台，增加返回发送应用程序的摩擦，因为浏览器 UI 没有提供返回引用应用程序的功能。被置于后台也会增加被杀的可能性。 [5] 在这种状态下返回源应用程序会感到非常痛苦。重新启动原始应用程序并恢复 UI 状态可能需要几秒钟的时间，这种体验在最有可能首先驱逐应用程序的低端设备上变得更糟。渴望参与的应用开始包含“应用内浏览器”（“IAB”）来应对这些挑战。与对“浏览器”的任何简单语言理解相反，这些 IAB 通常不能安装为链接的默认处理程序，即使操作系统支持浏览器选择。相反，它们会在系统提供的 WebView 中加载由其托管本机应用程序引用的内容。 WebView 是专为在其他应用程序中使用而设计的系统组件。它们不会将嵌入器放置在系统可​​能会杀死它们以回收资源的后台。这减少了摩擦并相应地增加了“参与度”指标。 [6] 因为它们现在是“浏览器”，所以它们可以提供用户界面，使返回主机应用程序比继续在网络上更容易。

因为他们依赖于系统提供的 WebView 组件，所以他们不需要支付繁重的应用程序下载费用来支持渲染 HTML、运行 JavaScript、解码图像或加载网络资源。应用程序可以自定义 UI 以添加更深入的集成，例如，将图像从托管页面“固定”到 Pinterest。在今天的 Android 和早期的 iO​​S 版本上，WebViews 允许嵌入器观察和修改所有网络流量（无论加密如何）。应用程序还可以监视用户输入、生成的 DOM 和系统自动填充的凭据。如果用户对不记得他们以前存储的密码、登录状态、隐私首选项、扩展程序或可访问性配置的应用程序感到满意，这可能是双赢的。由于对托管应用程序的轻微（接近于不存在）归因，以及用于禁用此错误功能的脱节和隐藏的用户控件，用户可能认为网络不值得访问，或者他们的浏览器坏了。 [7] 在围绕应用程序和浏览器选择的争论中，WebViews 是许多混乱的根源。值得庆幸的是，情况只是复杂而不是复杂。因此，浏览器可以基于 WebView，IAB 也可以。但两者都不必是。

显示网页的视图......在大多数情况下，我们建议使用标准网络浏览器（如 Chrome）向用户提供内容。提供浏览器的核心，其工作是显示第三方内容。例如，最初的 Android 浏览器使用了早期的 Android 系统 WebView。尽管在每种情况下都使用“网络技术”来呈现内容，但这些情况的权力动态却截然不同。使用“原始”WebView 完全适合第一方和第二方内容。在这里，原生应用正在做与其核心功能相关的工作；用户数据的存储和跟踪完全属于应用程序自然职责的四个方面。此外，内容开发人员不太可能发现 WebView 呈现的限制是不受欢迎的或不合理地不可变的（通过与应用程序开发人员的合作）。在这些场景中，WebViews 可能会忠实地促进内容，而不是破坏内容。然而，所有关于 WebViews 和第三方内容的赌注都没有了。要了解为什么知道 WebView 不是浏览器会有所帮助。 WebViews 包含核心浏览器功能，以及允许嵌入器“点亮”更多的钩子。然而，生产一个完整且具有竞争力的基于 WebView 的浏览器需要额外的 UI 和粘合代码。特别是，需要权限门控访问特权服务的功能需要嵌入者的明确支持才能按规定工作。基本导航和窗口管理功能（例如 window.open() 和 <a target="_blank"> 这对某些站点货币化功能至关重要）。

很少（如果有）WebView 浏览器实现所有这些功能，即使它们的底层 WebView 支持它们的绑定。这种情况在 WebView IAB 中更为严重，它们往往不完全支持这些类别的功能，即使它们似乎通过脚本对开发人员可用。更糟糕的是，从这些 IAB 进行调试非常具有挑战性，再加上缺乏对这些来源可能有多少流量的认识。怎么可能？ Web 开发人员习惯于桌面模式中的真实浏览器。标准工具、分析包和功能可用性仪表板没有提到 IAB，最大的 WebView IAB 发布者（Facebook、Pinterest、Snap 等）几乎没有投入任何资金来澄清这种情况。用户和开发者都没有选择 Facebook、Pinterest 或 Google Go 作为浏览器，了解这一点至关重要。 WebView IAB 呈现的流程拒绝用户代理他们的选择，并且他们强加的技术限制通常会阻止开发人员在真实浏览器中打开内容。任何最大的 WebView IAB (ab) 用户都没有可供第三方 Web 开发人员使用的文档。这种缺席反映了这些应用程序发行商在浏览器功能支持方面的可耻搭便车，这也许并不奇怪。然而，由于破损的微妙和规模，它更加令人震惊。如果 Facebook，Android 的第三大“浏览器”制造商，雇佣一个开发者关系工程师或文档作家来解决这些问题，我不知道。与此同时，论坛上充斥着忧郁的帖子，讲述了这些潜艇渲染器破坏其他浏览器功能的无数方式。由于获得了浏览器的“前 80%”，操作系统供应商补贴了关键组件的开发和分发，WebView IAB 几乎无法跟上用户或开发人员的讨价还价。第一方网络开发人员可以与他们的应用程序开发同事合作，为操作系统支持的任何奇异功能构建自定义访问。第二方开发者期望较少（广告通常没有获得广泛的功能访问权限）。但是第三方开发商呢？他们和用户一样无助于理解为什么浏览器呈现的环境看起来微妙而深刻，破碎。

仍然有用户使用 Chrome 37 引擎（7 年前）浏览，不是因为他们不更新浏览器，而是因为它是使用 webview 的 Android 5 上的 Facebook 移动浏览器。 Facebook 不尊重用户浏览器的选择，让该用户使用旧引擎。 + 这些相同的应用程序发布者在真实浏览器中请求（并大量使用）他们不会为其他人启用的功能，即使发现大部分工作也是如此。也许浏览器和平台供应商应该考虑拒绝这些应用程序访问他们破坏他人的功能。 WebView IAB 对开发人员的影响值得注意，但它对用户的影响却引发了混乱和愤怒。单击应用程序中的链接会将控制权转移到外部浏览器，该浏览器尽职尽责地应用用户存储的首选项和累积状态。当从电子邮件中点击链接时，不会忘记 example.com 的登录凭据。相同的统一体验可确保保存的地址和付款信息随时可用。最重要的是，可访问性设置和隐私首选项始终适用。相比之下，WebView IAB 会破坏用户状态，将其存储在每个托管应用程序中的孤岛中，从而造成持续的部分健忘症。可靠结果的混淆是应用程序和网站之间权力关系倒置的结果。是否有任何用户希望从 Facebook 应用、Instagram 或 Google Go 中的链接加载的任何网站上所做的一切都可以被这些应用完全监控？是否可以记录和跟踪所有共享的密码以及从第一页访问的所有站点？ [8] 需要明确的是，没有这些应用程序以明显敌对的方式使用这种特殊访问的记录，但即使是意想不到的副作用也会减少用户对数据和安全的控制。

保留前向链接在也提供自己作为浏览器的程序中并不令人反感，但 WebView IAB 的伎俩是在用户最不期望的时候充当浏览器，但永远不会应对浏览器所承担的责任的权力和隐私影响。库的出现是为了促进 WebView IAB 的构建，导致操作系统和浏览器供应商认识到用户变得困惑和开发人员愤怒。为了应对这一挑战，Apple 推出了 SFSafariViewController，Google 紧随其后，推出了名称巧妙的 Chrome 自定义标签协议和帮助程序库。这两个系统都允许本机应用程序开发人员跳过构建 WebView IAB 系统的繁重工作，而是与操作系统一起调用用户的默认浏览器在宿主应用程序的上下文中加载网页。与 WebView IAB 类似，CCT 和 SFSVC 解决后台驱逐和丢失应用程序状态。但是，由于它们调用用户的实际浏览器，因此它们还可以防止用户混淆，同时提供适当浏览器支持的完整功能集。对于无法读取用户和第三方站点之间的网络流量的应用程序开发人员，这些解决方案的代价是一些灵活性。他们也不能简单地检查和更改页面内容，从而无法向他们的 IAB 添加新的非标准功能。抵消这些担忧，CCT 和 SFSVC 恢复用户选择 [9] 并确保开发人员访问完整的浏览器功能集。嗯，是的。至少在默认配置中。尽管名称中包含笨拙的“Chrome”，但 CCT 库和协议与浏览器无关。行为良好的 CCT 调用应用程序（例如，Android 版 Twitter）将通过 Firefox、Brave、Samsung Internet、Edge 或 Chrome（如果它们是系统默认浏览器）在 CCT 提供的类似 IAB 的 UI 中打开 URL。 @slightlylate 我最近和我爸爸谈论网络，问他使用什么浏览器，他向我展示了他的工作：他在 Google 搜索小部件中搜索网站，然后只使用结果页面 Chrome 选项卡作为他的整个浏览器.他的默认浏览器没有设置为 Chrome。你可能会问，谁会这样做？除了谷歌自己的搜索应用程序；您知道通过无处不在的主屏幕搜索小部件出现在每台信誉良好的 Android 设备上的那个。

被称为“Android Google 搜索应用”（“AGSA”或“AGA”），这种不起眼的文本输入是真正令人震惊的网络流量的来源；无论用户选择哪种浏览器，流量都流向 Chrome。添加这样的代码是有正当理由的。在 CCT 协议生命周期的早期，在支持广泛之前，许多浏览器都表现出令人震惊的错误。然而，2021 年已远超早期，因此调用 Chrome 的主要影响是扭曲浏览器市场并破坏用户选择。这种行为颠覆了用户隐私，破坏了引擎多样性的生态系统优势，并使替代浏览器难以在公平的竞争环境中竞争。诚然，这种情况比 WebView IAB 对面向开发人员的重要功能的大规模清除要好，但仍然是霍布森的选择。 Google 可以（并且应该）通过删除违规选项覆盖来恢复系统默认设置，即肯定尊重浏览器中的用户选择。鉴于 AGSA 使用 CCT 加载网页而不是 WebView，这在今天几乎是微不足道的。如果 Android 和 Play 团队强制要求 CCT 的核心设计取代 WebView IAB，那么它具有巨大的潜力。 Chrome for Android 团队没有解决开发人员对 CCT 库中功能的频繁请求，而是在“WebLayer”项目中投入了大量资金。您可以将 WebLayer 视为包含电池的 WebView，修复与缺失功能相关的问题，但继续破坏状态和用户选择。 WebLayer 有一个积极的例子：作为浏览器上下文中 WebViews 的替代品，这是向前迈出的重要一步。然而，在 IAB 的背景下，WebLayer 看起来将进一步巩固用户敌对模式。这种颠覆性的选择扩展了搜索应用程序的一个令人沮丧的趋势，这些应用程序喜欢自己的浏览器，甚至不试图通过浏览器来赢得用户的业务。

除了 Google Go 之外，适用于 iOS 的 Google 应用程序以及适用于 Android 的 Microsoft 的 Bing 应用程序都可以捕获 WebView IAB 中的出站链接，从而颠覆了浏览器的选择和开发人员的功能可用性。如果有任何怜悯，那就是它们相对较低的使用量在某种程度上限制了它们对整个生态系统的影响。采用 WebLayer 不会显着改善这些健忘症浏览体验的用户体验或隐私。谷歌和苹果有机会发挥领导作用，表明他们对用户并不怀有敌意，并删除不那么谨慎的玩家利用的糟糕行为的许可结构。稍后会详细介绍。想象一下，如果汽车制造商只能在所有汽车和卡车上使用一种政府规定的发动机模型。不同的轮胎和室内装潢就到此为止。如果发动机动力不足，许多任务可能无法完成，从而使整个车辆类别变得毫无意义。这就是 iOS 为浏览器制造商和浏览器下载公众创造的情况，也是购买新手机的唯一途径。 iOS 很重要，因为富有的用户携带 iPhone。就这么简单。即使 Apple 的产品未能在市场上获得大多数用户，iOS 用户的利润贡献也可以主导所有其他业务考虑。至少从 2012 年开始，Apple 已经屈尊允许在其 App Store 中使用“竞争浏览器”。这些应用程序在任何意义上都不是浏览器，因为它们无法取代 Safari 作为 http/https 链接的默认处理程序。随着 iOS 14.2 于 2020 年末发布，iOS 14.2 最终在没有效果的长期选择中结束，使 iOS 在支持替代浏览器方面与其他所有重要操作系统保持一致。 [10] 但 Apple 已经采取了明确和广泛的谨慎措施，以确保这种选择仅适用于 iOS。 Windows、Linux、ChromeOS、Android 和 MacOS 上的浏览​​器可以是集成浏览器。与此同时，iOS 将浏览器限制在系统提供的 WebView 上的 shell。与其他操作系统上的 WebView 浏览器不同，Apple 以防止其他领域竞争的方式锁定这些组件，包括限制网络堆栈以阻止提高性能、新协议或增加隐私。这些限制在 WebView IAB 的上下文中是有意义的，但将它们扩展到浏览器只会转移来自

......