<p>Mozilla 重申了对谷歌决定在其 Chrome 浏览器中构建 AI 基础设施的反对意见，尽管这一反对意见来得有些晚，因为这一被称为 Prompt API 的技术已经在 Chrome 和 Microsoft Edge 中进行测试。</p>
<p>Mozilla 的网络开发者关系负责人 Jake Archibald 在关于该 API 的 GitHub 讨论中阐述了该组织的担忧，该 API 提供了一种标准方式来发送和接收来自本地机器学习模型的提示和响应。</p>
<p>&#34;我们继续反对这个 API，并认为它对网络平台的互操作性、可更新性和中立性有严重的负面影响，&#34;Archibald 说。</p>
<p>谷歌描述的 Prompt API，&#34;赋予网页直接提示浏览器提供的语言模型的能力。&#34;它提供了一种将自然语言指令发送到谷歌的 Gemini Nano 模型的方法，该模型足够小，可以通过 Chrome 进行本地推理下载。</p>
<p>它并不那么小——谷歌建议至少有 22GB 的可用空间，尽管用于桌面的 Nano（v3Nano）模型约为 4.27GB。</p>
<p>网络开发者已经有多种方式与 AI 模型进行交互。他们可以使用云服务 API 与托管模型进行通信。或者，他们可以通过 JavaScript 运行时框架、WASM 或 WebGPU 等技术访问本地模型。</p>
<p>OpenAI 和 Perplexity 等各种供应商已经发布了嵌入访问远程托管 AI 模型的浏览器。Mozilla 本身正在 Firefox 中测试基于 AI 的智能窗口，并正在开发 AI 模型支架的工具。</p>
<p>Prompt API 旨在以利用浏览器安全机制的方式更容易地进行本地推理，以产生更快的响应时间，允许离线使用，并提供更具成本效益的方式来集成 AI 服务（例如，如果用户缺乏付费 AI API 密钥，则提供免费的 AI 后备）。</p>
<p>正如 Archibald 所阐述的，Mozilla 的担忧与 Prompt API 对网络的影响有关，更不用说谷歌对其部署的辩解。</p>
<p>首先，他担心谷歌自己的 Nano 模型将成为默认模型，开发者将会以此为标准，以使 AI 模型的非确定性响应更可预测。他认为，这种趋势将迫使苹果和 Mozilla 为了共同的用户体验而授权 Nano。</p>
<p>或许更重要的是，Archibald 指出，使用 Prompt API 需要同意谷歌的生成 AI 禁止使用政策，该政策禁止一些不一定违法的活动，例如生成 “令人不安” 的内容。</p>
<p>&#34;这似乎是网络平台上 API 的一个糟糕方向，并为更多具有 [浏览器] 特定使用规则的 API 设定了令人担忧的先例，&#34;他说。</p>
<p>最后，Archibald 认为谷歌通过挑选一些社交媒体帖子来夸大对该 API 的需求，从而误导了公众。</p>
<p>&#34;在 blink-dev 上发布的意图表明网络开发者的态度是'强烈积极的'，并链接到解释以作为证据，&#34;他写道。&#34;那里提供的证据似乎与这一说法不符。&#34;</p>
<ul>
<li>Hashicorp 联合创始人 Mitchell Hashimoto 表示 GitHub'不再是严肃工作的地方'</li>
<li>谷歌修复关键的 Gemini CLI 漏洞可能会破坏你的 CI/CD 管道</li>
<li>AWS 表示急性服务器内存短缺正在推动客户转向云</li>
<li>Linux 加密代码缺陷提供了快速获取 root 的途径</li>
</ul>
<p>在一封电子邮件中，Archibald 告诉_The Register_，问题在于 Prompt API 是否对网络有利，而 Mozilla 并不认为它是。</p>
<p>&#34;核心问题是互操作性，&#34;他说。&#34;提示与模型紧密耦合；开发者不可避免地会调整以适应他们所构建的模型的特性和政策。</p>
<p>&#34;这就是你最终得到模型特定代码路径的原因，这又是浏览器兼容性问题的重现。T&amp;C 问题也是其中的一部分：如果使用网络 API 意味着接受特定供应商的内容政策（尤其是超出法律的政策），那么你就不再是在为一个开放平台构建。&#34;</p>
<p>关于谷歌夸大开发者热情的问题，Archibald 表示，确实有开发者对 AI 能力感兴趣，但谷歌未能提供相关证据。</p>
<p>&#34;信号是极化的，而不是'强烈积极的，'&#34;他解释道。&#34;无论如何，仅仅开发者的需求并不足以达到标准。问题在于 API 是否能够在不同实现之间工作，而不将平台绑定到一个供应商的模型上。&#34;</p>
<p>谷歌没有立即回应置评请求。</p>
<p>然而，在周四，负责发布 Prompt API 的谷歌 Chrome 工程师 Rick Byers 在 GitHub 讨论中回应了 Archibald 所表达的担忧。</p>
<p>&#34;作为在 Chromium 中发布此 API 的 blink API 所有者批准者之一，我承认我在 Mozilla 的标准立场上分享这些担忧，&#34;他写道。&#34;我不同之处在于更倾向于促进实验、从错误中学习和竞争的路径，而不是因为害怕可能发生的事情而选择停滞创新。&#34;</p>
<p>Byers 请求网络社区帮助收集证据以推动讨论。指出关于其他有争议的网络技术（如加密媒体扩展（EME））的辩论，他建议结果并没有像预测的那样糟糕。</p>
<p>但迄今为止，专注于数据并没有为谷歌的事业带来太多好处。根据 2 月份创建的一份报告，该报告比较了使用 Prompt API 的 Chrome（Gemini Nano）和 Edge（Phi-4 mini-instruct）的性能，这些模型的结果并不好。</p>
<p>&#34;对于生成任务（创作、标签生成等），Edge 的 24.29% 和 Chrome 的 15.17% 的响应未能完成任务，&#34;该报告提到，失败的标准是 5 分制中得分为 2 或更低。&#34;对于分类任务，Edge 的 29.58% 和 Chrome 的 23.93% 的响应未能正确标记或分类输入。&#34;</p>
<p>在准确性和可靠性方面，Edge 的失败率为 17%，而 Chrome 的失败率为 6%。</p>
<p>这对网络来说好吗？你可以问 Chrome，但可能得不到可靠的答案。®</p>

2 倍做多谷歌 ETF - Direxion

GOOW

<p>Mozilla 对 Google 的 Prompt API 表达了强烈反对，该 API 将 AI 能力集成到 Chrome 中。Mozilla 的网络开发者关系负责人 Jake Archibald 对该 API 对网络互操作性和中立性的影响表示担忧，认为这可能导致对 Google AI 模型的依赖。他批评 Google 对开发者支持该 API 的描述夸大其词。Archibald 强调，该 API 的要求可能会损害网络的开放性，而 Google 则承认了这些担忧，但倡导创新和实验</p>

<p>Mozilla has reiterated its opposition to Google's decision to build AI plumbing into its Chrome browser, though rather belatedly now that the technology, known as the Prompt API, is already being tested in Chrome and Microsoft Edge.</p>
<div class="lb-trans"><p>Mozilla 重申了对谷歌决定在其 Chrome 浏览器中构建 AI 基础设施的反对意见，尽管这一反对意见来得有些晚，因为这一被称为 Prompt API 的技术已经在 Chrome 和 Microsoft Edge 中进行测试。</p>
</div><p>Jake Archibald, Mozilla web developer relations lead, articulated the org’s concerns in a GitHub discussion of the API, which provides a standard way to send and receive prompts and responses from a local machine learning model.</p>
<div class="lb-trans"><p>Mozilla 的网络开发者关系负责人 Jake Archibald 在关于该 API 的 GitHub 讨论中阐述了该组织的担忧，该 API 提供了一种标准方式来发送和接收来自本地机器学习模型的提示和响应。</p>
</div><p>&#34;We continue to oppose this API, and feel it has severe negative consequences to the interoperability, updatability, and neutrality of the web platform,&#34; said Archibald.</p>
<div class="lb-trans"><p>&#34;我们继续反对这个 API，并认为它对网络平台的互操作性、可更新性和中立性有严重的负面影响，&#34;Archibald 说。</p>
</div><p>The Prompt API, as Google describes it, &#34;gives web pages the ability to directly prompt a browser-provided language model.&#34; It provides a way to send natural language instructions to Google's Gemini Nano model, which is small enough to be downloaded for local inference through Chrome.</p>
<div class="lb-trans"><p>谷歌描述的 Prompt API，&#34;赋予网页直接提示浏览器提供的语言模型的能力。&#34;它提供了一种将自然语言指令发送到谷歌的 Gemini Nano 模型的方法，该模型足够小，可以通过 Chrome 进行本地推理下载。</p>
</div><p>It's not that small – Google recommends having 22 GB of space available, though the Nano (v3Nano) model for desktop use is ~4.27 GB.</p>
<div class="lb-trans"><p>它并不那么小——谷歌建议至少有 22GB 的可用空间，尽管用于桌面的 Nano（v3Nano）模型约为 4.27GB。</p>
</div><p>Web developers already have a variety of ways to interact with AI models. They can use cloud service APIs to communicate with hosted models. Or they can access local models through technologies like JavaScript runtime frameworks, WASM, or WebGPU.</p>
<div class="lb-trans"><p>网络开发者已经有多种方式与 AI 模型进行交互。他们可以使用云服务 API 与托管模型进行通信。或者，他们可以通过 JavaScript 运行时框架、WASM 或 WebGPU 等技术访问本地模型。</p>
</div><p>Various vendors like OpenAI and Perplexity have shipped browsers that embed access to remotely hosted AI models. Mozilla itself is testing an AI-based Smart Window in Firefox and it's developing tools for AI model scaffolding.</p>
<div class="lb-trans"><p>OpenAI 和 Perplexity 等各种供应商已经发布了嵌入访问远程托管 AI 模型的浏览器。Mozilla 本身正在 Firefox 中测试基于 AI 的智能窗口，并正在开发 AI 模型支架的工具。</p>
</div><p>The Prompt API aims to make it easier to run local inference in a way that takes advantage of browser security mechanisms, to produce faster response times, to allow offline usage, and to provide more cost effective ways to integrate AI services (e.g. providing a free AI fallback if users lack a paid AI API key).</p>
<div class="lb-trans"><p>Prompt API 旨在以利用浏览器安全机制的方式更容易地进行本地推理，以产生更快的响应时间，允许离线使用，并提供更具成本效益的方式来集成 AI 服务（例如，如果用户缺乏付费 AI API 密钥，则提供免费的 AI 后备）。</p>
</div><p>Mozilla's concern, as articulated by Archibald, has to do with what the Prompt API means for the web, not to mention Google's justification for deployment.</p>
<div class="lb-trans"><p>正如 Archibald 所阐述的，Mozilla 的担忧与 Prompt API 对网络的影响有关，更不用说谷歌对其部署的辩解。</p>
</div><p>First, he worries that Google's own Nano model will become the default and that developers will standardize on it in an effort to make the non-deterministic responses of an AI model more predictable. That tendency, he argues, will create pressure for Apple and Mozilla to license Nano, for the sake of a common user experience.</p>
<div class="lb-trans"><p>首先，他担心谷歌自己的 Nano 模型将成为默认模型，开发者将会以此为标准，以使 AI 模型的非确定性响应更可预测。他认为，这种趋势将迫使苹果和 Mozilla 为了共同的用户体验而授权 Nano。</p>
</div><p>Perhaps more significantly, Archibald notes that using the Prompt API requires agreeing to Google's Generative AI Prohibited Uses Policy, which prohibits activities that are not necessarily illegal, like generating &#34;disturbing&#34; content.</p>
<div class="lb-trans"><p>或许更重要的是，Archibald 指出，使用 Prompt API 需要同意谷歌的生成 AI 禁止使用政策，该政策禁止一些不一定违法的活动，例如生成 “令人不安” 的内容。</p>
</div><p>&#34;This seems like a bad direction for an API on the web platform, and sets a worrying precedent for more APIs that have [browser]-specific rules around usage,&#34; he said.</p>
<div class="lb-trans"><p>&#34;这似乎是网络平台上 API 的一个糟糕方向，并为更多具有 [浏览器] 特定使用规则的 API 设定了令人担忧的先例，&#34;他说。</p>
</div><p>Finally, Archibald argues that Google misrepresented demand for the API by cherry-picking a few social media posts and calling that a groundswell of developer support.</p>
<div class="lb-trans"><p>最后，Archibald 认为谷歌通过挑选一些社交媒体帖子来夸大对该 API 的需求，从而误导了公众。</p>
</div><p>&#34;The intent to ship on blink-dev states web developers as 'Strongly positive,' and links to the explainer for evidence,&#34; he wrote. &#34;The evidence provided there does not seem to fit the claim.&#34;</p>
<div class="lb-trans"><p>&#34;在 blink-dev 上发布的意图表明网络开发者的态度是'强烈积极的'，并链接到解释以作为证据，&#34;他写道。&#34;那里提供的证据似乎与这一说法不符。&#34;</p>
</div><ul>
<li>Hashicorp co-founder Mitchell Hashimoto says GitHub 'no longer a place for serious work'</li>
<li>Google's fix for critical Gemini CLI bug might break your CI/CD pipelines</li>
<li>AWS says acute server memory shortage is driving customers to the cloud</li>
<li>Linux cryptographic code flaw offers fast route to root</li>
</ul>
<div class="lb-trans"><ul>
<li>Hashicorp 联合创始人 Mitchell Hashimoto 表示 GitHub'不再是严肃工作的地方'</li>
<li>谷歌修复关键的 Gemini CLI 漏洞可能会破坏你的 CI/CD 管道</li>
<li>AWS 表示急性服务器内存短缺正在推动客户转向云</li>
<li>Linux 加密代码缺陷提供了快速获取 root 的途径</li>
</ul>
</div><p>In an email, Archibald told <em>The Register</em> that the question is whether the Prompt API is good for the web, and Mozilla doesn't believe that it is.</p>
<div class="lb-trans"><p>在一封电子邮件中，Archibald 告诉_The Register_，问题在于 Prompt API 是否对网络有利，而 Mozilla 并不认为它是。</p>
</div><p>&#34;The core problem is interoperability,&#34; he said. &#34;Prompts are tightly coupled to models; developers will inevitably tune to the quirks and policies of whatever model they're building against.</p>
<div class="lb-trans"><p>&#34;核心问题是互操作性，&#34;他说。&#34;提示与模型紧密耦合；开发者不可避免地会调整以适应他们所构建的模型的特性和政策。</p>
</div><p>&#34;That's how you end up with model-specific code paths, which is the browser-compatibility problem all over again. The T&amp;C issue is part of that: if using a web API means accepting a specific vendor's content policy (especially one that goes beyond law) you're not really building for an open platform anymore.&#34;</p>
<div class="lb-trans"><p>&#34;这就是你最终得到模型特定代码路径的原因，这又是浏览器兼容性问题的重现。T&amp;C 问题也是其中的一部分：如果使用网络 API 意味着接受特定供应商的内容政策（尤其是超出法律的政策），那么你就不再是在为一个开放平台构建。&#34;</p>
</div><p>With regard to Google's exaggeration of developer enthusiasm, Archibald said there are definitely devs interested in AI capabilities but Google failed to provide evidence of that.</p>
<div class="lb-trans"><p>关于谷歌夸大开发者热情的问题，Archibald 表示，确实有开发者对 AI 能力感兴趣，但谷歌未能提供相关证据。</p>
</div><p>&#34;The signal is polarised, not 'strongly positive,'&#34; he explained. &#34;Either way, developer demand alone doesn't meet the bar. The question is whether the API can work across implementations without tying the platform to one vendor's model.&#34;</p>
<div class="lb-trans"><p>&#34;信号是极化的，而不是'强烈积极的，'&#34;他解释道。&#34;无论如何，仅仅开发者的需求并不足以达到标准。问题在于 API 是否能够在不同实现之间工作，而不将平台绑定到一个供应商的模型上。&#34;</p>
</div><p>Google did not immediately respond to a request for comment.</p>
<div class="lb-trans"><p>谷歌没有立即回应置评请求。</p>
</div><p>However, on Thursday, Rick Byers, the Google Chrome engineer responsible for shipping the Prompt API, chimed in to the GitHub discussion to acknowledge the concerns articulated by Archibald.</p>
<div class="lb-trans"><p>然而，在周四，负责发布 Prompt API 的谷歌 Chrome 工程师 Rick Byers 在 GitHub 讨论中回应了 Archibald 所表达的担忧。</p>
</div><p>&#34;As one of the blink API owner approvers for shipping this in Chromium, I admit that I share the concerns here in Mozilla's standards position,&#34; he wrote. &#34;Where I differ is in preferring paths that promote experimentation, learning from mistakes, and competition to those which err on the side of stalling innovation out of fear of what <em>might</em> happen.&#34;</p>
<div class="lb-trans"><p>&#34;作为在 Chromium 中发布此 API 的 blink API 所有者批准者之一，我承认我在 Mozilla 的标准立场上分享这些担忧，&#34;他写道。&#34;我不同之处在于更倾向于促进实验、从错误中学习和竞争的路径，而不是因为害怕可能发生的事情而选择停滞创新。&#34;</p>
</div><p>Byers asked the web community to help collect evidence of harm to advance the discussion. Pointing to the debate over other controversial web technologies like Encrypted Media Extensions (EME), he suggested the outcome has not been as dire as predicted.</p>
<div class="lb-trans"><p>Byers 请求网络社区帮助收集证据以推动讨论。指出关于其他有争议的网络技术（如加密媒体扩展（EME））的辩论，他建议结果并没有像预测的那样糟糕。</p>
</div><p>But focusing on data, so far, hasn't done much for Google's cause. According to a report created in February that compares the performance of Chrome (Gemini Nano) and Edge (Phi-4 mini-instruct) using the Prompt API, these models just don't provide very good results.</p>
<div class="lb-trans"><p>但迄今为止，专注于数据并没有为谷歌的事业带来太多好处。根据 2 月份创建的一份报告，该报告比较了使用 Prompt API 的 Chrome（Gemini Nano）和 Edge（Phi-4 mini-instruct）的性能，这些模型的结果并不好。</p>
</div><p>&#34;For generative tasks (composition, tag generation, etc), 24.29 percent of Edge's and 15.17 percent of Chrome's responses failed to complete the task,&#34; the report says, in reference to a rubric that defines failure as a score of 2 or less on a scale of 5. &#34;For classification tasks, 29.58 percent of Edge's and 23.93 percent of Chrome's responses did not label or categorize the input correctly.&#34;</p>
<div class="lb-trans"><p>&#34;对于生成任务（创作、标签生成等），Edge 的 24.29% 和 Chrome 的 15.17% 的响应未能完成任务，&#34;该报告提到，失败的标准是 5 分制中得分为 2 或更低。&#34;对于分类任务，Edge 的 29.58% 和 Chrome 的 23.93% 的响应未能正确标记或分类输入。&#34;</p>
</div><p>In terms of groundedness and accuracy, Edge failed (&#34;hallucinated&#34;) 17 percent of the time while Chrome failed 6 percent of the time.</p>
<div class="lb-trans"><p>在准确性和可靠性方面，Edge 的失败率为 17%，而 Chrome 的失败率为 6%。</p>
</div><p>Is that good for the web? You could ask Chrome but you might not get a reliable answer. ®</p>
<div class="lb-trans"><p>这对网络来说好吗？你可以问 Chrome，但可能得不到可靠的答案。®</p>
</div>

Firefox maker torches Google for building Prompt API into browser

The Register

火狐浏览器的制造商猛烈抨击谷歌将 Prompt API 集成到其浏览器中