이 페이지는 Cloud Translation API를 통해 번역되었습니다.

독립적인 파티션 상태가 있는 쿠키 (CHIPS)

개발자가 최상위 사이트마다 별도의 쿠키 jar를 사용하여 '파티션을 나눈' 저장소에 쿠키를 선택하도록 허용합니다.

구현 상태

브라우저 지원

Chrome 114 이상에서 기본적으로 지원됩니다.
현재 완료된 오리진 트라이얼이 Chrome 100~116에서 제공되었습니다.
실험 의도 및 배송 의도를 읽습니다.

CHIPS란 무엇인가요?

CHIPS (Independent Partitioned State)를 사용하는 개발자는 쿠키를 분할된 저장소에 선택하여 최상위 사이트별로 별도의 쿠키 jar를 사용하여 사용자 개인 정보 보호와 보안을 개선할 수 있습니다.

파티션 나누기 없이 서드 파티 쿠키를 사용하면 서비스에서 사용자를 추적하고 관련 없는 여러 최상위 사이트에서 사용자의 정보를 조인할 수 있습니다. 이를 크로스 사이트 추적이라고 합니다.

브라우저는 파티션으로 나누지 않은 서드 파티 쿠키에 대한 지원을 단계적으로 중단하고 있으므로 서드 파티 쿠키가 차단된 경우 CHIPS, Storage Access API, 관련 웹사이트 세트를 사용해야만 iframe과 같은 크로스 사이트 컨텍스트에서 쿠키를 읽고 쓸 수 있습니다.

2개의 서로 다른 웹사이트 간에 Cookes를 공유하는 방법을 보여주는 다이어그램 — 쿠키 파티션 나누기를 사용하지 않으면 서드 파티 서비스가 하나의 최상위 사이트에 삽입된 경우 쿠키를 설정하고 다른 최상위 사이트에 삽입된 경우 동일한 쿠키에 액세스할 수 있습니다.

CHIPS는 최상위 컨텍스트로 파티션을 나눈 크로스 사이트 쿠키를 지원하기 위해 새로운 쿠키 속성인 Partitioned를 도입했습니다.

Set-Cookie 헤더:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

자바스크립트:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

파티션을 나눈 서드 파티 쿠키는 처음 설정되는 최상위 사이트에 연결되며, 다른 곳에서는 액세스할 수 없습니다. 이렇게 하면 타사 서비스에 의해 설정된 쿠키는 처음 설정된 최상위 사이트의 동일한 삽입된 컨텍스트 내에서만 읽을 수 있습니다.

공통 서드 파티가 포함된 두 개의 다른 웹사이트가 더 이상 해당 서드 파티의 쿠키를 공유하지 않음을 보여주는 다이어그램 — 쿠키 파티션 나누기를 사용하면 하나의 최상위 사이트에 삽입된 서드 파티 서비스가 쿠키를 설정하는 서드 파티 서비스가 다른 최상위 사이트에 삽입된 해당 쿠키에 액세스할 수 없습니다.

파티셔닝된 쿠키를 사용하면 사용자가 사이트 A를 방문하고 사이트 C에서 삽입된 콘텐츠가 Partitioned 속성이 있는 쿠키를 설정하면 쿠키는 사이트 A에 삽입될 때 사이트 C가 설정하는 쿠키 전용으로 지정된 파티션을 나눈 jar에 저장됩니다. 브라우저는 최상위 사이트가 A인 경우에만 해당 쿠키를 전송합니다.

사용자가 새 사이트(예: 사이트 B)를 방문할 때 삽입된 C 프레임은 사이트 A에 C가 삽입되었을 때 설정된 쿠키를 수신하지 않습니다.

사용자가 최상위 웹사이트로 사이트 C를 방문하는 경우 A에 삽입될 때 C가 설정한 파티션을 나눈 쿠키도 해당 요청에서 전송되지 않습니다.

동일한 서드 파티가 2개의 서로 다른 웹사이트에 삽입된 경우 쿠키가 공유되지 않음을 보여주는 다이어그램 — 쿠키 파티션 나누기를 사용하면 사이트에 삽입된 쿠키를 설정하는 서드 파티 서비스에서 사용자가 최상위 사이트로 서비스를 방문하더라도 동일한 쿠키에 액세스할 수 없습니다.

사용 사례

