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

의견 보고서 - 2022년 4분기
bookmark_border 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

개인 정보 보호 샌드박스 제안 및 Chrome의 대응에 대해 접수된 생태계 의견을 요약한 2022년 4분기 분기 보고서입니다.

CMA에 대한 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안서의 이해관계자 참여 절차에 관한 분기별 보고서를 공개적으로 제공하기로 합의했습니다 (약속의 12항 및 17항(c)(ii) 참고). 이러한 개인 정보 보호 샌드박스 의견 요약 보고서는 GitHub 문제, privacysandbox.com에 제공된 의견 양식, 업계 이해관계자와의 회의, 웹 표준 포럼 등 의견 개요에 나열된 다양한 소스에서 Chrome이 수신한 의견을 집계하여 생성됩니다. Chrome은 생태계로부터 받은 의견을 환영하며, 학습한 내용을 디자인 결정에 통합할 방법을 적극적으로 모색하고 있습니다.

의견 주제는 API별로 발생 빈도에 따라 순위가 매겨집니다. 이는 Chrome팀이 특정 주제와 관련하여 받은 의견의 양을 집계하고 수의 내림차순으로 정렬하여 수행됩니다. 일반적인 의견 주제는 공개 회의(W3C, PatCG, IETF), 직접적인 의견, GitHub, Google 내부 팀 및 공개 양식을 통해 자주 제기되는 질문을 검토하여 확인했습니다.

구체적으로 웹 표준 기관 회의의 회의록을 검토하고 직접적인 의견의 경우 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 목록, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 홍보 활동에 참여하는 팀 간에 조정하여 각 API와 관련하여 나타나는 주제의 상대적 발생 빈도를 확인했습니다.

Chrome의 의견에 대한 응답에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 응답, 이 공개 보고서 작성의 목적을 위한 구체적인 입장을 결정하는 데서 비롯되었습니다. 현재 개발 및 테스트의 중점을 반영하여 특히 Topics, Fledge, Attribution Reporting API에 관한 질문과 의견이 접수되었습니다.

현재 보고 기간이 종료된 후에 받은 의견은 아직 Chrome에서 고려하지 않았을 수 있습니다.

약어 용어집

CHIPS: 독립적으로 파티션된 상태의 쿠키
DSP: 수요측 플랫폼
FedCM: Federated Credential Management
FPS: 퍼스트 파티 세트
IAB: 인터넷광고협회
IDP: ID 공급업체
IETF : 인터넷 엔지니어링 태스크포스: 인터넷 엔지니어링 태스크포스
IP: 인터넷 프로토콜 주소
openRTB: 실시간 입찰
연장전: Origin 무료 체험
PatCG: 비공개 광고 기술 커뮤니티 그룹
RP: 신뢰 당사자
SSP: 공급측 플랫폼
TEE: 신뢰할 수 있는 실행 환경
UA: 사용자 에이전트 문자열
UA-CH: 사용자 에이전트 클라이언트 힌트
W3C: World Wide Web Consortium
WIPB: 의도적 IP 무시

일반적인 의견이며 특정 API/기술이 아님

의견 주제	요약	Chrome 응답
(3분기에도 신고됨) 다양한 유형의 이해관계자 유용성	개인 정보 보호 샌드박스 기술이 대규모 개발자를 선호하고 일반 (대규모) 사이트보다 틈새 (소규모) 사이트가 더 많은 기여를 한다는 우려	답변은 3분기와 동일합니다. "Google은 CMA에 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안을 설계하고 구현하며, 규모와 관계없이 디지털 광고 경쟁과 게시자 및 광고주에 미치는 영향을 고려하겠다고 약속했습니다. Google은 이러한 약속을 준수하기 위해 CMA와 긴밀하게 협력하고 있습니다. 개인 정보 보호 샌드박스 테스트가 진행되면서 Google에서 평가할 주요 질문 중 하나는 새로운 기술이 다양한 유형의 이해관계자들에게 어떤 영향을 미치는지입니다. 이 점에서 의견은 매우 중요합니다. 특히 기술 설계를 더욱 개선하는 데 도움이 되는 구체적이고 실행 가능한 의견이 필요합니다. Google은 CMA와 협력하여 정량적 테스트에 대한 접근 방식을 개발했으며, CMA가 시장 참여자에게 더 많은 정보를 제공하고 제안된 접근 방식에 대해 의견을 제공할 수 있는 기회를 제공하기 위해 실험 설계 관련 메모를 게시하는 것을 지지합니다."
(3분기에도 신고됨) 문서 요청	테스트, 분석, 구현을 관리하는 방법을 자세히 설명하는 리소스를 더 요청함	4분기 업데이트: Google은 개발자들이 현재 자료가 유용하다고 생각해 주셔서 감사드리며, 개발자들이 새로운 기술을 어떻게 활용할 수 있는지 이해할 수 있도록 더 많은 자료를 제공하기 위해 최선을 다하고 있습니다. 지난 분기에 Google은 privacysandbox.com에 '뉴스 및 업데이트' 섹션을 추가하고 개인 정보 보호 샌드박스가 향후 광고 관련성을 높이는 데 어떻게 도움이 될 수 있는지에 대한 광범위한 검토를 게시했습니다. 또한 권장사항 및 데모를 공유하는 공개 개발자 업무 시간 세션과 제품 및 엔지니어링 책임자와의 Q&A 세션을 통해 실시간 토론/질문도 진행했습니다.
코어 웹 바이탈	개인 정보 보호 샌드박스 API 지연 시간이 Core Web Vitals에 미치는 영향은 무엇인가요?	지연 시간을 최소화하는 것이 개인 정보 보호 샌드박스 API의 주요 설계 목표입니다. 현재 API 지연 시간은 웹사이트의 초기 렌더링 후에 호출되므로 사이트의 Core Web Vitals에 미치는 영향이 최소화될 것으로 예상됩니다. YouTube는 각 API의 지연 시간을 줄이기 위해 지속적으로 모니터링하고 개선하고 있으며, 계속해서 테스트하고 의견을 보내주시기 바랍니다. 실시간 입찰 프로세스의 지연 시간은 FLEDGE 섹션의 'FLEDGE 입찰 실적'에서 다룹니다.
상호 운용성	다른 잠재적 솔루션과의 상호 운용성에 관한 우려사항	개인 정보 보호 샌드박스의 목표는 웹 생태계의 요구사항을 지원하면서 크로스 사이트 추적으로부터 사용자를 보호하는 것입니다. Google은 서드 파티 쿠키와 같은 크로스 사이트 추적을 지원하는 기존 브라우저 기술을 대체하고 특정 사용 사례를 지원하도록 설계된 새로운 기술을 제공하여 이를 달성하고자 합니다. 개인 정보 보호 샌드박스 제안은 사용자 기기에서 나가는 데이터를 제한하여 개인 정보 보호를 개선합니다. 이 제안은 브라우저에서 수집된 데이터를 공유하거나 다른 방식으로 처리하는 웹사이트의 기능에 기술적 제한을 두지 않습니다. 따라서 이러한 기술은 기업이 '데이터 스튜어드십' 계약 또는 기타 유사한 계약 관계를 체결하는 것을 막지 않습니다. 마찬가지로 사용자가 다른 방법을 통해 데이터 공유에 동의하는 기능도 제한하지 않습니다. 명확히 하기 위해 Google은 Google 제품 및 서비스를 포함한 모든 웹사이트에 동일한 방식으로 개인 정보 보호 샌드박스 기술을 적용하기 위해 노력하고 있습니다. Chrome에서 서드 파티 쿠키 지원을 중단한 후에도 Google은 사용자의 동기화된 Chrome 방문 기록과 같은 다른 개인 정보를 사용하여 디지털 광고의 타겟팅 또는 측정을 위해 사용자를 추적하지 않을 것임을 분명히 합니다.

