2024년부터 서드 파티 쿠키 지원 중단에 대비해 많은 개인 정보 보호 샌드박스 API가 Chrome 안정화 버전 (GA)으로 단계적으로 확대되고 있습니다. 이러한 API 중 일부는 CHIPS와 같은 중요한 크로스 사이트 쿠키 사용 사례와 현재 퍼스트 파티 세트 (FPS)로 알려진 API를 보존하는 데 도움이 됩니다. 이 게시물에서는 목적을 더 잘 반영하는 FPS의 새로운 이름인 RWS (관련 웹사이트 세트)를 소개하고 관련 하위 집합 도메인 제한에 대한 업데이트와 함께 주요 사용 사례를 복습합니다.
중요한 사용자 여정 유지
RWS는 Chrome이 기본적으로 서드 파티 쿠키에 대한 액세스를 제한하기 시작하면 특정 사용자 대상 기능의 중단을 최소화하도록 설계되었습니다. Google의 목표는 사용자가 개인 정보 보호 샌드박스의 개인 정보 보호 목표를 유지하면서도 중단을 최소화하면서 웹을 탐색할 수 있도록 하는 것입니다. 균형을 맞추기 위해 RWS는 웹사이트 기능과 관련된 특정 사용 사례를 타겟팅합니다.
- ccTLD 사용 사례는 Google의 공개 추적기에 제출된 로그인 예와 같은 손상을 해결합니다. 이러한 사례는 휴리스틱 기반 예외를 통해 생태계에서 해결하는 경우가 많습니다 (참조 1 참고).
- 서비스 도메인 사용 사례는 민감한 기능 (예: 인증 흐름 지원)을 사용자 대상 도메인에서 분리하기 위한 일반적인 개발자 관행을 다룹니다. 이러한 사례는 타겟팅된 예외를 통해 생태계 내에서 해결할 수 있습니다 (참조 2 참고).
- 관련 도메인 사용 사례는 중요한 사용자 여정을 위해 서드 파티 쿠키 액세스가 필요할 수 있는 도메인 유형에 더 많은 유연성을 제공합니다 (참조 3 참고). ccTLD 및 서비스 도메인 사용 사례에서는 악용을 최소화하기 위해 도메인 특성을 기반으로 엄격한 기술 검사를 사용하지만 관련 도메인은 숫자 제한을 사용합니다. 다음 섹션에서 자세히 알아보세요.
연결된 도메인 한도가 5개로 증가됨
Chrome은 광범위한 추적 악용을 방지하려는 Google의 목표에 따라, 이전에 연결된 하위 집합에 도메인 3개 (기본 도메인 1개 포함)의 숫자 제한을 제안했습니다. Google은 웹 표준 참가자들로부터 여러 유형의 사용 사례에 비해 한도가 너무 낮다는 의견을 받았습니다.
Google에서는 관련 도메인 한도를 다른 주요 브라우저에서 제공하는 가장 유사한 구현과 가장 일치하는 5개 도메인 (기본 도메인 1개 포함)으로 늘리기로 결정했습니다 (참조 4 참고). 이 변경사항은 Chrome 117부터 적용됩니다.
RWS는 광고 솔루션이 아니므로 Google에서는 광고 사용 사례를 개선하기 위해 RWS를 개선하는 방법에 관한 의견을 고려하지 않습니다. 광고 사용 사례의 경우 개발자는 Topics, Protected Audience, Attribution Reporting API 사용을 살펴보고 그에 따라 의견을 제공해야 합니다.
사용자는 5개의 연결된 도메인 이외의 확장된 사용 사례를 선택할 수 있습니다.
이 한도로 지원되지 않는 사용자에게 영향을 미치는 환경을 지원하기 위해 Chrome은 다른 브라우저에서 채택한 표준인 Storage Access API (SAA)도 활용하는 사용자 메시지 흐름에서 작업 중입니다. 5개 이상의 연결된 도메인이 필요한 사용 사례의 경우 개발자는 RWS 이외의 컨텍스트에서 SAA가 어떻게 지원되는지 평가하는 것이 좋습니다. Google은 이 기능과 관련하여 Blink 출시 프로세스를 별도로 따르고 있으며, Chrome 117부터 Chrome 데스크톱에 출시될 예정입니다.
다음 단계
지금까지 API를 완성하는 데 도움이 된 생태계의 의견을 보내주셔서 감사합니다. Google은 개발자가 빌드하는 웹사이트의 최종 사용자 환경을 유지하는 데 필요한 예측 가능성, 제어 기능, 대행사를 제공하는 방법으로 RWS에 투자해 왔습니다. 개발자들이 RWS를 채택하고 사용하는 방식이 더욱 중요해지고 있습니다. 현재 제출 절차가 진행 중이며 RWS JSON 생성기 도구를 사용해 제출에 도움을 받을 수 있습니다.
배송 인텐트에 따라 진행 상황을 추적하고 이 자료에서 구현 안내를 확인하세요.
참조
- 이러한 크로스 사이트 쿠키 사용 사례가 필요하다는 것은 브라우저 간에 일반적으로 일관하지만 실제로는 이를 지원하는 접근 방식이 다릅니다. Firefox (code) 및 Safari (code)는 모두 Nintendo 로그인 흐름에서 관찰된 중단을 해결하는 팝업 휴리스틱을 구현했습니다.
- 브라우저에서 사용자의 혼란을 최소화하기 위해 예외를 하드 코딩하는 사례도 있습니다. Firefox는 Microsoft Teams와 Login.microsoftonline.us 간 리디렉션 흐름에 대한 저장소 액세스 권한을 부여합니다.
- Firefox에서는 사용자가 instagram.com에 로그인할 때 facebook.com을 대신하여 requestStorageAccessForOrigin을 호출하는 'shim'을 제공합니다. 사이트 그룹화의 예는 Safari의 하드 코딩 예외에서 여러 도메인의 스토리지 액세스 프롬프트를 그룹화하기 위한에서도 확인할 수 있습니다.
- Firefox는 사용자가 이전에 방문한 타사 사이트에서 처음 5개의 requestStorageAccess 호출을 자동 부여 (코드)합니다. Chrome에서는 동일한 세트의 기본 도메인 외에 연결된 하위 집합에 나열된 처음 5개 도메인에 RWS를 통해 서드 파티 쿠키 액세스가 자동으로 부여됩니다.