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

Chrome이 퍼스트 파티 세트 제안을 발전시킨 방법

퍼스트 파티 세트 (FPS)는 Chrome에서 서드 파티 쿠키가 지원 중단된 후 사용자의 웹 탐색 환경을 지원하도록 설계되었습니다. 이 제안은 FPS 인큐베이션 기간 동안 공개 웹 포럼에서 크게 발전했으며, 처음에는 W3C의 개인 정보 보호 커뮤니티 그룹에서 시작하여 현재는 웹 인큐베이터 커뮤니티 그룹에서 논의되고 있습니다.

이 블로그 게시물에서는 진화 과정을 요약하고 주요 변경사항을 강조 표시하며 이러한 변경사항이 생태계를 계속 지원하면서 웹의 개인 정보 보호를 개선한다고 생각하는 이유를 설명합니다.

배경

사이트는 사용자에게 원활하고 맞춤화된 환경을 제공하기 위해 서드 파티 컨텍스트에서 쿠키에 액세스하는 경우가 많습니다. Chrome팀은 개인 정보 보호 광고 API (Topics, Protected Audience API, Attribution) 외에도 사용자에게 향상된 탐색 환경을 제공하기 위해 광고 개인 최적화 또는 측정 목적 외에도 서드 파티 쿠키가 사용되는 시나리오의 범위를 파악하고자 했습니다.

웹 아키텍처가 여러 도메인을 활용하도록 설계되어 있기 때문에 조직에서 서드 파티 쿠키를 사용할 수 있습니다. 예를 들어 조직에 하이킹 블로그용 도메인과 캠핑용품 매장용 도메인이 각각 하나씩 있고 이러한 사이트에서 사용자 여정을 지원하려는 경우가 있을 수 있습니다. 조직은 웹 서비스용 공유 인프라로 여러 국가 코드 도메인을 유지할 수도 있습니다. 이러한 경우를 위해 Google은 웹에서 사용자의 개인 정보 보호에 대한 기대치를 유지하면서 이러한 조직의 요구사항에 부합하는 솔루션을 만들기 시작했습니다.

시작점

브라우저는 현재 사이트 수준 경계를 사용하여 '퍼스트 파티'와 '서드 파티'를 해석하여 조직에서 관리할 수 있는 도메인 범위를 고려하므로 이 기술적 경계를 더 미묘한 정의로 대체하는 것이 적절해 보였습니다.

2021년 Chrome은 사이트에서 '동일한 당사자' 내 사이트에서 발생한 쿠키를 정의할 수 있도록 퍼스트 파티 세트의 SameParty 쿠키 속성을 처음 제안했습니다. User-Agent 정책을 사용하여 '동일한 당사자'를 정의했습니다. 이 정책 정의는 기존의 '당사자' 프레임워크(예: W3C DNT 사양)를 기반으로 하며 관련 개인 정보 보호 담화의 권장사항 (예: 2012년 연방통상위원회의 '급변하는 시대의 소비자 개인 정보 보호' 보고서)을 통합했습니다.

당시 Google은 이 접근 방식이 다양한 업종의 다양한 유형의 조직에 충분한 유연성을 제공하는 동시에 서드 파티 쿠키를 통한 광범위한 추적을 최소화한다는 Google의 기본 목표를 준수한다고 생각했습니다.

초안 제안에 대한 의견

웹 생태계의 이해관계자와의 많은 대화를 통해 이 초기 설계에는 제한사항이 있음을 확인했습니다.

SameParty 속성을 통한 수동 쿠키 액세스의 개인 정보 보호 문제