예를 들어 retail.example 사이트에서 서드 파티 서비스 support.chat.example와 협력하여 사이트에 지원 채팅 상자를 삽입할 수 있습니다. 오늘날 많은 삽입 가능한 채팅 서비스가 상태를 저장하기 위해 쿠키를 사용합니다.

채팅 위젯이 삽입된 웹사이트를 보여주는 다이어그램 — 서드 파티 서비스가 삽입된 최상위 사이트 Retail.example `support.chat.example`입니다.

크로스 사이트 쿠키를 설정하는 기능이 없으면 support.chat.example는 상태를 저장할 대체 메서드(종종 더 복잡함)를 찾아야 합니다. 또는 support.chat.example 스크립트가 Retail.example에 대한 승격된 권한(예: 인증 쿠키 액세스 기능)을 가질 수 있도록 허용하기 때문에 위험을 초래하는 최상위 페이지에 삽입해야 합니다.

CHIPS는 파티셔닝되지 않은 쿠키와 관련된 위험 없이 크로스 사이트 쿠키를 계속 사용할 수 있는 더 쉬운 옵션을 제공합니다.

CHIPS의 사용 사례로는 다음과 같이 크로스 사이트 하위 리소스에 단일 최상위 사이트의 사용자 활동으로 범위가 지정된 세션 또는 지속적인 상태 개념이 필요한 시나리오가 있습니다.

서드 파티 채팅 삽입
타사 지도 삽입
서드 파티 결제 삽입
하위 리소스 CDN 부하 분산
헤드리스 CMS 제공업체
신뢰할 수 없는 사용자 콘텐츠를 제공하기 위한 샌드박스 도메인 (예: googleusercontent.com 및 githubusercontent.com)
퍼스트 파티 사이트의 인증 상태에 의해 액세스가 제어되는 콘텐츠를 제공하기 위해 쿠키를 사용하는 서드 파티 CDN (예: 서드 파티 CDN에서 호스팅되는 소셜 미디어 사이트의 프로필 사진)
요청에 쿠키를 사용하는 원격 API에 의존하는 프런트엔드 프레임워크
게시자별 상태 범위가 필요한 삽입된 광고 (예: 해당 웹사이트에 대한 사용자의 광고 환경설정 파악)

CHIPS가 선택형 파티션 나누기 모델을 사용하는 이유

브라우저가 파티션으로 나누지 않은 서드 파티 쿠키를 단계적으로 폐지함에 따라, 파티션 나누기에 대해 몇 가지 다른 접근 방식을 시도했습니다.

Firefox는 모든 크로스 사이트 쿠키가 최상위 사이트에 의해 파티셔닝되도록 ETP 엄격 모드와 시크릿 브라우징 모드에서 기본적으로 모든 서드 파티 쿠키의 파티션 나누기를 발표했습니다. 그러나 일부 서드 파티 서비스에서는 파티셔닝되지 않은 서드 파티 쿠키를 기대하는 서버를 구축했기 때문에 서드 파티 선택 없이 쿠키를 파티셔닝하면 예기치 않은 버그가 발생할 수 있습니다.

Safari는 이전에 휴리스틱을 기반으로 쿠키 파티션 나누기를 시도했지만 결국에는 개발자의 혼란을 이유 중 하나로 언급하며 쿠키를 모두 차단하기로 했습니다. 최근에 Safari는 선택 기반 모델에 관심을 보였습니다.

CHIPS가 분할 쿠키의 기존 구현과 차별화되는 점은 서드 파티 수신 동의입니다. 파티셔닝되지 않은 서드 파티 쿠키가 사라진 후에 크로스 파티 요청에 쿠키를 전송하려면 새로운 속성으로 쿠키를 설정해야 합니다.

서드 파티 쿠키가 여전히 존재하지만 Partitioned 속성을 사용하면 더 제한적이고 안전한 유형의 쿠키 동작을 선택할 수 있습니다. CHIPS는 서비스에서 서드 파티 쿠키가 없는 미래로 원활하게 전환할 수 있도록 지원하는 중요한 단계입니다.

쿠키 파티셔닝 기술 설계

현재 쿠키는 쿠키를 설정하는 사이트의 호스트 이름 또는 도메인, 즉 호스트 키에 키가 지정됩니다.

예를 들어 https://support.chat.example의 쿠키의 경우 호스트 키는 ("support.chat.example")입니다.

CHIPS에서는 파티션 나누기를 선택하는 쿠키는 호스트 키와 파티션 키를 이중으로 지정합니다.