관련성 높은 콘텐츠 및 광고 표시

주제

의견 주제	요약	Chrome 응답
Google 검색 순위에 미치는 영향	웹사이트의 Topics API 지원이 Google 검색 결과 순위의 잠재적 신호로 사용될지 묻는 문의	일부 웹사이트에서는 Topics API를 선택 해제할 수 있습니다. 개인 정보 보호 샌드박스팀은 웹사이트가 Topics API를 채택하도록 장려하기 위해 페이지 순위를 사용하는 것과 관련하여 검색 조직과 조율하거나 요청한 적이 없습니다. Google은 CMA에 Google 검색에서 사이트의 Topics API 선택 해제 결정을 순위 신호로 사용하지 않을 것이라고 확인했습니다.
주제 분류 기준	다양한 이해관계자의 유용성을 개선하기 위해 웹페이지의 주제를 결정하기 위해 호스트 이름 외에 URL 및 페이지 콘텐츠를 추가합니다.	현재 사용자의 방문 기록은 웹사이트의 호스트 이름을 사용하여 분류됩니다. Chrome은 주제 분류에서 페이지 수준 메타데이터 (예: 페이지 URL 또는 콘텐츠의 일부 또는 전체 구성요소)를 고려하는 옵션을 계속해서 평가하고 있습니다. 유용성 개선은 개인 정보 보호 및 악용 위험과 비교하여 평가해야 합니다. 예를 들어 메타데이터와 관련하여 다음과 같은 위험이 있습니다. - 사이트에서 다양한 (잠재적으로 민감한) 의미를 주제에 인코딩하는 방법으로 페이지 수준 메타데이터를 수정하는 경우 - 사이트에서 금전적 이익을 위해 주제를 허위로 진술하기 위해 페이지 수준 메타데이터를 수정하는 경우 - 사이트에서 교차 사이트 추적 방법으로 페이지 수준 메타데이터를 동적으로 수정하는 경우
(3분기에 보고됨) 퍼스트 파티 신호에 미치는 영향	주제 신호는 매우 가치가 있을 수 있으며, 그 결과 다른 퍼스트 파티 관심분야 기반 신호의 가치가 떨어질 수 있습니다.	답변은 3분기와 동일합니다. "관심 기반 광고는 웹의 중요한 사용 사례이며 Topics는 이러한 사용 사례를 지원하도록 설계되었습니다. [3분기 보고서]에서 설명한 바와 같이 다른 생태계 이해관계자는 주제가 가치를 제공하기에 충분히 유용하지 않을 수 있다는 우려를 제기했습니다. 모든 경우에 분류 개선은 지속적인 노력이며 생태계 테스트 및 의견을 바탕으로 분류가 발전할 것으로 예상됩니다."
분류 업데이트	분류 목록은 어떻게 업데이트되나요?	YouTube는 생태계에 가장 유용한 분류에 관한 의견을 적극적으로 수렴하고 있습니다. 초기 Topics API 제안서에 포함된 분류는 기능 테스트를 지원하도록 설계되었습니다. Chrome에서는 분류를 업데이트하기 위한 여러 접근 방식을 적극적으로 고려하고 있습니다. 예를 들어 Chrome은 각 주제의 상업적 가치 개념을 활용하여 향후 반복에 포함할 카테고리를 결정할 수 있습니다.
주제 지역 분류 기준 실적	지역 도메인에서 실적이 저조한 주제 분류 기준	분류기를 개선하기 위한 노력은 계속되고 있습니다. Google은 받은 의견을 바탕으로 Topics 재정의 목록을 확장하는 방안을 고려하고 있습니다. 분석에 따르면 이 경우 전 세계 노출 범위가 확대되고 정확성이 개선될 것으로 보입니다. Topics API 분류에는 두 가지 관련 구성요소가 있습니다. (1) 인기 사이트 10, 000개와 해당 주제가 포함된 재정의 목록, (2) 호스트 이름을 주제로 분류하는 기기 내 ML 모델입니다. 재정의 목록 (1)을 확장하면 분류기가 실적이 좋지 않은 영역의 분류 성능을 개선할 수 있습니다.
1주일 기준점	1주일의 이포크는 단기적인 결정을 내리려는 사용자에게는 너무 깁니다.	Google은 적절한 에포크 길이를 찾기 위해 노력하고 있으며 생태계에 더 적합한 에포크에 관한 추가 의견을 기다리고 있습니다.
HTTP 헤더 검색	주제의 HTTP 헤더 검색과 관련된 정보가 충분하지 않다는 우려	헤더 및 fetch()에 관한 작업이 진행 중입니다. 여기에서도 정보를 확인할 수 있습니다. 또한 설명에 skipObservation 정보가 추가되었습니다.
주제는 사용자를 돕는 것이 아니라 광고주만을 돕는 것을 목표로 합니다.	주제/개인 정보 보호 샌드박스는 업계 중심의 접근 방식으로 보입니다. 사용자에게 미치는 이점이 업계에 미치는 이점만큼 명확하지 않습니다.	Google은 Topics가 웹을 자유롭고 개방적으로 유지하는 관심 기반 광고를 지원하여 사용자에게 이점을 제공하고 서드 파티 쿠키에 비해 개인 정보 보호를 대폭 개선한다고 생각합니다. 대안 없이 서드 파티 쿠키를 삭제하면 게시자에게 부정적인 영향을 미칠 수 있으며, 더 나아가 더 나쁜 접근 방식으로 이어질 수 있습니다. 이는 개인 정보 보호 수준이 낮고, 투명하지 않으며, 사용자가 현실적으로 재설정하거나 제어할 수 없는 접근 방식입니다. 많은 기업이 Topics 및 Sandbox API를 적극적으로 테스트하고 있으며 Google은 개인 정보 보호를 강화하고 웹을 지원하는 도구를 제공하기 위해 노력하고 있습니다. W3C 기술 아키텍처 그룹은 최근 Topics API에 관한 초기 견해를 발표했으며, Google은 이에 공개적으로 응답할 예정입니다. 현재 Google은 이 검토가 Topics API의 개발 및 출시에 미칠 수 있는 영향에 관해 생태계로부터 질문을 받았으므로 올해 Chrome 안정화 버전에서 이 API를 제공할 계획임을 다시 한번 확인해 드립니다. Google은 W3C 기술 아키텍처 그룹의 의견을 높이 평가하지만 CMA 및 생태계와 협의하여 주제를 개발하고 테스트하기 위한 노력을 계속하는 것이 가장 중요하다고 생각합니다.
데이터 유출	주제가 허가 없이 다른 사이트에 유출될 수 있다는 우려	Topics API의 설계로 인해 단일 게시자 또는 소규모 게시자 그룹의 데이터가 어떤 식으로든 유출될 가능성은 매우 낮습니다. 게시자 웹사이트는 Topics API를 완전히 제어할 수 있으며 권한 정책을 통해 이 API에 대한 액세스를 금지할 수 있습니다.
테스트할 광고주가 부족함	게시자는 현재 광고주에게 주제의 가치를 입증할 수 없다고 우려하고 있습니다.	2023년 하반기에는 모든 광고 관련 API를 통합 테스트에 사용할 수 있도록 하고 광고주를 위한 주제의 가치에 대한 생태계 분석을 사용 설정할 계획입니다. 테스트 및 결과 게시는 CMA에서 감독하며, CMA는 데이터, 분석, 방법론을 검토합니다. 생태계는 Google 및 CMA와 의견을 공유하는 것이 좋습니다.
Topics 및 FLEDGE	FLEDGE 입찰 로직 내에서 Topics를 사용하는 방법에 관한 자세한 정보 요청	FLEDGE 입찰 로직 내에서 주제를 사용할 수 있습니다. 통합 가이드도 진행 중이며 구현에 관한 추가 세부정보가 포함될 예정입니다.
주제 호출자의 맞춤 순위	호출자가 순위를 조정할 수 있도록 허용	각 광고 기술에 맞는 맞춤 주제 순위 또는 값의 문제는 광고 기술이 반환되는 주제에 영향을 미칠 수 있는 메커니즘이 될 수 있으므로 지문 식별 벡터가 될 수 있다는 점입니다.
주제 호출자 우선순위 목록	호출자가 자격요건에 따라 Topics API가 반환할 주제의 우선순위 목록을 제공할 수 있습니다.	현재 이 아이디어를 추가로 논의 하고 있으며 추가 의견을 기다리고 있습니다.

