교차 출처 저장소

1. 소개

이 절은 비규범적입니다.

저장소는 일반적으로 사용자 보안과 개인정보를 보호하기 위해 출처별로 분할됩니다. 이는 적절한 기본값이지만, 매우 크고, 매우 널리 사용되며, 공개적으로 배포되는 일부 유형의 리소스(AI 모델, WebAssembly 모듈, JavaScript 라이브러리, 게임 엔진 및 대용량 웹 글꼴)에는 잘 맞지 않습니다. 이러한 리소스는 어느 사이트에서 요청하든 바이트 단위로 동일한 파일입니다. 서로 관련 없는 두 출처가 각각 동일한 8 GB 모델에 의존하면, 출처별로 분할된 저장소에서는 사용자가 해당 모델을 두 번 다운로드하고 보관해야 하므로, 사용자의 대역폭, 저장 공간, 배터리뿐 아니라 네트워크 전체에도 낭비가 발생합니다.

교차 출처 저장소(COS)는 콘텐츠 주소 지정 방식의 캐시로, URL 대신 암호학적 해시를 키로 사용하여 사용자 에이전트가 이러한 리소스의 저장된 사본 하나를 사용에 동의한 출처 간에 공유할 수 있게 합니다. COS에 리소스를 저장하는 것은 항상 저장하는 출처가 명시적으로 선택하는 행위이며, 사용자 에이전트는 리소스의 존재 여부 확인을 읽기가 허용되는 출처에 대해서도 보류할 수 있습니다. § 8 개인정보 보호 및 보안 고려 사항을 참조하세요.

이 명세의 진입점은 getFileHandle() 메서드이며, 다음을 통해 노출됩니다. crossOriginStorage:

