스토리지 액세스 API

2. 인프라

이 명세는 Infra 표준에 의존합니다. [INFRA]

3. Storage Access API

이 명세는 Document가 현재 자신의 비분할 데이터에 접근할 수 있는지 질의하는 메서드(hasStorageAccess())와, 자신의 비분할 데이터에 대한 접근을 요청할 때 사용할 수 있는 메서드(requestStorageAccess())를 정의합니다.

비분할 데이터 는 사이트가 퍼스트 파티 사이트 컨텍스트에서 로드된 경우 사용할 수 있는 클라이언트 측 저장소입니다.

Document 는 해당 문서가 활성 문서이고 최상위 탐색 컨텍스트인 경우 퍼스트 파티 사이트 컨텍스트에 있다고 합니다. 아니면, origin과 top-level origin이 관련 설정 객체의 서로 동일 사이트인 경우, 퍼스트 파티 사이트 컨텍스트에 있다고 합니다.

Document 는 퍼스트 파티 사이트 컨텍스트에 있지 않으면 서드 파티 컨텍스트에 있다고 합니다.

사용자 에이전트가 비분할 쿠키 접근을 명시적으로 허용하는지 판단하기 위해, 튜플 tuple에 두 사이트가 포함되어 있다고 하고, 다음 절차를 따르세요. 이 알고리즘은 "none", "allow", "disallow"를 반환합니다.

참고: 사용자 에이전트의 설정은 사이트별 허용 목록, 사용자가 브라우저 전역 설정을 변경하거나 유사한 커스텀 오버라이드를 통해 비분할 쿠키 접근을 명시적으로 허용 또는 차단할 수 있습니다.

1. 사용자 에이전트가 tuple에 대한 비분할 쿠키 접근에 대해 명시적 설정이 없다면, "none"을 반환합니다.

2. 사용자 에이전트 설정이 tuple에 대해 비분할 쿠키 접근을 명시적으로 허용한다면, "allow"를 반환합니다.

3. Assert: 사용자 에이전트 설정이 tuple에 대해 비분할 쿠키 접근을 명시적으로 차단합니다.

4. "disallow"를 반환합니다.

FedCM 사이트 연결 상태를 결정하기 위해, origin embedder와 origin identityProvider가 주어졌을 때 다음 단계를 따르세요. 이 알고리즘은 불리언을 반환합니다.

1. 각 item에 대해 connected accounts set을 반복:

   1. (rp, idp, account)을 item으로 둡니다.

   2. rp와 embedder가 동일 사이트이고, idp와 identityProvider도 동일 사이트라면 true를 반환합니다.

2. false를 반환합니다.

실효성 있는 FedCM 연결 상태를 결정하기 위해, origin embedder, origin identityProvider, Document doc이 주어졌을 경우, 다음 절차를 따르세요. 이 알고리즘은 불리언을 반환합니다.

1. policyStatus에 doc가 "identity-credentials-get"을 사용할 수 있는지 여부를 저장합니다.

2. policyStatus가 "Disabled"라면 false를 반환합니다.

3. connected에 사이트 연결 상태 결정 절차의 결과를 저장합니다.

4. connected가 false라면 false를 반환합니다.

5. preventSilentAccess에, user agent의 크리덴셜 저장소의 prevent silent access flag를 embedder 기준으로 저장합니다.

6. preventSilentAccess가 true라면 false를 반환합니다.

7. true를 반환합니다.

3.1. 스토리지 접근 관련 사용자 에이전트 상태 변화

environment 정의를 다음과 같이 수정합니다:

1. has storage access 라는 이름의 새 멤버를 불리언 타입으로 추가합니다.

source snapshot params 정의를 다음과 같이 수정합니다:

1. has storage access 라는 이름의 새 멤버를 불리언 타입으로 추가합니다.

2. environment id라는 이름의 새 멤버를 opaque 문자열 타입으로 추가합니다.

스토리지 접근 적격성은 "unset", "ineligible", 또는 "eligible" 중 하나입니다.

request는 스토리지 접근 적격성 eligible for storage-access를 가집니다. 초기 값은 "unset"입니다.

