관련 웹사이트 집합과 사용자 에이전트 상호작용

1. 소개

이 절은 비규범적이다.

Related Website Sets(“RWS”)는 개발자가 사이트들 간의 관계를 선언할 수 있게 하는 프레임워크를 제공하여, 사용자 에이전트가 사용자 대면 목적을 위해 쿠키와 같은 크로스 사이트 데이터에 제한적으로 접근하도록 허용할 수 있게 한다. 이는 Storage Access API를 사용하여 촉진된다.

이 문서는 사용자 에이전트가 Related Website Sets list와 통합하는 방법을 정의한다. RWS 목록의 구조 및 제출 시 실행되는 기술적 검증에 대한 정식 참조는 Related Website Sets Submission Guidelines를 참조하라.

2. 인프라

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

3. 목록 소비

사용자 에이전트는 정식 Related Website Sets list를 정기적으로(예: 2주마다) 소비하고, 이를 업데이트 가능한 컴포넌트로서 개별 클라이언트(예: 브라우저 애플리케이션)에 제공해야 한다.

여기서 업데이트 간격에 대한 권고를 할 수 있는가? [wicg/first-party-sets Issue #122]

개별 클라이언트는 다시 시작할 때, 또는 새로 다운로드된 경우 시작 시 관련 웹사이트 세트 목록을 구축해야 한다. 클라이언트는 그 밖의 어떤 시점에도 목록을 다시 구축해서는 안 된다.

RWS 목록은 UTF-8로 인코딩된 파일이며, Related Website Sets Submission Guidelines에 설명된 [JSON-SCHEMA]를 따르는 JSON 객체로 파싱 가능한 내용을 포함한다.

참고: 스키마 준수 여부는 제출 시 검증된다. 따라서 사용자 에이전트가 클라이언트에서 준수 여부를 다시 검증할 필요는 없다. 이 명세의 알고리즘은 사용자 에이전트가 RWS 목록을 파싱하는 방법과 특정 세트가 클라이언트 관점에서 언제 유효한 것으로 간주되어야 하는지를 설명한다.

서버와 클라이언트 간에 Public Suffix List 버전이 다른 경우 클라이언트 측 검증이 필요할 수 있다. [wicg/first-party-sets Issue #125]

JSON 바이트 시퀀스 bytes에서 관련 웹사이트 세트 목록을 구축하려면, 사용자 에이전트는 다음 단계를 실행해야 한다:

1. json을 bytes로 JSON 바이트를 infra 값으로 파싱한 결과로 둔다.

2. json이 파싱 예외이거나, json이 순서 있는 맵이 아니거나, json[“sets”]가 존재하지 않으면, 반환하고 선택적으로 목록 가져오기를 다시 시도하거나 다른 오류 복구 작업을 수행한다.

3. json의 각 entry에 대해:

   1. set을 관련 웹사이트 세트로 둔다.

   2. entry[“primary”]가 존재하지 않으면, 계속한다.

이 명세는 현재 전체 목록을 거부하는 대신 유효하지 않은 세트(기본 항목이 없는 세트)를 건너뛰도록 제안한다. 그러나 서버가 항상 유효한 정보를 보유할 것으로 기대된다는 점을 고려하면 전체 거부에 이점이 있을 수 있다. [wicg/first-party-sets Issue #126]

3. set의 primary를 entry[“primary”]로 설정한다.

4. ccTLDs를 entry[“ccTLDs”]에서 동등성 맵을 파싱한 결과로 둔다. ccTLDs가 실패이면, 계속한다.

5. set의 ccTLDs를 ccTLDs로 설정한다.

6. serviceSites를 entry[“serviceSites”]에서 하위 집합을 파싱한 결과로 둔다. 결과가 실패이면, 계속한다.

7. set의 serviceSites를 serviceSites로 설정한다.

8. associatedSites를 entry[“associatedSites”]에서 하위 집합을 파싱한 결과로 둔다. 결과가 실패이면, 계속한다.

9. set의 associatedSites를 associatedSites로 설정한다.

10. set을 사용자 에이전트의 관련 웹사이트 세트 목록에 추가한다.

사용자 에이전트는 최적화 등의 이유로 클라이언트에 전달하기 전에 목록을 다른 형식으로 전처리할 수 있다. 단, 클라이언트가 이 명세에서 정의한 유효한 관련 웹사이트 세트 목록을 최종적으로 보유하게 됨을 보장해야 한다.

4. 데이터 구조

사용자 에이전트는 전역 관련 웹사이트 세트 목록을 유지하며, 이는 목록인 관련 웹사이트 세트들의 목록이다.

관련 웹사이트 세트는 다음 항목들을 가진 구조체이다:

primary: 세트의 기본 도메인을 나타내는 사이트.

ccTLDs: 제출자가 지정한, 세트의 동등한 국가 코드 최상위 도메인을 나타내는 동등성 맵.

associatedSites: associated 하위 집합의 사이트들의 목록.

serviceSites: service 하위 집합의 사이트들의 목록.

참고: 이러한 필드의 의미에 대한 추가 맥락은 Related Website Sets Submission Guidelines를 참조하라.

동등성 맵은 사이트에서 사이트들의 목록으로 가는 순서 있는 맵이다.

문자열 input에서 사이트를 파싱하고 검증하려면, 다음 단계를 실행한다:

1. url을 input에 대해 기본 URL 파싱을 수행한 결과로 둔다. 결과가 실패이면, 실패를 반환한다.

2. url의 스킴이 "https"가 아니면, 실패를 반환한다.

3. site를 url의 출처에서 사이트를 얻은 결과로 둔다.

4. site를 반환한다.

목록 input에서 하위 집합을 파싱하려면, 다음 단계를 실행한다:

1. list를 빈 목록으로 둔다.

2. input의 각 item에 대해:

   1. site를 item에서 사이트를 파싱하고 검증한 결과로 둔다.

   2. site가 실패이면, 실패를 반환한다.

   3. site를 list에 추가한다.

3. list를 반환한다.

순서 있는 맵 input에서 동등성 맵을 파싱하려면, 다음 단계를 실행한다:

4. map을 빈 동등성 맵으로 둔다.

5. input의 각 key → value에 대해:

   4. keySite를 key에서 사이트를 파싱하고 검증한 결과로 둔다. 결과가 실패이면, 실패를 반환한다.

   5. equivalents를 빈 목록으로 둔다.

   6. value 안의 각 equivalent에 대해:

      1. equivalentSite를 equivalent에서 사이트를 파싱하고 검증한 결과로 둔다. 결과가 실패이면, 실패를 반환한다.

      2. equivalentSite를 equivalents에 추가한다.

   7. map[keySite]를 equivalents로 설정한다.

6. map을 반환한다.

5. 관련 웹사이트 세트 포함 검증

RWS에서, 사이트 site1은 사이트 site2에 대해, 동등성 맵 equivalents가 주어졌을 때 equivalents[site1]가 site2를 포함하거나 equivalents[site2]가 site1를 포함하면 동등하다고 간주된다.

수학적 동치 관계와 혼동되지 않도록 이름을 바꾸어야 하는가? [wicg/first-party-sets Issue #123]

주어진 사이트 site가 주어진 관련 웹사이트 세트 set에서 가지는 멤버 유형을 결정하려면, 다음 단계를 실행한다:

1. site가 set의 ccTLDs가 주어진 상태에서 set의 primary와 동등하면, “primary”를 반환한다.

2. set의 associatedSites의 각 associatedSite에 대해:

   1. site가 set의 ccTLDs가 주어진 상태에서 associatedSite와 동등하면, “associated”를 반환한다.

3. set의 serviceSites의 각 serviceSite에 대해:

   2. site가 set의 ccTLDs가 주어진 상태에서 serviceSite와 동등하면, “service”를 반환한다.

4. “none”을 반환한다.

주어진 사이트 site에 대한 관련 웹사이트 세트를 찾으려면, 다음 단계를 실행한다:

1. 사용자 에이전트의 관련 웹사이트 세트 목록의 각 set에 대해:

   1. type을 set에서 site의 멤버 유형으로 둔다.

   2. type이 “none”이 아니면, set을 반환한다.

2. null을 반환한다.

참고: Related Website Sets Submission Guidelines는 각 사이트가 최대 하나의 Related Website set에만 나타날 수 있음을 요구하며, 이는 제출 시 검증된다. 이러한 이유로 사용자 에이전트는 이러한 단계를 수행할 때 관련 웹사이트 세트 목록의 순서를 신경 쓸 필요가 없다.

단일 관련 웹사이트 세트 내의 associated 사이트에 대한 한계를 구현 정의 값으로 정의하며, 권장값은 3이다.

참고: 이 한계는 associated 사이트에 대한 적격성을 결정할 때 associated 하위 집합의 맨 위에 나열된 사이트들만 고려하는 데 사용된다. 이는 남용을 억제하고 사용자 및 사용자 에이전트가 특정 관련 웹사이트 세트가 존재해야 하는 이유를 이해하는 데 도움을 주기 위한 것이다. 사용자 에이전트는 이 목표에 따라 다른 숫자를 선택할 수 있다.

사이트 embeddedSite는 다음 단계가 true를 반환하는 경우, 사이트 topLevelSite 안에 임베드되었을 때 same-party 멤버십에 적격이다:

1. set을 topLevelSite에 대해 관련 웹사이트 세트를 찾은 결과로 둔다.

2. set이 null이면, false를 반환한다.

3. topLevelType을 set에서 topLevelSite의 멤버 유형으로 둔다.

4. topLevelType이 “associated”이고 topLevelSite와 set가 주어진 상태에서 associated 사이트에 대한 적격성을 결정한 결과가 false이면, false를 반환한다.

5. topLevelType이 “service”이면, false를 반환한다.

6. type을 set에서 embeddedSite의 멤버 유형으로 둔다.

7. type이 “none”이면, false를 반환한다.

8. type이 “associated”이면, embeddedSite와 set가 주어진 상태에서 associated 사이트에 대한 적격성을 결정한 결과를 반환한다.

9. true를 반환한다.

사이트 site 및 관련 웹사이트 세트 set가 주어진 상태에서 associated 사이트에 대한 적격성을 결정하려면, 다음 단계를 실행한다:

1. set의 associatedSites가 site를 포함하지 않으면, false를 반환한다.

2. index를 set의 associatedSites 안에서 site의 인덱스로 둔다.

3. index가 associated 사이트에 대한 한계 이상이면, false를 반환한다.

4. true를 반환한다.

주어진 환경 설정 객체 settings는 다음 단계가 true를 반환하는 경우 그 최상위 임베더와 same-party이다:

1. topLevelSite를 settings의 최상위 출처에서 사이트를 얻은 결과로 둔다.

2. embeddedSite를 settings의 출처에서 사이트를 얻은 결과로 둔다.

3. embeddedSite가 topLevelSite 안에 임베드되었을 때 same-party 멤버십에 적격인지 여부를 반환한다.

주어진 환경 설정 객체 settings와 출처 origin은 다음 단계가 true를 반환하는 경우 임베딩 맥락에서 same-party이다:

1. topLevelSite를 settings의 최상위 출처에서 사이트를 얻은 결과로 둔다.

2. embeddedSite를 origin에서 사이트를 얻은 결과로 둔다.

3. embeddedSite가 topLevelSite 안에 임베드되었을 때 same-party 멤버십에 적격인지 여부를 반환한다.

6. Storage Access API와의 통합

requestStorageAccess()를 수정하여, 단계 13.5 이전(즉 사용 권한을 요청하기 전)에 다음 단계를 삽입한다:

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

2. settings가 그 최상위 임베더와 same-party이면, 사용자 에이전트는 granted로 process permission state를 실행하고 나머지 단계를 중단할 수 있다.

requestStorageAccessFor(requestedOrigin)를 수정하여, 단계 13.8 이전(즉 사용 권한을 요청하기 전)에 다음 단계를 삽입한다:

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

2. settings와 requestedOrigin이 임베딩 맥락에서 same-party이면, 사용자 에이전트는 global이 주어진 상태에서 permissions 태스크 소스의 전역 태스크를 큐에 넣어 p를 resolve하고 나머지 단계를 중단할 수 있다.

7. 관련 웹사이트 세트 변경 처리

새 관련 웹사이트 세트 목록을 구축한 결과 사이트 site가 관련 웹사이트 세트를 떠날 때, 사용자 에이전트는 다음 단계를 실행하여 해당 사이트가 관련 웹사이트 세트 내 다른 사이트가 보유한 데이터 또는 공유 식별자에 대한 접근을 유지하지 않도록 보장해야 한다:

1. site가 불투명 출처가 아님을 단언한다.

2. domain을 site의 호스트로 둔다.

3. 사용자 에이전트가 알고 있는 각 origin 중, 그 호스트의 등록 도메인이 domain인 것에 대해:

   1. 출처에 대한 캐시 지우기.

   2. 출처에 대한 쿠키 지우기.

   3. 출처에 대한 DOM 접근 가능 저장소 지우기.

   4. descriptor를 “storage-access”로 초기화된 name을 가진 새로 생성된 PermissionDescriptor로 둔다.

   5. descriptor에 대해, key[0]이 site이거나 key[1]이 origin인 모든 권한 저장소 항목을 제거한다.

   6. origin에서 웹 접근 가능한 저장소가 제거되도록 보장하기 위해 추가적인 구현 정의 단계를 실행한다.

이 절은 사용자 에이전트가 사이트가 RWS를 떠나는 시점을 파악하는 방법에 대해 더 많은 세부사항을 제공해야 한다. [wicg/first-party-sets Issue #124]

8. 다른 기능과의 통합

사용자 에이전트는 RWS를 통해 선언된 도메인 관계를 다른 구현 정의 목적에 사용할 수 있으며, 이 경우에도 RWS 목록을 소비하고 저장하는 것뿐 아니라 same-party 멤버십에 대한 적격성을 확인하는 것에 대해 이 명세의 나머지 부분을 따라야 한다.

참고: 예를 들어, Chrome의 IP Protection 제안은 first-party 및 third-party 맥락을 결정하기 위한 목적으로 RWS에 의존하는 것을 포함한다.

9. 프라이버시 고려사항

9.1. 사용자 투명성과 제어 제공

RWS를 사용하여 두 사이트 간의 관계를 추론하는 사용자 에이전트는 사용자가 이러한 사용자 에이전트의 선택에 대해 알 수 있도록 하고, 사용자 에이전트가 내린 선택을 보고 제어할 기회를 사용자에게 제공해야 한다.

9.2. 비-RWS 환경과의 호환성 보장

일부 사용자 에이전트는 특정 환경(예: Private Browsing Modes)에서 또는 전혀 RWS를 지원하지 않기로 선택할 수 있다. 모든 사용자 에이전트와 명세는 각자의 API 통합에서 이를 염두에 두고, 사용자와 개발자를 위해 작동하는 해결책으로 우아하게 폴백하는 것을 목표로 해야 한다.

크로스 사이트 쿠키에 대한 접근을 제공하기 위해, 이 명세는 Storage Access API의 사용을 통해 비-RWS 환경과의 호환성을 보장하는 것을 목표로 한다. 이 API는 개발자에게 요청 거부를 처리할 수 있는 인터페이스를 제공하고, 사용자 에이전트에게 RWS의 대안으로 프롬프트나 휴리스틱 같은 메커니즘을 사용할 유연성을 제공한다.

9.3. 목록 변경으로 인한 프라이버시 유출 방지

개발자는 사이트를 추가하거나 제거하기 위해 자신의 세트에 변경 사항을 제출할 수 있다. 세트의 멤버십은 Storage Access API의 자동 grant를 통해 크로스 사이트 쿠키에 대한 접근을 제공할 수 있으므로, 이러한 전환에 주의를 기울여 이들이 과거에 속했던 모든 RWS에 걸쳐 사용자 신원을 연결하지 않도록 해야 한다. 특히 도메인이 세트 멤버십을 변경할 때 하나의 Related Website Set에서 다른 Related Website Set으로 사용자 식별자를 전송할 수 없도록 보장해야 한다. 세트 멤버가 항상 크로스 사이트 쿠키에 대한 접근을 요청하고 grant받는 것은 아니지만, 세트 전환 처리를 단순화하기 위해 그러한 접근이 항상 grant된 것으로 취급할 것을 제안한다.

이러한 이유로, 이 명세는 사이트가 세트에서 제거될 때 사용자 에이전트가 해당 권한 또는 사이트 데이터에 의존하는 fetch를 시작하기 전에, 주어진 사이트의 모든 사이트 데이터와 storage-access 권한을 지울 것을 요구한다.

참고: 대부분의 fetch는 지워야 하는 데이터에 의존하지 않으므로, 사용자 에이전트는 요청 지연 시간에 맞춰 최적화하는 것이 권장된다.

10. 보안 고려사항

10.1. 새로운 및 기존 보안 경계 약화 방지

프라이버시 강화를 위해 경계를 강화하는 웹 플랫폼의 변경은 종종 보안에도 긍정적인 효과를 갖는다. 예를 들어, 캐시 파티셔닝은 Cache Probing 공격을 제한하고, third-party 쿠키 차단은 기본적으로 Cross Site Request Forgery (CSRF)를 수행하기 훨씬 어렵게 만든다. 사용자 에이전트가 Related Website Sets를 사용하여 웹에서 사이트 또는 출처를 기반으로 하는 기존 경계를 대체하거나 확장하려는 경우, 프라이버시에 대한 영향뿐 아니라 보안에 대한 영향도 고려하는 것이 중요하다.

공통 RWS 안의 사이트들은 보안 요구사항이 크게 다를 수 있다. 예를 들어 한 세트에는 사용자 자격 증명을 저장하는 사이트와 신뢰할 수 없는 사용자 데이터를 호스팅하는 다른 사이트가 포함될 수 있다. 같은 세트 안에서도 사이트들은 여전히 데이터 노출을 제어하기 위해 크로스 사이트 및 크로스 출처 제한에 의존한다. 합리적인 범위 내에서, RWS 안의 침해된 사이트가 세트 내 다른 사이트의 무결성에 영향을 미칠 수 있어서는 안 된다.

이 고려사항은 항상 성능 또는 상호운용성 같은 이득과 사용자 및 사이트에 대한 위험 사이의 필수적인 절충을 수반한다. 사용자 에이전트는 이러한 절충을 관리하기 위해 출처별 opt-in 또는 opt-out 같은 추가 메커니즘을 촉진해야 한다.

감사의 글

W3C Privacy Community Group의 다른 멤버들은 이전에 SameParty 쿠키 대신 Storage Access API 또는 동등한 API의 사용을 제안했었다. @jdcauley(1), @arthuredelstein(2), 및 @johnwilander(3)에게 감사한다.

브라우저 벤더, 웹 개발자, 그리고 웹 커뮤니티의 멤버들이 W3C Privacy Community Group에서 이 제안이 인큐베이션되는 동안 귀중한 피드백을 제공했다.

이 제안은 이전 공동 편집자인 David Benjamin 및 Harneet Sidhana의 상당한 기여를 포함한다.

또한 Chris Fredrickson 및 Shuran Huang의 기여에 감사한다.