Android Chrome 88 和電腦版 Chrome 92 中的 SharedArrayBuffer 更新

Jake Archibald
Jake Archibald
X 首頁
Eiji Kitamura

SharedArrayBuffer 在網路上雖然有點粗糙，但事情一直停滯不前。以下是一些注意事項：

簡短

  • SharedArrayBuffer 目前適用於 Firefox 79 以上版本；將於 Android Chrome 88 以上版本支援。但僅適用於跨來源隔離的網頁。
  • SharedArrayBuffer 目前可在電腦版 Chrome 中使用，但自 Chrome 92 版起，將只能存取跨來源的獨立網頁。如果您認為可能無法及時進行這項變更，可以註冊來源試用，這樣就能在 Chrome 113 以上版本之前保留目前行為。
  • 如果您打算啟用跨來源隔離，繼續使用 SharedArrayBuffer 評估這對您網站上的其他跨來源元素 (例如廣告刊登位置) 的影響。檢查您的任何第三方資源是否使用 SharedArrayBuffer，瞭解相關影響和指引。

跨來源隔離總覽

您可使用下列標頭提供網頁，讓網頁跨來源隔離：

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

執行此操作後，除非資源已透過 Cross-Origin-Resource-Policy 標頭或 CORS 標頭 (Access-Control-Allow-* 等) 明確允許，否則頁面將無法載入跨來源內容。

此外還有 Reporting API，方便您收集因 Cross-Origin-Embedder-Policy 和 Cross-Origin-Opener-Policy 而失敗的要求資料。

如果您不認為自己是否可以在 Chrome 92 中及時進行這些變更，可以註冊來源試用，讓 Chrome 電腦版在至少 Chrome 113 以上版本仍可使用。

如需跨來源隔離的詳細指南和相關資訊，請參閱本頁底部的「延伸閱讀」一節。

但這項技術是如何演變而來？

SharedArrayBuffer 已推出 Chrome 60 版 (2017 年 7 月，限於在搜尋日期，而非 Chrome 版本的使用者)，一切都非常實用。6 個月。

2018 年 1 月，某個熱門 CPU 發現了安全漏洞。如需完整詳細資料，請參閱公告，但基本上，程式碼會使用高解析度計時器讀取原本不應存取的記憶體。

這對我們瀏覽器供應商來說是問題，因為我們希望網站能夠以 JavaScript 和 WASM 格式執行程式碼，但嚴格控制此程式碼可存取的記憶體。如果來到我的網站，我應該無法從您剛取得的網路銀行網站上讀取任何資訊。事實上，我不應該知道你的網路銀行網站已經開啟。這些是網路安全性的基礎知識

為減緩此問題，我們降低了高解析度計時器的解析度，例如 performance.now()。不過，您可以使用 SharedArrayBuffer 建立高解析度計時器，方法是修改工作站中的緊密迴圈記憶體，然後在另一個執行緒中讀取該記憶體。除非對意圖明確影響的程式碼造成嚴重影響，否則無法有效緩解這個狀況，因此會完全停用 SharedArrayBuffer。

一般的解決方法是確保網頁系統程序不含其他位置的機密資料。Chrome 從一開始就投資了多程序架構 (記住這本漫畫？)，但是在某些情況下，來自多個網站的資料最終可能會以同一個程序運作：

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

這些 API 具有「舊版」行為，可讓其他來源的內容在未選擇加入另一個來源的情況下使用。這些要求則是由其他來源的 Cookie 所提出，因此是完整的「已登入」要求。目前，新的 API 會要求其他來源使用 CORS 選擇加入。

我們解決這些舊版 API 的用意，是防止內容看起來「不正確」時進入網頁程序，並稱為跨來源讀取封鎖。因此，在上述情況下，我們無法允許 JSON 進入程序，因為該程序對任何這些 API 都不是有效格式。也就是 iframe 除外。至於 iframe，我們會以不同程序顯示內容。

作為這些因應措施，我們在 Chrome 68 (2018 年 7 月) 中重新推出 SharedArrayBuffer，但僅適用於電腦版。額外的程序要求 使我們在行動裝置上做不到的事這同樣指出 Chrome 的解決方案並不完善，因為我們只封鎖「不正確」的資料格式，但有時有效的 CSS/JS/圖片可以包含私人資料。

網路標準團隊攜手合作，想出更完整的跨瀏覽器解決方案。這項解決方案的用意就是讓網頁明白：「我特此決定，不只要使用者選擇加入，就能在這項程序中將其他來源的內容納入這項程序。」這個宣告是透過透過頁面提供的 COOP 和 COEP 標頭來完成。瀏覽器會強制執行該政策，並交換頁面以存取 SharedArrayBuffer 和其他類似效能的 API。其他來源可透過 Cross-Origin-Resource-Policy 或 CORS 選擇加入內容嵌入。

Firefox 是在 79 版 (2020 年 7 月) 中首次發布設有這項限制的 SharedArrayBuffer。

然後，我在 2021 年 1 月寫了這篇文章，而您讀。你好！

這就是目前的現況Chrome 第 88 版將 SharedArrayBuffer 傳回 Android 來處理跨來源隔離的頁面，而 Chrome 92 則為電腦採用相同的規定，除了為電腦帶來一致的體驗，也針對跨來源進行全面隔離。

延後 Chrome 電腦版變更

這個例外狀況是以「來源試用」的形式暫時的例外狀況，讓員工有更多時間實作跨來源隔離的頁面。這樣會在不跨來源隔離頁面的情況下啟用 SharedArrayBuffer。例外狀況將於 Chrome 113 到期，且僅適用於電腦版 Chrome。

  1. 為來源要求權杖。
  2. 將權杖加入網頁。有以下兩種方法：
    • 在每個網頁的標頭中加入 origin-trial <meta> 標記。例如：
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • 如果您能設定伺服器，也可以使用 Origin-Trial HTTP 標頭新增權杖。產生的回應標頭應如下所示：
      Origin-Trial: TOKEN_GOES_HERE

其他資訊

Daniel Gregoire 在 Unsplash 提供的橫幅相片