참고: request의 스토리지 접근 적격성은, storage-access 권한이 이미 부여된 적이 있는지 등, 해당 request가 어떤 쿠키를 포함할지 결정할 때 고려 대상이 되어야 하는지 나타냅니다. 특히, requestStorageAccess가 resolve되고 environment의 has storage access가 true로 설정되어도, 해당 request가 발행하는 모든 environment의 요청이 모두 비분할 쿠키를 포함하는 것은 아닙니다.

예를 들어, 사용자가 https://top.com에서 페이지를 방문하고 거기에 https://embed.com의 iframe이 embed되어 있다고 가정합니다. 이 iframe의 스크립트가 requestStorageAccess를 resolve시켰다면, 이후 이 iframe이 https://3p.com에서 리소스를 fetch하더라도, 해당 요청에는 Storage Access API를 통해 쿠키가 포함되지 않습니다.

3.2. Document에 대한 변경 사항

partial interface Document {
  Promise<boolean> hasStorageAccess();
  Promise<undefined> requestStorageAccess();
};

Document doc에서 hasStorageAccess() 메서드를 호출할 때 다음 단계를 수행해야 합니다:

1. p를 새로운 promise로 둔다.

2. doc가 완전히 활성화 상태가 아니면, reject p를 "InvalidStateError" DOMException 이유로 거부하고 p를 반환한다.

3. doc의 origin이 opaque origin이면, resolve p를 false로 하고 반환한다.

4. global을 doc의 관련 global object로 둔다.

5. global이 secure context가 아니면, resolve p를 false로 하고 반환한다.

6. doc의 top-level origin이 doc의 관련 settings object에서 opaque origin이면 resolve p를 false로 하고 반환한다.

7. browsingContext를 doc의 브라우징 컨텍스트로 둔다.

8. topLevelSite를 사이트 획득을 통해 doc의 top-level origin에 대해 얻는다.

9. embeddedSite를 사이트 획득을 통해 doc의 origin에서 얻는다.

10. 다음 단계를 병렬로 실행한다:

    1. explicitSetting을 사용자 에이전트가 비분할 쿠키 접근을 명시적으로 허용하는지를 (topLevelSite, embeddedSite)로 실행한 결과로 둔다.

    2. permissionState를 현재 권한 상태 가져오기를 "storage-access"와 global로 실행한 결과로 둔다.

    3. 전역 태스크 대기열을 networking 작업 소스의 global에 다음과 같이 동작한다:

       1. explicitSetting이 "disallow"이면, resolve p를 false로 한다.

       2. explicitSetting이 "allow"이면, resolve p를 true로 한다.

       3. Assert: explicitSetting은 "none"이다.

       4. browsingContext가 최상위 브라우징 컨텍스트이면, resolve p를 true로 한다.

       5. browsingContext가 browsingContext의 최상위 브라우징 컨텍스트의 active document와 same authority이면, resolve p를 true로 한다.

          여기서 "same authority"는 교차 사이트 부모 문서의 존재 등 추가 보안 요소를 고려하여 사용자 에이전트가 same site를 체크할 수 있도록 하는 미래 개념의 placeholder이다. 실제 동작은 쿠키용 site 비교나 최상위 문서와 same site 비교를 포함할 수 있다.

       6. permissionState가 granted이면, resolve p를 global의 has storage access로 한다.

          참고: 글로벌 storage access 권한 상태는 로컬 has storage access 플래그보다 우선적용되어, 사용자 설정에서 권한을 회수한 경우 이를 즉시 반영한다.

       7. resolve p를 false로 한다.

11. p를 반환한다.

Document doc에서 requestStorageAccess() 메서드를 호출할 때 다음 단계를 수행해야 합니다:

1. p를 새로운 프로미스로 둔다.

2. doc가 완전히 활성 상태가 아니면, reject p를 "InvalidStateError" DOMException으로 거부하고 p를 반환한다.

3. global을 doc의 관련 전역 객체로 둔다.

4. settings를 doc의 관련 설정 객체로 둔다.

5. global이 보안 컨텍스트가 아니면, reject p를 "NotAllowedError" DOMException으로 거부하고 p를 반환한다.

6. doc가 "storage-access" 사용 허가됨이 아니면, reject p를 "NotAllowedError" DOMException으로 거부하고 p를 반환한다.