쿠키의 파티션 키는 쿠키를 설정하는 엔드포인트에 대한 요청을 시작할 때 브라우저가 방문 중이던 최상위 URL의 사이트 (스키마 및 등록 가능한 도메인)입니다.

https://support.chat.example가 https://retail.example에 삽입된 이전 예에서 최상위 URL은 https://retail.example입니다.

이 경우 파티션 키는 ("https", "retail.example")입니다.

마찬가지로 요청의 파티션 키는 브라우저가 요청 시작 시 방문하는 최상위 URL의 사이트입니다. 브라우저는 해당 쿠키와 파티션 키가 동일한 요청에서 Partitioned 속성이 있는 쿠키만 전송해야 합니다.

앞에서 예로 든 쿠키 키는 CHIPS 전과 후의 모습입니다.

사이트 A와 삽입된 사이트 C는 파티셔닝된 쿠키를 공유합니다. 삽입되지 않으면 사이트 C는 파티션을 나눈 쿠키에 액세스할 수 없습니다. — 사이트 A와 삽입된 사이트 C는 파티션을 나눈 쿠키를 공유합니다. 삽입되지 않으면 사이트 C는 파티션을 나눈 쿠키에 액세스할 수 없습니다.

CHIPS 이전

key=("support.chat.example")

CHIPS 이후

key={("support.chat.example"),("https", "retail.example")}

보안 설계

우수한 보안 관행을 장려하기 위해 CHIPS에서는 쿠키가 보안 프로토콜을 통해서만 설정되고 전송됩니다.

파티션을 나눈 쿠키는 Secure로 설정해야 합니다.
파티션을 나눈 쿠키를 설정할 때는 등록 가능한 도메인이 아닌 호스트 이름에 바인딩되도록 __Host 접두사를 사용하는 것이 좋습니다.

예:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

참고: SameSite=None를 추가하면 브라우저 설정에서 서드 파티 쿠키가 허용되는 한 Partitioned 속성이 지원되지 않는 서드 파티 컨텍스트에서 쿠키를 전송할 수 있습니다.

CHIPS의 대안

Storage Access API 및 관련 관련 웹사이트 세트 (RWS)는 특정 사용자에게 표시되는 목적으로 제한된 교차 사이트 쿠키 액세스를 지원하는 웹 플랫폼 메커니즘입니다.

이는 크로스 사이트(파티션을 나누지 않은 쿡)에 액세스해야 하는 CHIPS 파티션 나누기의 대안입니다.

여러 관련 사이트에 삽입된 서비스에서 동일한 쿠키를 사용해야 하는 경우에는 Storage Access API 및 관련 웹사이트 세트를 고려해 보세요.

CHIPS는 서비스가 여러 사이트에서 격리된 구성요소 역할을 하는 기능을 제공하므로 여러 사이트에서 동일한 쿠키를 사용할 필요가 없습니다. 서비스가 파티셔닝된 쿠키를 설정하는 경우 파티션 키는 최상위 사이트가 되며 해당 쿠키는 서비스를 사용하는 다른 사이트에서 사용할 수 없습니다.

관련 웹사이트 세트 설계는 Storage Access API를 사용하며 CHIPS 파티션 나누기와 통합되지 않습니다. RWS 내의 사이트 전반에서 공유된 쿠키 파티션을 사용하는 사용 사례가 있다면 GitHub 문제에 관한 예와 의견을 제공할 수 있습니다.

데모

이 데모에서는 파티션을 나눈 쿠키의 작동 방식과 DevTools에서 쿠키를 검사하는 방법을 안내합니다.

사이트 A는 자바스크립트를 사용하여 분할된 쿠키와 파티셔닝되지 않은 쿠키인 사이트 B의 iframe을 삽입합니다. 사이트 B는 document.cookie를 사용하여 해당 위치에서 액세스할 수 있는 모든 쿠키를 표시합니다.

서드 파티 쿠키가 차단되면 사이트 B는 크로스 사이트 컨텍스트에서 Partitioned 속성을 통해서만 쿠키를 설정하고 액세스할 수 있습니다.

서드 파티 쿠키가 허용되는 경우 사이트 B도 파티션을 나누지 않은 쿠키를 설정하고 액세스할 수 있습니다.

사이트 A 및 사이트 B — 왼쪽: 서드 파티 쿠키가 차단됨. 오른쪽: 서드 파티 쿠키가 허용됩니다.

기본 요건

Chrome 118 이상
chrome://flags/#test-third-party-cookie-phaseout에서 이 설정을 사용 설정하세요.

