사이트 데이터 삭제

4. 알고리즘

4.1. 파싱

response가 주어졌을 때, 사용자 에이전트는 response의 Clear-Site-Data 헤더 파싱을 다음과 같이 수행하여 타입 리스트를 반환할 수 있습니다:

1. types를 빈 리스트로 한다.

2. header를 extracting header list values 결과로 한다. 입력은 Clear-Site-Data, response의 header list.

3. header가 null 또는 실패라면 빈 리스트를 반환한다.

4. header의 각 type에 대해, 첫 번째로 일치하는 문장 실행(스위치):

   `"cache"`

   cache를 types에 추가.

   `"cookies"`

   cookies를 types에 추가.

   `"storage"`

   storage를 types에 추가.

   `"executionContexts"`

   executionContexts를 types에 추가.

   `"*"`

   cache, cookies, storage, executionContexts를 types에 모두 추가.

5. types를 반환.

참고: 기존 값들은 위와 같이 단순한 스위치로 처리할 수 있습니다. 더 복잡한 타입 정의가 생기면, 파서는 전적으로 JSON 방식으로 전환될 수 있습니다.

4.2. response의 데이터 삭제

response(response)가 주어졌을 때, 사용자 에이전트는 response에 대한 사이트 데이터 삭제를 다음과 같이 수행할 수 있습니다:

1. response의 url이 a priori 인증된 URL이 아니라면, break한다.

2. types를 파싱한 response의 Clear-Site-Data 헤더 결과로 한다.

3. origin을 response의 url의 origin으로 한다.

4. browsing contexts를 해당 origin과 types에 대한 데이터 삭제 준비 결과로 한다.

5. types의 각 type에 대해:

   1. 첫 번째 일치 문장 실행(스위치):

      "cache"

      origin의 캐시 삭제

      "cookies"

      origin의 쿠키 삭제

      "storage"

      origin의 DOM 접근 가능한 저장소 삭제

6. types에 "executionContexts"가 포함되어 있다면, browsing contexts를 리로드한다.

참고: 사용자 에이전트는 웹 개발자가 삭제 작업을 디버깅할 수 있도록, (성공시) 콘솔 메시지 또는 타임라인 항목 등의 메커니즘을 제공하는 것이 권장됩니다.

4.2.1. origin의 데이터 삭제 준비

origin(origin)과 타입 리스트(types)가 주어졌을 때, 사용자 에이전트는 origin의 데이터 삭제 준비를 다음 단계로 수행합니다. 이 알고리즘은, 인-메모리 JavaScript 변수로부터 삭제된 데이터를 복구하는 것을 방지하기 위해 샌드박싱된 브라우징 컨텍스트 리스트를 반환합니다.

1. sandboxed를 빈 리스트로 한다.

2. types에 "executionContexts"가 없다면 sandboxed를 반환한다.

3. 각 context(사용자 에이전트의 브라우징 컨텍스트 집합 내)에 대해:

   1. document를 context의 활성 문서로 한다.

   2. document의 relevant settings object의 origin이 origin이 아니라면, continue.

   3. 빈 문자열을 입력값으로 하여 샌드박싱 지시문 파싱을 하고, document의 active sandboxing flag set에 출력한다.

   4. context를 sandboxed에 추가한다.

4. sandboxed를 반환한다.

4.2.2. browsing contexts 다시 불러오기

browsing contexts (contexts) 리스트가 주어졌을 때, 사용자 에이전트는 다음과 같이 browsing contexts를 다시 불러오기를 실행할 수 있습니다:

1. contexts의 각 context에 대하여:

   1. context의 active document의 relevant settings object의 global object의 Location 객체의 reload()를 실행한다.

      이 방법이 가장 단순하지만, 아마도 문서 안쪽까지 너무 깊게 관여하는 것일 수 있다. HTML에서 관련 부분을 복사하여 작성하는 편이 낫겠음.

4.2.3. origin의 캐시 삭제

origin (origin)이 주어졌을 때, 사용자 에이전트는 다음과 같이 origin의 캐시 삭제를 실행할 수 있습니다:

1. host를 origin의 host로 설정한다.

2. cache list를 network cache에서 target URI의 host가 host와 동일한 엔트리의 집합으로 한다.