7. doc의 origin이 불투명 origin이면, reject p를 "NotAllowedError" DOMException으로 거부하고 p를 반환한다.

8. settings의 top-level origin이 불투명 origin이면, reject p를 "NotAllowedError" DOMException으로 거부하고 p를 반환한다.

9. doc의 active sandboxing flag set에 sandbox storage access by user activation flag가 설정되어 있다면, reject p를 "NotAllowedError" DOMException으로 거부하고 p를 반환한다.

10. browsingContext를 doc의 브라우징 컨텍스트로 둔다.

11. topLevelOrigin을 doc의 top-level origin으로 둔다.

12. topLevelSite를 사이트 얻기를 통해 topLevelOrigin에서 얻는다.

13. embeddedOrigin을 doc의 origin으로 둔다.

14. embeddedSite를 사이트 얻기를 통해 embeddedOrigin에서 얻는다.

15. has transient activation을 doc의 Window 객체가 일시적 활성화를 가지고 있는지 여부로 둔다.

16. 다음 단계를 병렬로 실행한다:

    1. process permission state라는 알고리즘을 두고, 권한 상태 state를 받아 다음을 실행한다:

       1. 전역 태스크 큐를 네트워킹 태스크 소스의 global에 대해 실행:

          1. state가 granted이면:

             1. global의 has storage access를 true로 설정한다.

             2. resolve p를 undefined로 한다.

          2. 그 외:

             1. 사용자 활성화 소모를 global에 적용한다.

             2. reject p를 "NotAllowedError" DOMException으로 거부한다.

    2. explicitSetting을 사용자 에이전트가 비분할 쿠키 접근을 명시적으로 허용하는지 판단하기를 (topLevelSite, embeddedSite)에 대해 실행한 결과로 둔다.

    3. explicitSetting이 "disallow"이면:

       1. denied로 process permission state 실행.

       2. 이 단계를 중단한다.

    4. explicitSetting이 "allow"이면:

       1. granted로 process permission state 실행.

       2. 이 단계를 중단한다.

    5. Assert: explicitSetting은 "none"이다.

    6. browsingContext가 최상위 브라우징 컨텍스트이면:

       1. granted로 process permission state 실행.

       2. 이 단계를 중단한다.

    7. embeddedSite가 same site이면 topLevelSite와:

       참고: 이 체크는 의도적으로 same site임. 임베디드 사이트가 사용자의 관여 없이 requestStorageAccess()를 통해 보안 목적 제한 상황에서 저장소 접근에 opt-in할 수 있도록 허용한다.

       1. granted로 process permission state 실행.

       2. 이 단계를 중단한다.

    8. previous permission state를 현재 권한 상태 가져오기를 "storage-access"와 global의 인자로 실행한 결과로 둔다.

    9. previous permission state가 prompt가 아니면:

       1. process permission state를 previous permission state로 실행.

       2. 이 단계를 중단한다.

    10. connected를 실효성 있는 FedCM 연결 상태 결정을 topLevelOrigin, embeddedOrigin, doc에 대해 실행한 값으로 둔다.

    11. connected가 true이면:

        참고: 사용자 에이전트는 기존 FedCM 연결로 저장소 접근을 허용받은 (site, site) 튜플들을 추적하고, 쿠키 접근 시 목록을 재검토해 악의적 공격자가 잘못된 environment의 has storage access 상태를 쓰도록 속이는 일을 방지할 것 권장.

        1. granted로 process permission state 실행.

        2. 이 단계를 중단한다.

    12. has transient activation이 false이면:

        1. denied로 process permission state 실행.

        2. 이 단계를 중단한다.

    13. permissionState를 권한 사용 요청을 "storage-access"로 실행한 결과로 둔다.

        참고: 권한 요청 및 프롬프트 표시 여부 판단 시, 사용자 에이전트는 사용자 경험을 위해 구현 정의 동작을 적용 가능함. 특히 storage-access 경우, 프롬프트 없이 커스텀 규칙으로 권한을 자동 부여/거부할 수 있음이 알려져 있다.

    14. process permission state를 permissionState로 실행.

17. p를 반환한다.