FLEDGE

의견 주제	요약	Chrome 응답
Google Ad Manager	Google Ad Manager가 FLEDGE 입찰의 최종 결정권자이며 Google 게시자 태그와 Google Ad Manager를 선호할 것이라는 우려	FLEDGE를 사용하면 각 게시자가 최상위 및 구성요소 판매자 선택을 비롯한 입찰 구조를 선택할 수 있습니다. 구성요소 입찰의 각 구매자와 판매자는 최상위 판매자가 누구인지 알고 있으며 입찰 여부를 선택할 수 있습니다.
FLEDGE를 테스트하는 참여자가 충분하지 않음	API의 기능을 개선하고 지문 식별과 같은 개인 정보 침해성 대안을 사용하지 못하도록 하여 더 많은 기업이 FLEDGE를 테스트하도록 장려해 달라는 요청	개인 정보 보호 샌드박스는 CMA 및 ICO의 안내에 따라 긴밀한 파트너십을 통해 단계적으로 진행되고 있으며, 기능적 FLEDGE 테스트에서 필요한 안정성과 기능을 입증했습니다. Google은 생태계가 샌드박스 API를 테스트하도록 계속해서 장려하고 있으며, 최근에는 '광고 관련성 극대화' 문서를 게시하여 서드 파티 쿠키 지원 중단 후 FLEDGE 및 기타 API가 광고 업계의 중요한 사용 사례를 지원하는 데 어떻게 도움이 될 수 있는지 보여주었습니다. 개인 정보 보호 샌드박스의 다른 부분에서는 이미 추적을 차단하기 위한 완화 조치를 지원하고 있으며 (UA-CH, IP 보호, 이탈 추적 완화 조치 참고) 시간이 지남에 따라 계속 개선될 예정입니다. Google의 목표는 FLEDGE를 유일한 실행 가능한 타겟팅 솔루션으로 만드는 것이 아니라 업계 및 규제 기관과 협력하여 Chrome 브라우저에서 최고의 개인 정보 보호 광고 기술을 추진하는 데 전념하는 것입니다.
머신러닝 사용 사례	입찰가 알고리즘을 학습하는 머신러닝 사용 사례가 FLEDGE 및 기여 분석 보고서에서 어떻게 지원되는지에 관한 자세한 안내	Google은 테스터가 개인 정보 보호 샌드박스 기술을 적용하는 가장 유용한 방법을 찾을 수 있도록 지원해야 한다는 점을 잘 알고 있습니다. Google에서는 개인 정보 보호 샌드박스 API의 다양한 측면을 머신러닝의 입력으로 사용하는 것과 관련된 안내를 게시하기 시작했습니다. 가장 최근에 게시된 광고 관련성 극대화에서는 광고 업계에서 이러한 신호를 머신러닝에 사용하는 방법을 설명하며, 앞으로도 이러한 가이드를 계속 게시할 계획입니다.
FLEDGE 키-값 (K/V) 서버 쿼리	K/V 서버에 공개적으로 쿼리할 수 있는 이유는 무엇인가요?	K/V 서버는 FLEDGE 입찰에 실시간 신호를 제공하는 것을 목표로 합니다. 따라서 K/V 서버는 FLEDGE 입찰이 실행되는 위치(사용자 기기)에서 액세스할 수 있어야 하므로 공개적으로 제공되어야 합니다. K/V 서버에 저장된 값은 이미 키를 보유한 당사자만 검색할 수 있습니다. 따라서 광고 기술이 관심분야 그룹에 있는 브라우저에만 키를 제공하고 무작위로 추측할 수 있는 키를 사용하지 않으면 입찰을 실행하는 데 값이 필요한 브라우저만 값을 검색할 수 있습니다.
날짜/시간 타겟팅을 하는 방법	입찰 로직 함수에서 날짜 객체를 지원합니다.	다음과 같이 여러 가지 방법이 있습니다. 구매자는 판매자에게 현재 날짜와 시간을 제공해 달라고 요청할 수 있으며 판매자는 모든 구매자에게 이 정보를 쉽게 제공할 수 있어야 합니다. 구매자는 실시간 키-값 응답에 날짜와 시간을 제공할 수도 있습니다. 마지막으로 구매자는 구매자별 신호의 문맥 응답의 일부로 날짜와 시간을 제공할 수 있으며, 판매자는 이를 구매자의 generateBid 스크립트에 전달할 수 있습니다.
사용자 환경설정	사용자가 FLEDGE 또는 대체 솔루션을 통해 게재되는 경우 광고주별로 광고 소재를 차단하도록 선택할 수 있는 기능	사용자는 Chrome에서 Ads API를 선택 해제할 수 있습니다. 특정 광고의 경우 관련 광고 기술이 표시되는 광고 소재 또는 광고 소재가 선택되는 방식을 제어할 수 있는 최적의 위치에 있습니다.
더 명확한 타임라인	펜싱된 프레임 요구와 같은 FLEDGE의 개인 정보 보호 기능 사용 가능 여부에 관한 자세한 정보를 요청합니다.	1분기에 더 자세한 일정을 게시할 예정입니다.
혼란스러운 상황 신고	FLEDGE 보고가 Fenced Frames 및 Private Aggregation API와 같은 다른 API와 어떻게 작동하는지 명확히 설명해 달라고 요청합니다.	앞으로 몇 주 내에 Private Aggregation API, FLEDGE, Fenced Frames 간의 상호작용에 관한 설명을 게시할 계획입니다.
실시간 입찰 및 FLEDGE	FLEDGE를 표준 실시간 입찰과 통합하는 방법에 관한 안내입니다.	광고 기술의 실시간 입찰 기능을 복잡하게 만드는 두 가지 주요 요소는 이벤트 수준 데이터에 대한 액세스와 ARA와의 보다 쉬운 통합입니다. 1분기에 두 가지 모두에 관한 업데이트 및 설명을 보내드릴 예정입니다.
FLEDGE 입찰 실적	FLEDGE 입찰의 지연 시간이 길다는 테스터의 신고	테스트 결과와 사용 사례를 공유해 주신 테스터 여러분께 감사드리며 FLEDGE 성능을 개선하는 방법에 관한 몇 가지 제안을 공유했습니다. 이와 동시에 개발자가 입찰 속도를 저하시키는 요인을 더 정확하게 진단할 수 있는 도구를 브라우저에 추가했으며, 관찰된 지연의 주요 원인을 체계적으로 해결해 왔습니다. 최근 개선사항에는 느린 입찰의 제한 시간, 빠른 입찰자 필터링 기법, FLEDGE 워크렛을 재사용하여 시작 비용을 지불하지 않는 방법, FLEDGE 시작 시간 및 네트워크 가져오기와 문맥 광고 요청을 동시에 실행할 수 있도록 하는 작업이 포함됩니다. Chrome 개발자와 FLEDGE 테스터가 API를 사용하는 실제 경험을 바탕으로 지속적으로 대화하면서 지연 시간 최적화가 계속될 것으로 예상됩니다.
관심분야 그룹 크기 메모리 한도	단일 관심분야 그룹의 크기 제한을 50KB에서 상향 조정해 달라는 요청	YouTube는 이 요청을 적극적으로 검토하고 있으며 적절한 한도 값에 관한 의견을 수렴하고 있습니다.
FLEDGE에서 제공된 데이터를 퍼스트 파티 쿠키와 결합	FLEDGE에서 광고주의 퍼스트 파티 데이터와의 통합을 지원하나요?	FLEDGE는 광고주가 이미 보유한 퍼스트 파티 데이터를 사용하여 광고를 지원하도록 설계되었습니다. 그러나 FLEDGE는 광고주가 자체 사이트 이외의 웹사이트에서 개인의 탐색 행동을 학습하는 것을 지원하지 않습니다. 퍼스트 파티 데이터에 오프사이트 탐색 동작을 연결하는 것은 개인 정보 보호 샌드박스의 목표에 위배됩니다. FLEDGE에서 퍼스트 파티 데이터 통합을 지원하는 방법을 자세히 설명하는 통합 가이드를 앞으로 몇 주 이내에 공유할 예정입니다.
K-익명성 값	'K'에서 'k-anon' 값은 어떻게 결정되며 게시되나요?	'K' 값은 아직 확정되지 않았으며 계획이 진행되면 더 많은 정보를 공유할 예정입니다. 알 수 없는 k 값이 FLEDGE 준비 및 ML 모델 학습 범위를 어떻게 방해할 수 있는지 자세히 알아보고자 하며 이 주제에 관한 추가 의견을 보내주시기 바랍니다.
여러 SSP 지원	FLEDGE에서 여러 SSP가 어떻게 지원되나요?	FLEDGE는 이 제안서에 설명된 대로 복수 판매자 입찰을 지원합니다.
입찰 로직의 공개 상태	DSP 입찰 로직이 JavaScript에 노출될 수 있다는 우려	현재 설계에서는 입찰 로직 JavaScript에 다른 사용자가 액세스할 수 있지만, DSP에서 우려할 수 있는 이유에 관한 추가 의견을 보내주세요.
prebid.js	FLEDGE에서 prebid.js를 지원하는 타임라인은 어떻게 되나요?	Prebid.js 버전 7.14 이상에서만 FLEDGE 모듈을 지원합니다. 테스트에 관심이 있는 게시자는 FLEDGE 모듈을 추가하고 Prebid 인스턴스를 업그레이드해야 합니다.
FLEDGE의 사용자 정의 함수	FLEDGE에서 사용자 정의 함수 (UDF)는 어떻게 지원되나요? 이는 최종 사용자가 API의 기능을 확장하도록 프로그래밍할 수 있는 함수입니다.	여기에서 설명을 확인하세요. 아직 구체화되고 있으므로 사용 사례에 관한 추가 의견을 보내주세요.
관심분야 그룹 리소스에 대한 동일 출처 제약 조건 완화	특정 광고 기술 사용 사례를 사용 설정하기 위해 관심분야 그룹 리소스에 대한 동일 출처 제약 조건을 완화해 달라는 요청	현재 FLEDGE 구현에서 `biddingLogicUrl`, `biddingWasmHelperUrl`, `dailyUpdateUrl`, `trustedBiddingSignalsUrl`는 관심분야 그룹 소유자와 동일한 출처를 가져야 합니다. 여기에 설명된 대로 공격자의 특정 악용을 방지하기 위해 제약 조건이 적용됩니다.
interestGroup 소유권	광고 기술이 여러 사이트에서 동일한 관심분야 그룹에 joinInterestGroup을 사용할 수 있는지 여부를 제한하도록 요청	YouTube는 잠재고객을 구축하는 방법이 아니라 잠재고객을 사용하는 방법에 중점을 둡니다. YouTube는 가능한 접근 방식을 논의하고 있으며 추가 의견을 기다리고 있습니다.
키-값 서버 키 만료	해당 관심분야 그룹이 만료된 후 서버 키를 삭제하는 방법에 관한 논의	Google에서는 키 만료를 처리하는 방법을 모색하고 있으며 의견을 기다리고 있습니다.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 주제	요약	Chrome 응답
오리진 트라이얼 트래픽	현재 출처 무료 체험판 트래픽은 유용성 테스트를 수행하기에 충분하지 않습니다.	현재 Origin 트라이얼은 생태계 참여자가 API가 의도한 대로 작동하는지 확인하기 위해 기능 테스트를 진행하기 위한 것입니다. 다양한 개인 정보 보호 샌드박스 API의 개발이 더 성숙해지면 유용성 테스트를 실행하는 데 더 많은 트래픽이 필요할 것으로 예상됩니다. 현재 테스트 일정에 따르면 정식 버전 (즉, 사용 사례의 기술이 출시되어 Chrome 트래픽의 100% 에 사용 가능해지는 시점)인 2023년 3분기에 이 작업이 완료될 것으로 예상됩니다 (최신 privacysandbox.com의 타임라인 참고). 추가 트래픽이 필요한 사용 사례 테스트에 관한 추가 의견은 언제든지 환영합니다.
여러 개인 정보 보호 샌드박스 측정 API의 기능 중복	개인 정보 보호 샌드박스를 통해 여러 측정 접근 방식이 겹치는 문제로 인해 복잡성이 증가합니다(예: Attribution Reporting API 및 Private Aggregation API).	Google에서는 API의 다양한 사용 사례를 명확히 설명하는 더 나은 문서를 작성하기 위해 노력하고 있으며, 설명이 부족한 부분에 관한 추가 의견을 환영합니다. 예를 들어 Attribution Reporting API는 전환 측정을 지원하기 위해 특별히 고안된 반면, Private Aggregation API 및 Shared Storage는 더 광범위한 크로스 사이트 측정 사용 사례를 지원하기 위한 범용 API입니다.
실패한 보고서 요청 재시도	보고 요청이 실패할 경우 요청이 시도되는 횟수에 관한 설명을 명확히 했습니다.	이와 관련된 안내가 게시되어 있습니다. 요약하자면 보고서는 브라우저가 실행 중일 때만 전송됩니다. 전송에 처음 실패하면 5분 후에 보고서가 다시 전송됩니다. 두 번째 실패 후 15분 후에 보고서가 다시 시도됩니다. 그 후에는 보고서가 전송되지 않습니다.
보고 지연	예상되는 보고 지연은 얼마나 되나요?	Google은 이러한 지연을 동시에 추가로 평가하기 위해 데이터를 수집하는 과정에서 발생하는 보고 지연에 관한 생태계의 의견을 더 많이 수렴하고자 합니다.
페이지 미리 렌더링	ARA 기여 분석이 사전 렌더링 페이지에서 작동하나요?	기여 분석 등록은 활성화 (실제 클릭 또는 조회가 발생)될 때까지 사전 렌더링 페이지에서 지연됩니다. 즉, `attributionsrc` 요청 핑이 지연됩니다.
전환 상승도 측정	동일한 도메인에서 A/B 테스트를 통해 전환 상승도를 측정하는 방법	웹사이트는 기여 분석 보고서를 통해 동일한 도메인에서 A/B 테스트를 통해 전환 상승 폭을 측정할 수 있습니다. 집계 API를 사용하여 A/B 매개변수를 키로 인코딩한 다음 이러한 키 버킷별 전환 가치에 대한 요약 보고서를 수신할 수 있습니다.
(3분기에도 보고됨) 교차 도메인 전환	2개 이상의 도착 페이지가 있는 등 교차 도메인 전환을 추적하는 방법	4분기 업데이트: 교차 도메인 대화를 추적할 수 있는 방문 페이지 도착 페이지 제한을 삭제하기 위한 제안서를 게시했습니다. 이 제안은 구현되었습니다.
(3분기에 신고됨) 전환 보고서의 만료 설정	24시간 미만의 보고서 필터 / 만료 지원 요청	4분기 업데이트: 만료 기간과 보고 기간을 분리하여 보고 지연과 전환 만료 간의 절충점을 완화하는 이 풀 리퀘스트 를 공유했습니다. 이제 M110에서 출시됩니다.
사기 및 악용	광고가 게재되는 게시자 사이트를 기준으로 데이터를 분류하고 집계하여 잠재적인 허위 광고 행위에 대한 유용한 정보를 얻을 수 있도록 해 달라는 광고주 및 마케팅 담당자의 요청	이 의견은 여기 에서 적극적으로 논의되고 있으며 추가 의견을 보내주세요.
(3분기에도 신고됨) 이벤트 수준 보고 지연	이벤트 수준 보고의 지연 기간인 2~30일이 특정 사용 사례에 너무 길 수 있습니다.	이벤트 수준 보고의 기본 보고 기간은 2일, 7일, 30일입니다. 'expiry' 매개변수를 사용하여 이를 수정할 수 있습니다. 광고 기술은 만료를 최소 1일로 설정하여 2일 이내에 잠재적 신고를 받을 수 있습니다. 더 세분화된 보고는 타이밍 공격으로 이어질 수 있으므로 Google에서는 개인 정보 보호 메커니즘으로 만료의 세부사항을 1일로 제한합니다. 또한 이벤트 수준 보고서와 집계 보고서에 대해 독립적인 '만료' 매개변수를 설정할 수 있습니다. 여기를 참조하세요. 또한 Google Ads는 Attribution Reporting API를 통해 다른 광고 기술에서 가져오지 않는 특별한 보고 기간을 가져오지 않습니다.
동일한 보고 출처 요구사항	소스 등록 출처가 전환 등록 출처와 동일해야 한다는 요구사항을 삭제해 달라는 요청	이 사용 사례를 해결하려면 HTTP 리디렉션을 사용하여 등록을 위임하는 것이 좋습니다. 새로운 가이드에 대한 추가 의견을 보내주세요.
전환 추적	광고주가 설정한 특정 시간 전후에 전환이 발생했는지 구분해야 함	Attribution Reporting API는 소스 기여 분석의 만료 기간 및 우선순위 설정을 지원합니다. 둘 다 사용하면 X일 이내에 발생한 전환과 X일 후에 발생한 전환을 별도로 기여도로 부여할 수 있습니다.
노이즈 시뮬레이션	전환수가 적은 광고주에게 미치는 영향을 파악하기 위해 버킷별로 전환수를 다르게 시뮬레이션할 수 있는 기능을 요청합니다.	향후 버전의 Noise Lab에서 이를 시뮬레이션하는 방법을 추가할 예정입니다. 추가 의견이 있으시면 알려주세요.
모바일에서 보고	Chrome이 모바일에서 백그라운드로 실행 중일 때도 보고서가 계속 전송되나요?	현재는 모바일에서도 Chrome이 백그라운드에 있으면 보고서가 전송되지 않습니다. API가 Android 개인 정보 보호 샌드박스와 통합되면 변경될 수 있습니다. 여기를 참조하세요. Android 개인 정보 보호 샌드박스는 CMA에서 수락한 약속의 일부가 아닙니다.
데이터 사용 가능 여부	Google이 개인 정보 보호 샌드박스 API를 통해 데이터에 추가로 액세스할 수 있다는 우려	첫째, Google Ads는 Attribution Reporting API 또는 기타 개인 정보 보호 샌드박스 API의 데이터에 대한 우선적인 액세스 권한을 받지 않습니다. 이 문제는 Google의 약속에 관한 자세한 내용이 포함된 '상호 운용성'의 일반 의견 섹션에서도 다룹니다. 둘째, 규모가 큰 사이트와 작은 사이트의 차이에 관해 Google은 노이즈 기반 개인 정보 보호가 소규모 데이터 슬라이스에 더 큰 영향을 미칠 수 있음을 인식하고 있습니다. 하지만 완화할 수 있는 방법이 있습니다. 예를 들어 장기간에 걸쳐 집계하는 등의 방법으로 이 문제를 해결할 수 있습니다. 하지만 구매 1~2건과 같이 매우 작은 데이터 슬라이스를 기반으로 한 결론이 광고주에게 의미가 있는지 여부는 아직 명확하지 않습니다. Google은 오리진 체험 기간 동안 테스터가 다양한 개인 정보 보호 및 노이즈 매개변수를 실험하여 이 문제에 관한 더 구체적인 의견을 제공할 수 있도록 권장했습니다.