다른 브라우저 공급업체는 수동 쿠키 액세스를 유지할 수 있는 경계를 설정하는 대신 명시적 API 호출이 필요한 서드 파티 쿠키 액세스에 대한 적극적인 접근 방식을 선호했습니다. 쿠키 액세스를 위한 활성 요청은 서드 파티 쿠키를 통한 은밀한 추적 위험을 완화할 수 있도록 브라우저에 가시성과 제어 기능을 제공합니다. 또한 이러한 공개 상태를 통해 브라우저는 사용자에게 이러한 쿠키 액세스를 허용하거나 차단할 수 있는 선택권을 제공할 수 있습니다.

Google은 브라우저 간 웹 상호 운용성을 모색하고 개인 정보 보호 이점을 개선하기 위해 이 방향으로 전환하기로 결정했습니다.

제안된 정책의 구현 관련 문제

원래 정책에서는 도메인이 단일 세트로 구성되기 위한 세 가지 요구사항('공동 소유권', '공동 개인정보처리방침', '공동 그룹 ID')을 제안했습니다.

광범위한 생태계에서 정책에 관해 받은 의견을 살펴본 결과 다음과 같은 네 가지 주요 주제가 발견되었습니다.

공동 소유권이 너무 제한적입니다.

'공동 소유권' 요건과 관련하여, 기업 소유권에만 초점을 맞춘 FPS의 정의는 대기업이 소규모 기업에 비해 다양한 도메인과 사용자 대상 서비스에서 데이터를 더 많이 풀링할 수 있게 해준다는 의견이 접수되었습니다. Google의 목표는 생태계 전체를 위한 개인 정보 보호 샌드박스를 구축하는 것이므로 이러한 의견을 진지하게 받아들이고 포용성이 더 높은 솔루션을 우선시했습니다.

단일 정책으로 확장성을 사용 사례로 제한

경계를 관리하는 전체적인 정책의 아이디어는 조직의 FPS에 있어야 하는 다양한 유형의 도메인에 유연성을 제공하기 위한 것이었지만 일부 중요한 사용 사례에서는 이 정책 설계를 충족할 수 없는 것으로 확인되었습니다. 예를 들어 사용자 제작 콘텐츠를 호스팅하는 서비스 도메인은 사용자를 인증하거나 식별하기 위해 서드 파티 컨텍스트의 쿠키에 액세스해야 할 수 있습니다. 이러한 도메인에는 사용자가 액세스할 수 있는 홈페이지가 거의 없으므로 동일한 FPS의 다른 도메인과 '공통 그룹 ID' 또는 '공통 개인 정보 보호 정책' 요구사항을 충족할 수 없습니다.

사용자의 그룹 정체성에 대한 인식과 이해는 다를 수 있습니다.

Google은 원래 단일 세트 내의 도메인 범위를 공통 그룹 ID와 쉽게 연결할 수 있는 도메인으로 정의하기 위해 '공통 그룹 ID'를 정의하는 가이드라인을 제안했습니다. 그러나 공통 그룹 ID를 '사용자가 쉽게 찾을 수 있는지' 측정하고 평가할 수 있는 기술적 수단을 정의할 수 없습니다. 이로 인해 악용 가능성이 있으며 시정 조치에 관한 질문이 제기될 수 있습니다.

또한 '공동 소유권' 경계의 의미에 대한 이해는 사용자마다 다를 수 있으므로 모든 사이트에 적용할 수 있는 가이드라인을 작성하기 어렵다는 의견이 접수되었습니다.

주관적인 정책은 대규모로 적용하기 어렵습니다.

Google은 특정 요구사항 (예: '공통 그룹 ID')의 주관적 특성과 다른 요구사항의 예외 또는 특이 사례('일반 개인정보처리방침' 관련)를 다루어야 할 필요성을 고려하여 더 자세한 가이드라인을 제공해 달라는 요청을 많이 받았습니다.

정책을 공정하고 일관되게 적용하려면 Chrome에서 사이트 작성자에게 훨씬 더 구체적인 가이드라인을 제공해야 했습니다. YouTube는 더 엄격한 가이드라인을 만들려고 시도하면 생태계가 오히려 손해를 볼 수 있다고 판단했습니다.