참고: 이 알고리즘의 의도는 storage-access 권한이 부여되기 전에 항상 사용자 활성화를 요구하는 것입니다. 사용자 에이전트가 사용자 활성화 없이 자체 휴리스틱으로 storage-access 권한을 부여할 수는 있으나, 상호운용성 저하의 원인이 될 수 있으므로 이러한 동작은 비추천합니다.

3.3. 내비게이션의 변경점

source snapshot params 스냅샷 시:

1. has storage access를 sourceDocument의 has storage access로 설정한다.

2. environment id를 sourceDocument의 relevant settings object의 id로 설정한다.

create navigation params by fetching 알고리즘에 대해, step 3으로 다음 단계를 삽입한다:

1. originalURL을 entry의 URL로 둔다.

reserved client를 create navigation params by fetching에서 생성할 때:

1. reserved client의 has storage access를 sourceSnapshotParams의 has storage access로 설정한다. 단, 다음 모든 조건을 만족해야 한다:

   1. sourceSnapshotParams의 environment id가 navigable의 active document의 relevant settings object의 id와 동일.

   2. originalURL의 origin이 currentURL의 origin과 동일 출처이다.

   3. response가 null이거나, response의 has-cross-origin-redirects가 false이다.

2. 그렇지 않으면 request의 reserved client의 has storage access를 false로 설정한다.

window environment settings object 설정 시:

1. settings object의 has storage access를 reserved environment의 has storage access로 설정한다.

3.4. Fetch 통합

3.4.1. 페칭

fetch의 step 14 이후에 새로운 단계를 삽입한다:

3.4.2. HTTP-redirect-fetch

HTTP-redirect fetch의 step 17 이후에 새로운 단계를 삽입한다:

3.5. 다양한 클라이언트 측 스토리지 메커니즘 변경점

이 API는 HTTP 쿠키에만 영향을 미친다. 차후 개정에서는 다른 클라이언트 상태에도 영향을 줄 수 있다. [RFC6265]

3.5.1. 쿠키

이 API는 서드 파티 컨텍스트에서 비분할 쿠키 접근을 차단하는 환경 및 사용자 에이전트 설정과 함께 쓰는 것을 목적으로 한다. 이 문서 작성 시점에서는, 이 개념은 아직 HTTP-network-or-cache fetch 및 cookie 알고리즘에 통합되어 있지 않다. 이러한 통합을 위해, cookie store는 요청의 최상위 및 임베드 사이트(교차 사이트, 분할, 쿠키 첨부 여부 결정), 그리고 request가 스토리지 접근이 가능한 문서에서 생성되었는지도 받아야 하며, 이 정보는 본 명세에서 정의한 request의 eligible for storage-access를 통해 전달된다.

쿠키 저장소가 스토리지 접근 정보를 받을 수 있게 되면 HTTP-network-or-cache fetch 및 cookie 에서도 쿠키를 가져올 때 request의 eligible for storage-access를 cookie store에 전달하도록 업데이트할 예정이다.

스토리지 접근으로 cookie store에서 비분할 쿠키를 가져올 때, 사용자 에이전트는 여전히 적용되는 SameSite 제한(즉, 서드 파티 컨텍스트 내에서 SameSite=Strict 또는 SameSite=Lax으로 표시된 쿠키 미첨부)을 따른다.

참고: 사용자 에이전트마다 SameSite 쿠키 속성의 기본값이 다를 수 있다. 이로 인해 일부 사용자 에이전트(기본값이 SameSite=None인 경우)에서는 SameSite 속성이 없는 비분할 쿠키가 요청에 첨부되고, 다른 에이전트(SameSite=Lax가 기본값인 경우)에서는 첨부되지 않을 수 있다. 웹 개발자들은 이러한 문제를 피하기 위해 쿠키에 SameSite 속성을 명시적으로 지정하는 것이 좋다.

3.6. 스토리지 접근 샌드박싱

sandboxing flag set에는 sandbox storage access by user activation flag가 있다. 이 플래그는 콘텐츠가 스토리지 접근을 요청하지 못하게 한다.

샌드박싱 지시문 파싱 알고리즘의 3번째 단계 하위로 다음을 추가한다:

• sandbox storage access by user activation flag(단, tokens에 allow-storage-access-by-user-activation 키워드가 없을 때만).

4. 권한 통합