은밀한 추적 제한

사용자 에이전트 축소

의견 주제	요약	Chrome 응답
웹 생태계가 더 준비될 때까지 사용자 에이전트 축소 지연	예정된 User-Agent 축소 변경사항에 적응할 시간이 충분하지 않습니다.	이 의견은 전체 보고서의 'Google과 CMA의 상호작용' 섹션에 있는 '이해관계자 우려사항'에서 다룹니다.
웹 생태계가 더 준비될 때까지 사용자 에이전트 축소 지연	구조화된 사용자 에이전트 (SUA)가 배포될 때까지 사용자 에이전트 축소 출시 지연 요청	Google Ads팀은 2021년 10월에 OpenRTB에 구조화된 User-Agent 추가 (사양 참고)를 제안했으며, 이는 2022년 4월에 출시된 2.6 사양 업데이트에 통합되었습니다. 현재 SUA가 배포되어 사용되고 있다는 증거가 있습니다. UA-CH 및 WURFL API를 사용하여 SUA를 만드는 방법을 보여주는 Scientia Mobile 블로그 게시물에서 확인할 수 있습니다.

###

사용자 에이전트 클라이언트 힌트

의견 주제	요약	Chrome 응답
기타 은밀한 추적 방지 기법으로 UA-CH 테스트	전체적인 접근 방식으로 제안된 모든 개인 정보 보호 샌드박스 API 및 지문 식별 기법을 테스트하는 방법에 관한 안내	테스트 계획은 나머지 샌드박스 제안서와 달리 일부 핑거프린트 방지 조치를 개발하는 비동기 타임라인을 반영하도록 설계되었습니다. 일부 핑거프린트 방지 조치 (예: 개인 정보 보호 예산, IP 보호, 이탈 추적 완화)는 서드 파티 쿠키 지원 중단 후에만 완전히 개발되고 정식 버전으로 출시할 준비가 된다는 현실을 반영합니다. 이러한 핑거프린트 방지 조치는 정량적 테스트에 포함되지 않지만, 정지 시점에 사용 가능한 사실을 토대로 정성적 평가를 받게 됩니다.
(2분기에도 보고됨) 실적	첫 페이지 로드 시 Critical-CH를 통한 힌트 가져오기 지연 시간에 대한 우려	아래의 전용 UA-CH 섹션을 참고하세요.
불충분한 의견	UA-CH 변경사항에 대한 생태계의 의견이 충분하지 않을 수 있으므로 생태계의 인식 부족에 대한 우려가 제기될 수 있습니다.	Google은 중단을 최소화하는 신중한 출시를 위해 계획을 사전에 공유해 왔습니다. 사용자 에이전트 축소 및 UA-CH API에 대한 계획은 2022년 3월 18일에 W3C 사기 방지 커뮤니티 그룹에, 2022년 1월 20일에 웹 결제 작업 그룹 및 웹 결제 보안 관심 그룹에 모두 제출되었습니다. 프레젠테이션 중이나 후에 심각한 우려사항이 제기되지 않았습니다. Google은 의견을 얻기 위해 100개가 넘는 사이트 운영자와 사전 협력했습니다. 또한 Google은 Blink-Dev 채널을 사용하여 생태계 이해관계자의 의견을 바탕으로 사용자 에이전트 감소 출시를 공개적으로 알렸습니다.
시간	출시 시기 및 업계 준비 상태에 대한 우려 제기	아래의 전용 UA-CH 섹션을 참고하세요.
Chrome 플랫폼 상태	UA-CH의 chromestatus 페이지 업데이트 요청	chromestatus 항목이 12월 19일에 '혼합 신호'로 업데이트되었습니다.