const hash = {
  algorithm: 'SHA-256',
  value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
try {
  const handle = await navigator.crossOriginStorage.getFileHandle(hash);
  const file = await handle.getFile();
  // 파일로 작업을 수행합니다.
} catch (err) {
  if (err.name === 'NotFoundError') {
    // 교차 출처 저장소에 (공개 가능한 상태로) 존재하지 않으므로 대신 네트워크에서 가져옵니다.
  }
}

이 명세는 FileSystemFileHandle, FileSystemWritableFileStream, 및 관련 기반 구조를 파일 시스템 표준 [FS]에서 재사용하며, 전용 파일 시스템으로 범위를 한정합니다. 이 파일 시스템은 출처 간에 공유되며, 각 출처의 비공개 또는 사용자에게 보이는 파일 시스템과 분리됩니다.

이 명세는 명령형 JavaScript API와 호스트 통합이 기반으로 삼는 공유 저장 단계를 정의합니다. 관련 제안은 동일한 기반 캐시를 다른 호스트 명세에 통합합니다. HTML crossoriginstorage 속성은 link 및 script에 적용되며, 그 밖에 crossOriginStorage JavaScript 가져오기 속성, CSS cross-origin-storage() <request-url-modifier>, 그리고 crossOriginStorage RequestInit 옵션이 fetch()에 적용됩니다. 각각은 해당 호스트 명세에서 정의됩니다. § 9 통합 및 다른 명세와의 관계를 참조하세요.

2. 개념

2.1. 해시

COS 해시는 구조체이며, 다음 항목을 갖습니다:

알고리즘

문자열로, 다음에서 인식하는 해시 알고리즘의 이름입니다. [WEBCRYPTO]에서 "SHA-1"은 제외하며, 예를 들면 "SHA-256"입니다.

값

문자열로, 다음이 생성한 다이제스트를 소문자 16진수로 인코딩한 것입니다. 알고리즘. "SHA-256"의 경우 길이는 64자입니다.

algorithm 딕셔너리 멤버의 타입은 일반 DOMString이지만, 그 값의 범위는 정확히 [WEBCRYPTO]의 해시 알고리즘이 허용하는 이름의 집합입니다. HashAlgorithmIdentifier 는 (object or DOMString)이며, 그 object 분기는 다음에 의해 정규화됩니다. [WEBCRYPTO]는 이를 Algorithm 형태의 딕셔너리로 정규화하여 호출자가 추가 매개변수가 필요한 알고리즘에 이를 전달할 수 있게 합니다(예: {name: "HMAC", hash: "SHA-256"}). 해시 알고리즘에는 이러한 매개변수가 필요하지 않으며, 알고리즘은 저장되고, 비교되며, 다음과 같은 방식의 콘텐츠 주소 지정 키의 일부로 왕복 변환됩니다. 또한 이 명세의 모든 예제에서는 단순 문자열을 사용합니다. 여기서 임의의 객체를 허용해도 기능은 추가되지 않으면서 동등성과 직렬화가 불필요하게 복잡해집니다. 따라서 DOMString이 이 필드에 더 제한적이고 올바른 타입입니다.

두 COS 해시 값이 동일하려면, 두 값의 알고리즘 값이 ASCII 대소문자를 구분하지 않고 일치해야 하며, 두 값의 값이 정확히 같아야 합니다.

참고: 값은 이미 규범적으로 소문자이므로(위 참조), 이를 비교하는 것은 일반적인 문자열 비교입니다. 알고리즘에는 규범적인 대소문자 형태가 없으므로, ASCII 대소문자를 구분하지 않고 비교합니다.

콘텐츠 주소 지정 방식의 저장소는 항목의 키가 다음의 동등성에 따라 정해집니다. COS 해시를 기준으로, 두 파일의 바이트가 동일하고 해시 알고리즘이 같으면, 이를 저장한 출처의 수나 가져온 URL의 수와 관계없이 같은 항목입니다.

2.2. COS 항목

COS 파티션은 환경 설정 객체 settings에 대해 다음과 같이 정해지는 결과입니다. 사이트를 얻습니다. 이때 settings의 최상위 출처를 사용합니다. settings는 제1자 COS 컨텍스트입니다. 다음을 수행한 결과가 사이트 얻기이며, 그 입력인 settings의 출처에서 얻은 사이트가 동일 사이트 관계를 만족하는 경우입니다. 비교 대상은 해당 COS 파티션입니다.

COS 허가는 구조체이며, 다음 항목을 갖습니다. 출처는 출처이며, 파티션은 COS 파티션으로, 쓰기 작업에 해당하며 해당 쓰기가 허가를 추가했습니다. 또한 제1자는 불리언으로, 해당 쓰기가 다음에서 실행되었는지를 기록합니다. 제1자 COS 컨텍스트. 허가는 읽기의 COS 파티션이 동일 사이트 관계인 경우 적용됩니다. 비교 대상은 허가의 파티션입니다. 다음을 참조하세요. COS 공개 결정.

각 사용자 에이전트는 하나의 COS 레지스트리를 가지며, 이는 맵으로, COS 해시 값에서 COS 항목 구조체로 매핑하며, 교차 출처 저장소를 사용하는 모든 출처가 공유합니다. COS 항목은 다음 항목을 갖습니다:

해시

COS 해시입니다.

바이트

바이트 시퀀스로, 다음에 따른 다이제스트를 갖습니다. 해시의 알고리즘으로 계산한 다이제스트는 다음과 같습니다. 해시의 값.

참고: 항목은 다음에 추가됩니다. COS 레지스트리에 추가되는 시점은 쓰기 주체가 이러한 바이트를 제공하고 사용자 에이전트가 이를 검증한 이후뿐입니다. 검증 및 저장을 참조하세요. 요청되었지만 완료되지 않은 쓰기는 레지스트리에 전혀 표현되지 않으므로, 진행 중인 쓰기는 읽기 경로에서 존재하지 않는 쓰기와 구분되지 않습니다. § 8.3 진행 중인 쓰기를 참조하세요.

출처 목록

리스트이며, COS 허가들로 구성되어 명시적인 교차 출처 읽기 접근을 부여하며, 다음과 독립적입니다. 공개 해시 목록. 각 허가는 모든 출처로 확장되며, 동일 사이트 관계를 만족하는 대상은 허가의 출처입니다. 따라서 https://a.example을 나열하면 https://www.a.example도 허용됩니다. 허가의 제1자가 true이면 해당 허가는 다음의 읽기 주체에도 적용됩니다. 제1자 COS 컨텍스트에 있는 읽기 주체이며, 최상위 사이트는 무엇이든 가능합니다. 처음에는 비어 있으며, 이후에는 증가하기만 합니다. 이는 항목을 읽을 수 있는 주체를 결정하는 독립적이고 누적되는 세 가지 허가 중 하나이며, 나머지 둘은 해당 항목의 저장한 출처(항상 읽을 수 있으며, 다음 출처도 함께 읽을 수 있습니다. 동일 사이트 관계의 출처)와 전역적으로 공개 가능입니다.

참고: 쓰기의 origins 가 명시적인 빈 리스트인 경우 (origins: []), 해당 쓰기가 부여하는 허가는 다음을 생략한 쓰기가 origins 부여하는 허가와 정확히 같습니다. 항목의 저장한 출처와 다음 관계의 출처들입니다. 동일 사이트 관계이며, 모든 항목이 갖는 기본 허가입니다. 다음을 참조하세요. COS 공개 결정. 상한 적용은 빈 리스트를 null로 바꾸므로, 두 쓰기는 나머지 생성 요청 완료 단계에 같은 상태로 도달합니다. 명시적인 리스트는 수신 대상을 추가하기만 하며, 쓰기 주체 자체의 사이트에서 항목에 접근하지 못하게 하는 일은 없습니다.

전역적으로 공개 가능

불리언으로, 처음에는 false이며, 항목이 기록될 때 다음 요청이 있었는지를 기록합니다. 전역적("*") 가용성 요청입니다. true이면 요청이 다음을 통과하는 모든 출처가 해당 항목을 읽을 수 있습니다. § 8.4 가용성 제한, 즉 항목의 해시가 PHL에 포함되어 있고, GREASE 적용으로 억제되지 않는 경우입니다. 한 번 설정되면 true를 유지합니다.

참고: 이는 별도의 항목으로, 출처 목록과 구분되므로, 나중에 이루어지는 전역적 가용성 요청은 기존의 명시적인 허가에 "*" 허가를 추가합니다. 출처 목록 리스트는 유지됩니다. 두 항목을 하나의 필드로 합치면, 바이트를 제공한 쓰기 주체가 리스트 범위의 항목을 "*" 범위의 항목으로 바꿀 수 있습니다. § 8.4 가용성 제한이 "*" 허가에만 적용되므로, 이전에는 항목을 다음에 따라 읽을 수 있던 출처가 리스트에 있어도 다음 오류를 받기 시작할 수 있습니다. "NotFoundError" 가 발생하는 조건은 해시가 다음에 PHL에 포함되지 않은 경우입니다. 허가들을 독립적으로 유지하면 모든 가시성 변경이 엄격히 누적되며, 이는 확장할 수 있지만 축소할 수는 없음이라는 요구를 충족합니다.

저장한 출처

집합이며, COS 허가들로 구성됩니다. 각 출처와 COS 파티션의 조합마다 하나씩 있으며, 해당 파티션에서 그 출처가 이 항목의 바이트를 한 번 이상 성공적으로 쓰기 완료한 경우에 해당합니다. 이 허가들의 제1자는 영향을 주지 않습니다. 페이지를 새로 로드해도 유지되며 시간이 지남에 따라 증가합니다. 다음에 설명된 경우 외에는 줄어들지 않습니다. § 5.2 축출. 허가의 출처는 항상 다음을 통해 항목의 핸들을 얻을 수 있습니다. getFileHandle() 이때 허가의 파티션을 사용하며, 다음과는 관계없습니다. 출처 목록 또는 항목의 해시가 공개 해시 목록(PHL)에 포함되는지 여부입니다. § 3.5.1 최초 저장자의 접근을 참조하세요.

참고: 허가의 키에 최상위 사이트를 사용하면 내장된 프레임이 보는 교차 출처 저장소의 범위가 저장소 분할이 다른 저장소에 제공하는 범위와 같아집니다. 이 키가 없으면, 여러 사이트에 내장된 프레임이 한 사이트에서 작은 파일을 기록하고 다른 사이트에서 이를 다시 읽을 수 있습니다. 저장한 출처라는 자격을 이용하여 공개 해시 목록, GREASE 적용, 그리고 모든 조회 제한을 우회하므로, 사실상 제3자 쿠키와 같아집니다. 최상위 쓰기에도 키가 적용되므로, 추적기가 최상위 방문 중 한 번 기록한 뒤 모든 곳의 프레임에서 다시 읽을 수는 없습니다. 출처 목록 허가가 다음에서 발생했다면, 제1자 COS 컨텍스트 는 모든 최상위 사이트의 자사 컨텍스트에도 적용되므로 최상위 사이트 간의 제한적 공유가 유지된다. 다른 최상위 사이트에서 이 권한으로 조회에 응답하면 작성자 사이트에서 저장한 내용이 공개되므로 사이트 간 조회 예산에 포함된다(참조: § 8.4 가용성 제한). 전역적으로 공개 가능에는 키가 적용되지 않습니다. 이미 공개 해시 목록과 GREASE 적용이 이를 제어하기 때문입니다.

사용자 에이전트에는 연관된 교차 출처 저장소 큐가 있으며, 이는 다음의 결과입니다. 새 병렬 큐 시작. 다음에 대한 모든 작업은 COS 레지스트리에 대한 작업이며, 큐에 추가되어야 합니다. 이 큐에 추가하면 작업들은 큐에 추가된 순서대로 실행되며 서로 끼어들지 않습니다.

2.3. 공개 해시 목록

해시가 교차 출처 저장소에 존재함을 확인하는 행위 자체가 사용자의 탐색 기록에 관한 정보를 유출할 수 있습니다(§ 8.2 교차 사이트 탐색 참조). 이는 특히 전역적 허가에 해당하는 위험입니다. 항목의 명시적인 출처 목록 리스트와 모든 항목이 갖는 동일 사이트 기본 허가는 저장한 출처의 명시적인 선택으로 이미 공개 범위가 제한됩니다. 반면, 항목을 전역적으로 공개 가능하게 만들면 잠재적으로 웹상의 모든 출처에 노출됩니다. 이 특정 위험을 제한하기 위해, 전역적으로 공개 가능한 리소스는 다음 조건에서만 공개됩니다. 해당 허가를 통해 항목의 저장한 출처 이외의 출처에 공개되려면 해시가 추가적인 독립 조건을 통과해야 합니다. 바로 다음 목록에 포함되는 것입니다. 공개 해시 목록 (PHL)은 공급업체에 중립적인 구현 정의 허용 목록으로, COS 해시 값으로 구성됩니다. 해시는 k-익명성 방식의 인기도 기준을 통과한 뒤에만 공개 해시 목록에 포함됩니다(예를 들어, 바이트가 동일한 상태로 일정 수 이상의 독립적인 출처에 나타나야 합니다). 따라서 공유 캐시에 해시가 존재함을 확인해도 개별 사용자에 관한 정보는 드러나지 않습니다.

COS 해시 hash가 공개 해시 목록에 포함된다는 것은 hash가 동일한 항목을 사용자 에이전트의 현재 스냅샷에서 찾을 수 있다는 뜻입니다. 해당 스냅샷은 공개 해시 목록의 스냅샷입니다.

검색 프로토콜, 업데이트 주기, 데이터 형식, 인기도 임계값 및 거버넌스와 관련하여, 공개 해시 목록은 이 명세의 동반 산출물로 상세하게 설계됩니다. 이는 다음 표준의 동반 데이터 파일인 공개 접미사 목록의 취지를 따릅니다. [URL] 표준입니다. 다음을 참조하세요. 공개 해시 목록 설명서는 이 저장소에 있습니다. 해당 설계는 WHATWG가 거버넌스를 맡도록 제안하며, 공개 접미사 목록의 공급업체 간 롤링 릴리스 선례를 따르고, 독립적으로 확인된 보편성을 등재 기준으로 삼습니다. 이는 위에서 설명한 k-익명성 방식의 기준을 구체화한 것으로, 한 번만 오프라인으로 적용되며, 해시의 등재 과정에 포함되므로 사용자 에이전트가 쿼리마다 이를 반복하지 않습니다. 이 중 어느 것도 아직 이 제안 밖에서 확립되지는 않았습니다. 목록 자체의 초기 비규범적 코드 프로토타입은 현재 이 저장소의 다음 위치에 있습니다. public-hash-list/implementation/. 전용 공급업체 간 저장소는 여전히 PHL 설명서에 기술된 거버넌스 목표입니다. 이 명세는 해시가 다음 조건을 만족하는지에만 의존하므로, PHL에 포함되는지에만 의존하므로, 목록의 검색 메커니즘, 거버넌스 모델 또는 나머지 설계가 어떻게 발전하든 올바르게 유지됩니다.

3. CrossOriginStorageManager 인터페이스

[Exposed=(Window,Worker), SecureContext]
interface CrossOriginStorageManager {
  Promise<FileSystemFileHandle> getFileHandle(
      CrossOriginStorageGetFileHandleHash hash,
      optional CrossOriginStorageGetFileHandleOptions options = {});
};

dictionary CrossOriginStorageGetFileHandleHash {
  required DOMString value;
  required DOMString algorithm;
};

dictionary CrossOriginStorageGetFileHandleOptions {
  boolean create = false;
  (DOMString or sequence<DOMString>) origins;
};

interface mixin NavigatorCrossOriginStorage {
  [Exposed=(Window,Worker), SameObject, SecureContext] readonly attribute CrossOriginStorageManager crossOriginStorage;
};
Navigator includes NavigatorCrossOriginStorage;
WorkerNavigator includes NavigatorCrossOriginStorage;

각 Navigator 및 WorkerNavigator 객체에는 연관된 CrossOriginStorageManager 객체가 있습니다. crossOriginStorage의 getter 단계는 다음을 반환하는 것입니다. this에 연관된 CrossOriginStorageManager.

각 CrossOriginStorageManager 객체에는 연관된 출처가 있으며, 다음으로 설정됩니다. this의 관련 설정 객체의 출처입니다. 또한 연관된 파티션이 있으며, 다음 COS 파티션으로 설정됩니다. this의 관련 설정 객체에 대한 파티션이며, 객체가 생성될 때 설정됩니다.

참고: 출처를 다음에서 가져오고, 관련 설정 객체에서 가져오며, 스크립트 자체의 어떤 사항과도 독립적이라는 점은 워커에 대해 명시할 만한 결과를 갖습니다. blob: URL에서 생성된 워커는 출처가 자신을 생성한 컨텍스트의 출처와 같으므로, 해당 출처가 보는 교차 출처 저장소의 범위를 정확히 공유합니다. 이러한 워커가 기록한 것은 생성 페이지에서 다시 읽을 수 있고, 페이지가 저장한 것은 워커에서 읽을 수 있습니다. blob: URL은 자체 출처가 아니며, 이를 해제해도 워커가 해당 범위에서 분리되지는 않습니다. data: URL에서 생성된 워커에는 다음과 같은 불투명 출처가 있습니다. 이 명세는 현재 다음 메서드가 getFileHandle() 호출 출처가 불투명할 때 어떻게 동작하는지 정의하지 않습니다. 다음의 출처 규칙은 COS 요청 검증의 규칙이며, 호출자가 명시하는 출처만 제어합니다. 불투명 출처에는 다음의 키로 삼을 안정적인 식별자가 없습니다. 저장한 출처 또는 동일 사이트 비교에 사용할 식별자가 없으므로, 의미 있게 부여할 허가가 없습니다.

3.1. getFileHandle() 메서드

3.2. 파일 읽기

3.3. 파일 생성 및 쓰기

FileSystemFileHandle이 다음에 의해 생성되면, 생성 요청 완료에 의해 생성되면, 연관된 요청된 출처를 갖습니다. 이 값은 검증 및 저장에서 항목의 다음 값을 확장할 대상으로 사용합니다. 출처 목록을 해당 값으로 확장하는 시점은 핸들을 통한 쓰기가 성공한 이후입니다.

모든 FileSystemFileHandle은 다음을 가리키는 경우, 교차 출처 저장소 파일 시스템을 가리키는 경우, 다음도 연관된 값으로 갖습니다. COS 해시는 COS 해시로, 해당 핸들이 가리키는 해시입니다. 또한 연관된 COS 출처는 다음 출처로, 핸들을 얻은 출처입니다. 또한 연관된 읽기 허용 여부 불리언은 다음 메서드가 getFile() 해당 핸들을 통해 대상 항목의 바이트를 공개할 수 있는지 결정합니다. 다음에서 반환된 핸들에서는 true입니다. 읽기 요청 완료로 반환된 핸들은 이미 가용성 제한을 통과했습니다. 반면 다음에서 반환된 핸들에서는 false입니다. 생성 요청 완료로 반환된 핸들에서는 검증 및 저장이 바로 그 핸들에 대해 성공할 때까지 false입니다.

참고: 핸들이 가리키는 것은 COS 해시이며, COS 항목이 아닙니다. 생성 요청 완료는 다음에 항목이 없고, COS 레지스트리에 항목이 없으며, 앞으로도 생기지 않을 수 있는 해시에 대한 핸들을 반환합니다. 따라서 다음이 항목을 생성할 때까지 참조할 항목이 없습니다. 검증 및 저장이 항목을 생성합니다.

참고: 이는 의도적으로 각 핸들의 속성으로 정의됩니다. 생성 요청은 해당 해시의 항목이 이미 존재하는지와 관계없이 핸들을 반환합니다(다음 참조. 생성 요청 완료). 따라서 항목별 규칙을 사용하면 어떤 출처든 다음을 호출하여 getFileHandle() 다음을 전달하고, create: true를 전달하고, 자신이 기록하지 않은 항목을 즉시 읽어서 내용을 알아낼 수 있습니다. 이때 출처 목록, PHL 포함 여부 또는 GREASE 적용 조건을 충족하지 않아도 됩니다. 이 명세의 모든 공개 제어는 읽기 경로에 적용되므로, 항목별로 제한하면 생성 요청이 모든 제어를 우회할 수 있습니다. 호출자가 먼저 올바른 바이트를 제공하도록 요구하면, 생성으로 얻은 핸들을 통한 읽기가 성공해도 호출자가 이미 갖고 있지 않은 정보는 공개되지 않습니다.

다음 FileSystemWritableFileStream이 다음을 호출하여 얻어진 경우, createWritable()을 호출한 핸들의 로케이터가 다음을 가리키는 경우, 교차 출처 저장소 파일 시스템을 가리키며, 스트림이 닫히면 [FS], 사용자 에이전트는 반드시 다음 검증 및 저장 단계를 해당 핸들을 전달하여 실행해야 합니다. 이는 닫기 작업의 프로미스가 이행되기 전이어야 합니다.

참고: 이는 닫기가 어떤 방식으로 시작되었는지와 관계없이 적용됩니다. 명시적인 close() 호출 또는 pipeTo() 호출이 해당 소스의 끝에 도달한 경우이며, 후자는 기본적으로 대상도 닫습니다. [STREAMS]는 스트림이 닫히는 시점에 이 둘을 구분하지 않으며, 이 알고리즘도 마찬가지입니다.

createWritable()을 다음 FileSystemFileHandle에서 호출할 때, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키면, 반드시 FileSystemWritableFileStream을 생성해야 하며, 그 내용은 처음에 비어 있어야 합니다. 이는 keepExistingData의 값과 관계없으며, 대상 COS 해시가 다음에 항목을 갖는지와도 관계없습니다. COS 레지스트리.

참고: [FS]는 다른 경우에 keepExistingData가 다음을 수행하도록 정의합니다. 기존 파일의 내용으로 스트림을 초기화합니다. 여기서 이를 따르면 호출자는 저장한 출처가 될 수 있으며, 자신이 가진 적 없는 바이트에 대해서도 그렇게 될 수 있습니다. 생성 요청은 항목이 이미 존재하는지와 관계없이 핸들을 반환하므로, 호출자는 다른 출처가 저장한 해시에 대해 쓰기 가능한 스트림을 열고, 아무것도 기록하지 않은 채 닫아서, 이어받은 바이트의 해시가 요청한 값과 일치하도록 할 수 있습니다. 그러면 다음에 따른 확인 없이 읽기 접근 권한을 얻게 됩니다. 출처 목록, 공개 해시 목록 및 GREASE 적용을 확인하지 않게 되며, 이는 가용성 제한을 우회하는 방법이 개별적으로 허용된 두 작업의 조합으로 만들어지는 것입니다. 같은 이유로 검증 및 저장은 모든 생성 요청에서 전체 내용을 요구합니다.

참고: 따라서 아무것도 기록하지 않고 닫은 쓰기 가능한 스트림은 빈 바이트 시퀀스를 가지며, 이는 호출자가 원하는 어떤 항목에서도 요청한 해시 값과 일치하지 않을 것이므로, 검증 및 저장은 다음 오류로 거부합니다. "DataError" DOMException 으로 거부하며, 다른 모든 불일치와 같습니다. 구현이 이 경우 대신 저장소 또는 I/O 실패를 보고하면, 검증 결과를 관련 없는 오류 뒤에 숨기게 됩니다.

파일 시스템 표준 [FS]은 아직 종속 명세가 쓰기마다 수행할 추가 검증을 다음에 연결할 확장 지점을 정의하지 않습니다. FileSystemWritableFileStream의 닫기 단계에 연결할 지점입니다. 이러한 훅이 마련되기 전까지 이 절은 필요한 동작을 직접 설명합니다. 향후 개정에서는 다음과 정식으로 통합될 것으로 예상됩니다. [FS].

3.4. 가져온 리소스 저장

다음에 나열된 호스트 통합은 § 9 다른 명세와의 통합에 나열되어 있으며, 자신이 가져온 리소스를 다음을 거치지 않고 저장합니다. FileSystemFileHandle. 해당 호스트 명세는 가져온 바이트가 해당 통합에서 요구하는 무결성 검사를 통과한 후 다음 알고리즘을 실행할 것으로 예상됩니다.

참고: 다음과 마찬가지로, 검증 및 저장과 마찬가지로, 저장에는 항상 전체 바이트가 필요하며, 항목이 이미 "written"인 경우도 포함되므로, 이전의 존재 여부에 관한 정보는 드러나지 않습니다. 통합에서의 조회는 네트워크에서 가져오기 전에 이루어지는 읽기이며, 가용성 제한과 § 8.2 교차 사이트 탐색의 탐색 관련 고려 사항이 적용됩니다.

3.5. 리소스 가시성 확장

COS 항목의 가시성은 확장할 수 있지만 축소할 수는 없습니다.

참고: 확장은 다음에 추가하거나, 출처 목록에 추가하거나, 다음을 전역적으로 공개 가능을 true로 설정하기만 합니다. 쓰기 주체가 리스트를 요청하면, 항목이 이미 전역적으로 공개 가능하더라도, 그렇지 않은 항목과 마찬가지로 가시성을 확장합니다. 두 허가는 독립적이기 때문입니다. 새로 나열된 출처들은 PHL과 독립적인 접근 권한을 얻으며, "*" 허가도 계속 유효합니다.

참고: 최초 저장자 이외의 사이트를 포함하여 어떤 사이트든 항목의 출처 목록을 확장할 수 있습니다. 단, 제공한 바이트의 해시가 항목의 해시와 같아야 합니다. 이는 의도된 동작입니다. 해시에 해당하는 올바른 바이트를 이미 가진 사이트는, 구조상 그 해시가 무엇을 나타내는지에 관해 최초 저장자와 동등한 권위를 갖습니다.

3.5.1. 최초 저장자의 접근

출처가 다음을 성공적으로 완료한 경우, 쓰기를 성공적으로 완료한 대상이 COS 항목인 경우(즉, 해당 항목의 다음 허가 중 어느 것의 출처인 경우, 허가가 항목의 저장한 출처에 속하는 경우), 언제든 이후 다음을 통해 해당 항목의 핸들을 얻을 수 있습니다. getFileHandle()을 사용하며, 동일한 최상위 사이트에서 수행합니다. 이는 항목의 출처 목록 값과 관계없으며, 해당 항목의 해시가 PHL에 포함되는지와도 관계없습니다. 이는 Cache API의 모델을 따르며, 이 모델에서는 출처가 자신이 저장한 것에 항상 접근할 수 있고, 저장소 분할이 Cache API의 키에도 최상위 사이트를 사용한다는 점까지 같습니다. 다른 최상위 사이트에서는 해당 출처도 다른 출처와 같은 방식으로 항목을 읽습니다.

4. 교차 출처 저장소 파일 시스템

교차 출처 저장소 파일 시스템은 파일 시스템 루트이며, 모든 출처의 버킷 파일 시스템 또는 로컬 파일 시스템 접근 루트와 구분됩니다. 그 항목이 일대일로 대응하는 대상은 COS 레지스트리의 COS 항목들입니다.

교차 출처 저장소 파일 시스템은 [FS]의 일반적인 호출별 권한 검사 모델을 사용하지 않습니다. 모든 FileSystemFileHandle은 여기서 얻어질 때 이미 다음에 따라 완전히 승인되었으며, § 3.2 파일 읽기 또는 § 3.3 파일 생성 및 쓰기에 따라 스크립트로 반환되기 전에 승인됩니다. 따라서 getFile() 또는 createWritable()을 이러한 핸들에서 호출해도 추가 권한 요청 창이 표시되지 않습니다.

이러한 핸들의 queryPermission() 및 requestPermission()이 절대 보고해서는 안 되는 값은 "prompt"입니다. 권한 요청 창이 표시될 수 없기 때문입니다. 쓰기 모드에서는 반드시 "denied"를 보고해야 하는데, 해당 핸들이 생성 요청으로 얻어진 것이 아닌 경우에 해당하며, "granted"를 보고해야 하는 경우는 그 외의 경우입니다.

createWritable()을 다음 FileSystemFileHandle에서 호출할 때, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키고, 다음을 통해 얻어진 것이 아니면, 생성 요청으로 얻어진 것이 아니면, 반드시 "NotAllowedError" DOMException으로 거부해야 하며, FileSystemWritableFileStream을 생성해서는 안 됩니다.

참고: 쓰기는 핸들에 실제로 없을 수 있는 유일한 기능입니다. 생성 요청만이 쓰기를 수행할 수 있는 핸들을 제공하므로, 다른 핸들의 쓰기 모드에 "granted"를 보고하면 다음 메서드가 거부하는 기능을 있다고 주장하게 됩니다. createWritable()이 거부하는 기능입니다. 읽기는 계속 "granted"입니다. 읽기 가능한 핸들을 가진 호출자는 이를 통해 읽을 수 있기 때문입니다. 권한 요청으로도 변경할 수 없는 것은 이 두 응답 모두입니다. 표시할 권한 요청 창도 없고 허가를 기록할 상태도 없기 때문입니다.

getFile()을 다음 FileSystemFileHandle에서 호출할 때, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키고, 그 읽기 허용 여부가 false이면 반드시 "NotAllowedError" DOMException으로 거부해야 합니다. 여기에는 서로 다른 두 경우가 포함됩니다:

• 생성 요청에서 얻었지만 아직 쓰기를 수행하지 않은 핸들이며, 대상 해시에 해당하는 항목이 COS 레지스트리에 없는 경우입니다. 검증된 바이트가 없어 반환할 수 없으며, 호출자가 자신의 미완료 쓰기를 마치 파일의 실제 내용인 것처럼 관찰할 수 있어서는 안 됩니다.

• 어떤 다른 출처가 이미 기록한 해시에 대해 생성 요청으로 얻은 핸들입니다. 검증된 바이트는 존재하지만, 이 호출자는 이를 제공하지 않았고 가용성 제한도 통과하지 않았으므로, 항목에 관해 아무것도 알아서는 안 되며, 심지어 존재 여부조차 알아서는 안 됩니다.

참고: 두 경우의 거부는 동일하므로 아무 정보도 공개하지 않습니다. 따라서 "NotAllowedError" 는 읽기 경로에서 의도적으로 피하는 오류이지만 여기서는 안전합니다. 이 핸들은 호출자가 자신의 생성 요청으로 얻은 것이며, 핸들을 다른 출처에서 역직렬화할 수 없기 때문입니다(§ 4.1 핸들 전송 참조). 따라서 응답은 출처 경계를 넘지 않으며, 레지스트리의 내용과 관계없이 일정합니다. § 8.3 진행 중인 쓰기와 비교해 보세요. 여기서는 읽기 경로의 별도 오류가 그 경계를 넘었을 것입니다.

핸들의 읽기 허용 여부가 true이면, getFile()을 해당 핸들에서 호출하면 File을 반환하며, 그 내용은 대상 항목의 바이트입니다. 이는 정확히 다음 동작입니다. [FS]가 이미 정의한 동작이며, 파일 항목의 이진 데이터가 해당 바이트인 경우입니다.

FileSystemFileHandle이 다음을 가리키면, 교차 출처 저장소 파일 시스템을 가리키면, 다음을 갖습니다. 파일 시스템 로케이터의 경로는 리스트이며, 다음 하나의 문자열을 포함합니다. 해당 핸들의 COS 해시의 값이며, 로케이터의 루트는 다음 교차 출처 저장소 파일 시스템입니다.

참고: [FS]가 정의하는 name은 핸들의 로케이터 경로에서 마지막 경로 구성 요소이므로, 다음 값도 정해집니다. name: 그 값은 해시입니다. 항목에는 자체 이름이 없으며, 해시만이 유일한 식별자이므로, 이를 보고하면 빈 문자열이었다면 버렸을 정보를 전달할 수 있습니다.

항목에는 이름도 포함 디렉터리도 없으므로, [FS]의 구조 관련 기능 대부분에는 적용할 대상이 없습니다. 동일성은 예외이며, 콘텐츠 주소 지정 항목이 항상 답할 수 있는 유일한 질문입니다. COS 레지스트리는 최대 하나의 COS 항목을 각 COS 해시마다 가지므로, 두 핸들의 해시가 같을 때, 그리고 그때에만 두 핸들이 같은 항목을 가리킵니다.

isSameEntry()을 다음 FileSystemFileHandle에서 호출할 때, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키고, 인수 역시 같은 파일 시스템을 가리키며 동일한 출처에서 얻어졌다면, 두 핸들의 COS 해시 항목이 동일하면 반드시 true를, 그렇지 않으면 false를 반환해야 합니다.

참고: 이를 거부하면 사용자 에이전트가 이미 가진 정보를 버리게 됩니다.

isSameEntry()을 다음 FileSystemFileHandle에서 호출할 때, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키고, 인수가 호출하는 출처에서 얻어진 것이 아니거나, 다음이 아닌 다른 파일 시스템을 가리키는 경우, 교차 출처 저장소 파일 시스템이 아닌 경우, 반드시 다음으로 거부해야 합니다. "NotAllowedError" DOMException. 다른 파일 시스템을 가리키는 핸들, 예를 들어 다음이 getDirectory() 반환하는 핸들은 [FS]가 정의하는 동작을 유지합니다. 호출 시 FileSystemFileHandle이 다음을 가리키는 상태로, 교차 출처 저장소 파일 시스템을 가리키는 상태로 인수로 전달되어도 마찬가지입니다.

참고: 이 경우 false를 반환하면 두 핸들이 서로 다른 항목을 가리킨다고 단정하게 되며, 이는 호출 출처가 검사할 권한이 없는 핸들에 관한 주장입니다. 거부는 비교할 수 없었다는 사실만 나타냅니다.

move() 및 remove()을 다음에서 호출할 때, FileSystemFileHandle이 다음을 가리키면, 교차 출처 저장소 파일 시스템을 가리키면, 반드시 "NotAllowedError" DOMException으로 거부해야 하며, 대상 항목을 변경하지 않아야 합니다.

참고: 항목은 다음에 속하는 모든 출처가 공유합니다. 저장한 출처가 공유하므로, 제거를 허용하면 한 사이트가 다른 사이트들이 의존하는 데이터를 파괴할 수 있습니다. 삭제는 축출 및 사용자 자신의 저장소 제어에 맡겨집니다. 이름 변경이나 부모 변경은 적용할 대상이 없습니다. 항목의 이름은 해당 COS 해시이며, 포함 디렉터리가 없기 때문입니다.

참고: 두 메서드 모두 다음에서 정의하지 않으며, [FS]에서도 파일 시스템 접근 API에서도 작성 시점에는 정의하지 않습니다 (WICG/file-system-access#214). 따라서 오류 이름은 다음을 따릅니다. removeEntry()는 [FS]가 실제로 항목 삭제를 위해 정의하는 작업이며, 읽기 및 쓰기 접근이 허용되지 않으면 접근 결과의 오류 이름으로 거부합니다. 여기서는 거부가 정확한 동작입니다. 해당 작업들은 의미가 있지만 허용되지 않습니다.

createSyncAccessHandle()에는 별도 규칙이 필요하지 않습니다. 해당 단계는 다음으로 거부합니다. "InvalidStateError" DOMException으로, 핸들이 다음에 속하지 않을 때마다 거부합니다. 버킷 파일 시스템에 속하지 않는 경우이며, 교차 출처 저장소 파일 시스템은 파일 시스템 루트로, 모든 출처의 루트와 구분되므로, [FS]가 이미 거부 여부와 오류 이름 모두를 결정합니다.

참고: 이는 이 명세가 독립적으로도 원하는 결과입니다. FileSystemSyncAccessHandle은 호출자에게 쓰기 가능한 파일 디스크립터를 제공하며, 이를 통해 호출자는 항목의 바이트를 해당 바이트가 저장된 키인 COS 해시와 무관하게 변경할 수 있게 됩니다. 그리고 항목이 공개 가능한 다른 모든 출처도 바로 그 바이트를 읽습니다.

4.1. 핸들 전송

FileSystemFileHandle은 직렬화 가능한 객체입니다. [FS]에 따라, 다음을 가리키는 핸들은 COS 항목을 가리키는 핸들은 다른 환경 설정 객체로 전달할 수 있습니다. 예를 들면 postMessage(message, options)을 사용합니다. 이는 이러한 핸들을 얻는 두 번째 방법이며, 다음과 함께 사용할 수 있으므로, getFileHandle()과 함께 사용할 수 있으므로, 여기서도 제약합니다.

직렬화 단계는 다음 FileSystemFileHandle에 대해, 해당 핸들이 교차 출처 저장소 파일 시스템을 가리키는 경우, 주어진 value 및 serialized에 대해 다음을 추가로 수행합니다:

1. serialized.[[COSHash]]를 value의 COS 해시로 설정합니다.

2. serialized.[[COSOrigin]]을 value의 COS 출처로 설정합니다.

3. serialized.[[COSMayRead]]를 value의 읽기 허용 여부로 설정합니다.

역직렬화 단계는 주어진 serialized, value 및 realm에 대해 다음을 추가로 수행합니다:

1. serialized.[[COSOrigin]]이 동일 출처 관계를 realm의 환경 설정 객체의 출처와 만족하지 않으면, "DataCloneError" DOMException을 던집니다.

2. value의 COS 해시를 serialized.[[COSHash]]로 설정합니다.

3. value의 COS 출처를 serialized.[[COSOrigin]]으로 설정합니다.

4. value의 읽기 허용 여부를 serialized.[[COSMayRead]]로 설정합니다.

참고: 다음의 동일 출처 검사가 없으면, 전송을 통해 이 명세의 모든 공개 제어를 한 번에 무력화할 수 있습니다. 핸들의 읽기 허용 여부가 true이면 이미 다음을 통과한 것입니다. 가용성 제한 적용을 요청한 출처에 대해 통과한 것이므로, 이를 다른 출처로 보내면 해당 출처에 항목의 바이트가 전달되면서도 출처 목록, PHL 포함 여부 또는 GREASE 적용이 해당 출처에 대해 평가되지 않습니다. 이는 파일 시스템 표준의 기존 핸들 처리 방식과 일치하며, 이 역시 동일 출처 수신자에게만 유용합니다.

참고: 읽기 허용 여부는 핸들과 함께 전달되므로, 쓰기를 수행하지 않은 생성 요청 핸들은 전송 후에도 읽을 수 없으며, 읽기 요청 핸들은 제한을 다시 적용하지 않고 계속 읽을 수 있습니다. 도착 시 제한을 다시 적용하면 호출자가 같은 핸들을 전송하여 가용성을 반복적으로 탐색할 수 있습니다.

참고: 원본 핸들을 통해 쓰기가 이루어지기 전에 복제된 핸들은 계속 읽을 수 없습니다. 그 보유자는 create 없이 getFileHandle()을 호출하여 원래 저장자에게 부여된 권한을 통해 읽을 수 있는 핸들을 얻을 수 있습니다.

5. 저장소 관리

5.1. 저장소 한도

사용자 에이전트는 반드시 다음 출처가 다음에 제공할 수 있는 총 바이트 수에 COS 레지스트리에 성공한 쓰기를 통해 제공할 수 있는 총량에 한도를 설정해야 합니다. 이는 단일 출처가 캐시를 채워 다른 출처의 항목을 축출하려고 시도하는 것을 방지합니다. 구체적인 한도는 구현 정의입니다. 출처의 쓰기가 해당 한도를 초과하게 되면, 사용자 에이전트는 반드시 거부해야 합니다. 해당 쓰기를 "QuotaExceededError" DOMException으로 거부하고, 다음에 경고를 기록하는 것이 좋습니다. 콘솔에 기록합니다.

참고: 항목은 콘텐츠 주소 지정 방식이므로, 출처가 같은 해시에 같은 바이트를 반복해서 기록해도 첫 번째 성공한 쓰기 이후에는 추가 할당량을 소비하지 않습니다. § 2.2 COS 항목을 참조하세요.

사용자 에이전트에는 또한 구현 정의 최대 출처 목록 길이가 있습니다. 이는 양의 정수로, 다음 출처의 수를 제한합니다. 하나의 출처 목록 리스트가 포함할 수 있는 수입니다. 이 한도는 리스트가 처음 제공될 때(다음 참조. COS 요청 검증) 그리고 이후 기존 항목에 병합될 때 모두 적용됩니다(다음 참조. 리소스 가시성 확장). 따라서 단일 호출이나 시간에 걸친 여러 호출의 누적 효과로 항목의 출처 목록이 무제한으로 증가할 수 없습니다. 메모리 사용량을 제한할 뿐 아니라, 출처 리스트가 다음과 같이 사용되는 것도 방지합니다. 즉, "*"의 암묵적인 대체 수단으로 사용되는 것을 방지합니다. § 8.2 교차 사이트 탐색을 참조하세요.

이 두 위치에서는 한도 초과를 서로 다르게 처리합니다. 두 호출이 작업 과정에서 매우 다른 시점에 발생하기 때문입니다:

• COS 요청 검증에서는 어떤 파일도 가져오거나 해시를 계산하거나 기록하기 전에 한도를 확인합니다. 한도를 초과한 호출자는 즉시 "TypeError" 를 받으며, 다른 작업은 수행되지 않습니다. 이는 잘못된 형식의 다른 origins 값과 같은 처리입니다.

• 리소스 가시성 확장에서는 한도에 도달할 수 있는 원인이 다음의 누적 효과뿐입니다. 독립적인 별도 쓰기 호출에 걸쳐 요청된 출처들의 누적 효과이며, 서로 관련 없는 출처들이 오랜 시간 동안 요청했을 수도 있습니다. 또한 이 호출의 바이트를 이미 해시 계산하고, 검증하고, 영구 저장한 후에만 확인합니다. 그 시점에 쓰기를 거부하면 성공했고, 이미 검증되었으며, 잠재적으로 매우 큰 쓰기를 관련 없는 관리 한도 때문에 버리게 되며, 단일 호출자의 실수로 볼 수도 없습니다. 따라서 쓰기는 성공한 상태로 두고, 용량을 초과하는 출처들만 다음에서 제외합니다. 출처 목록에서 제외하고, 콘솔에 경고를 기록합니다. 이는 기존의 다음 요청 처리 방식과 같습니다. 허용 범위가 넓은 상태에서 더 제한된 상태로의 요청입니다. 출처 요청을 완전히 반영할 수 없으면 별도 오류 없이 상한을 적용하고, 이를 포함한 쓰기는 여전히 성공합니다. 이 명세의 다른 부분에 있는 § 8.4 가용성 제한과 일관되게, 호출자는 자신이 요청한 출처가 실제로 추가되었는지 사후에 확실히 확인할 방법이 없습니다. 이후 getFileHandle()을 해당 출처에서 호출해도, 출처가 추가되었더라도 실패할 수 있기 때문입니다(예를 들어 항목이 축출되거나 사용자 에이전트가 요청을 제한한 경우). 따라서 그 결과를 어느 쪽이든 확인하는 증거로 해석해서는 안 됩니다.

5.2. 축출

이 절은 비규범적입니다.

저장 공간이 부족하면 사용자 에이전트는 항목을 다음에서 축출할 수 있습니다. COS 레지스트리에서 축출하며, 예를 들어 다음에 걸쳐 최근 최소 사용 정책을 적용할 수 있습니다. 저장한 출처 중 각 항목에 가장 최근에 접근한 출처들을 기준으로 합니다. 사용자 에이전트는 설정 UI를 제공할 것으로 예상되며, 이를 통해 사용자는 저장된 파일과 각 파일에 접근한 출처들을 확인하고, 수동으로 항목을 삭제하거나 모든 교차 출처 저장소 데이터를 지울 수 있습니다.

사용자가 출처의 사이트 데이터를 지우면, 사용자 에이전트는 다음 조건의 모든 허가를 제거하는 것이 좋습니다. 출처가 해당 출처인 허가를 모든 저장한 출처 집합에서 제거합니다. 제거한 후 COS 항목의 저장한 출처가 비어 있으면, 사용자 에이전트는 해당 항목을 삭제 대상으로 고려할 수 있습니다.

5.3. 수동으로 추가한 항목

이 절은 비규범적입니다.

위에서 설명한 설정 UI는 사용자가 이미 디스크에 가진 파일을 교차 출처 저장소에 직접 추가할 수 있게 할 수 있습니다(예를 들어, 어떤 웹사이트와도 관계없이 다운로드한 AI 모델). 이때 어떤 스크립트도 다음을 호출하지 않습니다. getFileHandle(). 이러한 항목에는 요청한 출처가 없어 쓰기를 귀속시킬 수 없으므로, 다음 두 가지 질문이 생깁니다. 명령형 API 자체로는 답할 수 없는 질문입니다:

• 다음 절에서 말하는 최초 저장자는 누구일까요? § 3.5.1 최초 저장자의 접근의 관점에서는 아무도 아닙니다. 항목의 저장한 출처는 처음에 비어 있습니다. 따라서 어떤 출처도 일반적인 가용성 제한 및 출처 목록 검사에서 면제되지 않으며, 모든 요청 출처에 적용되는 검사를 받아야 합니다. 이는 올바른 결과입니다. 어떤 출처도 실제로 바이트를 기록하지 않았기 때문입니다.

• 이러한 항목도 다음을 생략한 일반 쓰기처럼 동일 사이트로만 제한해야 할까요? origins를 생략한 경우와 같아야 할까요? 아닙니다. "동일 사이트"는 요청 출처를 기준으로만 의미가 있으며, 수동 추가에는 요청 출처가 없으므로 "동일 사이트"가 의미할 사이트도 없습니다. 사용자 에이전트는 이러한 항목을 전역적으로 공개 가능하게 만들고, 명시적인 출처 목록 리스트는 비워 둘 것으로 예상됩니다. 파일을 수동으로 미리 추가하는 것은 다른 출처가 실제로 이를 발견할 수 있을 때에만 목적을 달성하기 때문입니다(사용자가 아직 방문하지 않은 사이트가 사용자의 디스크에 이미 있는 파일을 재사용하게 하는 목적). 사용자 에이전트의 설정 UI는 사용자가 더 좁은 범위를 선택할 수 있는 기능도 제공할 수 있습니다.

이렇게 추가된 항목은 그 외에는 구분할 수 없습니다. 웹사이트가 다음을 통해 기록한 항목과 구분할 수 없습니다. getFileHandle(): 동일한 가용성 제한 및 가시성 확장 규칙이 적용되며, 같은 허가를 갖는 다른 항목과 정확히 같습니다. 여기에는 PHL에 포함되는지 확인하는 검사도 포함되며, 항목이 결과적으로 전역적으로 공개 가능해질 때마다 적용됩니다. 이는 수동 추가의 기본값입니다.

5.4. 출처 메타데이터

이 절은 비규범적입니다.

COS 항목은 의도적으로 바이트를 어디서 가져왔는지에 관한 정보를 기록하지 않습니다. 식별자는 해시뿐입니다. 같은 바이트는 이를 저장한 출처의 수나 가져온 URL의 수와 관계없이 같은 항목입니다(§ 2.2 COS 항목 참조). URL은 한 쓰기 주체의 가져오기 작업에 속하는 속성이므로, 여러 출처가 기록한 항목에서 하나를 선택할 비임의적인 방법은 없습니다. 바이트처럼 검증할 수도 없습니다(§ 8.1 리소스 무결성 참조). 또한 URL은 사용자의 탐색에 관해 훨씬 많은 정보를 담습니다. 대략적인 출처 값이 다음에 담는 정보보다 많습니다. 저장한 출처의 값과 달리, 경로나 쿼리 문자열은 특정 문서, 계정 또는 세션을 지정할 수 있기 때문입니다. 따라서 이를 항목에 기록하면 엔트로피가 높은 신호가 다음의 공개 제한을 우회하게 됩니다. 출처 목록 및 § 8.4 가용성 제한이 적용하려는 제한입니다.

그럼에도 이를 원하는 동기는 실제로 존재합니다. 사용자가 § 5.2 축출에서 설명한 설정 UI에서 수 기가바이트 파일을 보거나, 개발자가 getFileHandle() 호출이 적중하지 않은 이유를 디버깅할 때, 둘 다 파일이 어디서 왔는지 알고 싶어 합니다. 사용자 에이전트는 구현 내부 전용 출처 기록을 유지하여 이를 지원할 수 있습니다. 항목과 함께 유지하는 기록이며(예를 들어 각 저장한 출처가 해당 바이트를 가져온 URL과 시점), 단 해당 기록을 다음 항목 외부에 보관되는 사용자 에이전트 상태로 취급해야 합니다. 항목 자체와 분리해야 합니다:

• 스크립트에 노출되지 않습니다. 이 명세의 어떤 기능도 이를 공개하지 않으며, 이후 추가되는 기능도 공개하지 않는 것이 좋습니다. 다음도 마찬가지입니다. getFileHandle() 또는 그것이 반환하는 FileSystemFileHandle은 이러한 기록의 존재 여부를 드러내지 않는 것이 좋으며, 내용은 더더욱 드러내지 않는 것이 좋습니다. 특히 요청하는 출처가 다음 기록을 관찰할 수 있어서는 안 됩니다. 자신이 직접 생성하지 않은 기록입니다.

• 신뢰할 수 있는 웹 외부 인터페이스를 통해서만 표시됩니다. 사용자 에이전트 자체의 설정과 저장소 검사 UI, 개발자 도구 및(사용자 에이전트에 확장 프로그램 플랫폼이 있는 경우) 사용자가 명시적으로 부여한 권한으로 제한되는 확장 프로그램 API이며, 이는 다른 탐색 기록 공개 API와 같은 기준을 따릅니다. 다음을 참조하세요. 브라우저 확장 프로그램 통합 지점 설명서는 이 저장소에 있으며, 고려 중인 확장 프로그램 인터페이스를 설명합니다.

• 검증되지 않은 정보이며, 그렇게 표시됩니다. 그 안의 URL은 바이트를 기록한 출처의 주장입니다. 오직 해시만이 내용을 보장합니다(§ 8.1 리소스 무결성 참조). 두 출처가 같은 항목에 대해 서로 다른 URL을 기록할 수 있으며, 어느 쪽이든 부정확하거나 의도적으로 오해를 유발할 수 있습니다.

• 항목 및 기록이 귀속되는 출처와 수명을 공유합니다. 항목이 축출되거나 삭제되면 기록을 버리며, 출처에 귀속되는 부분은 해당 출처의 허가가 다음에서 제거될 때 버립니다. 저장한 출처에서 제거되는 경우이며, 사용자가 해당 출처의 사이트 데이터를 지우는 경우도 포함됩니다(§ 5.2 축출 참조).

이러한 기록은 콘텐츠에서 볼 수 없으므로, 사용자 에이전트가 이를 유지할지와 얼마나 유지할지는 전적으로 구현에 맡깁니다. 이 명세의 어떤 부분도 이에 의존하지 않으며, 사이트는 기록의 존재 여부를 감지할 수 없습니다.

6. 권한 정책 통합

이 명세는 문자열 "cross-origin-storage"로 식별되는 정책으로 제어되는 기능 [permissions-policy]을 정의한다. 기본 허용 목록은 self이다. 워커용 Permissions Policy [WORKERS-PERMISSIONS-POLICY]의 정의에 따르면 이 기능은 서비스 워커에서 활성화할 수 없다.

이 절은 워커용 Permissions Policy [WORKERS-PERMISSIONS-POLICY]를 이미 [permissions-policy]와 [HTML]의 일부인 것처럼 사용한다. 이 제안은 설명 문서이며, 어떤 명세도 워커 정책, SharedWorker의 allow 옵션 또는 이 절에서 언급하는 "서비스 워커에서 활성화할 수 있음" 불리언을 정의하지 않는다. 작성 시점에 Chromium은 공유 워커 부분을 PermissionsPolicyForSharedWorkers 플래그 뒤에서 구현하지만 정식 제공하는 엔진은 없다. 해당 작업이 명세화되면 이 절은 훅을 직접 설명하는 대신 호출해야 한다.

[permissions-policy]는 Document에 대해 사용 허용을 정의하지만, CrossOriginStorageManager는 자체 Document를 갖지 않는 WorkerGlobalScope에도 노출된다. 따라서 이 검사는 호출하는 전역 객체에 대해 [WORKERS-PERMISSIONS-POLICY]에 따라 기술된다. 전용 워커는 이를 전이적으로 소유하는 Document의 정책을 상속하고, 공유 워커는 자체 정책을 가지며, 서비스 워커는 이 기능을 활성화할 수 없다.

전역 객체에 대해 이 알고리즘이 false를 반환하면, 해당 객체에서 이루어지는 모든 getFileHandle() 호출은 다음으로 거부됩니다. "NotAllowedError" DOMException으로 거부되며, 이는 해시 검증, 레지스트리 조회 또는 쓰기가 수행되기 전입니다.

참고: 다음을 통해 추적하는 이유는 소유자 집합을 통해 추적하는 이유는 이 기능의 비활성화가 이름뿐인 것이 되지 않도록 하기 위해서입니다. blob: URL로 생성된 워커는 생성 페이지의 출처에서 실행되며, 해당 페이지가 보는 교차 출처 저장소의 범위를 정확히 공유합니다(다음 참조. § 3 CrossOriginStorageManager 인터페이스). 따라서 전역 객체 자체의 Document만 확인하는 검사는 모든 워커에서 공허하게 충족되며, 호출을 다음으로 옮기면 new Worker(URL.createObjectURL(…))로 옮기면 cross-origin-storage=() 정책을 벗어날 수 있습니다. 그 외에는 아무것도 변경하지 않고도 가능합니다.

참고: 서비스 워커는 교차 출처 저장소를 사용할 수 없다. "cross-origin-storage"는 서비스 워커에서 활성화할 수 있는 기능이 아니기 때문이다 [WORKERS-PERMISSIONS-POLICY]. 이는 모든 정책 제어 기능의 기본값이며 교차 출처 저장소도 이를 유지한다. 서비스 워커의 등록은 지속되고 사용자 에이전트는 이벤트에 응답하여 이를 시작한다. 하나의 실행 중인 서비스 워커가 정책이 서로 다를 수 있는 여러 클라이언트에 서비스를 제공하므로, 정책을 참조할 수 있는 단일 Document는 없다. API는 그곳에서도 노출되므로 호출은 이 알고리즘이 거부하는 다른 호출과 마찬가지로 "NotAllowedError"로 거부된다. explainers-by-googlers/workers-permissions-policy#4도 참조한다.

참고: SharedWorkerGlobalScope의 소유자 집합은 서로 다른 정책을 가진 여러 Document를 포함할 수 있으며, 워커 수명 동안 소유자가 추가되거나 제거된다. 생성 시 고정된 워커 자체 정책을 참조하면 두 번의 getFileHandle() 호출 사이에 결과가 안정적으로 유지된다. 이는 옵트아웃을 우회하는 데도 사용할 수 없다. 정책에서 교차 출처 저장소를 비활성화한 문서는 이를 위임할 수 없으므로 해당 기능을 가진 공유 워커를 생성하거나 연결할 수 없다.

7. Cross-Origin-Storage-Allow-Origin 헤더

COS 항목의 출처 목록 리스트가 비어 있지 않으면, 해당 항목은 다음 출처들에 공개될 수 있습니다. 쓰기 출처가 제어하지 않는 출처들입니다. 하지만 그 리스트는 스크립트가 선언하거나(다음을 통해 origins) 마크업이 선언하며, 공격자도 스크립트나 마크업 주입에 성공하면 어느 쪽이든 설정할 수 있습니다. 이 선언을 바이트가 공개되는 출처의 운영자와 연결하고, 주입된 콘텐츠가 위조할 수 없는 형태로 만들기 위해, 이 명세는 그러한 선언이 지정할 수 있는 출처를 제한하는 응답 헤더를 정의합니다.

Cross-Origin-Storage-Allow-Origin 응답 헤더는 다음을 전달합니다. COS 범위 상한은 집합이며, 다음 출처들로 구성됩니다. 쓰기가 동일 사이트 외부의 출처 목록 리스트에 지정할 수 있는 출처들입니다. 바이트를 제공하는 주체가 헤더를 보내므로, 헤더는 다음 응답에서 읽습니다. 공개되는 바이트의 기반이 되는 응답입니다:

• getFileHandle() 쓰기의 바이트는 스크립트에서 생성되어 자체 원본 응답이 없을 수 있다. 이 경우 사용하는 응답은 호출하는 전역 객체의 Document를 생성하는 데 사용된 응답이다. 워커의 경우 직접 또는 다른 워커를 통해 해당 워커를 생성한 Document의 응답이다(COS 범위 상한 얻기 참조).

• 호스트 통합의 경우에는 다음 응답입니다. 바이트가 저장되는, 가져온 리소스의 응답입니다 (다음 참조. 가져온 리소스를 교차 출처 저장소에 저장). 이는 해당 리소스의 서버이며, 다음 Document의 서버와 같을 필요는 없습니다. 해당 문서는 리소스를 로드하는 문서입니다.

선언된 리스트는 교집합을 상한과 취합니다(다음 참조. COS 범위 상한 적용). 따라서 상한은 선언의 범위를 좁히기만 합니다.

참고: 이 헤더는 바이트를 제공하는 측의 승인입니다. 헤더가 지정하는 출처들, 즉 최종 읽기 주체들에게는 확인하지 않으며, 이들은 아무것도 보내지 않습니다. 나열된 출처는 나중에만 참여하며, 다음을 호출합니다. getFileHandle()을 COS 해시에 대해 다른 읽기 주체와 똑같이 호출합니다. 이는 Access-Control-Allow-Origin [FETCH]과 반대 방향으로 작동합니다. 그 경우에는 리소스를 보유한 서버가 특정 출처의 읽기를 허용합니다. 여기서는 바이트 제공자가 나중에 교차 출처 저장소에서 바이트를 읽을 수 있는 주체를 제한하며, 쓰기 페이지에 주입된 콘텐츠는 제공자의 응답 헤더를 설정할 수 없으므로 그 제한을 확장할 수 없습니다.

참고: 이 헤더는 리스트 형식에만 적용됩니다. 동일 사이트 기본값은 교차 출처의 수신 대상을 지정하지 않으므로 승인이 필요하지 않으며, "*" 형식은 읽기 경로에서 가용성 제한의 제어를 받습니다. 이 제한은 공개 해시 목록을 기준으로 하며, 사용자별 비밀은 이 조건을 절대 통과할 수 없으므로, 쓰기 시 상한도 필요하지 않습니다. "*"에 헤더를 요구하면, 별도 설정 없는 전역 공유 사용 사례도 깨뜨리면서 공개 해시 목록이 이미 차단하지 않은 위험을 추가로 차단하지는 못합니다.

모든 Document는 COS 범위 상한을 가지며, 이는 집합 형태의 출처들입니다. 문서가 생성될 때 다음을 실행한 결과로 설정됩니다. COS 범위 상한 파싱에 다음을 전달합니다. 헤더 리스트로, 다음 응답의 리스트입니다. 해당 문서를 생성하는 데 사용된 응답입니다.

모든 WorkerGlobalScope는 출처의 집합인 COS 범위 상한을 가진다. 워커 실행 알고리즘이 워커를 생성할 때, 이 알고리즘에 전달된 외부 설정의 전역 객체를 인수로 COS 범위 상한 얻기를 실행한 결과를 상한으로 설정한다. 전용 워커의 경우 이 전역 객체는 해당 워커를 생성한 객체로, 워커 실행이 사용하는 외부 설정에 대응한다. 공유 워커의 경우 SharedWorker 생성자 호출로 워커를 만든 전역 객체다. 나중에 실행 중인 워커에 연결하는 컨텍스트는 상한을 변경하지 않는다.

참고: 워커는 생성자의 상한을 사용하며 자체 스크립트의 응답에서 상한을 얻지 않는다. blob: 워커는 생성 페이지의 출처 및 교차 출처 저장소 뷰를 정확히 공유한다(§ 3 CrossOriginStorageManager 인터페이스 참조). 또한 해당 응답에는 헤더가 없으므로, 워커 자체에서 상한을 읽으면 모든 blob: 워커의 상한이 비게 된다. 목록으로 범위를 지정한 쓰기를 new Worker(URL.createObjectURL(…))로 옮기면 페이지가 승인한 수신자가 제거된다. 생성 시 상한을 고정하는 것은 교차 출처 저장소 권한 확인과 일치한다. 공유 워커의 정책에는 생성자가 위임한 기능만 포함되므로 컨텍스트가 연결되거나 연결이 해제되어도 두 번의 getFileHandle() 호출 사이에 결과가 유지된다. 공유 워커에 연결할 수 있는 모든 컨텍스트는 워커의 출처를 가진다. 따라서 나중에 연결되고 상한이 더 좁은 컨텍스트도 생성자의 상한을 승인한 동일한 운영자가 실행한다.

Document의 응답에서 해당 COS 범위 상한을 채우려면 [HTML]의 문서 생성 단계에 훅이 필요하다. 이는 [permissions-policy] 및 [CSP]가 응답 처리 시 채워지는 방식과 같다. 해당 훅이 마련되기 전까지 이 절은 필요한 동작을 직접 설명한다. 향후 개정에서는 § 3.3 파일 생성 및 쓰기에서 언급한 [FS] 훅과 함께 이를 공식적으로 통합할 예정이다. WorkerGlobalScope의 COS 범위 상한에도 워커 실행 내의 같은 종류의 훅이 필요하다. 호스트 통합에는 이런 훅이 필요하지 않다. 가져온 응답을 가져온 리소스를 교차 출처 저장소에 저장에 전달하면 이 알고리즘이 응답에서 상한을 읽는다.

8. 개인정보 보호 및 보안 고려 사항

이 절은 RFC 2119 키워드를 사용하는 부분을 제외하면 비규범적입니다. 다음도 참조하세요. 보안 및 개인정보 보호 질문서는 저장소에 있습니다.

8.1. 리소스 무결성

모든 COS 항목의 키는 암호학적 해시이며, 바이트도 해당 해시와 대조하여 검증됩니다(다음 참조. § 3.3 파일 생성 및 쓰기). 따라서 사이트는 확신할 수 있습니다. 다음을 통해 얻은 파일이 getFileHandle() 자신이 직접 가져왔을 때와 정확히 같은 바이트를 갖는다는 점을 확신할 수 있습니다. hash에 해당하는 파일을 직접 가져오는 경우와 같습니다. 개발자는 교차 출처 저장소의 내용을 열거하거나 해시를 미리 알지 못하는 파일에 접근할 수 없습니다.

COS 해시는 비밀이 아닙니다. 이는 콘텐츠 식별자로, 다음에 해당하는 사람은 누구나 쉽게 계산할 수 있습니다. 파일을 이미 가진 사람이며, 이 명세가 대상으로 하는 널리 배포되는 리소스에서는 일반적으로 공개된 정보이고, 흔히 모델이나 라이브러리의 릴리스와 함께 게시됩니다. 따라서 해시를 알면 항목을 조회하기에 충분하지만, 그 자체로 접근 권한을 부여하지는 않습니다. 조회의 성공 여부는 전적으로 출처 목록 및 § 8.4 가용성 제한에 따라 결정됩니다. 개발자는 공개되지 않은 해시를 접근 제어 수단으로 취급해서는 안 됩니다. 특정 파일에 관심이 있는 공격자는 해시를 추측할 필요 없이 파일 자체를 얻기만 하면 됩니다(§ 8.2 교차 사이트 탐색 참조).

8.2. 교차 사이트 탐색

리소스가 소수의 사이트에서만 사용된다면, 공격자가 그 리소스가 교차 출처 저장소에 있음을 알아낼 수 있을 때 사용자가 해당 사이트 중 하나를 방문했을 가능성을 추론할 수 있습니다. getFileHandle()이 존재 여부를 알아내는 수단이므로, 각 호출은 사실상 탐색입니다. 이 명세의 두 가지 독립적인 메커니즘이 탐색으로 알아낼 수 있는 정보를 제한합니다:

• 출처 목록(다음 참조. § 3.5 리소스 가시성 확장)을 통해 저장한 출처는 공개 대상을 선택한 출처 집합과 다음 관계의 출처로 제한할 수 있습니다. 동일 사이트 관계의 출처들입니다. 따라서 독점적이거나 인기도가 낮은 리소스는 아예 전역적인 탐색 대상이 될 필요가 없습니다.

• § 8.4 가용성 제한은 추가로 다음 리소스의 공개를 보류합니다. "*" 범위의 리소스에 대해, 요청 출처가 해당 리소스의 저장한 출처 밖에 있고, 해시가 PHL에 포함되지 않은 경우입니다. 따라서 리소스를 다음으로 저장하더라도 origins: "*"로 저장하더라도 웹상의 모든 출처가 자동으로 탐색할 수 있게 되지는 않습니다. 이 조건은 오직 "*" 범위의 항목에만 적용됩니다. 리스트 및 동일 사이트 범위의 항목에는 첫 번째 항목의 제한만 적용됩니다. 저장한 출처가 이미 공개 범위를 명시적으로 제한했기 때문입니다.

첫 번째 항목은 "선택한 출처 집합"이 웹 전체보다 의미 있게 작은 경우에만 성립합니다. 다음의 형식 자체는 origins의 형식 자체는 호출자가 매우 많은 출처를 열거하는 것을 막지 않습니다(예를 들어 공개된 인기 사이트 순위에서 조합한 목록). 이는 기능적으로 전역 공개에 가까워지면서도 "*"에만 요구되는 의도적이고 명시적인 선택을 우회합니다. 최대 출처 목록 길이(다음 참조. § 5.1 저장소 한도)가 이를 제한합니다. 실제로 필요한 여러 속성에 걸친 사용 사례 (공통 제어 아래의 소수 관련 출처)를 수용하면서도 "모든 출처"에 의미 있게 근접하는 수에는 훨씬 못 미치는 한도를 설정하면, 제한된 출처 형식의 출처 목록이 "*"의 암묵적인 대체 수단으로 사용되는 것을 방지할 수 있습니다.

사용자 에이전트는 추가로 다음이 반복될 때 속도를 제한하거나 다른 방식으로 호출 빈도를 조절하는 것이 좋습니다. getFileHandle() 호출이 단일 출처에서 반복되는 경우이며, 또한 기기 내 휴리스틱을 적용할 수 있습니다(예를 들어 사용자별로 생성된 것으로 보이는 해시를 요청하는 패턴을 감지하는 방식). 이를 통해 탐색 시도를 식별하고 차단할 수 있으며, 탐색 대상 해시가 PHL에 포함되는지와는 관계없습니다.

8.3. 진행 중인 쓰기

요청되었지만 완료되지 않은 쓰기는 모든 출처에서 다음과 구분할 수 없어야 합니다. 한 번도 기록되지 않은 해시와 구분할 수 없어야 합니다. 이 명세는 구조적으로 이를 달성합니다. COS 항목이 다음에 추가되는 것은 COS 레지스트리에 추가되는 것은 다음에 의해서만 가능합니다. 검증 및 저장 또는 가져온 리소스를 교차 출처 저장소에 저장으로만 가능하며, 두 경우 모두 전체 바이트가 해시와 대조하여 검증된 후에만 추가됩니다. 생성 요청 완료는 레지스트리를 읽지도 기록하지도 않습니다. 따라서 읽기가 관찰할 자리표시자 상태가 없으며, 읽기 경로에는 다음보다 먼저 응답할 수 있는 분기가 없습니다. 가용성 제한 적용보다 먼저 응답할 수 없습니다.

대안으로 생성 요청 시 자리표시자를 등록하고, 동시에 발생하는 읽기를 구별 가능한 오류로 거부하면, 호출자는 어떤 출처가 지금 특정 해시를 기록하고 있음을 알아낼 수 있습니다. 그 1비트는 사소해 보이지만 그렇지 않습니다. 이 정보는 다음과 같이 제공됩니다:

• 모든 출처에 제공되며, 항목에 대해 어떤 종류의 허가도 없는 출처도 포함됩니다. 자리표시자에는 허가가 없고, 읽기는 다음이 실행되기 전에 응답하기 때문입니다. COS 공개 결정이 실행되기 전입니다;

• 모든 해시에 대해 제공되며, 다음에 포함되지 않고 PHL에 포함될 수도 없는 해시도 포함됩니다. 따라서 공격자는 사용자별 값에서 도출한 해시를 사용할 수 있으며, 이는 정확히 다음에서 § 8.6 핑거프린팅 포착하려는 패턴입니다;

• GREASE 적용 없이 제공됩니다. 이는 제한 단계에 도달한 공개에만 적용되므로, 해당 비트에는 잡음이 없게 됩니다;

• 바이트를 전혀 제공하지 않고도 가능하므로, 출처별 저장소 한도도 다음도 § 5.2 축출도 출처가 생성할 수 있는 이러한 비트 수를 제한하지 못합니다.

따라서 두 사이트에 내장된 추적기는 첫 번째 사이트에서 임의 길이의 식별자를 만들고, 두 번째 사이트에서 다시 읽을 수 있습니다. 저장 비용 없이 출처 목록, 공개 해시 목록 및 GREASE 적용을 한꺼번에 우회합니다. 자리표시자는 서비스 거부 수단이 되기도 합니다. 실제로 인기 있는 리소스의 해시를 고정하면, 다른 모든 출처의 해당 리소스 읽기를 자리표시자가 유지되는 동안 억제할 수 있습니다.

참고: 이로 인해 잃는 것은 한 호출자가 다른 호출자가 이미 대용량 파일을 다운로드 중임을 알아내어 중복 다운로드를 시작하지 않을 수 있는 기능입니다. 이는 실제 비용이며, 이 명세의 이전 초안에서 구별 가능한 오류를 사용했던 이유입니다. 하지만 가장 중요한 곳인 단일 출처 내에서는 다음을 사용하여 이 기능을 회복할 수 있습니다. Web Locks, BroadcastChannel 또는 공유 워커를 사용할 수 있으며, 이들 중 어느 것도 출처 경계를 넘어 정보를 공개하지 않습니다. 출처 간 절감 효과는 대부분 이론적입니다. 서로 관련 없는 두 출처가 같은 순간에 같은 해시를 두고 경합해야 하며, 어느 쪽도 아직 기록하지 않은 항목은 다음 조건을 충족할 때까지 어차피 다른 쪽에 공개될 수 없기 때문입니다. PHL에 포함되어야 합니다.

참고: "NotAllowedError" 는 여전히 다음 호출의 응답입니다. getFile()을 다음 핸들에서 호출한 경우입니다. 생성 요청으로 얻었지만 쓰기를 수행하지 않은 핸들입니다(다음 참조. § 4 교차 출처 저장소 파일 시스템). 이 응답은 레지스트리와 관계없이 일정하며 요청한 출처에만 전달됩니다. 핸들은 출처를 넘어 역직렬화될 수 없기 때문입니다(§ 4.1 핸들 전송 참조). 따라서 정보 전달 경로가 되지 않습니다.

8.4. 가용성 제한

다음 getFileHandle() 읽기가 다음에 속하지 않는 출처에서 저장한 출처에 속하지 않는 출처에서 성공하는지는 항상 요청 출처가 해당 항목의 읽기를 허용받았는지에 달려 있으며, 이는 출처 목록이 제어합니다. "*" 범위 항목에는 두 번째의 독립적인 질문도 적용됩니다. 사용자 에이전트가 항목의 존재 자체를 공개하려는지이며, 이는 PHL 포함 여부 및 GREASE 적용이 제어합니다. 두 조건이 모두 충족되어야 합니다. 리스트 또는 동일 사이트 범위 항목에는 첫 번째 질문만 적용됩니다. 규범적 알고리즘은 § 3.2 파일 읽기를 참조하세요. 따라서 "NotFoundError" 는 다음의 증거가 아닙니다. 리소스가 없다는 증거가 아닙니다. 리소스가 실제로 없거나, 요청 출처가 범위 밖이거나, "*" 범위 리소스의 해시가 PHL에 (아직 또는 영원히) 포함되지 않거나, GREASE 적용이 진양성을 억제했다는 뜻일 수 있습니다. 개발자는 "NotFoundError" 를 "네트워크로 대체합니다"보다 더 구체적인 의미로 취급해서는 안 됩니다.

참고: 제3자 쿠키를 지원하는 사용자 에이전트에서, "*" 허가는 추적기가 사용자의 사이트 간 방문을 연결할 수 있게 하지만, 제3자 쿠키가 이미 제공하는 능력을 넘어서지는 않습니다. PHL 만으로는 이를 제한하지 못합니다. 공격자는 개별적으로 PHL 자격을 충족하는 리소스들 중 기록할 부분집합을 선택하여 교차 사이트 식별자를 만들 수 있습니다. 제3자 쿠키를 차단하는 사용자 에이전트도 교차 사이트 공개를 제한한다면 "*" 허가를 제공할 수 있습니다. 예를 들어 최상위 사이트를 키로 하고 페이지의 모든 프레임이 공유하는 소량의 교차 사이트 조회 예산을 두거나, 일정 시간 동안 다시 로드해도 유지되는 횟수 계수를 사용하거나, 기록한 항목을 사용자 제스처 이후에만 "*" 허가를 통해 사용할 수 있게 할 수 있습니다. README의 개인정보 보호 고려 사항 에서 이러한 완화 조치를 설명한다.

참고: 조회가 예산에 계산되지 않는 경우는 COS 공개 결정이 읽는 측 자신의 최상위 사이트에서 작성된 권한으로 응답할 때뿐이다. 이는 저장한 출처 권한 또는 파티션이 읽는 측의 COS 파티션과 동일 사이트인 출처 목록 권한이다. 다른 모든 조회는 항목 발견 여부와 관계없이 계산된다. 다른 최상위 사이트에서 작성된 제1자 출처 목록 권한으로 응답한 조회도 포함된다. Cross-Origin-Storage-Allow-Origin 헤더는 삽입된 콘텐츠가 이런 읽는 측을 지정하지 못하게 한다. 쓰는 사이트의 운영자는 여전히 어떤 출처든 지정할 수 있으므로, 예산에 계산하지 않으면 협력하는 두 사이트가 한쪽에 표시 파일을 만들고 리스트로 다른 쪽을 지정하여, 별개의 방문에 걸쳐 임의의 비트 폭을 가진 식별자를 그곳에서 제한 없이 읽을 수 있게 된다. 예산 초과로 거부된 조회는 검색 실패와 완전히 동일하게 "NotFoundError" DOMException으로 거부된다. 사용자 제스처 제한은 GREASE 적용과 마찬가지로 전역적으로 공개 가능 권한만으로 자격을 얻는 출처에만 적용된다. 저장한 출처, 명시적 출처 목록 리스트의 출처, 그리고 이들 중 어느 쪽과든 동일 사이트인 출처는 COS 공개 결정이 항목을 반환하면 바로 읽을 수 있다.

8.5. GREASE 적용

사용자 에이전트는 GREASE 적용을 수행할 수 있습니다(무작위 확장 생성 및 지속적인 확장성 유지). 때때로 다음과 같이 응답합니다. 공개 가능한 항목이 없는 것처럼 응답하며, § 8.4 가용성 제한이 원래라면 공개를 허용하는 경우에도 그렇게 합니다. 이는 사이트가 실제 부재와 개인정보 보호를 위한 위음성을 구분하기 어렵게 만드는 잡음을 추가하며, 다음에서 적용하는 기법과 유사합니다. UA 클라이언트 힌트.

GREASE 적용은 다음을 통해 자격을 얻는 출처에만 적용됩니다. 전역적으로 공개 가능 허가만을 통한 경우이며, 이는 공개 해시 목록이 제한하는 경우와 같습니다(다음 참조. COS 공개 결정). 사용자 에이전트는 이를 다음에 적용해서는 안 됩니다. 저장한 출처, 명시적인 출처 목록 리스트의 출처, 또는 어느 쪽과든 동일 사이트 관계인 출처입니다.

GREASE를 적용하는 사용자 에이전트는 반드시 해당 항목의 크기에 비례하는 판단을 해야 합니다. 네트워크 가져오기로 대체하는 비용이 낮은 작은 항목에서는, 간헐적인 위음성이 합리적인 개인정보 보호상의 절충입니다. 사용자 에이전트는 다음 항목에 GREASE를 적용해서는 안 됩니다. 불필요한 재다운로드 비용이 그에 따른 개인정보 보호 이익에 비해 명백히 과도해지는 크기의 항목입니다 (예를 들어 기가바이트 규모의 AI 모델 가중치). 이런 경우 위음성이 발생하면 전체를 관찰 가능하고 비용이 큰 방식으로 다시 다운로드해야 하기 때문입니다.

8.6. 핑거프린팅

공격자가 교차 출처 저장소를 탐색하여 추출할 수 있는 정보는 탐색 대상 리소스의 인기도에 따라 제한됩니다. 사용자가 일반적인 AI 모델처럼 매우 인기 있는 리소스나 널리 사용되는 JavaScript 라이브러리를 보유함을 알아내도, 사용자가 이를 사용하는 (잠재적으로 매우 많은) 사이트 중 하나를 방문했다는 사실만 드러납니다. 희귀하거나 고유한 리소스를 보유함을 알아내면 훨씬 많은 정보를 얻습니다. 사용자 에이전트는 기기 내 휴리스틱을 적용하여 해시가 사용자별로 의도적으로 고유하게 만들어진 것으로 보이는 리소스를 감지할 것으로 예상됩니다(예를 들어 단일 사이트에서만 기록된 해시 또는 비정상적으로 자주 요청되는 해시). 이러한 패턴은 탐색 시도로 취급하며, 명목상의 PHL 상태와 관계없이 처리합니다.

9. 다른 명세와의 통합

이 절은 비규범적입니다.

여기서 정의한 COS 레지스트리에는 네 가지 호스트 통합에서도 접근할 수 있으며, 다음을 거치지 않습니다. getFileHandle()을 직접 거치지 않습니다. 각 통합은 자체 호스트 명세에서 정의됩니다. 이 명세는 공유되는 기반 개념(COS 해시, COS 항목, 가용성 제한 및 공개 해시 목록)과 가져온 리소스를 교차 출처 저장소에 저장하는 단계를 정의하며, 해당 통합들은 이를 기반으로 삼을 것으로 예상됩니다.

• HTML: crossoriginstorage 속성을 다음에 적용합니다. link 및 script 요소 중 이미 integrity [SRI]를 가진 요소입니다. WHATWG에 제안된 위치는 whatwg/html#12770입니다.

• JavaScript: 호스트가 정의하는 crossOriginStorage 가져오기 속성이며, 함께 사용할 수 있는 대상은 integrity입니다. 기반이 되는 제안은 가져오기 속성 제안이며, WHATWG에 제안된 위치는 whatwg/html#12771입니다.

• CSS: cross-origin-storage() <request-url-modifier>이며, integrity()와 함께 사용할 수 있고, CSS 작업 그룹에 제안된 위치는 w3c/csswg-drafts#14056입니다.

• Fetch: crossOriginStorage RequestInit 옵션이며, 다음과 함께 사용할 수 있습니다. integrity [FETCH]와 함께 사용하며, 제안된 대상은 WHATWG이고, 위치는 whatwg/fetch#1954입니다. 이 경우 호스트가 정의하는 대상이 없으며, COS 항목은 바이트만 저장하므로, 해당 명세가 다음 Response를 정의합니다. 다음에서 제공되는 응답입니다. COS 레지스트리에서 제공됩니다. 예상되는 형태는 성공 응답입니다. 상태는 200이고, 상태 메시지는 OK이며, 본문은 다음의 스트림입니다. 바이트의 스트림입니다. Content-Type 헤더는 MIME 타입이며, 그 값은 호출자가 선언합니다. 네트워크 가져오기가 없었으므로 다른 헤더는 포함하지 않습니다. 이 옵션은 GET 메서드를 요구할 것으로 예상됩니다. 캐시 적중 시 요청을 전송하지 않고 응답하는데, 이는 요청에 본문도 부작용도 없는 메서드에서만 안전하므로, 다른 메서드를 사용하면 Request 생성자가 TypeError를 던지게 됩니다.

설명을 위한 예시로, 동일한 전역 공유 리소스를 교차 출처 저장소에 사용하도록 선택하는 방법을 네 가지 형식으로 각각 제시합니다:

<script src="popular-library.js" integrity="sha256-abc123..." crossoriginstorage="*"></script>

import data from "popular-resource.ext" with {
 integrity: "sha256-abc123...",
 crossOriginStorage: "*",
};

@font-face {
 font-family: "Popular Font";
 src: url("popular-font.woff2" integrity("sha256-abc123...") cross-origin-storage(*));
}

const response = await fetch("popular-resource.ext", {
 integrity: "sha256-abc123...",
 crossOriginStorage: "*",
});

이 코드 조각들은 설명을 위한 예시일 뿐입니다. 이 구문 중 어느 것도 이 명세에서 정의하지 않습니다. 제한된 출처 목록의 표기법을 포함하여 각 형식의 권위 있는 문법은 해당 호스트 명세에 속합니다. 표기법은 의도적으로 서로 다릅니다. RequestInit 멤버는 sequence<DOMString>을 받을 수 있어 다음과 origins 정확히 일치하지만, 속성 값, 가져오기 속성 값 및 CSS 수정자 인수는 텍스트만 포함할 수 있습니다.

네 가지 형식 모두 다음을 먼저 확인하는 처리 모델을 공유할 것으로 예상됩니다. COS 레지스트리에서 일치하는 공개 가능한 항목을 확인한 후 네트워크 가져오기로 대체하며, 또한 가져오기에 성공하고 무결성이 검증된 리소스를 다음에 저장합니다. COS 레지스트리에 저장하여 다른 출처에서 재사용할 수 있게 하며, 이는 정확히 getFileHandle()의 동작과 같습니다. 저장 단계는 가져온 리소스를 교차 출처 저장소에 저장이며, 각 통합은 다음을 전달하여 실행합니다. 가져온 응답을 전달합니다. 따라서 제한된 출처 값은 해당 리소스 응답의 Cross-Origin-Storage-Allow-Origin 헤더로 제한되며, 이는 바이트를 제공하는 서버가 보냅니다(다음 참조. § 7 Cross-Origin-Storage-Allow-Origin 헤더). 이러한 통합에 관한 논의는 이를 포함할 호스트 명세의 추적기에서 이루어져야 하며, 이 저장소의 이슈 추적기에서 다루는 것이 아닙니다.

감사의 말

귀중한 의견을 제공해 주신 Tab Atkins-Bittner, Yash Raj Bharti 및 Joshua Lochner와, 귀중한 영감이나 아이디어를 제공해 주신 Kenji Baheux 및 Kevin Moore께 깊이 감사드립니다.

이 명세에는 다음을 본떠 작성한 자료가 포함되어 있습니다. 파일 시스템이며, 다음에 따라 제공됩니다. W3C 소프트웨어 및 문서 라이선스.