3. cache list의 각 entry에 대하여:

   1. entry를 network cache에서 제거한다.

4. 사용자 에이전트가 순수 network cache 이외의 캐시를 구현했다면, 반드시 origin에 일치하는 해당 캐시의 모든 엔트리도 제거해야 한다.

   여기서는 [RFC7234]에 정의된 network cache에만 다루지만, 실제로는 사용자 에이전트가 캐시하는 모든 것은 아니다. 벤더별 섹션에서 어느 정도 추상적으로 기술할 수 있을까? 예를 들어, Chrome은 프리렌더 페이지, 스크립트 캐시, WebGL 셰이더 캐시, WebRTC 조각, 주소 창 제안 캐시 등 다양한 네트워크 외 캐시도 모두 삭제한다. 아마도 [STORAGE]에서 더 명확해질 수 있음.

4.2.4. origin의 쿠키 삭제

origin (origin)이 주어졌을 때, 사용자 에이전트는 다음과 같이 origin의 쿠키 삭제를 실행할 수 있습니다:

참고: 전체 등록 도메인의 모든 쿠키를 삭제합니다. 쿠키는 same-origin 정책을 무시하므로, 특정 서브도메인만 쿠키를 삭제하는 경우 애플리케이션이 비정의 상태에 놓일 수 있습니다. 예를 들어, accounts.google.com과 mail.google.com은 모두 사용자의 로그인 상태를 나타내는 쿠키를 가짐.

참고: 이 알고리즘은 사용자 에이전트가 cookie store를 구현한다고 가정합니다([RFC6265] 5.3절 참고). 이를 통해 호스트별 쿠키 리스트를 얻고 개별 쿠키를 삭제할 수 있습니다.

1. registered를 origin의 등록 도메인으로 한다(host 기준).

2. cookie list를 cookie store에서 domain 속성이 registered와 domain-match인 쿠키들의 집합으로 한다.

3. cookie list의 각 cookie에 대하여:

   1. cookie를 cookie store에서 삭제한다.

4. 사용자 에이전트가 쿠키 유사 저장소를 추가로 지원하는 경우, 반드시 origin의 host가 등록 도메인이 registered인 경우 모두 삭제해야 함.

   참고: 예) 사용자 에이전트가 Flash를 지원하면, local stored object는 NPP_ClearSiteData로 삭제됨.

5. [CHANNELID] 및 [TOKBIND]의 바운드 토큰, Channel ID도 origin의 등록 도메인 registered에 대해 삭제해야 함.

6. authentication entry와 proxy-authentication entry도 origin의 등록 도메인 registered에 대해 삭제해야 함.

토큰/ID와 HTTP 인증 삭제 과정이 설명이 불충분함. <https://github.com/w3c/webappsec-clear-site-data/issues/2>

4.2.5. origin의 DOM 접근 가능한 저장소 삭제

origin (origin)이 주어졌을 때, 사용자 에이전트는 다음과 같이 origin의 DOM 접근 가능한 저장소 삭제를 수행할 수 있습니다:

1. 사용자 에이전트의 local storage areas 집합의 각 area에 대하여 [HTML]:

   1. area의 origin이 origin이면:

      1. area에 연관된 Storage 객체의 clear()를 실행한다.

2. 사용자 에이전트의 session storage areas 집합의 각 area에 대하여 [HTML]:

   1. area의 origin이 origin이면:

      1. area에 연관된 Storage 객체의 clear()를 실행한다.

3. databases 집합 중 origin에 해당하는 각 database에 대하여 [INDEXEDDB]:

   1. database 삭제.

4. 사용자 에이전트의 service worker registrations 집합의 각 registration에 대해:

   1. registration의 scope URL origin이 origin이면:

      1. registration에 unregister()를 실행한다.

5. 사용자 에이전트의 application caches 집합의 각 appcache에 대해:

   1. appcache의 application cache group이 origin이 origin인 URL로 식별되면:

      1. appcache를 폐기한다.