IP 보호 (이전 명칭: Gnatcatcher)

의견 주제	요약	Chrome 응답
선택 또는 선택 해제	IP 주소 개인 정보 보호를 선택해야 하나요 아니면 선택 해제해야 하나요?	Google의 목표는 모든 사용자에게 IP 보호를 제공하는 것입니다. Google은 이러한 목표를 달성하기 위해 현재 IP 보호를 위한 사용자 선택 옵션을 평가하고 있습니다.
퍼스트 파티 데이터의 IP 주소 사용 사례	IP 보호 후 IP 주소를 사용하여 퍼스트 파티 도메인 전반에서 사용자 여정을 연결할 수 있나요?	이전에 게시된 바와 같이 IP 보호는 초기에 서드 파티 맥락에서의 추적에 중점을 둘 예정이므로 퍼스트 파티 도메인은 영향을 받지 않습니다.
광고 기술 사용 사례	기업은 IP 보호를 통해 사기 방지 조치를 어떻게 설정할 수 있나요?	Google은 오늘날 웹에서 사기 방지 노력을 위한 신호로서 IP 주소의 중요성을 인식하고 있습니다. Google은 CMA에 대한 약속 (20항)의 일환으로 웹사이트의 스팸 및 사기 방지 기능을 지원하기 위한 합당한 노력을 기울이지 않으면 IP 보호를 구현하지 않겠다고 밝혔습니다. Google의 최우선 과제 중 하나는 IP 보호가 사기 방지 사용 사례와 감지 기능에 어떤 영향을 미치는지 파악하여 기업이 웹 안전을 유지하는 데 도움이 되는 개인 정보 보호 기술에 추가로 투자하는 것입니다. Google은 신호가 시간이 지남에 따라 변화하더라도 보안 및 사기 방지 회사의 요구사항을 지원하기 위한 의견과 새로운 제안서에 대한 의견을 적극적으로 수렴하고 있습니다.
사기 및 악용	IP 보호에 서비스 거부 (DoS) 보호가 포함되나요?	Google은 웹을 안전하게 유지하면서 개인 정보 보호를 개선하기 위해 노력하고 있으며, 서비스 거부 공격으로부터 보호하는 것은 설계해야 하는 중요한 악용 방지 사용 사례입니다. Google은 IP 보호 자체의 설계와 새로운 악용 방지 솔루션을 통해 DoS 보호에 미치는 영향을 최소화하고자 합니다. IP 보호는 초기에 서드 파티 삽입 서비스에 중점을 두었기 때문에 일부 이해관계자는 퍼스트 파티 사이트의 DoS 보호에 미치는 영향이 제한적일 것이라고 지적했습니다. 하지만 Google은 DoS 사용 사례, 특히 서드 파티 삽입 서비스에 대한 위험을 평가하기 위해 계속해서 공개 의견을 요청하고 있습니다. 이와 동시에 Google에서는 사이트 또는 서비스가 사용자를 식별하지 않고도 스팸 사용자를 차단할 수 있는 악용사례 신고 및 클라이언트 차단 메커니즘을 모색하고 있습니다.
콘텐츠 필터링	IP 보호를 통한 콘텐츠 필터링	콘텐츠 필터링 및 사용자 환경 맞춤설정에 대한 요구사항은 회사마다 다릅니다. 이러한 사용 사례 중 상당수는 현재 IP 주소를 사용하지 않으므로 IP 보호의 영향을 받지 않습니다. 예를 들어 콘텐츠를 맞춤설정하고 참여도를 높이려는 게시자는 퍼스트 파티 쿠키 또는 서드 파티 파티션 쿠키 (CHIP)를 사용하여 사용자의 관심분야와 게시자와의 이전 상호작용을 파악할 수 있습니다. 또는 적합한 사용자에게 적합한 광고를 게재하는 데 중점을 둔 광고 기술 파트너는 FLEDGE 및 Topics를 통합하여 오늘날 서드 파티 쿠키 또는 기타 교차 사이트 추적 기술을 통해 제공하는 것과 유사한 광고 결과를 제공할 수 있습니다. 또한 기존 메커니즘이 충분하지 않은 경우 콘텐츠 필터링을 더욱 지원하기 위해 대략적인 위치 정보와 같은 새로운 개인 정보 보호 기능을 IP 보호에 구현하는 방안도 모색하고 있습니다. IP 보호의 영향을 받을 수 있는 콘텐츠 필터링 사용 사례에 관한 추가 의견을 보내주세요.
(3분기에도 신고됨) 위치정보 사용 사례	IP 보호로 인해 향후 위치정보 기반 콘텐츠 맞춤설정과 같은 합법적인 위치정보 사용 사례가 작동하지 않을 수 있습니다.	4분기 업데이트: Google은 Chrome에서 IP 주소의 적법한 사용 사례를 계속 지원할 수 있도록 이해관계자와 협력하고 있습니다. 여기에서 IP 위치정보 세분성에 관한 생태계 의견을 받고 있습니다.

