Safari 不是在保护网络,而是在扼杀它(翻自-https://twitter.com/pimterry)

·  阅读 34

最近有很多关于“Safari 是新的 IE”的讨论。

我不想重述它的基础知识,但我看到了一些有趣的反驳,最常见的是:Safari 实际上是在保护网络,通过抵制添加造成安全/隐私/膨胀问题的不必要和实验性功能。

这值得进一步讨论,因为它很普遍,而且是错误的。 更具体地说,Safari 的方法并没有保护网络免受膨胀和邪恶的谷歌影响,因为:

  1. Safari 尚未实现的大多数功能都没有暗示安全、隐私或性能问题,而且它们已经在所有其他浏览器中实现 了。
  2. 最大的 Safari 投诉与 Chrome 团队的实验性功能无关:它是已实现功能中令人瞩目的错误,由于 Safari 的缓慢发布周期而变得更糟。
  3. 拒绝参与针对实际用例的有争议的 API 提案实际上并不能保护网络——它只会将网络开发人员和用户推入 Chromium 的怀抱。

稍后我们将更详细地探讨这些要点中的每一个,然后我们将讨论 Safari 可以做什么。

也有人提出了其他论点,包括关于 Safari 为什么可能会扼杀网络的许多猜测——这是为了保护 Apple 的应用程序商店利润吗?我将完全忽略这些建议,并坚持解决具体问题。他们的理由是他们自己的,在苹果之外我们只能猜测,具体问题可以不加猜测。

在我们开始之前,我确实想承认 Safari/WebKit 团队正在努力工作,我非常希望他们成功! Chromium 的统治对每个人都不利,而构建一个专注于隐私和安全的流行浏览器,正如他们似乎正在努力做的那样,是一个了不起的目标。这并不意味着他们目前的做法值得我们盲目支持。

我确信 Safari 团队已经在解决以下问题,而且我认为这些问题很可能从根本上源于关于公司优先级的管理决策,而不是团队本身。不幸的是,今天有大问题,目前的发展轨迹正在使网络变得更糟,而不是更好。

在以上三点中,我认为最后一点将是最有趣和最有争议的,但让我们先弄清楚前两点:

Safari 通过省略简单的安全功能来扼杀网络

一个常见的论点是 Safari 也没有实现所有功能:

  1. 通过支持跟踪减少用户隐私风险安全
  2. 通过增加浏览器攻击面,冒着安全风险
  3. 通过使网页膨胀和低效来损害电池寿命

这不是真的。以下是所有其他浏览器已实现但 Safari 未实现的一些功能的快速列表,没有任何隐私、安全或电池寿命问题的建议:

  1. CSS 的 contains 属性将元素的布局与 DOM 的其余部分隔离,提高浏览器渲染性能,并通过隔离为开发人员简化页面布局。 2016 年在 Chrome 中实现,2019 年在 Firefox 中实现。
  2. CSS 的 offset-path 属性,它允许元素沿着 SVG 路径以声明方式进行动画处理。 2015 年由 Chrome 实施,2020 年由 Firefox 实施。
  3. CSS 的 overflow-anchor 属性,可在用户阅读时阻止页面跳转。 2017 年在 Chrome 中实现,2019 年在 Firefox 中实现。
  4. 解析媒体查询,允许内容的样式与设备像素密度相匹配。 2012 年在 Firefox 中实现,2013 年在 Chrome 中实现。
  5. :focus-visible,通过仅在键盘导航期间显示焦点样式来避免可访问性/设计冲突。 2020 年在 Chrome 中实施,2021 年 1 月在 Firefox 中实施。
  6. TouchEvents,支持网络上的多点触控和触控手势。 2012 年在 Chrome 中实现,2017 年在 Firefox 中实现。
  7. BroadcastChannel,它允许同一来源的页面轻松通信,例如将所有页面一起注销。 2015 年在 Firefox 中实现,2016 年在 Chrome 中实现。
  8. beforeprint 和 afterprint JavaScript 事件,允许页面动态自定义超出简单媒体样式的打印布局。 2001 年在 IE 6 (!!!)、2011 年的 Firefox 和 2018 年的 Chrome 中实现。
  9. JavaScript 中的正则表达式回溯。 2017 年在 Chrome 中实现,2020 年在 Firefox 中实现。
  10. scrollIntoView({ behavior: 'smooth' }) 滚动到页面上的一个项目。 2015 年在 Firefox 中实现,2017 年在 Chrome 中实现。
  11. 屏幕方向 JavaScript API,允许页面动态处理屏幕方向变化。 2014 年在 Chrome 中实现,2016 年在 Firefox 中实现。
  12. AV1 视频和 AVIF 图像,一种新的高效且免费许可的压缩格式。 2018 年在 Chrome 和 2019 年在 Firefox 中实施。

其中每一个都有一个已发布的标准,并由多个浏览器引擎实现,包括 Firefox,我在任何地方都看不到任何问题。 Safari 团队对我所看到的任何这些都没有明确的公开反对意见,只有沉默。

据我所知,Safari 团队也没有任何迹象表明这些功能很快就会出现,而且我已经省略了很多已实现但落后于标志(通常多年)的缺失功能,但是大概很快就会上线。

根据 Can I Use 的指标,Safari 在功能支持方面落后 Firefox 约 10%,落后 Chrome 15%。这包括所有基本功能,如 HTML 图像、表单和链接 - 因此它严重低估了现代功能集。

同时,Web 平台测试仪表板(不隶属于任何供应商,有来自 Mozilla、Google、Apple 和整个行业的贡献者)对此有自己的衡量标准,即浏览器对其 Web 开发人员最常用的核心 Web 功能列表的支持计数。 Safari 表现不佳: image.png “他们只忽略坏功能”的论点因 Safari 以前的行为而变得更弱,因为 Safari 缺少这些功能,其中许多功能最终在没有反对的情况下实现,但比其他浏览器落后多年。如果对这些功能有很好的争论,它们显然应该永远不会被实现。

不存在实现 Web 平台功能的好案例,除了比其他所有人晚很多年,例如:

  1. 日期和时间输入类型 - Firefox 发布 4 年后和 Chrome 发布 9 年后
  2. Service Workers,用于页面请求中间件(离线支持和缓存)——在其他地方支持后 2 年发布
  3. AbortController,用于中止获取请求和其他异步操作 - 在其他地方支持它一年后发布
  4. IntersectionObserver,检测元素可见性,例如允许延迟加载 - 在其他地方支持后 2 年发布
  5. 表单验证 - 技术上在 Firefox 和 Chrome 之前发布,但已损坏 7 年无法使用
  6. WebP 图像 - Firefox 发布 1.5 年后,Chrome 发布 6 年后

像这样的例子还有数百个,其中的功能在所有其他主要浏览器中都得到了讨论、实现和标准化,但在此后的几年里却没有在 Safari 中进行。这增加了在现实世界中轻松使用每个浏览器提供的其他标准化功能的延迟一两年(在标准化和实施的现有时间之上),如果它曾经被实施的话。

再说一遍:这些不是仅由 Chrome 提供的有争议的功能,它们是得到广泛支持且没有明确反对意见的功能,但 Safari 直到几年后才推出它们。它们也不是在任何意义上“使网络膨胀”的闪亮无关功能:我上面包含的每个示例主要是改进核心网页用户体验和性能。 Safari 在这里放慢了进度。

忽略这样的标准并不能帮助网络更加谨慎地发展——一旦这些功能在所有其他浏览器中稳定多年,它们无论如何都无法改变。改进 API 的更好方法是在 Safari 中尽早发布此类功能,在标志和原始试验之后,并在它们稳定之前从尽可能广泛的开发人员和浏览器实现者那里收集反馈,以便反馈可以帮助每个浏览器包括更好的 API。

相反,每当 Safari 不支持其他广泛可用的 Web 功能时,开发人员就不能 100% 依赖它们,因此有些人会拒绝使用它们(尤其是在移动用例中)或修改变通方法,从而减少了明确的反馈,问题更难发现,开发好的 Web API 对每个人来说都变得更加困难。

我将避免猜测所有这些的原因,但很明显这是一个新的发展。在过去(2010 年代初期),Apple 经常在新功能方面处于领先地位,作为第一个发布主要 JavaScript API(如 Web Workers)的浏览器,以及驱动实验性前缀功能(如 CSS Canvas 背景)的浏览器。现在看到主要由 Apple 驱动的网络功能非常罕见。有些东西已经改变了

Safari 正在通过印象深刻的错误杀死网络

除了缺少的功能之外,Safari 在其实现的各种 Web 标准的功能中还有很多错误。其中许多错误会产生严重影响,其他地方正常工作的网页会完全失败或布局严重损坏等。以下是最新稳定版 Safari 中存在的当前错误示例:

  1. IndexedDB API 在初始页面加载时无限期挂起,使其几乎完全无法使用:
    bugs.webkit.org/show_bug.cg…
  2. 当一个页面在多个选项卡中打开时,LocalStorage 被破坏,在大多数用例中可能会导致重大数据丢失:
    bugs.webkit.org/show_bug.cg…
  3. 支持背景附件:本地突然完全消失了:
    bugs.webkit.org/show_bug.cg…
  4. 一些 Fetch 请求错误地完全跳过了 service worker:
    bugs.webkit.org/show_bug.cg…
  5. 使用带有边框样式的边框图像:没有呈现完全错误,9 年前报道:
    bugs.webkit.org/show_bug.cg…
  6. 非输入元素的焦点事件在 Safari 中的行为与其他所有浏览器不同,13 年前报道:
    bugs.webkit.org/show_bug.cg…
  7. 从 HTTPS 页面访问时,Safari 错误地将 localhost 阻止为混合内容(但允许从 HTTP 访问!),打破了从 Spotify 到 Ethereum 的用例:
    bugs.webkit.org/show_bug.cg…
  8. 100vh(100% 视口高度)在移动 Safari 中意味着与其他地方不同的东西:
    bugs.webkit.org/show_bug.cg…
  9. 获取请求流的实现刚好足以通过功能检测,但实际上并不起作用:
    twitter.com/jaffathecak…
  10. Mousemove 事件在按下修饰键时触发,即使鼠标没有移动:
    twitter.com/jaffathecak…
  11. 在许多情况下,将元素附加到 shadow DOM 会导致浏览器进程硬崩溃,从而使包括 redhat.com 在内的网站完全无法访问:
    bugs.webkit.org/show_bug.cg…

还有很多很多。从轶事到数据:下图计算了整个套件中仅在一个浏览器中失败的 Web 平台测试的数量。黄线是 Safari,多年来在测试中失败的次数明显多于 Firefox 和 Chrome: image.png 对于上面的每个错误和该图中的所有数据,正确使用标准 API 的页面 - Firefox 和 Chrome 完全支持的页面(在 localStorage 情况下,由 IE8 支持!) - 对于所有 Safari 用户来说都是损坏的。

这是不好的。 Safari 发布速度极慢,这让情况变得更糟。以下是今天的浏览器发布周期:

Chrome:每 6 周一次,计划在 2021 年第三季度改为每 4 周一次
Edge:每 6 周一次,计划在 2021 年第三季度改为每 4 周一次,并提供 8 周稳定的企业选项
Vivaldi:每 6 周一次
Firefox:每 4 周
Brave:每 3 周
Safari:每 6 个月

(这仅适用于稳定的错误修复和功能发布 - 浏览器还发布了自己的夜间/测试版/预览版以及针对此时间表之外的关键安全问题的紧急补丁)

这使得整个问题变得更糟,因为即使错误被迅速识别并修复,它们也将至少存在 6 个月,并且可能会持续更长时间(因为更新是手动的并且与操作系统更新相关,而不是自动,背景和低麻烦)。

这意味着即使在最好的情况下,各地的 Web 开发人员和 JS 库作者也必须为每个 Safari 问题添加永久的变通方法,并支持这些变通方法至少一年,而不是快速修复来解决可能只存在于 Firefox 的错误4周多一点。 Dave Rupert 本周写了一篇很棒的文章,列出了他让 Safari 像其他现代浏览器一样运行所需的特定变通方法。这是艰苦的工作。

例如:上面的 localStorage 错误严重破坏了核心 Web API,并且很快得到了修复(在 24 小时内!太棒了)但是在将近 3 个月后的今天,该修复程序仍未发布给用户,所有 Safari 团队可以说是:

我们知道这个错误有多么重要。我们对未来的版本没有评论。

很难夸大这对网络来说有多糟糕。

现在,每个想要在本地存储中存储任何数据的网站都必须接受不可预测的不必要的数据丢失,而且这种情况很可能会持续数月。通过使用 IndexedDB 来解决这个问题是有可能的,但是它本身也被上面的其他错误破坏了。

这种缓慢的发布周期也削弱了 Safari 通过频繁的迭代发布获取反馈、推送修复和测试实验的能力。过去 10 年软件开发的一个关键变化是朝着更小和更多增量发布的方向发展,而不是偶尔的大爆炸部署。尽快将软件交到用户手中,并建立一个管道来获取结果反馈,进行更改并部署修复程序,并快速再次发布新版本,这是非常有价值的。

很遗憾看到 Safari 完全避免迭代发布的好处,而且它使这里的其他问题变得更糟。

Safari 通过忽略提议的新 API 来扼杀网络

我们已经讨论了 Safari 不支持的没有争议的标准 API。让我们来谈谈有争议的实验。

这些 API 通常由 Chrome 团队提出,使浏览器能够使用蓝牙、写入本地文件以及在后台与服务器同步内容。对于其中的每一个,Safari 和 Firefox 都表示他们打算完全忽略 API,从不实施它,因为安全、隐私和电池寿命问题。

首先,我确实认为 Chromium 在推动新 API 并在达成适当共识之前发布它们过于激进。就 Web 标准达成共识非常重要,而且通常感觉 Google 的团队更愿意立即发布新的 API,而不是花时间与其他供应商合作并发布正确的 API。

也就是说,他们提出的许多有争议的 API——从 Web 蓝牙到文件系统访问——显然都在利用真正的用例和真正的需求。通读对
twitter.com/jensimmons/… (来自 Apple 的 Web Dev Evangelist)的回复,关于 Firefox 对文件系统访问 API 或 WebMIDI 的讨论的评论,或 Safari 的 Web 推送问题。

在这场辩论的背后,有大量热情的开发人员,他们兴奋地在这些技术的基础上构建产品,并为获得更广泛的支持而奋斗。

鉴于对这些功能的真正需求,并且 Chrome 热衷于发布它们,这对 Safari、Firefox 和其他人来说是一个非常大的问题。

流行特性问题

我非常赞同围绕这些功能存在安全和隐私问题的讨论。不幸的是,Safari 和 Firefox 生活在一个领先的浏览器的市场份额远远超过它们两者的总和的世界,绝对会满足需求并发布这些新的 API。

在其他供应商完全阻止这些功能进入网络的情况下,没有任何合理的选择。在许多情况下,它们已经存在。只有这样一个世界才能阻止他们超越 Chrome 65% 的市场份额(约 70%,包括所有基于 Chromium 的浏览器,或约 80% 的桌面浏览器)。

渐进增强是一种经常用作解决此类 Web 兼容性问题的方法。不幸的是,在主流浏览器构建了一个不能被 polyfill 的流行特性,而少数浏览器试图无限期地忽略它的情况下,渐进增强意味着:

Chromium 提供了一个功能,其他浏览器没有 如果这是一项有价值的功能,Web 开发人员将在可用时使用它,但对其他浏览器有一些后备行为 其他浏览器的体验更差,这会损害指标/参与度/等 Web 开发人员张贴了“在 Chrome/Edge/Opera 中效果最佳”的通知,以鼓励用户获得最佳体验 用户切换到 Chromium 并获得良好体验 其他浏览器慢慢消亡,浏览器生态崩溃,网络消亡,悲哀 这并不是说每个网站都会使用这些闪亮的新 API——它们大多与 Web 应用程序用例隔离。但在某些方面更糟:您的普通用户不会安装新浏览器来阅读新闻文章,但如果它从他们的聊天应用程序(后台推送)向他们提供可靠的通知,那么他们可能会更容易使用他们每天在工作中使用的 webapp(本机文件系统),或者如果需要设置新的蓝牙小工具(网络蓝牙)。一旦他们为一件事切换,就会显着增加他们为所有事情切换的变化。

您可能会想“我不在乎 - 我不会切换到 Chrome,我不想要使用这些 API 的 web 应用程序”。那没关系。

与将切换到工作的最佳工具的用户组相比,永远不会违反原则使用 Chrome 的用户比例微乎其微。如果 Chromium 真的比其他浏览器引擎功能更强大,那么用户就会转向 Chromium,随着替代浏览器的市场份额缩小,开发人员开始忽视它,无论您想要哪种非 Chromium 浏览器,您对整个网络的体验都会变得更糟使用或访问的网页。

浏览器生态系统的健康影响着每一个人。

在 Safari 的情况下,如果支持 Safari 很容易并且他们有很好的 Web 开发人员善意可以借鉴,那么这种风险就会降低。回到 Firefox 与 IE 的早期,Firefox 很小的初始市场份额问题不大,因为 Web 开发人员会积极努力确保他们的网站在那里工作,因为它是一个很好的支持和使用的浏览器。不幸的是(请参阅本文的前两节)Safari 不容易支持,并且绝对没有 Web 开发人员的善意可以依赖。

所有这些都不是理论上的 - 这在今天明显发生。这些功能非常流行,以至于它们现在正在网络上的实际产品中使用,而上述过程正是正在发生的事情。

例如,如果您购买 Espruino(一种流行的可编程 IoT 小工具),推荐的开发流程是他们基于 Web 的 IDE,它使用 Web 蓝牙,并且需要基于 Chromium 的浏览器: image.png 同样,Excalidraw(一种流行的在线白板工具)仅为具有文件系统访问 API(仅限 Chromium)的浏览器提供更好的 UX,Godot 引擎(一种开源游戏引擎)现在正在构建一个需要文件系统的基于 Web 的编辑器访问 API 支持(仅限 Chromium)以方便保存和加载,并且 Noteflight(一种流行的音乐创作服务)关闭了他们现有的 MIDI 适配器并将他们的主要工作流程转移到 Web MIDI(仅限 Chromium)。

这些 API 已经是网络结构的一部分。这些是流行的 web 应用程序(Noteflight 有 600 万用户,Excalidraw 有 22,000 个 github star),很多用户都想使用它们,并且它们的核心功能只在 Chromium 中运行良好。

当然,现在还为时尚早,可能的现实并不是浏览器生态系统会在此结束时真正崩溃。尽管 Firefox 和 Safari 担心,如果一个 API 真的起飞并达到临界质量,现实是他们将不得不按原样实施这些 API,否则就有与现实世界的网络不兼容的风险。

这是一个稍微好一点的结果——我们仍然有多个兼容的浏览器——但只是非常温和:在这一点上,他们无意中允许谷歌单方面设置网络标准。我们应该避免这种情况。

墙壁正在倒塌

这描绘了一幅惨淡的画面。今天的一个可取之处是 Apple 阻止在 iOS 上使用任何非 WebKit 引擎,以保护该环境,而且 iOS 市场(至少在美国)足够大,这意味着必须优先考虑 Safari。

然而不幸的是,苹果目前陷入了反垄断斗争,在这种情况下,允许在 iOS 上使用替代浏览器引擎是一种合理的法律强制,或者是避免接受替代应用程序商店的合理让步。这种限制似乎不太可能永远持续下去。

即使该限制确实存在,也没有什么可以阻止上述情况仅在桌面上发挥作用,其中 Chromium 已经拥有 80% 的市场份额。值得注意的是,上面发生这种情况的所有示例都是以桌面为中心的 web 应用程序。在移动设备上,虽然这种限制有所帮助,但 Chrome 仍保持稳定在 64% 的市场份额(并且自 2020 年 11 月以来上升了 3 个百分点),这很容易成为足够大的受众,一些网络应用程序会接受失去非 Chromium 用户返回以有机会以在 Safari/Firefox 中完全不可能的方式在网络上构建应用程序或游戏。

这里与过去有两个明显的相似之处:

IE 的缓慢消亡:在 IE 停滞不前的情况下,通过为 Web 开发人员提供更少的错误、更好的工具和更多功能,Firefox 建立了足够的开发人员善意,以克服困难大幅扩大其市场份额,迫使 IE(后来的 Edge)紧随其后。 WebExtensions:尽管以前每个浏览器都提供自己的附加 API,但 Chrome 有效地主导了开发人员的思想份额,提供了更强大、更易于使用的扩展 API,并且变得更加流行,Firefox 和 Safari 最终都杀死了自己的 API 并接受了 Chrome 的 API,无意中允许谷歌单方面设置网络扩展标准。 今天的 Chrome 正在走同样的道路:为 Web 开发人员提供比 Safari 更强大的工具和更好的开发体验(更好的开发工具,更少的错误)。如果没有任何变化,结果很可能是相似的。这是不好的。

有一个更好的方法

因此,完全无视流行功能并不能阻止它们的发生,并且有可能将所有市场份额都给谷歌,或者所有浏览器都被迫遵循谷歌的标准。我们该怎么办?

Safari、Firefox 和其他公司需要为这些用例提出更好的建议。

如果他们担心网络蓝牙(例如)可能会被滥用,他们需要与 Chrome 团队合作改进权限控制和用户体验,加强标准,将功能限制在实际用例的最低限度,让用户控制在这些 API 之上,并建立标准来支持这些用例而不会危及用户。

归根结底,一旦用户开始看到具有需要蓝牙的酷功能的网站,就很难推销“我们是不支持蓝牙的浏览器”。销售“我们是安全支持蓝牙同时保护您的隐私的浏览器”要容易得多。

这很难,但这绝对不是不可能的。

一些想法:

  1. 未经用户明确许可,不得公开任何信息/访问 Web 应用程序(我认为这些 API 已经是这种情况,但让我们设定一个明确的基线)。
  2. 支持有限的功能,或危险功能的额外权限,例如默认情况下没有 SysEx 指令的 Web MIDI。
  3. 通过在大量用户参与(重复访问、手动 PWA 安装等)之前禁止敏感权限弹出窗口或 PWA 安装提示,避免权限疲劳。
  4. 根本不允许针对敏感权限的权限提示 - 要求用户主动启用浏览器 UI 中的某些内容以激活每个域的敏感功能。
  5. 建立与域名相关联的声誉系统,并在此基础上限制对某些 API 的访问或显示更响亮的警告,直到域名获得声誉。
  6. 更进一步:要求这些 PWA 在应用商店注册,将个人身份的 Apple 开发者订阅绑定到它们,并禁止滥用它们的帐户。
  7. 或者:出售在开放网络上使用敏感 API 所需的更昂贵的 HTTPS 证书。
  8. 允许所有不希望这些 API 的用户在其浏览器设置中轻松禁用整个网络中的此类功能。

这些都不是好主意。它们都不是完美的,存在复杂的权衡和挑战,是的,这些绝对是难题。不过,每个团队中都有很多聪明的人参与其中,Apple 有很多动力和资金可以用于这方面的工作,而另一种选择是 Google 的方法无论如何都会发生,而 Safari/Firefox 必须要么与网络或稍后按原样接受 Google 的标准。

同样重要的是要记住,今天任何网站都可以通过让您下载和运行二进制文件(或安装具有蓝牙权限的应用程序)来使用蓝牙。保护措施不一定是完美的——它们只需要比说服用户运行恶意二进制文件更难被击败。

尽管如此,这需要大量的工作,我对 Firefox 在这方面的立场表示同情:他们只是没有足够的资源来认真跟上 Google 的工程努力。苹果的情况并非如此,通过联合力量,苹果将帮助 Firefox 保持在游戏中,以限制谷歌在苹果自己平台之外的主导地位。苹果有能力引领网络标准,跟上谷歌,并在他们选择时推出替代方法。现在看来他们选择不这样做。 让我们保护网络

好的,总结:

  1. Safari 没有实现的功能通常并不危险——绝大多数是被广泛接受的标准。
  2. “Safari 是下一个 IE”的论点得到了 Safari 的许多引人注目的错误和开发人员所需的额外解决方法的充分支持——这并不是对 Safari 保护隐私和安全的斗争的误解。
  3. Safari 和其他人不能简单地忽略 Chrome 想要实现的流行功能的严肃提议。他们需要参与并提供替代方案,否则问题只会变得更糟。
  4. 将 Safari 的方法描述为保护网络是不准确的,现在看起来更有可能它使每个人的网络变得更糟。

特别是对于新提议的 API,最终他们要么不得不接受 Chrome 的提议,要么与不断增长的网络部分不兼容,从而失去大部分用户群以及他们对标准的影响。如果没有用户,就没有必要赢得原则。

我希望看到一个 Apple、Mozilla、Microsoft 和 Brave 成为领先 Web 标准的世界,通过支持新用例和允许令人兴奋的新产品的功能推动 Web 向前发展,但要注意用户隐私、跟踪阻力和嵌入的安全性作为一流的优先事项。

我想要一个 Safari、Firefox、Chrome 和其他人都支持一套一致的不断发展的 API 的世界,共同努力避免显示错误或快速发布修复程序,并为 Web 开发人员提供一个一致可靠的平台来构建。

现在,这不会发生。我担心 Safari 目前完全拒绝和忽视网络的做法会给我们带来完全相反的结果,而且所有证据都表明这种情况已经开始发生。

Apple 拥有这样做的资源,如果他们想支持用户的隐私和安全,他们可以说有责任这样做。如果他们不这样做,网络就会遇到大麻烦。

分类:
前端
标签: