<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 集成到其瀏覽器中