개인 정보 보호 예산

의견 주제	요약	Chrome 응답
더 명확한 문서	이해관계자가 개인 정보 보호 예산이 구현되면 어떻게 제한될 수 있는지 예상할 수 있도록 더 많은 예시	개인 정보 보호 예산 제안서는 아직 논의가 진행 중이며 어떤 브라우저에서도 구현되지 않았습니다. 확장된 사용 가능 여부의 가장 빠른 날짜는 개인 정보 보호 예산을 적용할 수 있는 가장 빠른 날짜를 나타냅니다. 2024년 서드 파티 쿠키가 삭제되기 전에는 이러한 변경사항이 적용되지 않습니다. 현재 공유해 드릴 추가 문서가 없습니다. 제안서가 최종적으로 확정되면 자세한 내용을 공유해 드리겠습니다. 그동안 이해관계자는 제안서 작성에 도움이 되는 의견을 공유해 주시기 바랍니다.

크로스 사이트 개인 정보 보호 경계선 강화

퍼스트 파티 세트

의견 주제	요약	Chrome 응답
(3분기에도 신고됨) 도메인 한도	연결된 도메인 수 확대 요청	4분기 업데이트: GitHub의 모의 세트 제출 프로세스와 로컬에서 rSA 및 rSAFor를 테스트하는 플래그를 포함하여 로컬 테스트를 위한 FPS를 출시했습니다. 또한 FPS 개발자를 대상으로 관련 하위 집합의 사용 사례에 관한 질문을 계속해서 해결하기 위한 공개 회의를 두 번 개최했습니다. 개발자는 FPS 기능을 테스트하여 연결된 하위 집합의 도메인 제한이 사용 사례에서 FPS의 사용성에 어떤 영향을 미치는지에 관한 의견을 제공하는 것이 좋습니다. WICG 회의에서 Chrome은 사용자의 개인 정보 보호 이익도 고려하는 사용 가능한 솔루션을 제공하기 위해 노력하고 있다고 명확히 밝혔습니다. Google은 이러한 맥락에서 Google에서 사용자 개인 정보를 계속 보호하면서 이러한 사용 사례를 해결할 방법을 고려할 수 있도록 도메인 제한의 영향을 받을 수 있는 특정 사용 사례에 관한 커뮤니티의 의견을 기다립니다.
악용사례 완화 조치에 관한 자세한 정보 요청	동의하지 않은 세트에 도메인이 추가되면 어떻게 되나요?	2022년 12월 2일에 퍼스트 파티 세트 제출 가이드라인이 여기에 게시되었습니다. 제출 가이드라인에 설명된 대로 모든 설정 변경 관리는 소유권 검증을 비롯하여 GitHub의 검증 프로세스를 따르고 준수하므로 이 위험을 완화할 수 있습니다.
악용 완화	퍼스트 파티 세트 구성이 악용될 수 있다는 우려	YouTube는 하위유형 유형에 대한 기술적 검토를 확대할 방법을 모색하고 있으며 여기에서 커뮤니티의 추가 의견을 적극적으로 수렴하고 있습니다.
광고 사용 사례	광고 타겟팅을 지원하는 데 퍼스트 파티 세트를 사용해야 하는지에 관한 질문	Google에서는 퍼스트 파티 세트의 광고 타겟팅 사용 사례를 지원하지 않으며, 이러한 사용 사례에는 Ads API를 사용하는 것이 좋습니다.
(3분기에도 신고됨) 정책	GDPR에서는 세트의 사이트 수에 제한을 두지 않지만 FPS에서는 3개로 제한하고 있으므로 FPS가 '해당하는 데이터 보호법률'에 관한 CMA의 약속과 일치하지 않는다는 우려	답변은 3분기와 동일합니다. "Google은 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안을 설계하고 구현하며, 디지털 광고, 게시자, 광고주의 경쟁에 미치는 영향은 물론 개인 정보 보호 결과와 관련 데이터 보호 원칙 준수에 미치는 영향도 고려하기 위해 CMA에 계속해서 노력하고 있습니다. 제기된 우려사항은 GDPR과의 비호환성을 드러내지 않습니다. Google은 이러한 약속을 준수하기 위해 CMA와 긴밀히 협력하고 있습니다."
대안 제안서	GDPR 검증 세트	'GDPR Validated Sets'를 채택하기 위한 제안서에 대해 생태계에서 제공한 의견 외에도 Chrome은 이 대체 제안서의 다음과 같은 제한사항에 관해 우려하고 있습니다. 'GDPR 검증 세트'는 GDPR을 '준수'한다고 주장하지만 그 의미는 명확하지 않습니다. 반면 Google은 '개인 정보 보호 결과에 미치는 영향'을 더 일반적으로 고려해야 합니다. CMA는 약속을 수락하는 결정에서, 이는 '해당하는 데이터 보호법에 명시된 데이터 보호 원칙 준수'를 고려해야 하는 Google의 의무와는 다르다고 지적합니다. CMA는 Google이 약속에 적용되는 경우와 더 일반적인 경우 모두 관련 데이터 보호법의 적용을 받는다는 사실을 반영한다고 설명합니다. 도메인이 여러 세트에 표시되도록 허용하는 제안에 개인 정보 보호 문제가 있습니다. 퍼스트 파티 세트는 광범위한 크로스 사이트 추적을 사용 설정하지 않고도 현재 서드 파티 쿠키에 의존하는 특정 사용 사례를 지원하기 위한 것입니다. 도메인이 여러 세트에 참여하도록 허용하면 다른 의미 있는 제한사항을 도입하지 않고도 퍼스트 파티 세트 제안서에 내장된 주요 개인 정보 보호 기능이 삭제됩니다. GDPR Validated Sets는 '공통 사용 정책을 공유하는 데이터 컨트롤러 및 프로세서의 그룹으로 세트를 정의'할 것을 제안합니다. 이는 세트의 모든 당사자가 공통 개인정보처리방침을 공유해야 한다는 기존 퍼스트 파티 세트 제안서의 요구사항과 유사합니다. 이후 개인정보처리방침 기반 요구사항에 대한 우려를 제기하는 생태계의 강력한 의견을 바탕으로 해당 요구사항을 삭제했습니다. 예를 들어 사이트 게시자는 W3C 커뮤니티 회원들이 제기한 여러 문제 중 제품 및 지역적 차이로 인해 공통적인 개인 정보처리방침을 유지하는 것이 불가능하다고 말했습니다 (1, 2, 3). 이 제안에도 동일한 문제가 적용될 것으로 보입니다. 이 대안이 제기된 이후 Chrome은 퍼스트 파티 세트 제안서를 업데이트하고 새 세트를 만드는 방법에 관한 제출 가이드라인을 게시했습니다.

Fenced Frames API

의견 주제	요약	Chrome 응답
OT 중 펜싱된 프레임 제한	오리진 트라이얼 기간 동안 Fenced Frames에는 현재 어떤 제한사항이 있나요?	제한사항 및 구현 상태에 관한 문서를 준비 중이며 2023년 1분기에 공유할 계획입니다.
하나의 펜싱된 프레임에 여러 광고	하나의 입찰에서 하나의 펜싱된 프레임에 여러 광고주를 표시하도록 요청	현재 이 요청은 적극적으로 개발되고 있지 않지만 생태계 참여자가 이 기능을 중요하게 생각하는 경우 추가 의견을 보내주세요.
웹 번들	펜싱된 프레임이 있는 웹 번들에 계획된 요구사항 및 지원은 무엇인가요?	향후 이 요건이 적용될지 여부에 대한 업데이트는 현재 없습니다. 변경사항이 있으면 사전에 공지되며 서드 파티 쿠키 지원 중단 전에 시행되지 않습니다. 현재 상태는 이 설명을 참고하세요.

Shared Storage API

의견 주제	요약	Chrome 응답
광고 기술용 공유 저장소	광고 기술 사용 사례에 공유 스토리지를 사용하는 것과 관련된 불확실성	Shared Storage API와 Private Aggregation API는 교차 사이트 스토리지 측정이 필요한 다양한 측정 목적으로 사용할 수 있습니다. 여기에 몇 가지 예가 나와 있습니다. DSP 및 측정 솔루션 제공업체가 광고 사용 사례의 주요 통합업체가 될 것으로 예상됩니다.

