퍼스트 파티 세트 (FPS)는 Chrome의 서드 파티 쿠키 지원 중단 후 사용자의 웹 탐색 환경을 지원하도록 설계되었습니다. 이 제안서는 FPS 인큐베이션 기간 동안 오픈 웹 포럼에서 크게 발전했습니다. 처음에는 W3C의 개인 정보 보호 커뮤니티 그룹에 참여했고 현재는 웹 인큐베이터 커뮤니티 그룹에 참여했습니다.
이 블로그 게시물에서는 진화 과정을 요약하고 주요 변경사항을 강조하며, 이러한 변화가 웹 생태계를 지속적으로 지원하는 동시에 웹의 개인 정보 보호를 개선한다고 생각하는 이유를 설명합니다.
배경
사이트에서는 사용자에게 원활한 맞춤형 환경을 제공하기 위해 서드 파티 컨텍스트에서 쿠키에 액세스하는 경우가 많습니다. Chrome팀은 개인 정보 보호 광고 API (Topics, Protected Audience API, Attribution) 외에도 사용자에게 향상된 탐색 환경을 제공하기 위해 광고 개인 최적화 또는 측정 목적 외에 서드 파티 쿠키가 사용되는 시나리오의 범위를 파악하고자 했습니다.
Google은 조직의 웹 아키텍처가 여러 도메인을 활용하도록 설계되었기 때문에 조직에서 서드 파티 쿠키를 사용할 수 있음을 발견했습니다. 예를 들어 하이킹 블로그용 도메인과 캠핑 매장용 도메인을 각각 하나씩 가지고 있는 조직에서 이러한 사이트 간의 사용자 여정을 지원하려고 할 수 있습니다. 조직은 웹 서비스의 공유 인프라를 사용하여 여러 국가 코드 도메인을 유지관리할 수도 있습니다. 이와 같은 사례를 위해 Google은 웹에서 개인 정보 보호에 대한 사용자의 기대치를 유지하면서 이러한 조직의 요구사항에 부합하는 솔루션을 만들기 시작했습니다.
처음
브라우저에서는 현재 사이트 수준 경계를 사용하여 '퍼스트 파티'와 '서드 파티'를 해석하므로 조직에서 관리할 수 있는 도메인의 범위를 감안하여 이 기술적 경계를 보다 미묘한 정의로 대체하는 것이 적절해 보입니다.
2021년에 Chrome은 사이트가 '동일 당사자' 내의 사이트에서 발생하는 쿠키를 정의할 수 있도록 퍼스트 파티 세트에 SameParty 쿠키 속성을 처음 제안했습니다. Google은 사용자 에이전트 정책을 사용하여 '동일 당사자'를 구성하는 요소를 정의했습니다. 이 정책 정의는 '당사자'의 기존 프레임워크(예: W3C DNT 사양)를 기반으로 했으며, 관련 개인 정보 보호 담론 (예: '급변하는 시대에 소비자 개인 정보 보호'라는 제목의 2012년 연방통상위원회 보고서)의 권장사항을 포함했습니다.
당시 Google은 이 접근 방식이 업종을 불문하고 다양한 유형의 조직에 충분한 유연성을 제공하는 동시에 서드 파티 쿠키를 통한 광범위한 추적을 최소화한다는 기본 목표를 고수하고 있다고 생각했습니다.
초기 제안에 대한 의견
Google은 웹 생태계의 이해관계자와 많은 대화를 통해 이러한 초기 설계에 한계가 있음을 발견했습니다.
SameParty 속성을 통한 수동적 쿠키 액세스와 관련된 개인 정보 보호 문제
다른 브라우저 공급업체는 수동적 쿠키 액세스를 유지할 수 있는 경계를 설정하는 것보다 명시적인 API 호출을 요구하는 능동적인 서드 파티 쿠키 액세스 방식을 선호합니다. 적극적인 쿠키 액세스 요청은 브라우저 가시성 및 제어 기능을 제공하므로 서드 파티 쿠키를 통한 은밀한 추적 위험을 완화할 수 있습니다. 또한 이러한 공개 상태를 통해 브라우저에서는 사용자에게 이러한 쿠키 액세스를 허용하거나 차단할 수 있습니다.
브라우저 간 웹 상호 운용성을 추구하고 개인 정보 보호의 이점을 향상시키기 위해 Google은 이러한 방향으로 진행하기로 결정했습니다.
제안된 정책의 구현 문제
원래 정책에서는 '공통 소유권', '공통 개인정보처리방침', '공통 그룹 ID'라는 도메인을 하나의 세트로 만들기 위한 세 가지 요구사항을 제안했습니다.
Google은 더 광범위한 생태계에서 이 정책에 대해 받은 의견을 4가지 주요 주제를 따르는 것으로 확인했습니다.
공동 소유권이 너무 제한적임
Google은 '공동 소유권' 요구사항과 관련하여 기업 소유권에만 초점을 맞춘 FPS의 정의가 중소기업에 비해 대기업에서 광범위한 도메인과 사용자 대상 서비스에서 데이터를 풀 수 있는 능력을 더 크게 제공할 것이라는 의견을 받았습니다. Google의 목표는 생태계 전체를 위한 개인 정보 보호 샌드박스를 구축하는 것이기 때문에 이 의견을 심각하게 받아들여 보다 포용적인 솔루션을 우선시했습니다.
단일 정책으로 사용 사례로의 확장 가능성 제한
경계를 제어하는 전체적 정책의 아이디어는 조직의 FPS에 속해야 하는 다양한 유형의 도메인에 유연성을 제공하기 위한 것이었지만 일부 중요한 사용 사례는 이 정책 설계를 충족하지 못하는 것으로 확인되었습니다. 예를 들어 서비스 도메인 (예: 사용자 제작 콘텐츠 호스팅)이 사용자를 인증하거나 식별하기 위해 서드 파티 컨텍스트에서 쿠키에 액세스해야 할 수 있습니다. 이러한 도메인에는 사용자가 액세스할 수 있는 홈페이지가 거의 없으므로 동일한 FPS의 다른 도메인과 관련된 '공통 그룹 ID' 또는 '공통 개인정보처리방침'의 요구사항을 충족할 수 없습니다.
집단 정체성에 대한 사용자의 인식과 이해가 다를 수 있음
Google은 원래 단일 집합 내의 도메인을 공통 그룹 ID와 쉽게 연결할 수 있는 도메인으로 범위를 지정하기 위해 '공통 그룹 ID'를 정의하는 안전장치를 제안했습니다. 하지만 공통 그룹 ID를 '사용자가 쉽게 검색'할 수 있는지 측정하고 평가할 기술적 수단을 정의하지 못했습니다. 이로 인해 악용 가능성과 시정 조치에 대한 질문이 남아 있었습니다.
또한 '공통 소유권' 경계의 의미를 이해하는 것이 사용자마다 다르기 때문에 모든 사이트에 적용할 수 있는 가이드라인을 만드는 것이 어렵다는 의견 의견을 받았습니다.
주관적인 정책은 대규모로 시행하기 어려움
Google은 특정 요구사항의 주관적 특성 (예: '공통 그룹 ID')과 다른 예외에 대한 예외나 특이 사례를 다루어야 할 필요성('일반적인 개인정보처리방침')을 고려하여 더 자세한 가이드라인을 요청해 왔습니다.
정책이 공평하고 일관되게 적용되도록 하기 위해 Chrome은 사이트 작성자에게 훨씬 더 구체적인 가이드라인을 제공해야 했습니다. Google은 보다 엄격한 가이드라인을 마련하려는 시도가 생태계에 악영향을 미칠 수 있다고 판단했습니다.
Google은 처음에 독립적인 시정 조치 기관에서 정책 준수를 조사하고 시행하는 역할을 맡을 것을 제안했지만, 현재 생태계에서는 이러한 책임을 공정하게 수행할 수 있는 적절한 전문성을 갖춘 독립 집행 기관을 찾기가 쉽지 않았습니다. 대신 Google에서는 구현이 일관되고 객관적으로 적용될 수 있도록 기술적으로 시행할 수 있는 정책으로 전환하려고 노력했습니다.
진화
Google에서는 사용자 의견에 따라 FPS를 새롭게 디자인했습니다. 해결하고자 했던 구체적인 문제로 돌아가서 해결하려는 특정 사용 사례를 중심으로 제안을 보다 직접적으로 설정하기로 했습니다.
주요 사용 사례 해결
Chrome은 웹의 주요 사용 사례를 충족하기 위해 목적에 맞게 구축된 세 가지 '하위 집합'을 개발했습니다. 하위 집합 접근 방식은 더 비공개적이고, 더 구체적이며, 일관되게 적용하기가 더 쉽다는 점에서 이전 접근 방식보다 개선되었습니다.
- 'ccTLD' (국가 코드 최상위 도메인) — 조직은 현지화된 환경을 위해 다른 ccTLD를 사용하여 사이트를 관리할 수 있지만 이러한 사이트에서는 여전히 공유 서비스 및 인프라에 액세스해야 할 수 있습니다.
- '서비스' 도메인 - 사이트에서 보안 또는 성능 목적으로 개별 도메인을 사용할 수 있으며, 이러한 사이트에서는 기능을 수행하기 위해 사용자 ID에 액세스해야 할 수 있습니다.
- '연결된' 도메인 — 조직에서는 서로 다른 관련 브랜드 또는 제품을 위한 여러 사이트를 관리할 수 있습니다. 조직의 사용자층이 사이트와 상호작용하는 방식을 더 잘 이해하거나 동일한 로그인 인프라를 사용하는 관련 사이트에서 사용자의 로그인 상태를 기억하기 위해 관련 사이트 간 사용자 여정 분석과 같은 사용 사례에 크로스 사이트 쿠키 액세스를 원할 수 있습니다.
이러한 각 사용 사례에는 별개의 정책 요구사항, 해당하는 기술 유효성 검사 확인 및 특정 브라우저 처리 동작이 있습니다 (자세한 내용은 제출 가이드라인 참조). 이러한 변경사항은 '일률적인' 디자인을 포기하고 구획화된 사용 사례 중심 프레임워크를 선호하여 원래 제안서의 제한사항을 해결합니다.
서드 파티 쿠키 액세스에 대한 적극적인 요청을 통한 상호 운용성 기회
Chrome은 웹 플랫폼의 상태를 유지하기 위해 다른 브라우저와의 상호 운용성을 촉진하고자 합니다. Safari, Firefox, Edge와 같은 다른 브라우저는 현재 Storage Access API(SAA)를 사용하여 활성 쿠키 요청을 용이하게 하므로, Google은 수신된 키 피드백을 처리하는 데 도움이 될 뿐만 아니라 웹 상호 운용성도 지원하기 위해 Chrome에서 SAA를 활용하기로 했습니다.
개발자에게 더 많은 유연성을 제공하고 SAA의 알려진 제한사항을 해결하기 위해 Google에서는 requestStorageAccessForOrigin API도 제안했습니다.
Storage Access API와 FPS를 함께 사용할 수 있는 기회
Storage Access API (SAA)를 구현할 때 브라우저는 직접 사용자에게 권한을 요청할 수도 있고, 다른 경우에는 권한 메시지 없이 제한된 수의 요청을 허용할 수도 있습니다.
Chrome은 FPS가 사용자의 불편을 제한하고 중요한 제한된 사용 사례로 인한 프롬프트 피로를 방지하여 SAA에 투명한 레이어를 제공할 수 있다고 생각합니다. 또한 FPS는 사용자가 권한을 요청하는 메시지를 표시하도록 선택한 경우 브라우저가 사용자에게 설정된 멤버십에 관한 추가 컨텍스트를 제공할 수 있는 유연성을 제공합니다.
FPS를 사용하면 개발자가 주요 사용 사례를 처리하는 영향을 받는 자체 사이트를 식별할 수 있습니다. 이를 통해 기관에서는 사이트가 사용자에게 어떻게 작동할지 예측하고 FPS 또는 서드 파티 쿠키 대안을 활용하여 사용자 환경에 미치는 영향을 제한하는 조치를 취할 수 있습니다. 또한 FPS는 시간이 지남에 따라 변하거나 사용자마다 다른 동작을 유발할 수 있는 휴리스틱과 달리 개발자에게 플랫폼 예측 가능성을 제공합니다.
마지막으로 Chrome에서 FPS를 사용하기 위해 SAA를 구현하는 개발자는 FPS를 제공하지 않는 브라우저를 포함하여 다른 브라우저의 사이트 성능에도 SAA를 활용할 수 있습니다.
계속 토론
Google의 최신 제안은 사용자와 개발자의 니즈를 고려하는 까다로운 균형 잡기 부분에서 적절한 균형을 이룰 수 있다고 생각합니다. FPS 제안을 발전시키는 데 도움을 준 웹 생태계 이해관계자들이 제기한 의견에 감사드립니다.
웹 생태계 이해관계자들은 여전히 업데이트된 제안서를 익히고 있습니다. 개발자에게 더 유용한 방식으로 디자인을 개선하고 웹의 개인 정보 보호를 지속적으로 개선할 수 있도록 Google에 협조해 주시기 바랍니다. 또한 Google은 영국의 경쟁시장청 (CMA)과 계속 협력하여 약정을 준수할 것입니다.
참여하려면 다음 리소스를 확인하세요.
생태계와의 협력
Salesforce와 CafeMedia와 같은 기업이 퍼스트 파티 세트의 주요 의견과 개발에 참여하고 있습니다. 기술 발전에 중요한 역할을 해왔습니다. 또한 퍼스트 파티 세트 및 웹 생태계와의 협력을 위한 Chrome의 노력에 관한 의견을 공유한 사람들도 있습니다.
"Chrome은 사용자 경험 보존과 같은 다양한 사용 사례에 맞춰 퍼스트 파티 세트를 개발하고 있습니다. 이를 통해 Google팀은 웹 전반에서 사이트 소유자의 다양한 요구사항을 이해하고자 노력하고 있음을 알 수 있습니다." - Mercado Libre
"VWO는 진정한 사용 사례를 처리하는 동시에 개인 정보 보호 표준을 높이려는 Google의 노력에 감사드립니다. 담당 팀이 개발자 생태계와 협력하고 있으며 웹 이해관계자의 의견을 바탕으로 퍼스트 파티 세트 제안서의 구현을 지속적으로 개선하고 있습니다. 제안서의 테스트 여정에 동참할 수 있게 되어 매우 기쁘게 생각하며, 제안사항이 브라우저에 통합되기를 기대합니다." - Nitish Mittal, VWO 엔지니어링 이사