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 113 이상까지 현재 데스크톱 Chrome 동작을 유지할 수 있습니다.
교차 출처 격리에 관한 자세한 안내와 정보는 이 페이지 하단의 추가 리소스 섹션을 참고하세요.
왜 이렇게 되었을까요?
SharedArrayBuffer가 Chrome 60 (Chrome 버전이 아닌 날짜로 시간을 생각하는 분들을 위해 2017년 7월)에 도착했고 모든 것이 좋았습니다.
6개월간
2018년 1월에 일부 인기 CPU에서 취약점이 발견되었습니다. 자세한 내용은 공지사항을 참고하세요. 기본적으로 코드가 고해상도 타이머를 사용하여 액세스할 수 없는 메모리를 읽을 수 있다는 의미입니다.
사이트에서 JavaScript 및 WASM 형식으로 코드를 실행하도록 허용하면서 이 코드가 액세스할 수 있는 메모리를 엄격하게 제어하려는 브라우저 공급업체에게는 문제가 되었습니다. 고객이 내 웹사이트에 도착하면 고객이 열어 둔 인터넷 뱅킹 사이트에서 아무것도 읽을 수 없어야 합니다. 사실 고객님께서 인터넷 뱅킹 사이트를 열어 두셨는지조차 알 수 없습니다. 이는 웹 보안의 기본사항입니다.
이를 완화하기 위해 performance.now()와 같은 고해상도 타이머의 해상도를 줄였습니다. 그러나 작업자의 빡빡한 루프에서 메모리를 수정하고 다른 스레드에서 다시 읽어서 SharedArrayBuffer를 사용하여 고해상도 타이머를 create. 의도한 바와 같이 작동하는 코드에 큰 영향을 주지 않고는 이를 효과적으로 완화할 수 없으므로 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에만 적용됩니다.
- 출처의 토큰을 요청합니다.
- 페이지에 토큰을 추가합니다. 다음과 같은 두 가지 방법이 있습니다.
- 각 페이지의 헤더에
origin-trial<meta>태그를 추가합니다. 예를 들어 다음과 같이 표시될 수 있습니다.
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - 서버를 구성할 수 있는 경우
Origin-TrialHTTP 헤더를 사용하여 토큰을 추가할 수도 있습니다. 결과 응답 헤더는 다음과 같이 표시됩니다.
Origin-Trial: TOKEN_GOES_HERE
- 각 페이지의 헤더에