Storage Access API는 파워풀 기능을 정의하며, name은 "storage-access"이다. 다음 권한 관련 알고리즘들을 정의한다:

permission query algorithm

"storage-access" 권한을 질의하려면, PermissionDescriptor permissionDesc와 PermissionStatus status가 주어졌을 때:

1. status의 state 를 permissionDesc의 permission state로 설정한다.

2. status의 state 가 denied라면, status의 state 를 prompt로 설정한다.

   참고: "denied" 권한 상태는 사용자의 결정을 개발자에게 노출하지 않기 위해 표시되지 않습니다. 이는 사용자를 보복이나 반복 프롬프트로부터 보호하기 위함입니다.

permission key type

"storage-access" 기능의 permission key는, 튜플 타입이며, site top-level과 site requester로 이루어져 있다.

(("https", "news.example"), ("https", "social.example"))은 "storage-access" 기능의 permission key이며, top-level은 ("https", "news.example")이고, requester는 ("https", "social.example")이다.

permission key generation algorithm

"storage-access" 기능에 대한 새 permission key 생성 시, origin origin 및 origin embeddedOrigin이 주어졌을 때:

1. topLevelSite를 obtain a site로 origin에서 얻는다.

2. embeddedSite를 obtain a site로 embeddedOrigin에서 얻는다.

3. (topLevelSite, embeddedSite)를 반환한다.

permission key comparison algorithm

"storage-access" 기능의 permission key key1과 key2 비교하려면:

1. key1의 top-level이 key2의 top-level과 same site가 아니면 false를 반환한다.

2. key1의 requester가 key2의 requester와 same site가 아니면 false를 반환한다.

3. true를 반환한다.

5. 권한 정책 통합

Storage Access API는 policy-controlled feature를 정의하며 식별자는 "storage-access"이다. 기본 허용 목록은 "*"이다.

참고: Document의 permissions policy는 해당 문서의 콘텐츠가 requestStorageAccess()를 통해 스토리지 접근 요청을 할 수 있는지 결정한다. 어떤 문서에서라도 비활성화되어 있으면, 해당 문서에서 requestStorageAccess() 호출 시 거부된다.

6. 프라이버시 고려 사항

Storage Access API는 교차 사이트 쿠키 제거를 가능하게 한다. 특히, 인증이 필요한 임베드 케이스가 계속 동작하도록 허용한다. 즉, 개발자가 교차 사이트 쿠키에 다시 접근할 수 있는 수단을 제공하나, 추가 제약을 둔다.

중첩된 Document는 active document로서 최상위 브라우징 컨텍스트에 있을 때와 동일한 쿠키를, requestStorageAccess() 호출 후 resolve되는 Promise에서 획득한다. 이 쿠키는 서버 인증 및 사용자별 정보 로드에 사용할 수 있다.

이 기능은 제3자가 추적 목적으로 남용할 위험이 있으나, API의 명시적 목표는 교차 사이트 쿠키 폐지 후의 프라이버시 이득을 약화하지 않는 데 있다. 즉, 플랫폼 특화 정보로 stateless 추적을 막고, 새로 추가되는 상태는 임베더와 임베디 문서 sites 범위로 한정된 permission뿐이다.

기본 교차 사이트 쿠키가 이미 폐지된 경우 프라이버시 논점이 더 복잡해진다. 과제는 Storage Access API를 언제 어떻게 쿠키가 없는(또는 분할 쿠키만 있는) 중첩 Document에 예전 상태로 접근을 허용할지 결정하는 것이다. 즉, 비분할 데이터에 접근 권한을 부여하는 시점을 결정해야 한다.

이상적인 경우, 중첩 Document가 자신의 비분할 데이터를 획득할 조건은 다음과 같다:

1. 사용자가 중첩 Document와 상호작용한 경우

2. 중첩 Document가 임베더에 의해 API 사용이 허용된 경우

3. 중첩 Document가 보안 컨텍스트인 경우

4. 사용자가 임베더에서 임베디가 쿠키를 쓸 수 있도록 명시적, 쌍방 permission을 부여한 경우

5. 사용자가 "storage-access" 권한 요청에 너무 자주 노출되어 명시적 동의의 의미가 약화되지 않은 경우

