Bản cập nhật SharedArrayBuffer trong Android Chrome 88 và Chrome 92 dành cho máy tính

Jake Archibald
Jake Archibald
X Trang chủ
Eiji Kitamura

Có thể nói SharedArrayBuffer đã gặp một số vấn đề khi ra mắt trên web, nhưng mọi thứ đang dần ổn định. Dưới đây là những gì bạn cần phải biết:

Tóm tắt

  • SharedArrayBuffer hiện được hỗ trợ trong Firefox 79 trở lên và sẽ có trong Android Chrome 88. Tuy nhiên, tính năng này chỉ dành cho những trang được tách biệt nhiều nguồn gốc.
  • SharedArrayBuffer hiện có trong Chrome dành cho máy tính, nhưng từ Chrome 92, đối tượng này sẽ chỉ được dùng cho các trang được tách biệt nhiều nguồn gốc. Nếu cho rằng mình không thể thực hiện thay đổi này kịp thời, bạn có thể đăng ký dùng thử theo nguồn gốc để giữ nguyên hành vi hiện tại cho đến ít nhất là Chrome 113.
  • Nếu bạn dự định bật tính năng tách biệt nhiều nguồn gốc để tiếp tục sử dụng SharedArrayBuffer, hãy đánh giá tác động của việc này đối với các phần tử nhiều nguồn gốc khác trên trang web của bạn, chẳng hạn như vị trí đặt quảng cáo. Kiểm tra xem có tài nguyên nào của bên thứ ba sử dụng SharedArrayBuffer hay không để hiểu rõ tác động và hướng dẫn.

Tổng quan về tính năng tách biệt nhiều nguồn gốc

Bạn có thể tạo một trang tách biệt nhiều nguồn gốc bằng cách phân phát trang đó bằng các tiêu đề sau:

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

Sau khi bạn thực hiện việc này, trang của bạn sẽ không thể tải nội dung nhiều nguồn gốc trừ phi tài nguyên cho phép nội dung đó một cách rõ ràng thông qua tiêu đề Cross-Origin-Resource-Policy hoặc tiêu đề CORS (Access-Control-Allow-*, v.v.).

Ngoài ra, còn có API báo cáo để bạn có thể thu thập dữ liệu về các yêu cầu không thành công do Cross-Origin-Embedder-Policy và Cross-Origin-Opener-Policy.

Nếu cho rằng mình không thể thực hiện những thay đổi này kịp thời cho Chrome 92, bạn có thể đăng ký dùng thử theo nguyên gốc để giữ lại hành vi hiện tại của Chrome trên máy tính cho đến ít nhất là Chrome 113.

Hãy xem phần Đọc thêm ở cuối trang này để biết thêm hướng dẫn và thông tin về tính năng tách biệt nhiều nguồn gốc.

Chúng ta đã đến đây bằng cách nào?

SharedArrayBuffer đã xuất hiện trong Chrome 60 (tháng 7 năm 2017, đối với những bạn nghĩ về thời gian theo ngày thay vì phiên bản Chrome) và mọi thứ đều rất tuyệt vời. Trong 6 tháng.

Vào tháng 1 năm 2018, một lỗ hổng đã được phát hiện trong một số CPU phổ biến. Hãy xem thông báo để biết toàn bộ thông tin chi tiết, nhưng về cơ bản, điều này có nghĩa là mã có thể sử dụng bộ hẹn giờ có độ phân giải cao để đọc bộ nhớ mà mã không được truy cập.

Đây là vấn đề đối với các nhà cung cấp trình duyệt, vì chúng tôi muốn cho phép các trang web thực thi mã ở dạng JavaScript và WASM, nhưng kiểm soát nghiêm ngặt bộ nhớ mà mã này có thể truy cập. Nếu bạn truy cập vào trang web của tôi, tôi sẽ không thể đọc bất kỳ nội dung nào trên trang web ngân hàng trực tuyến mà bạn cũng đang mở. Trên thực tế, tôi thậm chí không biết bạn có mở trang web ngân hàng trực tuyến hay không. Đây là những kiến thức cơ bản về bảo mật web.

Để giảm thiểu vấn đề này, chúng tôi đã giảm độ phân giải của các bộ hẹn giờ có độ phân giải cao như performance.now(). Tuy nhiên, bạn có thể create một bộ hẹn giờ có độ phân giải cao bằng cách sử dụng SharedArrayBuffer bằng cách sửa đổi bộ nhớ trong một vòng lặp chặt chẽ trong một worker và đọc lại bộ nhớ đó trong một luồng khác. Chúng tôi không thể giảm thiểu hiệu quả vấn đề này mà không ảnh hưởng nặng nề đến mã có ý định tốt, vì vậy, SharedArrayBuffer đã bị tắt hoàn toàn.