DevTools를 사용하여 파티션을 나눈 쿠키 검사하기

https://chips-site-a.glitch.me를 방문합니다.
Control+Shift+J (Mac의 경우 Command+Option+J)를 눌러 DevTools를 엽니다.
Application 탭을 클릭합니다.
Application > Storage > Cookies로 이동합니다.
https://chips-site-b.glitch.me 아이콘을 클릭합니다.

그러면 DevTools가 선택한 출처의 모든 쿠키를 표시합니다.

사이트 B는 크로스 사이트 컨텍스트에서만 파티션을 나눈 쿠키를 설정할 수 있으며 파티션을 나누지 않은 쿠키는 차단됩니다.

최상위 사이트 https://chips-site-a.glitch.me의 파티션 키와 함께 __Host-partitioned-cookie가 표시되어야 합니다.

__Host-partitioned-cookie의 파티션 키입니다.

사이트 B로 이동을 클릭합니다.
DevTools에서 애플리케이션 > 저장소 > 쿠키로 이동합니다.
https://chips-site-b.glitch.me 아이콘을 클릭합니다.

이 시나리오에서는 최상위 컨텍스트의 사이트 B에 있으므로 사이트 B가 다음 두 쿠키를 모두 설정하고 액세스할 수 있습니다.

unpartitioned-cookie의 파티션 키가 비어 있습니다.
__Host-partitioned-cookie 쿠키에는 파티션 키 https://chips-site-b.glitch.me이 있습니다.

최상위 사이트로 B를 방문했을 때 DevTools Application 탭에 있는 사이트 B의 쿠키입니다. __Host-partitioned-cookie에는 파티션 키 https://chips-site-b.glitch.me가 있습니다.

이제 사이트 A로 돌아가면 unpartitioned-cookie이(가) 브라우저에 저장되지만 사이트 A에서는 액세스할 수 없습니다.

사이트 A로 이동을 클릭합니다.
네트워크 탭을 클릭합니다.
https://chips-site-b.glitch.me 아이콘을 클릭합니다.
Cookies(쿠키) 탭을 클릭합니다.

사이트 A에 있는 동안 최상위 사이트 https://chips-site-a.glitch.me의 파티션 키와 함께 __Host-partitioned-cookie가 표시됩니다.

사이트 A에 삽입될 때 액세스할 수 있는 사이트 B iframe의 쿠키가 표시된 네트워크 탭

필터링된 쿠키 요청 표시를 선택하면 DevTools에서 파티션을 나누지 않은 쿠키가 차단되었음을 표시하며 '사용자 환경설정으로 인해 차단된 쿠키입니다'라는 도움말과 함께 노란색으로 강조표시됩니다.

참고: 최상위 사이트로 B를 방문했으므로 사이트 B에는 이 컨텍스트에서는 사용할 수 없는 파티션 키 https://chips-site-b.glitch.me의 파티션을 나눈 쿠키도 있습니다. 따라서 '이 사이트에 이 요청과 함께 전송되지 않은 다른 파티션에 쿠키가 있습니다.'

라는 메시지가 표시됩니다.

Application > Storage > Cookies에서 https://chips-site-b.glitch.me를 클릭하면 다음과 같이 표시됩니다.

unpartitioned-cookie를 빈 파티션 키로 바꿉니다.
파티션 키 https://chips-site-a.glitch.me이 있는 __Host-partitioned-cookie 쿠키.

DevTools Application 탭에 있는 사이트 B의 쿠키. `__Host-partitioned-cookie` 쿠키에는 파티션 키 `https://chips-site-a.glitch.me`이 있습니다. `unpartitioned-cookie`가 표시되지만, 사이트 A에 삽입되면 사이트 B iframe에 액세스할 수 없습니다.

쿠키 삭제

데모를 재설정하려면 다음과 같이 사이트의 모든 쿠키를 지우세요.

Control+Shift+J (Mac의 경우 Command+Option+J)를 눌러 DevTools를 엽니다.
Application 탭을 클릭합니다.
Application > Storage > Cookies로 이동합니다.
https://chips-site-b.glitch.me을 마우스 오른쪽 버튼으로 클릭합니다.
Clear(삭제)를 클릭합니다.

자료

GitHub: 설명서를 읽고 질문을 올리고 토론을 팔로우합니다.
개발자 지원: 개인 정보 보호 샌드박스 개발자 지원 저장소에서 질문하고 토론에 참여하세요.