CHIPs

의견 주제	요약	Chrome 응답
(3분기에 신고됨) 파티션 요구사항	퍼스트 파티 쿠키의 '분할됨' 속성에 명시적인 동작 요구사항을 추가합니다.	4분기 업데이트: GitHub 및 PrivacyCG 통화에서 논의한 결과, 일치된 동작은 퍼스트 파티 쿠키에 설정된 파티션된 쿠키가 'A'가 최상위 사이트인 파티션 키 (A,A)를 사용한다는 것입니다. 이 동작은 설명서 및 사양에 문서화될 예정입니다.
쿠키 관리	퍼스트 파티 또는 서드 파티 쿠키를 관리/규제하는 도구가 있나요?	Chrome DevTools 및 NetLog를 사용하여 서드 파티 쿠키 차단이 사용 설정된 사이트를 테스트할 수 있습니다. 두 도구 모두 사용자 구성으로 인해 쿠키가 차단되면 이를 보고합니다. 어떤 종류의 추가 감사 웹사이트를 원하는지 의견을 보내주세요.

FedCM

의견 주제	요약	Chrome 응답
IDP가 세션을 허용하려면 RP에 대한 지식이 필요합니다.	사용자가 두 개의 서로 다른 RP에서 Feide IdP에 로그인하려고 할 때 발생하는 문제	이 문제에 대한 잠재적 해결책을 논의하고 있습니다.
상호 운용성	FedCM이 사용자와 FedCM을 사용하여 로그인하는 웹사이트 간의 관계에 미치는 영향 및 웹사이트 간의 '상호 운용성'에 관한 우려	FedCM은 Chrome에서 서드 파티 쿠키가 삭제된 후에도 현재 서드 파티 쿠키를 사용하는 제휴 ID 서비스를 계속 지원하는 것을 목표로 합니다. FedCM은 이러한 서비스에 사용할 수 있는 여러 옵션 중 하나일 것으로 예상됩니다. ID 공급자 (IdP)와 신뢰 당사자 (RP)는 필요에 더 적합한 다른 기술을 자유롭게 사용할 수 있습니다. 사용자-RP 관계 및 '상호 운용성'에 관한 우려는 FedCM 제안서에 대한 오해에서 비롯된 것으로 보입니다. FedCM은 사용자가 RP 사이트에 로그인하기 위해 선택한 후 RP와 공유할 정보와 형식을 IdP에 맡깁니다. FedCM은 IdP가 '사용자가 인증하는 각 [RP] 에 대해 고유한 가명 식별자를 생성'하도록 요구하지 않습니다. 대신 FedCM은 각 IdP가 사용자의 실제 식별자, 해당 식별자의 사이트별 버전 또는 이 정보의 다른 버전을 공유할지 선택할 수 있도록 합니다. (FedCM 사양에서는 교차 사이트 상관을 API와 관련된 개인 정보 보호 위험으로 식별하고, 가능한 완화 조치로 지향형 (사이트별) 식별자를 설명합니다. 그러나 지향형 식별자를 사용할지 여부는 브라우저가 강요하는 것이 아니라 IdP에서 결정합니다.) FedCM은 이미 ID와 관련된 사용자 선택권도 제공하고 있습니다. 예를 들어 사용자에게 동일한 IdP에 여러 ID (예: 직장 프로필 및 개인 프로필)가 있는 경우 FedCM을 통해 사용자가 RP 사이트에 로그인할 때 사용할 ID를 선택할 수 있습니다. 그 외에도 각 RP는 사이트에서 지원할 IdP를 자체적으로 결정합니다. 이 결정의 한 가지 측면은 FedCM인지 다른 기술인지 IdP에서 사용하는 메커니즘을 고려하는 것입니다. 다시 말하지만 브라우저는 RP 또는 IdP에 이러한 선택사항을 지시하지 않습니다.

스팸 및 사기 퇴치

Private State Token API

의견 주제	요약	Chrome 응답
봇 처리	발급기관에서 비공개 상태 토큰이 봇에 발급되었음을 발견하면 어떻게 되나요?	봇에 발급된 토큰이 생태계에 오랫동안 남아 있지 않도록 하려면 발급자가 토큰에 서명하는 데 사용하는 키를 정기적으로 회전해야 합니다. 그러면 손상되었을 수 있는 발급 로직에 따라 발급된 이전 토큰이 만료되고 사이트에서 업데이트된 발급 로직으로 새 토큰을 사용할 수 있습니다.
Same-site 양식 제출	비공개 상태 토큰을 fetch/XMLHttpRequest API의 요청이 아닌 전체 페이지 탐색 (예: Content-Type: application/x-www-form-urlencoded)이 포함된 동일 사이트 양식 제출에 사용할 수 있나요?	현재 비공개 상태 토큰의 첫 번째 버전에서는 지원되지 않습니다. 이 사용 사례에 대한 수요가 많은 경우 생태계의 의견을 기다립니다.
서버 측 확인	비공개 상태 토큰을 서버 측에서 확인할 수 있는지에 관한 질문	토큰은 발급자에 대해 사용되며, 발급자는 토큰 자체 또는 토큰에서 파생된 서명된 값을 포함할 수 있는 사용 레코드를 만듭니다. 서버는 이 사용 레코드를 사용하여 토큰의 진위를 확인할 수 있으며, 발급자 생태계마다 사용 레코드를 해석하는 방법에 관한 서로 다른 표준을 마련할 것으로 예상됩니다.

의견 보고서 - 2022년 4분기 bookmark_borderbookmark 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.