이 명세는 구현자에게 처음 세 가지 요건을 요구한다. 이를 통해 사용자가 중첩 Document의 내용을 인지하며, 임베더가 인증을 차단하지 않았고, 교차 사이트 쿠키가 네트워크 공격자에게 노출되지 않음을 보장한다.

마지막 두 항목은 상충한다. 이상적으로는 requestStorageAccess() 호출마다 프롬프트를 띄워야 한다. 그러나 이 경우 페이지가 사용자 프롬프트를 남용할 수 있으므로, 사용자 피로도를 줄이기 위해 사용자 에이전트가 과다 프롬프트를 방지해야 한다.

따라서 마지막 두 항목은 핵심적인 절충점을 나타낸다. 위 요건을 모두 충족하면 사용자 선택 없이도 비분할 데이터에 대한 요청 허용/거부 시점을 구현 정의로 허용한다. 이 절충은 본 제안의 프라이버시 보증, 구체적으로 4번 항목을 약화하나, 구현자에게 본 API로는 스토리지 접근이 불가능하도록 만드는 권한을 준다. 하지만 이 방식이 5번 조건을 허용하기 위해 불가피함이 입증되었다.

사용자 에이전트마다 구현 정의 동작이 크게 다르다면 개발자 경험이 저하되므로, 가능한 한 자동 허용/거부 동작의 최소화 및 표준화가 바람직하다.

6.1. 권한 범위

API 설계 시 또 다른 논점은 "storage-access" 권한을 키로 사용할 때 origin을 사용할지, site를 사용할지 여부이다. 우리는 site를 선택했다. 왜냐하면, site는 프라이버시의 허용 가능한 경계선이라고 판단했고, 동일 사이트 및 동일 페이지 내 교차 origin 중첩 Document 사용을 사용자 프롬프트 한 번으로 지원할 수 있기 때문이다.

7. 보안 고려 사항

이 명세는 교차 사이트 쿠키 제거 이후와 비교해도 웹 플랫폼의 보안 특성이 저하되지 않아야 한다. 서드 파티 쿠키 제거는 보안에 이익이 있으며, 특히 CSRF 등 인증 요청에 기대는 공격 경감을 위해서다. Storage Access API가 이러한 공격의 발판이 되는 것을 원치 않는다.

이를 위해 "storage-access" 권한 부여의 영향을 중첩 비분할 데이터에 대한 접근 권한으로 한정한다. 이 권한은 Document 가 requestStorageAccess()를 호출했을 때부터 그 중첩 Document가 origin 경계를 넘는 네비게이션을 하기 전까지만 유효하다. 즉, 실제 권한은 requestStorageAccess()를 호출한 페이지만이 인증 요청을 보낼 수 있으며, 나아가 embedee 페이지는 Content Security Policy의 "frame-ancestors" 디렉티브를 통해 허용할 embedder를 제어할 수 있다. 이로써 embedee가 보안을 위해 origin 범위 제어권을 유지할 수 있다.

7.1. 명예 훼손 공격

이 방식은 임베디된 서비스의 명예 훼손 공격을 막는 데에도 효과적이다. 모든 교차 사이트 인증 요청은 프라이버시에 민감해진 이용자에게 잠재적 명예 훼손 우려가 있다고 보고 있다. 따라서 퍼스트 파티 또는 sibling 교차 사이트가 사용자의 인증 쿠키를 사용해 임베드 리소스 요청을 일으키는 것도 해당 교차 사이트 소유자에 대한 명예 공격이 될 수 있다. 이 또한 API가 보안 컨텍스트에서만 사용되도록 요구하는 이유다. 네트워크 공격자가 embedee를 조작해 이 API를 쓰도록 유도하지 못하게 하기 위해서이다.

embedder는 중첩된 Document 들이 인증되거나 사용자에게 권한 프롬프트가 표시될 수 있는지, 혹은 Permission Policy와 중첩 Document 샌드박싱을 통해 제어할 수 있다.

7.2. 알림 남용

Storage Access API를 설계하면서 알림 남용 문제도 고려했다. 구체적으로, 중첩 Document 에서 사용자의 상호작용을 요구하고, 사용자가 거부했을 때 그 거절을 소비하여 사용자의 권한 프롬프트 표시 조건을 제한하도록 한다. 이로써 사용자가 거부한 직후 권한을 재요청하는 등의 공격을 완화한다.