6. 다른 script 접근 가능 저장소 메커니즘에 대해서도, 사용자 에이전트는 반드시 해당 origin에 연관된 모든 데이터를 삭제해야 한다. 이는 다음을 포함(한정되지 않음):

   1. origin의 WebSQL 데이터베이스 [WEBDATABASE]

   2. origin의 파일시스템 [file-system-api]

   3. 플러그인 데이터(예: Flash는 NPP_ClearSiteData를 통해)

   4. 더 추가?

5. 보안 고려 사항

5.1. 완전하지 않은 삭제

저장소 유형 하나만 삭제하면 애플리케이션이 불확정 상태가 될 수 있습니다. 이를 방지하고자, 모든 저장소를 블록 단위로 삭제하고, 헤더는 반드시 보안 연결을 통해 전달하도록 요구합니다.

5.2. Service workers

Clear-Site-Data 헤더는 반드시 네트워크에서 가져온 응답에만 적용되어야 하며, service worker가 제공하는 응답에는 적용하지 않아야 합니다.

Service worker는 자신의 범위 내에서 third-party 요청을 포함해, 임의의 응답을 반환할 수 있기 때문입니다. Clear-Site-Data를 지원하면, 이들은 임의의 오리진의 데이터를 삭제할 수 있는 권한을 얻게 됩니다.

요청이 service worker로 전송되었지만 처리되지 않고, service-workers mode가 "none"인 상태로 다시 네트워크에 요청된다면, 그 응답은 네트워크 응답으로 간주하며 처리할 수 있습니다. service worker에서 응답을 얻으려던 시도는 무관합니다.

또한 service worker의 업데이트는 네트워크 응답이므로 이 제한의 영향을 받지 않습니다. 이는 §1.1.4 Kill Switch의 사용 사례를 지원하는 데 중요합니다.

6. 프라이버시 고려 사항

6.1. 웹 개발자가 타이밍을 제어

적절한 시점에 트리거된다면, Clear-Site-Data는 사용자의 에이전트에서 민감한 데이터를 삭제하여 프라이버시와 보안을 높여줄 수 있습니다. 하지만, 삭제 이벤트의 트리거는 웹 개발자가 제어하며(사용자가 아님), 악의적이지 않은 사이트라 하더라도 사용자는 삭제 시점이나 삭제되는 데이터 유형을 제어할 수 없습니다.

특정 시점에 실제로 사이트 데이터가 삭제되었는지 확실히 보장하려면, 사용자는 사용자 에이전트의 데이터 삭제 기능을 사용해야 합니다.

최소한, 사용자 에이전트는 웹 개발자에 제공하는 기능을 동일하게 사용자에게도 제공해야 합니다([RFC6919] 의미의 OUGHT TO). 플랫폼 수준에서 제공하지 못하는 기능(예: 방문 기록 삭제 등)까지 더 많이 제공하는 것이 이상적입니다.

6.2. 디스크에 남은 데이터 자국

Clear-Site-Data가 사용자 에이전트에서 삭제 이벤트를 트리거하지만, 삭제 이후 사용자의 디스크에 대한 상태를 보장하기는 어렵습니다. 특히, 사이트의 모든 데이터 흔적을 디스크에서 완전히 삭제하는 것은 사용자 에이전트에게 맡겨지며, 이는 현실적으로 거의 불가능한 문제입니다(예로 가상 메모리 등).

즉, 대부분의 사용자 에이전트는 데이터 삭제를 "최대한" 구현하지만, 완전한 삭제를 보장하지 못합니다.

디스크에 사이트 데이터가 절대로 남지 않게 하려면, 데이터를 디스크에 의도적으로 기록하지 않기로 약속된 브라우징 모드(예: Chrome의 "Incognito", IE의 "InPrivate" 등)를 사용하는 것이 최선입니다. 이러한 모드는 실제로 데이터를 디스크에 남기지 않도록 더 잘 동작하나, 완전한 제거는 근본적 한계에 여전히 직면할 수 있습니다.

7. IANA 고려사항

영구 메시지 헤더 필드 레지스트리는 다음 등록 정보로 업데이트되어야 합니다: [RFC3864]

7.1. Clear-Site-Data

Header 필드 이름

Clear-Site-Data

적용 프로토콜

http

상태

standard

작성자/변경 관리

W3C

명세 문서

이 명세(See §3.1 The Clear-Site-Data HTTP Response Header Field)