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-* 등)를 통해 명시적으로 허용하지 않는 한 페이지에서 교차 출처 콘텐츠를 로드할 수 없습니다.

보고 API도 있으므로 Cross-Origin-Embedder-Policy 및 Cross-Origin-Opener-Policy로 인해 실패한 요청에 관한 데이터를 수집할 수 있습니다.

Chrome 92까지 이러한 변경사항을 적용할 수 없는 경우 오리진 트라이얼에 등록하여 최소한 Chrome 113까지 현재 데스크톱 Chrome 동작을 유지할 수 있습니다.

교차 출처 격리에 관한 자세한 안내와 정보는 이 페이지 하단의 추가 자료 섹션을 참고하세요.

왜 이렇게 되었을까요?

SharedArrayBuffer는 Chrome 60 (Chrome 버전이 아닌 날짜로 시간을 생각하는 사용자를 위해 2017년 7월)에 도입되었으며 모든 것이 훌륭했습니다. 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에는 다른 출처의 콘텐츠를 다른 출처의 선택 없이 사용할 수 있는 '레거시' 동작이 있습니다. 이러한 요청은 다른 출처의 쿠키로 이루어지므로 완전한 '로그인' 요청입니다. 요즘 새로운 API는 다른 출처가 CORS를 사용하여 선택해야 합니다.

Google은 콘텐츠가 '잘못'된 것으로 보이면 웹페이지의 프로세스에 콘텐츠가 입력되지 않도록 하여 이러한 기존 API를 해결했으며 이를 교차 출처 읽기 차단이라고 불렀습니다. 따라서 위의 경우 JSON은 이러한 API의 유효한 형식이 아니므로 프로세스에 입력할 수 없습니다. 즉, iframe은 제외됩니다. iframe의 경우 콘텐츠를 다른 프로세스에 넣습니다.

이러한 완화 조치를 적용한 후 Chrome 68 (2018년 7월)에서 SharedArrayBuffer를 다시 도입했지만 데스크톱에서만 가능합니다. 추가 프로세스 요구사항으로 인해 휴대기기에서는 동일한 작업을 할 수 없었습니다. 또한 Chrome의 솔루션은 불완전한 것으로 지적되었습니다. '잘못된' 데이터 형식만 차단하는 반면, 추측 가능한 URL의 유효한 CSS/JS/이미지에 비공개 데이터가 포함될 수 있기 때문입니다 (드문 경우지만).

웹 표준 담당자들이 모여 더 완전한 크로스 브라우저 솔루션을 마련했습니다. 해결책은 페이지가 '동의 없이 이 프로세스에 다른 출처 콘텐츠를 가져오는 기능을 포기합니다'라고 말할 수 있는 방법을 제공하는 것이었습니다. 이 선언은 페이지와 함께 제공되는 COOP 및 COEP 헤더를 통해 이루어집니다. 브라우저에서 이를 적용하며, 그 대가로 페이지는 SharedArrayBuffer 및 유사한 기능을 갖춘 다른 API에 액세스할 수 있습니다. 다른 출처는 Cross-Origin-Resource-Policy 또는 CORS를 통해 콘텐츠 삽입을 선택할 수 있습니다.

Firefox는 버전 79 (2020년 7월)에서 이 제한과 함께 SharedArrayBuffer를 처음으로 제공했습니다.

그런 다음 2021년 1월에 제가 이 도움말을 작성했고 여러분이 이 도움말을 읽었습니다. 안녕하세요.

현재 상황은 이렇습니다. Chrome 88에서는 교차 출처 분리된 페이지를 위해 Android에 SharedArrayBuffer를 다시 도입하고, 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 제공)