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。
- 為來源要求權杖。
- 將權杖加入網頁。有以下兩種方法:
- 在每個網頁的標頭中加入
origin-trial
<meta>
標記。例如:
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- 如果您能設定伺服器,也可以使用
Origin-Trial
HTTP 標頭新增權杖。產生的回應標頭應如下所示:
Origin-Trial: TOKEN_GOES_HERE
- 在每個網頁的標頭中加入
其他資訊
Daniel Gregoire 在 Unsplash 提供的橫幅相片