8. 자동화

사용자 에이전트 자동화 및 애플리케이션 테스트를 위해, 본 문서는 확장 명령어를 [WebDriver] 명세에 대해 정의합니다.

8.1. 스토리지 접근 설정

스토리지 접근 설정 확장 명령은 현재 브라우징 컨텍스트의 스토리지 접근 정책을 수정한다.

remote end 단계는 아래와 같다:

1. blocked를 parameters에서 blocked라는 이름의 프로퍼티 값으로 구한다.

2. blocked가 불리언이 아니면 WebDriver error 및 WebDriver error code invalid argument를 반환한다.

3. embedded origin을 parameters에서 origin 프로퍼티의 값으로 얻는다.

4. embedded origin이 단일 U+002A 별표 문자(*)가 아니라면:

   1. parsedURL을 URL 파서에 embedded origin을 넣어 실행한 결과로 얻는다.

   2. parsedURL이 실패이면, WebDriver error 및 WebDriver error code invalid argument를 반환한다.

   3. embedded origin을 parsedURL의 origin으로 설정한다.

5. 현재 브라우징 컨텍스트가 최상위 브라우징 컨텍스트가 아니면 WebDriver error 및 WebDriver error code unsupported operation을 반환한다.

6. doc를 현재 브라우징 컨텍스트의 active document로 둔다.

7. settings를 doc의 relevant settings object로 둔다.

8. top-level site를 settings의 site 얻기 결과로 둔다.

9. embedded origin이 단일 U+002A 별표 문자(*)이면:

   1. blocked가 true라면:

      1. 구현 정의 단계들을 실행해 top-level site에서 비분할 데이터가 어떤 사이트도 서드 파티 컨텍스트에서 접근할 수 없도록 보장한다.

   2. 그 외에 blocked가 false라면:

      1. 구현 정의 단계들을 실행해 top-level site에서 어떤 사이트든 비분할 데이터를 서드 파티 컨텍스트에서 접근할 수 있도록 보장한다.

10. 그 외에는:

    1. embedded origin이 settings의 origin과 same site라면, WebDriver error 및 WebDriver error code unsupported operation을 반환한다.

    2. blocked가 true라면:

       1. 구현 정의 단계들을 실행해 embedded origin이 top-level site의 서드 파티 컨텍스트에서 비분할 데이터에 접근할 수 없도록 보장한다.

    3. 그 외에 blocked가 false라면:

       1. 구현 정의 단계들을 실행해 embedded origin이 top-level site의 서드 파티 컨텍스트에서 비분할 데이터에 접근할 수 있도록 보장한다.

11. 위 구현 정의 단계들이 실패하면 WebDriver error 및 WebDriver error code unknown error를 반환한다.

12. success(성공) 및 데이터 null을 반환한다.

감사의 글

이 명세는 Storage Access API를 고안한 전 편집자 John Wilander, 초기 텍스트의 상당 부분을 집필한 Theresa O’Connor가 만든 토대 위에 구축되었습니다. 그들의 아이디어와 기여에 감사를 표합니다.

다음 분들께도 많은 감사를 드립니다. Anne van Kesteren, Ben Kelly, Brad Girardeau, Brad Hill, Brady Eidson, Brandon Maslen, Chris Mills, Dave Longley, Domenic Denicola, Ehsan Akhgari, Geoffrey Garen, Jack Frankland, James Coleman, James Hartig, Jeffrey Yasskin, Kushal Dave, Luís Rudge, Maciej Stachowiak, Matias Woloski, Mike O’Neill, Mike West, Pete Snyder, Rob Stone, Stefan Leyhane, Steven Englehardt, Travis Leithead, Yan Zhu, Zach Edwards, 그리고 whatwg/html#3338, privacycg/proposals#2, privacycg/storage-access/issues 에서 의견을 남겨주신 모든 분들께 이 제안에 대한 피드백에 감사드립니다.

WebKit 오픈 소스 프로젝트에서 Storage Access API 프롬프트 이미지를 사용하도록 허락해주신 것에도 감사드립니다. 이 이미지는 webkit.org 에 처음 게시되었습니다.