Google은 처음에 정책 준수 조사 및 시정 조치 역할을 독립적인 시정 조치 기관이 맡도록 제안했지만, 현재 생태계에서는 이러한 책임을 공정하게 수행할 수 있는 적절한 전문성을 갖춘 독립적인 시정 조치 기관을 찾기가 쉽지 않았습니다. 대신 구현을 일관되고 객관적으로 적용할 수 있도록 기술적으로 시행할 수 있는 정책으로 전환하기 위해 노력했습니다.

진화

의견을 바탕으로 FPS를 다시 디자인했습니다. 해결하려는 구체적인 문제로 돌아가서 해결하려는 구체적인 사용 사례를 중심으로 제안을 더 직접적으로 구성하기로 결정했습니다.

주요 사용 사례 해결

Chrome은 웹의 주요 사용 사례를 충족하기 위해 세 가지 목적에 맞게 제작된 '하위 집합'을 개발했습니다. 하위 집합 접근 방식은 더 비공개이고, 더 구체적이며, 일관되게 적용하기 더 쉬워서 기존 접근 방식을 개선했습니다.

'ccTLD' (국가 코드 최상위 도메인): 조직은 현지화된 환경을 위해 서로 다른 ccTLD로 사이트를 유지할 수 있으며, 이러한 사이트에도 공유 서비스 및 인프라에 대한 액세스 권한이 필요할 수 있습니다.
'서비스' 도메인: 사이트에서 보안 또는 성능 목적으로 개별 도메인을 사용할 수 있으며, 이러한 사이트에서는 기능을 실행하기 위해 사용자의 ID에 액세스해야 할 수 있습니다.
'연결된' 도메인: 조직은 서로 다른 관련 브랜드 또는 제품에 대해 여러 사이트를 운영할 수 있습니다. 조직의 사용자층이 사이트와 상호작용하는 방식을 더 잘 이해하거나 동일한 로그인 인프라를 사용하는 관련 사이트에서 로그인 상태를 기억하기 위해 관련 사이트에서 사용자 여정을 분석하는 등의 사용 사례에 교차 사이트 쿠키 액세스를 원할 수 있습니다.

이러한 각 사용 사례에는 개별적인 정책 요구사항, 상응하는 기술 검증 확인, 특정 브라우저 처리 동작이 있습니다 (제출 가이드라인에서 자세히 알아보기). 이러한 변경사항은 '하나의 크기가 모든 것에 적용되는' 설계를 폐기하고 구분된 사용 사례 중심 프레임워크를 선호하여 원래 제안서의 한계를 해결합니다.

서드 파티 쿠키 액세스에 대한 활성 요청을 통한 상호 운용성 기회

Chrome은 웹 플랫폼의 상태를 유지하기 위해 다른 브라우저와의 상호 운용성을 적극적으로 장려하고 있습니다. Safari, Firefox, Edge와 같은 다른 브라우저는 현재 Storage Access API(SAA)를 사용하여 활성 쿠키 요청을 처리하므로 Google은 받은 주요 의견을 해결하는 데 도움이 될 뿐만 아니라 웹 상호 운용성을 지원하기 위해 Chrome에서 SAA를 활용하기로 했습니다.

개발자에게 더 많은 유연성을 제공하고 SAA의 알려진 제한사항을 해결하기 위해 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이 진정한 사용 사례를 처리하는 동시에 개인 정보 보호 표준을 높이기 위해 노력하는 데 감사드립니다. 개발자 생태계와 협력하고 웹 이해관계자의 의견을 바탕으로 퍼스트 파티 세트 제안 구현을 지속적으로 개선하고 있는 팀에 감사드립니다. Google은 제안서의 테스트 여정에 참여하게 되어 기쁘게 생각하며 브라우저에 통합되기를 기대합니다." - Nitish Mittal, VWO 엔지니어링 부문 이사