Một biện pháp giảm thiểu chung là đảm bảo quy trình hệ thống của trang web không chứa dữ liệu nhạy cảm từ nơi khác. Chrome đã đầu tư vào cấu trúc nhiều quy trình ngay từ đầu (bạn còn nhớ truyện tranh đó không?), nhưng vẫn có những trường hợp dữ liệu từ nhiều trang web có thể kết thúc trong cùng một quy trình:

<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… -->

Các API này có hành vi "cũ" cho phép sử dụng nội dung từ các nguồn gốc khác mà không cần chọn sử dụng từ nguồn gốc khác. Các yêu cầu này được thực hiện bằng cookie của nguồn gốc khác, vì vậy, đây là yêu cầu "đã đăng nhập" đầy đủ. Ngày nay, các API mới yêu cầu nguồn gốc khác chọn sử dụng CORS.

Chúng tôi đã giải quyết các API cũ này bằng cách ngăn nội dung đi vào quy trình của trang web nếu nội dung đó có vẻ "không chính xác" và gọi đó là chặn đọc giữa các nguồn gốc. Vì vậy, trong các trường hợp trên, chúng tôi sẽ không cho phép JSON tham gia quy trình này vì đây không phải là định dạng hợp lệ cho bất kỳ API nào trong số đó. Nghĩa là ngoại trừ iframe. Đối với iframe, chúng ta đặt nội dung trong một quy trình khác.

Với các biện pháp giảm thiểu này, chúng tôi đã giới thiệu lại SharedArrayBuffer trong Chrome 68 (tháng 7 năm 2018), nhưng chỉ trên máy tính. Các yêu cầu bổ sung về quy trình khiến chúng tôi không thể làm như vậy trên thiết bị di động. Chúng tôi cũng nhận thấy rằng giải pháp của Chrome chưa hoàn chỉnh, vì chúng tôi chỉ chặn các định dạng dữ liệu "không chính xác", trong khi CSS/JS/hình ảnh hợp lệ tại các URL có thể đoán được có thể chứa dữ liệu riêng tư (mặc dù không phổ biến).

Các chuyên gia về tiêu chuẩn web đã cùng nhau đưa ra một giải pháp hoàn chỉnh hơn trên nhiều trình duyệt. Giải pháp là cung cấp cho các trang một cách để nói rằng "Tôi từ bỏ quyền đưa nội dung từ các nguồn khác vào quy trình này nếu họ không chọn sử dụng". Việc khai báo này được thực hiện thông qua tiêu đề COOP và COEP được phân phát cùng với trang. Trình duyệt thực thi điều đó và để đổi lại, trang sẽ có quyền truy cập vào SharedArrayBuffer và các API khác có quyền tương tự. Các nguồn gốc khác có thể chọn sử dụng tính năng nhúng nội dung thông qua Cross-Origin-Resource-Policy hoặc CORS.

Firefox là trình duyệt đầu tiên phát hành SharedArrayBuffer với quy định hạn chế này, trong phiên bản 79 (tháng 7 năm 2020).

Sau đó, vào tháng 1 năm 2021, tôi đã viết bài viết này và bạn đọc bài viết đó. Xin chào.

Đó là những gì chúng tôi đang làm. Chrome 88 đưa SharedArrayBuffer trở lại Android cho các trang được tách biệt nhiều nguồn gốc và Chrome 92 đưa các yêu cầu tương tự đến máy tính, cả để đảm bảo tính nhất quán và để đạt được chế độ tách biệt hoàn toàn nhiều nguồn gốc.

Trì hoãn thay đổi đối với Chrome dành cho máy tính

Đây là một trường hợp ngoại lệ tạm thời dưới dạng "thời gian dùng thử theo nguồn gốc" để mọi người có thêm thời gian triển khai các trang tách biệt nhiều nguồn gốc. Phương thức này cho phép SharedArrayBuffer mà không yêu cầu trang phải được tách biệt trên nhiều nguồn gốc. Trường hợp ngoại lệ này sẽ hết hạn trong Chrome 113 và chỉ áp dụng cho Chrome phiên bản máy tính.

  1. Yêu cầu mã thông báo cho nguồn gốc của bạn.
  2. Thêm mã thông báo vào các trang của bạn. Có hai cách để thực hiện việc đó:
    • Thêm thẻ origin-trial <meta> vào đầu mỗi trang. Ví dụ: nội dung này có thể có dạng như sau:
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • Nếu có thể định cấu hình máy chủ, bạn cũng có thể thêm mã thông báo bằng cách sử dụng tiêu đề HTTP Origin-Trial. Tiêu đề phản hồi thu được sẽ có dạng như sau:
      Origin-Trial: TOKEN_GOES_HERE

Tài liệu đọc thêm

Ảnh biểu ngữ của Daniel Gregoire trên Unsplash