의견 보고서 - 2025년 1분기

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

개인 정보 보호 샌드박스 제안 및 Chrome의 대응에 대해 받은 생태계 의견을 요약한 2025년 1분기 분기별 보고서입니다.

Google은 12항, 17항(c)(ii), 32항(a)에 따라 경쟁시장청('CMA')에 대한 약속의 일환으로 이 분기 보고서를 작성했습니다. 이 보고서에서는 개인 정보 보호 샌드박스 제안서와 관련하여 Google이 이루어낸 진전사항, 업데이트된 예상 일정, Google이 서드 파티의 관찰사항을 고려한 방식에 관한 실질적인 설명, CMA의 의견 및 Google의 의견 처리 방식을 포함하여 Google과 CMA 간의 상호작용에 관한 요약을 다룹니다.

Google은 약속 17항(b)에 따라 정기적으로 예정된 상태 회의에서 개인 정보 보호 샌드박스 제안서의 진행 상황을 CMA에 계속 업데이트해 왔습니다. 또한 팀은 핵심 비공개 광고 기능 및 쿠키 변경사항에 대한 개요와 API 구현 및 상태 정보를 제공하는 개발자 문서를 유지 관리합니다. 주요 업데이트는 개별 개발자 메일링 리스트에 공유되는 타겟팅된 업데이트와 함께 개발자 블로그에 공유됩니다.

약어 용어집

ARA

Attribution Reporting API

CHIPS

독립적으로 파티션된 상태의 쿠키

DSP

수요측 플랫폼

FedCM

Federated Credential Management

IAB

인터넷광고협회

IDP

ID 공급업체

IETF : 인터넷 엔지니어링 태스크포스

인터넷 엔지니어링 태스크포스

IP

인터넷 프로토콜 주소

openRTB

실시간 입찰

연장전

Origin 무료 체험

PA API

Protected Audience API (이전 명칭: FLEDGE)

PatCG

비공개 광고 기술 커뮤니티 그룹

RP

신뢰 당사자

RWS

관련 웹사이트 세트 (이전 퍼스트 파티 세트)

SSP

공급측 플랫폼

UA

사용자 에이전트 문자열

UA-CH

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

W3C

World Wide Web Consortium

WIPB

의도적 IP 무시

일반적인 의견이며 특정 API/기술 없음

의견 테마	요약	Chrome 응답
사용자 선택	사용자 선택권을 높이기 위한 Google의 업데이트된 접근 방식이 어떻게 표시되고 사용자에게 어떻게 제공될지, 예상되는 선택/선택 해제 비율은 무엇인지 명확하지 않습니다. 서드 파티 쿠키 지원 중단과 구분하려면 추가 정보가 필요합니다.	2025년 4월, Google은 Chrome의 개인 정보 보호 샌드박스 및 추적 보호 기능 관련 다음 단계에 관한 블로그 게시물을 게시하여 Chrome에서 사용자에게 서드 파티 쿠키를 제공하는 현재 접근 방식을 유지하기로 결정했으며 서드 파티 쿠키를 위한 새로운 독립형 메시지는 출시하지 않겠다고 발표했습니다. 추가 업데이트가 있으면 알려 드리겠습니다.
디지털 지문 수집	Google은 더 위험한 소비자 ID를 일반적인 일치 키 (예: 지문 식별)로 사용하지 않고도 Google의 광고 시스템에 대한 대안을 활용하는 방법에 관한 정보를 게시자 또는 마케팅 담당자와 공유하지 않았습니다.	개인 정보 보호 샌드박스 API를 부분적으로 기반으로 게시자와 마케터에게 솔루션을 제공하는 Google 이외의 광고 시스템을 몇 가지 소개했습니다. 여기에는 시장과 채널 전반에서 Google 이외의 광고 시스템이 포함됩니다. 자세한 내용과 우수사례는 privacysandbox.com의 비즈니스 리소스 섹션(여기)에서 확인할 수 있습니다.
개인 정보 보호 샌드박스	개인 정보 보호 샌드박스 API는 인터넷 데이터 구성요소를 Google 자체의 완제품으로 대체합니다. Google의 대안은 API이므로 Google에서 소유하고 관리하는 제품에 대한 액세스 권한을 제공하며 Google의 재량권에 따른 이용약관이 적용됩니다. 이는 다른 사용자가 자체 완제품을 만드는 데 사용하는 구성요소를 대체하지 않습니다.	개인 정보 보호 샌드박스 API는 규제 기관 및 다양한 생태계 이해관계자와의 광범위한 협의를 거쳐 개발 및 구현되었습니다. 다른 플랫폼 기술과 마찬가지로 개인 정보 보호 샌드박스 API는 다른 제품의 구성요소로 사용될 수 있다는 점을 고려해야 합니다. Google은 개인 정보 보호 샌드박스 API와 함께 작동하는 추가 기술을 개발하기 위한 생태계의 노력을 환영합니다.
사용자 선택	Chrome의 서드 파티 쿠키에 대한 Google의 업데이트된 접근 방식이 이해관계자 동의 관리 플랫폼 환경에 영향을 줄 수 있는 특정 규제 요건을 충족하는지 여부에 관한 정보 요청	2025년 4월, Google은 Chrome의 개인 정보 보호 샌드박스 및 추적 보호 기능 관련 다음 단계에 관한 블로그 게시물을 게시하여 Chrome에서 사용자에게 서드 파티 쿠키를 제공하는 현재 접근 방식을 유지하기로 결정했으며 서드 파티 쿠키를 위한 새로운 독립형 메시지는 출시하지 않겠다고 발표했습니다. 추가 업데이트가 있으면 알려 드리겠습니다.
개인 정보 보호 샌드박스 타임라인 및 채택	애드테크는 개인 정보 보호 샌드박스 API 테스트를 일시중지했으며 제품 및 마케팅 활동을 위해 이러한 기술에 재투자할 더 강력한 이유를 찾고 있습니다. 재투자 결정은 사용자 선택 타임라인에 대한 명확한 설명의 필요성과 Protected Audience API (PA API) 지연 시간 및 B&A 로드맵에 대한 우려에 크게 영향을 받습니다. 또한 예정된 CMA 약속 검토에 대한 우려가 있습니다. 특히 서드 파티 식별자를 사용하지 않고 개인 정보 보호 샌드박스 기술을 주도하는 Google의 역할과 투자 전략을 알리는 이니셔티브의 전반적인 향후 방향에 대한 우려가 있습니다.	2025년 4월, Google은 Chrome의 개인 정보 보호 샌드박스 및 추적 보호 기능 관련 다음 단계에 관한 블로그 게시물을 게시하여 Chrome에서 사용자에게 서드 파티 쿠키를 제공하는 현재 접근 방식을 유지하기로 결정했으며 서드 파티 쿠키를 위한 새로운 독립형 메시지는 출시하지 않겠다고 발표했습니다. 새로운 소식이 있으면 알려드리겠습니다. Chrome PA API 입찰이 전년 대비 35% 더 빨라졌습니다. 또한 병렬 입찰의 사용이 크게 증가하여 이러한 입찰에서 더 큰 낙찰가를 얻을 수 있게 되었습니다. 현재 B&A 로드맵은 여기에서 확인할 수 있습니다.
개인 정보 보호 샌드박스 타임라인	개인 정보 보호 샌드박스 타임라인 페이지에서 무엇이 업데이트되었나요?	최근 개인 정보 보호 샌드박스 타임라인 페이지에 Topics API의 개요가 추가되었습니다.
개인 정보 보호 샌드박스	개인 정보 보호와 유용성 간의 관계에 관한 연구 논문 중 개인 정보 보호 샌드박스가 수익에 미치는 영향을 이해하는 데 도움이 되는 논문이 있나요?	이러한 질문을 다루는 관련 시장 사례 연구는 여기에서 확인할 수 있으며 개인 정보 보호 샌드박스 API 테스트 결과는 여기에서 확인할 수 있습니다.
개인 정보 보호 샌드박스 채택	초기 사용자는 대기업의 도입이 느려 개인 정보 보호 샌드박스 API와 관련된 초기 문제가 테스트 출시에 영향을 미쳤다고 신고했습니다. 하지만 그럼에도 불구하고 개인 정보 보호 샌드박스팀의 공동작업 접근 방식과 의견에 대한 응답이 높이 평가되었습니다.	사전 체험판 사용자의 의견을 보내주셔서 감사합니다. Google은 조기 사용자와 협력하기 위해 최선을 다하고 있으며, 생태계 지원에 있어 개인 정보 보호 샌드박스 기술의 역할을 평가하면서 생태계와 지속적으로 소통하고 의견을 수렴할 것입니다.
Chrome 테스트	서드 파티 쿠키가 사용 중지된 Chrome (모드 B)과 Chrome 설정에서 서드 파티 쿠키를 직접 사용 중지한 사용자 간에 트래픽 품질의 상당한 차이를 보여주는 테스트 라벨이 삭제된 후 개인 정보 보호 샌드박스 테스트를 효과적으로 계속할 수 있을지에 대한 우려	Google의 대답은 이전 분기와 비슷합니다. 개인 정보 보호 샌드박스팀은 기업에서 쿠키 지원 중단 라벨을 계속 사용하고자 하는 점을 잘 알고 있습니다. 라벨의 사용 가능 여부를 연장하는 프로세스는 출처 체험판 연장과 유사합니다. 라벨 지원은 여러 번 연장되었습니다. 쿠키 지원 중단 라벨에 대한 지원을 추가로 확장하는 방안을 제안할 예정이며, 업데이트가 있으면 blink-dev에서 공유할 예정입니다.

등록 및 증명

이번 분기에 받은 의견이 없습니다.

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

주제

의견 테마	요약	Chrome 응답
수신 동의/수신 거부	Google 검색에서 사이트의 Topics API 선택 해제 결정을 순위 신호로 사용하지 않을 것이라는 Google의 확인은 사이트의 Topics API 선택 결정을 순위 신호로 사용하지 못하도록 제한하나요?	Google의 대답은 이전 분기와 비슷합니다. 개인 정보 보호 샌드박스팀은 웹사이트가 Topics API를 채택하도록 장려하기 위해 페이지 순위를 사용하는 방안을 검색 조직과 조정하거나 요청하지 않았습니다. Google 검색에서는 사이트가 Topics API를 지원하거나 지원하지 않기로 한 결정을 순위 신호로 사용하지 않습니다.
사용량 관측 가능성	SSP 또는 일반 광고 기술의 관찰 가능성 메커니즘을 요청하여 Topics API 구현이 웹에서 사용되고 있는지 확인할 수 있습니다.	이 기능에 대한 지원을 평가하고 있으며, 이 기능이 우선순위가 높은 경우 생태계의 추가 의견을 기다립니다.
개인 정보 보호	동의 및 재식별 가능성에 관한 질문	현재 여기에서 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다.

Protected Audience API

의견 테마	요약	Chrome 응답
PA API 및 GAM/AdX	Google은 경쟁 게시자 광고 서버를 이용하려는 게시자에게 GAM/AdX 수요를 전송하지 않습니다. Google은 경쟁 게시자가 최종 입찰을 제어할 수 있는 대체 최상위 PA API 입찰 판매자를 선택할 수 있도록 해야 합니다. PA API의 정보는 GAM에서 사용할 수 있지만 경쟁 SSP에서는 제한됩니다. 따라서 게시자는 GAM에서 PA API 소스 수요(예: AdX 또는 PA API에 통합된 SSP)의 실적을 비교할 수 없습니다.	Chrome 응답: PA API 표준은 유연하게 설계되어 여러 당사자가 최상위 입찰을 실행할 수 있습니다. 이 선택은 게시자의 광고 서버 (GAM이든 다른 서버든) 및 생태계의 다른 참여 회사에서 제공하는 구체적인 구현 및 기능에 따라 달라집니다. PA API의 개인 정보 보호 중심 설계는 모든 참여자에 대한 세부적인 보고를 일관되게 제한합니다. PA API 입찰 자체에서 보고된 특정 데이터에는 SSP를 포함한 모든 참여자에 대해 동일한 API 정의 개인 정보 보호 규칙 및 제한사항이 적용됩니다. 게시자는 PA API의 집계된 개인 정보 보호 보고서를 사용하여 실적을 평가합니다. 이를 통해 PA API를 통해 제공된 수요의 전반적인 기여도를 평가하고 API의 설계 시 개인 정보 보호 원칙에 따라 다른 수요 채널과 비교할 수 있습니다. Google Ad Manager에서 제공한 응답: 게시자는 AdX 수요에 액세스하기 위해 GAM의 광고 서버 기능을 사용할 필요가 없습니다. 또한 PA API는 단일 판매자 설계와 복수 판매자 설계 모두에서 입찰을 누가 시작하는지에 관계없이 작동합니다.
최상위 판매자	최상위 판매자 (TLS)는 다른 구성요소 판매자가 액세스할 수 없는 정보에 액세스할 수 있으므로 정보에 대한 액세스 불균형에 대한 우려가 제기됩니다. 어떤 항목이든 TLS가 될 수 있지만 게시자는 AdX 수요에 액세스하기 위해 GAM을 게시자 광고 서버로 사용해야 합니다. 이렇게 하면 GAM을 게시자 광고 서버로 사용하는 인센티브가 생겨 Google에 경쟁 우위가 생깁니다.	Chrome 응답: PA API의 설계는 TLS로 작동할 수 있는 항목을 지정하지 않습니다. TLS 역할은 API 구조에 따라 입찰을 조정하고 관련 입찰 정보에 액세스해야 합니다. Google Ad Manager의 답변: Google은 오랜 기간 입찰의 공정성에 중점을 두고 노력해 왔습니다. 그중 하나로 미보장 광고 항목 가격을 포함하여 게시자의 미보장 광고 소스에서 제공하는 가격은 입찰에 참여하기 전에 다른 구매자와 공유되지 않는다는 약속을 했는데, 이는 나중에 프랑스 경쟁 당국에 대한 Google의 약속에서 재확인되었습니다. PA API 입찰의 경우 Google은 약속을 지키고 복수 판매자 입찰에서 입찰이 완료되기 전에 입찰 참여자의 입찰가를 다른 입찰 참여자와 공유하지 않을 계획입니다. 명확히 말씀드리자면, 이 업데이트에 설명된 대로 Google은 Google의 입찰을 포함한 어떠한 구성요소 입찰에도 문맥 입찰의 가격을 공유하지 않습니다. 또한 Google은 구매자가 SSP에 제공하는 신호를 비롯한 구성요소 입찰 구성에 관한 정보를 자체 입찰에 사용하지 않습니다. 또한 위에 설명된 대로 GAM에서는 게시자가 AdX 수요에 액세스하기 위해 광고 서버 기능을 사용할 필요가 없습니다. 마지막으로, 이전에 Google의 2024년 2분기 / 3분기 보고서에서 언급했듯이 Google의 구매 측 플랫폼인 Google Ads (이전 명칭: AdWords) 및 DV360은 PA API를 통한 구매를 포함하여 Google 이외의 거래소에서 노출을 구매합니다.
PA API 및 GAM/AdX	옵션의 라벨이 목적을 명확하게 나타내지 않으므로 게시자가 인벤토리의 100% 에 PA API를 활성화하는 것을 이해하기 어렵습니다. 인벤토리에 액세스하는 기본 수단이 GAM이 TLS로 작동하는 다단계 입찰인 SSP의 경우 GAM의 영향을 받지 않고 PA API를 통해 테스트를 진행하거나 수익을 창출할 방법이 없습니다.	Chrome 응답: PA API 표준은 기술적 역할 (예: TLS 및 구성요소 판매자)과 입찰 프로세스를 정의하므로 플랫폼에서 이러한 역할을 수행하는 방식을 유연하게 조정할 수 있습니다. 구성, 조정, 계약과 같은 운영 활동은 PA API 프레임워크를 사용한 참여를 용이하게 하기 위해 구현 당사자 (게시자, SSP, TLS 제공업체)가 관리합니다. Google Ad Manager에서 제공하는 응답: 고객센터에 설명된 대로 Ad Manager는 게시자에게 API를 사용할 수 있는 게시자 인벤토리의 100% 에 대해 Google 이외의 구성요소 판매자(예: 다른 SSP)를 대상으로 테스트를 사용 설정할 수 있는 관리 기능을 제공합니다(GAM에서 적용할 수 있는 샘플링 또는 제한을 재정의함). 게시자가 이 제어 기능을 사용 설정하면 Google 이외의 구성요소 판매자가 입찰 구성을 제공할 때마다 GAM은 게시자가 필요한 사용자 동의를 얻은 경우 제공된 구성요소 입찰이 포함된 최상위 입찰을 실행하려고 시도합니다. GAM은 게시자가 충분한 정보를 바탕으로 결정을 내릴 수 있도록 이 제어 기능이 실적에 영향을 줄 수 있음을 게시자에게 명확하게 알려줍니다.
서버 측 및 기기 내	입찰과 같은 서버 측 솔루션은 개인 정보를 보호하면서 트래픽 형성을 해결할 수 있습니다. 서버 측 솔루션이 유일한 실행 가능한 경로이며 Google은 온디바이스 솔루션을 포기해야 합니다.	개인 정보 보호 샌드박스는 서버 측 (B&A 서비스) 및 기기 내 입찰 솔루션을 모두 지원하여 다양한 광고 기술 니즈와 사용 사례를 충족할 수 있는 옵션을 제공하는 것을 목표로 합니다.
입찰 보안	PA API 입찰에 대한 공격은 기본적으로 기기 내 입찰을 무효화합니다. 이 문제는 이해관계자로부터 해결된 것으로 간주되지 않으며, 이해관계자들은 PA API 입찰이 조작되지 않도록 하는 기술적 보장과 실시간 이슈 감지 및 효율적인 디버깅을 제공하는 포괄적인 디버그 모드를 계속 요청하고 있습니다.	잠재적 공격 완화를 비롯한 PA API 입찰 무결성 보장은 개인 정보 보호 샌드박스의 핵심 과제입니다. API 설계에는 무결성 측정항목이 통합되어 있으며 구체적인 우려사항에 관한 추가 기술적 논의를 환영합니다. 2024년 5월 W3C 사기 방지 커뮤니티 그룹 회의에서 PA API에 대한 잠재적 공격과 완화 조치에 관한 자세한 목록을 발표하고 논의했습니다. 우려되는 'PA API 입찰에 대한 잠재적 공격'에 관한 추가 논의 및 의견을 보내주세요.
쿠키 없는 트래픽	테스트 또는 기타 목적으로 쿠키가 없는 트래픽에서만 PA API를 사용 설정하는 방법이 있나요?	광고 기술은 3PC가 있는지 여부를 식별할 수 있습니다. 자세한 내용은 여기를 참고하세요.
시트 ID	좌석 ID 제안과 관련하여 좌석 ID 지식은 대부분의 입찰 요청에 필수적이며, 이는 좌석 ID를 광고 소재 등록에 연결하는 것에 대한 우려를 불러일으킵니다. 또한 '기본 광고'에만 적용되나요, 구성요소 광고에도 적용되나요?	BuyerAndSellerReportingId 제안서에서는 기본 광고의 광고 소재 등록 중에 구매자의 Seat ID가 누락되는 문제에 대해 다룹니다. 이 식별자는 구매자의 좌석 ID를 판매자에게 전달하는 것을 목표로 합니다. Google에서는 구성요소 광고 지원을 평가하고 있습니다.
모니터링 및 보고	실시간 모니터링 (RTM)에 관한 기능 요청으로 (1) 취소된 입찰에 대한 RTM 보고서 전송 및 (2) 어떤 종류의 취소가 발생했는지 명확히 하는 새로운 브라우저 채워진 버킷이 있습니다.	RTM은 참여율을 조사하는 데 적합한 솔루션이 아닌 것으로 보입니다. RTM은 갑작스럽고 일시적인 심각한 서비스 중단을 포착하기 위해 지연 시간이 짧은 모니터링 API로 설계되었습니다. 반면 참여율에는 지연 시간이 짧은 보고가 필요하지 않으며 갑작스러운 일시적인 중단이 아닙니다. 참여율에 대한 우려는 브라우저를 통해 조사하는 구매자가 아닌 구매자가 협력하는 판매자가 가장 효과적으로 해결해 줄 수 있습니다. 또한 취소된 입찰은 매우 흔하므로 브라우저가 취소된 각 입찰에서 RTM 보고서를 생성하면 실제 중단에 대한 RTM 보고서가 묻힐 수 있습니다.
문서 설명	nonce가 UUID 문자열이어야 하지만 실제로는 약속을 반환한다고 설명하는 PA API 설명서의 문서 불일치에 관한 신고가 접수되었습니다.	여기에서 설명을 확인할 수 있습니다.
냉동 컨텍스트	동결된 컨텍스트로 작업할 때 (1) 번들링, (2) 외부 라이브러리, (3) 지원되지 않는 데이터 유형과 관련된 문제와 과제를 해결할 수 있는 옵션은 무엇인가요?	이 질문에 대한 답변은 여기에서 확인하실 수 있습니다.
사양	Private Aggregation API에 일반 contributeToHistogramOnEvent 작업이 추가되었습니다. 그 결과 PA API의 정의가 오버로드된 작업이 되었으며 웹 IDL 작업은 '인터페이스, 부분 인터페이스 전반에서 오버로드되어서는 안 됩니다'. 따라서 이제 이 정의는 유효하지 않습니다.	이 문제는 PA API와 비공개 집계 사양 간에 일시적인 불일치를 지적하며, 이는 두 사양에서 유사한 변경사항을 병합하는 동안 발생합니다. 이 문제를 해결하기 위해 pull 요청을 병합했습니다.
관심분야 그룹	캠페인이 중지될 때 관심분야 그룹 (IG)의 입찰 참여를 종료하는 데 권장되는 리소스 효율적인 방법에 관한 안내를 요청합니다.	다음은 몇 가지 제안사항입니다. 지연 시간이 가장 짧고 영구적이지 않으며 리소스 해제 메커니즘이 가장 적은 방법은 실시간 입찰 신호를 사용하여 generateBid()에 입찰을 중지하도록 알리는 것입니다. 리소스를 더 적게 사용하는 두 번째 옵션은 실시간 입찰 신호 응답에서 해당 IG의 우선순위를 음수로 설정하는 것입니다. 이렇게 하면 generateBid()가 호출되지도 않습니다. 세 번째 옵션은 리소스를 훨씬 더 적게 사용하는 방법으로, 인스타그램에서 광고를 삭제하는 것입니다. 광고가 없는 IG는 generateBid()가 호출되지 않습니다. 더 적은 리소스를 사용하는 네 번째 옵션은 IG에서 biddingLogicURL를 삭제하는 것입니다. 이 시점에서는 IG를 다시 활성화할 수 있도록 업데이트/다시 가입할 수 있습니다. leaveAdInterestGroup() 또는 clearOriginJoinedAdInterestGroups()를 통해 또는 IG 만료를 통해 IG를 종료하는 것과 관련된 추가 옵션이 있습니다. 위에서 강조했듯이 옵션마다 지연 시간과 리소스 소비가 다릅니다. 광고 기술은 특정 사용 사례에 가장 적합한 옵션을 선택할 수 있습니다.
잠재고객	생성된 잠재고객에 대해 논리적 작업을 실행하는 메커니즘 요청 (예: IG A와 B의 교집합을 타겟팅하는 기능)	이제 PA API를 사용하면 동일한 사이트의 잠재고객에 대해 논리적 작업을 실행할 수 있습니다. 현재 Google의 개인 정보 보호 모델에 설명된 대로 개인 정보 보호 고려사항으로 인해 여러 사이트에서 잠재고객에 대한 논리적 작업이 지원되지 않습니다. YouTube는 이 분야에 대한 연구를 계속 진행하고 있으며 새로운 소식이 있으면 공유해 드리겠습니다.
기능 요청	TLS를 사전에 알고 있어야 하는 추가 입찰에 대한 제한을 삭제하는 제안	현재 여기에서 이 제안서에 대해 논의 중이며 추가 의견을 환영합니다.
Chrome의 3PC에 대한 접근 방식이 업데이트됨	PA API와 같은 개인 정보 보호 샌드박스 API는 모든 Chrome 안정화 버전 사용자에게 계속 제공되나요? 아니면 API (또는 API의 하위 집합)를 3PC를 거부한 사용자만 사용할 수 있나요?	Google은 사용자가 서드 파티 쿠키를 거부하기로 한 결정이 Chrome 안정화 버전에서 개인 정보 보호 샌드박스 API의 사용 가능 여부에 영향을 미치지 않도록 하기 위해 노력하고 있습니다.
향상된 신호	TLS가 PA API 입찰을 실행할 의향이 있는지 나타내는 기능을 추가할 계획이 있나요?	이 기능에 대한 지원을 평가하고 있습니다. 일정이 확정되는 대로 자세한 내용을 공유해 드리겠습니다. 이 요청에 관한 추가 의견도 보내주세요.
거래 ID	거래 ID 제안서의 KV 서버 요구사항이 비용이 많이 들고 시간이 많이 걸리는 서버 측 프로세스일 수 있다는 우려가 제기되었습니다.	거래 ID 제안을 사용하면 SSP가 PA 입찰 중에 키-값 서버에서 선택한 거래 ID의 메타데이터를 쿼리할 수 있으므로 모든 거래 관련 메타데이터를 기기에 미리 로드할 필요가 없습니다. 이 제안은 SSP의 요청에 따라 개발 중이며 여기에서 생태계 관련 추가 의견을 보내주세요. 키-값 서버를 설정하는 데는 작업이 필요하지만 전반적으로 광고 기술 회사에 이점이 있다고 생각합니다. 이 절차를 더 쉽게 진행할 수 있도록 의견과 제안을 보내주세요.
교차 IG 최대 게재빈도 설정	PA API를 통한 교차 IG 최대 게재빈도 설정 요청	교차 IG 최대 게재빈도 설정에는 해결 방법을 찾을 수 없는 어려운 개인 정보 보호 문제가 있습니다. 이 기능이 우선순위가 높은 경우 생태계의 추가 의견을 보내주세요.
거래 ID 및 시트 ID 보고	집계 보고에 특가 또는 좌석 ID를 가져올 수 있는 기능을 요청합니다.	여기 에서 개발 중인 보고 ID 기능을 사용하면 특가 및 좌석 ID를 보고할 수 있습니다. selectedBuyerAndSellerReportingId는 reportResult()에 제공되므로 이를 보고하는 가장 쉬운 방법은 이벤트 수준 보고를 사용하는 것입니다 (즉, sendReportTo()에 전달된 URL에 거래 ID를 인코딩). 집계된 보고를 사용해야 하는 경우에도 가능합니다. 보고 ID 기능은 현재 Chrome 안정화 버전 채널 트래픽의 10% 에 적용되어 있습니다. 출시 범위를 100%로 확대하는 방안을 검토하고 있습니다.
관심분야 그룹	IG 선택과 평가 모두에서 동일한 우선순위 순서를 사용하고 모든 평가 모드에서 이 우선순위 순서를 사용합니다.	현재 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.
관심분야 그룹	개인 정보 보호 샌드박스 API 채택을 늘리는 방법으로 잠재고객 활성화 및 위임을 사용하는 것이 좋습니다.	YouTube는 여러 이해관계자의 요청을 인지하고 있으며 해결책을 모색하고 있습니다. 생태계의 추가 의견을 기다리고 있습니다.
관심분야 그룹	PA API IG 생성과 관련된 문제, 특히 여러 구매를 대행하거나 게시자를 대신할 때 위임 및 소유권과 관련된 문제	Google은 여러 이해관계자로부터 고급 IG 위임을 지원해 달라는 요청을 받았으며, SSP가 이 프로세스에 기여하는 부가 가치를 확인했습니다. YouTube는 다양한 당사자가 잠재고객 확장 프로세스에 참여할 수 있는 최적의 솔루션을 찾기 위해 연구를 진행하고 있습니다. 생태계의 추가 의견을 기다리고 있습니다.
클라이언트 측 성능	인프라 비용과 지연 시간을 최적화하기 위해 trustedBiddingSignals의 클라이언트 측 캐싱을 완화하는 방법에 관한 안내를 요청합니다.	현재 여기에서 이 문제를 논의하고 있으며 추가 의견을 환영합니다.

Protected Auction (입찰 서비스)

의견 테마	요약	Chrome 응답
K/V 서비스	브라우저에서 판매자의 KV 서버로의 요청은 어떻게 일괄 처리되나요? 판매자의 경우 브라우저의 요청은 GET 요청과 POST 요청 중 어떤 형태로 표시되나요? 또한 k-익명성 요구사항에 관한 설명이 필요합니다.	v1의 경우 Chrome은 판매자의 KV 서비스에 GET 요청을 전송하여 요청의 쿼리 매개변수에 있는 신호로 trustedScoringSignalsURL를 가져옵니다. 매개변수에는 hostname, renderUrls, adComponentRenderUrls, experimentGroupId가 포함됩니다. 현재 광고 소재 스캔을 위해 추가 정보를 전송하는 확장 프로그램을 실험하고 있지만 아직 출시되지는 않았습니다. maxTrustedScoringSignalsURLLength를 0으로 설정하면 Chrome에서 모든 신호를 단일 요청으로 일괄 처리할 수 있지만 (서버의 URL 길이 제한을 초과할 수 있음) 보장되지는 않습니다. 현재 Chrome은 요청을 서로 10ms 이내에 전송할 준비가 되면 동일한 일괄 처리에 포함하도록 선택하고 있지만, 이를 최적화하는 방법을 조사하고 있습니다. trustedScoringSignals를 사용할 때는 Chrome이 캐싱 헤더를 준수한다는 점을 기억하는 것이 좋습니다. Stale-While-Revalidate 'Cache-Control' 헤더와 같은 헤더는 Chrome이 캐시된 사본을 사용하고 다음 입찰을 위해 캐시를 업데이트하도록 허용하여 평균 지연 시간을 줄일 수 있으며, 이를 통해 중요한 경로에서 신호 가져오기를 효과적으로 삭제할 수 있습니다. 마지막으로, k-익명성과 관련하여 설명서의 특정 섹션이 오래된 것으로 보입니다. 원래 신뢰할 수 있는 신호 URL이 k-익명성이어야 했지만 이 요구사항은 삭제되었습니다. 설명에서 이 문구를 삭제할 예정입니다.
B&A 서비스	최신 버전의 B&A로 업그레이드하는 데 시간이 오래 걸립니다. 빌드 시간이 짧거나 사전 빌드된 이미지가 있으면 유용합니다.	광고 기술은 자체적으로 바이너리를 빌드하고 제공된 해시를 사용하여 검증할 수 있습니다. 향후 사전 빌드된 아티팩트를 제공하거나 빌드 시간을 개선하는 방안을 모색할 예정입니다.
API 기능 요청	로컬 개발 및 테스트를 용이하게 하기 위해 입찰 서비스 (B&A) 빌드 스크립트, 컨테이너 이미지, 호출 도구의 macOS 호환성을 요청합니다.	현재 amd64를 지원하며, 이는 지원되는 클라우드 플랫폼 (GCP 및 AWS)에 배포하기에 충분합니다. 향후 다른 아키텍처에 대한 지원을 조사할 수도 있습니다.
AWS	프로덕션 빌드에 IAM 역할이 생성되어 있어야 하나요?	예. 적절한 권한을 부여하고 코디네이터와 소통하려면 IAM 역할이 필요합니다. 키는 여기에 설명된 대로 기기에서 생성된 ProtectedAudienceInput 암호문을 복호화하는 데 사용됩니다. 또한 동일한 코디네이터로 프로덕션 빌드의 서버/TEE 증명을 통과하려면 이러한 역할이 필요합니다. 자세한 내용은 셀프서비스 가이드를 참고하세요.
B&A 플래그	현재 이러한 정의는 Terraform 코드, cc 파일, proto 파일에 있지만, 광고 기술은 이러한 플래그에 관한 문서를 활용하여 배포를 맞춤설정하는 방법을 이해하는 데 도움이 될 수 있으므로 사용 가능한 B&A 플래그의 정의가 문서에 나열되도록 요청합니다.	Terraform 플래그 설명을 문서화할 가능성을 조사하고 있으며 여기에서 추가 의견을 보내주세요.
AWS bidding service	AWS의 입찰 서비스 및 기본 로깅 동작 및 구성에 관한 안내를 찾고 있습니다.	TEE 내에서 입찰 서비스 (예: 입찰 서비스)를 디버그하려면 광고 기술 동의 디버깅을 사용하는 것이 좋습니다. 이렇게 하면 디버깅에 도움이 되도록 자세한 로깅을 사용 설정하고 클라이언트에서 직접 특정 테스트 요청의 요청/응답 데이터를 캡처할 수 있습니다.
TEE K/V 문서	개발자 사이트에 명시된 대로 TKV 시정 조치 시작에 관한 명확한 설명을 요청합니다.	TEE 사용이 요구되기 전에 충분한 사전 알림을 제공할 예정입니다. 그때까지는 실시간 키/값 신호에 자체 서버를 계속 사용할 수 있습니다.
B&A 테스트 및 분석	B&A 분석 및 테스트는 비용이 많이 들고 프로덕션에 즉시 사용하기에는 적합하지 않은 것 같습니다.	자세히 살펴보려면 비용 분석과 프로덕션 준비 상태 평가로 이어진 요인에 관한 추가 정보가 필요합니다.
신뢰할 수 있는 서버 최적화	구성요소 판매자와 관련된 매개변수를 하나의 inputsPerSeller 매개변수로 병합하고 값에 JSON 문자열을 사용하는 제안서입니다.	이 제안서에 관해 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다.
보안	B&A를 사용하여 TKV의 보안 위험을 완화하는 방법은 무엇인가요?	TKV에 대한 외부 호출을 방지할 수 있습니다. 이 기능은 현재 GCP에서 완전히 지원되고 구성할 수 있습니다. AWS의 경우 이전에 이를 사용 설정했던 AWS App Mesh가 지원 중단되어 추가 지원을 개발해야 합니다. 여기에서 추가 의견을 보내주세요.
B&A 서비스	B&A 최적화를 위한 HTTP 스트리밍의 가치에 관한 내러티브/커뮤니케이션에 대한 명확한 설명을 요청합니다.	개인 정보 보호 샌드박스는 이를 사용하는 광고 기술의 지연 시간을 개선하기 위해 B&A 데이터를 전송할 때 스트리밍 기능을 지원합니다. 혼합 모드의 경우 선택적 성능 최적화입니다.
Prebid	생태계에서 PA API 입찰 기능을 사용 설정하기 위해 오픈소스 Prebid 라이브러리에 기여하는 방법에 관한 업데이트를 요청합니다.	2025년 3월, Chrome은 B&A 공개 로드맵에 설명된 대로 안정화 버전에서 Prebid 우선 최적화를 출시했습니다 (2025년 3월 참고).
트래픽 형성	B&A에서 수신한 문맥 시그널을 기록하는 메커니즘을 요청하여 IG가 활성화되는 시점을 더 잘 이해하고 문맥 응답에서 '입찰 의도' 로직을 개선합니다. 이를 통해 네트워크 리소스를 더 효과적으로 사용하여 '무용 트래픽' (트래픽 셰이핑이라고도 함)을 방지할 수 있습니다.	현재 여기에서 제안서를 논의 중이며 추가 의견을 기다리고 있습니다.
문서 설명	B&A 테스트 통합 설정에서 발견된 'Service/Vsock proxy is not reachable'(서비스/Vsock 프록시에 연결할 수 없음) 오류에 관한 설명이 필요합니다.	이는 최소 메모리 요구사항 때문입니다.이 요구사항을 반영하도록 AWS 구성 설명서가 업데이트되었습니다.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 테마	요약	Chrome 응답
실시간 데이터	실시간 데이터 부족은 업계의 모든 사람에게 영향을 미칩니다. 실시간 데이터 지연은 광고주에게 심각한 문제입니다. 구매자는 잠재고객 도달 증거를 얻을 수 있는 유일한 장소이기 때문에 Google 애널리틱스가 있는 플랫폼으로 이동합니다.	Attribution Reporting API (ARA)의 일부인 실시간 데이터 지연은 광고 기술이 이벤트 수준 보고서를 사용하여 사이트 전반에서 사용자를 추적하는 기능을 줄이기 위한 개인 정보 보호 메커니즘으로 구현됩니다. 그러나 ARA는 이벤트 수준 보고서의 최소 보고 기간을 1시간으로 허용하고 집계 보고서를 지연 없이 광고 기술에 즉시 전송할 수 있는 옵션을 제공하여 기여 분석 보고서를 전송하는 방식을 유연하게 지원합니다.
API 사용량	특히 웹 간 및 웹-앱 기여 분석을 동시에 운영하는 경우 교차 웹 앱 기여 분석 흐름의 올바른 구성에 관한 확인을 요청합니다.	웹에서 웹으로 캠페인과 웹에서 앱으로 캠페인을 동시에 실행할 때 광고 기술은 중복 집계를 방지하기 위해 각 소스 또는 트리거를 등록할 플랫폼을 하나만 선택해야 합니다. 웹 소스와 트리거가 올바르게 위임된 경우 OS는 웹 간 및 웹-앱 기여 분석을 모두 실행할 수 있으므로 가능하면 운영체제 (OS)를 사용하는 것이 좋습니다. 즉, 소스의 경우 Attribution-Reporting-Register-OS-Source 헤더로, 트리거의 경우 Attribution-Reporting-Register-OS-Trigger 헤더로 응답해야 합니다. Attribution-Reporting-Support 헤더는 Chrome 또는 Android 수준의 지원이 있는지 확인하는 데 사용할 수 있습니다. Attribution-Reporting-Info 헤더는 요청에 Attribution-Reporting-Support 헤더가 없는 경우에 유용합니다. 이 경우 브라우저는 사용자 기기에서 플랫폼 지원을 사용할 수 있는지 여부에 따라 플랫폼 등록 여부를 결정합니다.
API 사양	Attribution Reporting API에서 설정하는 Attribution-Reporting-Support HTTP 요청 헤더와 헤더에 플랫폼과 관계없이 웹 키와 os 키가 모두 포함되어야 하는지에 관한 명확한 설명을 구합니다.	서버가 사양을 준수하는 구조화된 헤더 파서를 사용하도록 하기 위해 브라우저에서 Attribution-Reporting-Support 헤더에 'GREASE' 매개변수를 추가할 수 있습니다. 이 헤더의 경우 구조화된 사전 키만 해석해야 합니다. 값과 매개변수는 현재 사용되지 않습니다. 예는 여기를 참고하세요.
3PC 기반 보고	광고 캠페인에서 ARA와 3PC 간의 측정 불일치를 해결하는 방법에 관한 안내를 요청합니다.	ARA는 불일치를 해결하고 디버그하는 데 사용할 수 있는 두 가지 유형의 디버그 보고서를 지원합니다. 기여 분석 성공 디버그 보고서를 사용하면 ARA 결과를 다른 측정 기술의 결과와 쉽게 비교할 수 있으며, 상세 디버그 보고서를 사용하면 기여 분석 등록에서 더 많은 정보를 얻고 잠재적인 문제를 해결할 수 있습니다.
API 사용량	ARA를 테스트하는 과정에서 세부적인 보고가 충분하지 않아 노이즈가 많은 데이터와 유연하지 않은 캠페인 최적화가 발생하고, 소규모 광고주를 제외하는 높은 기준점이 설정되어 있으며, 주요 실적 지표가 일관되지 않아 캠페인을 비교하는 데 어려움이 있다는 문제가 발견되었습니다.	ARA는 광고 기술이 특정 측정 사용 사례를 달성하기 위해 맞춤설정할 수 있는 여러 매개변수를 제공하여 유연성을 제공합니다. 이벤트 수준 보고서는 광고 기술이 보고 기간, 수신할 수 있는 보고서 수, 측정하려는 트리거 데이터를 맞춤설정할 수 있는 유연한 이벤트 수준 보고를 지원합니다. 이를 통해 데이터에 미치는 노이즈의 영향을 변경하고 다양한 사용 사례를 달성할 수 있습니다. 마찬가지로 집계 보고서에는 광고 기술이 구성을 맞춤설정할 수 있는 다양한 방법(예: 추적하는 측정기준 수, 일괄 처리 빈도, 기여도 예산 사용)이 있어 노이즈의 영향을 변경하고 다양한 사용 사례를 달성할 수 있습니다.
API 사양	ARA의 서드 파티 컨트롤러(3PC) 종속 항목에 관한 질문으로, 특히 이러한 3PC가 필요한 테스트 단계에 계속 남아 있는지 여부에 관한 질문입니다.	ARA는 3PC와 관계없이 사용 설정되지만 ARA 전환 디버그 보고에서 ARA 결과를 쿠키 기반 기여 분석 결과와 비교할 수 있도록 하려면 3PC를 사용 설정해야 합니다.
API 사용량	ARA를 사용하여 이전 Android 버전 (11, 12, 13)에서 앱과 웹 간 기여 분석을 위한 소스를 등록하는 방법에 관한 문의	ARA는 현재 Android S 이상 (12 이상)에서 지원됩니다.
API 사용량	ARA 선택 비율 및 배포 세부정보를 요청합니다.	이전 분기와 동일한 답변을 제공합니다. "이 정보를 생태계와 공유할 계획은 없습니다. 개발자는 현재 코드가 배포된 위치에서 API를 호출하여 개인 정보 보호 샌드박스 API의 가용성을 추정할 수 있습니다."
API 사용 가능 여부	ARA가 사용 설정된 경우 3PC는 사용 설정되나요?	사용자의 브라우저에서 ARA가 사용 설정되어 있어도 사용자의 쿠키 설정에는 영향을 미치지 않습니다. ARA가 사용 설정되어 있고 사용자가 쿠키를 사용 설정 또는 중지할 수 있습니다.
보고	'Attribution-reporting-support' 헤더에서 받을 수 있는 사전 정의된 값 목록이 있나요?	안내에 설명된 대로 값은 구조화된 헤더 사전이며 현재 정의된 유일한 시맨틱은 OS 및 웹 키의 존재 여부입니다. 헤더의 다른 모든 부분은 무시해야 합니다. 즉, 파싱하려면 간단한 문자열 일치가 아닌 구조화된 헤더 파서를 사용해야 합니다.

Aggregation Service

의견 테마	요약	Chrome 응답
기능 요청	집계 서비스의 기능 요청: 서버 간 통합, 교차 기기 측정, 멀티 터치 기여 분석 및 기여도 보고 간소화, 옴니채널 기여 분석, 고급 ML 최적화 루프 지원 (예: 비공개 모델 학습)을 사용합니다.	Google에서는 이러한 요청을 검토 중이며, 가능한 경우 추가 세부정보를 공유해 드리겠습니다. 이러한 요청이 우선순위가 높은지 여부에 관한 생태계의 추가 의견을 기다립니다.
기능 요청	집계 서비스 세트를 업데이트할 때 재설정 관련 우려사항을 완화하기 위해 terraform 환경에서 EBS delete_on_termination 매개변수를 True로 설정하도록 요청합니다.	이 요청을 검토 중이며 추가 세부정보가 있으면 공유해 드리겠습니다. 이 요청이 우선순위가 높은지 여부에 관한 생태계의 추가 의견은 여기에서 보내주세요.
문서 설명	변경할 수 있는 항목 (예: 모니터링 기준점)과 변경하지 말아야 할 항목에 관한 안내를 요청합니다.	집계 서비스에 사용할 수 있는 맞춤설정에 관한 추가 문서 및 안내를 게시하는 방안을 검토하고 있습니다.
배포	bazel 명령어에서 새 배포가 실패하는 것과 관련하여 설명을 요청합니다.	환경에서 사용되는 bazel 버전으로 인해 배포가 실패할 수 있습니다. Terraform 실패의 디버깅을 다루고 필요한 bazel 버전을 표시하도록 문서가 조정됩니다.

Private Aggregation API

의견 테마	요약	Chrome 응답
API 사용량	보고된 공유 저장소 제한으로 인한 잠재적인 데이터 손실, 복잡한 집계 서비스 허용 목록 (와일드 카드 권장)이 필요한 높은 카디널리티 관련 문제, 집계 서비스의 '중복 없음' 규칙으로 인한 느린 테스트와 같은 구현 관련 문제에 대한 안내를 요청합니다.	공유 저장소 제한사항과 관련하여 20개의 참여 제한 (여기에서 자세히 설명)은 월별이 아닌 실행당 적용됩니다. 또한 API 호출자가 이 제한을 재정의할 수 있습니다. 이 한도는 보고 유틸리티를 제한하기 위한 것이 아니라 집계 서비스에서 보고서를 처리하는 데 드는 비용을 관리하기 위한 것입니다. 와일드 카드 쿼리와 관련하여 이 요청을 평가 중이며, 가능한 경우 추가 세부정보를 공유해 드리겠습니다. '중복 없음' 규칙과 관련하여 테스트를 사용 설정하기 위해 이 규칙을 우회하기 위한 디버그 모드를 일시적으로 지원합니다. 자세한 내용은 여기 를 참고하세요.
ID 및 버킷 필터링	두 개의 별도의 집계 실행에서 집계 서비스에 두 개의 서로 다른 필터링 ID가 있는 동일한 버킷을 요청할 수 있나요? 즉, 필터링 ID가 도메인의 보조 파티셔닝 역할을 할 수 있나요?	예, 이 기능은 지원됩니다. 집계를 실행할 때는 필터링 ID가 작업 매개변수의 목록과 일치하는 기여도만 처리되고 나머지는 별도의 실행에서 처리할 수 있습니다.
멀티 터치 기여 분석	멀티 터치 기여 분석 (MTA) 구현에 관한 설명 요청: 1) 집계 값이 2^16을 초과하지 않는 경우 기여도 수에 제한이 있나요? 2) 특정 컨텍스트에 저장할 수 있는 고유한 집계 키 (버킷) 수에 제한이 있나요? 3) MTA에서와 같이 각 사용자 에이전트 (브라우저)에 고유한 집계 키가 있는 경우 집계 서비스는 요약 보고서를 어떻게 처리하나요?	1) 기본 기여도 한도가 설정되어 있지만 여기에 설명된 대로 API 호출자가 이를 재정의할 수 있는 옵션이 있습니다. 한도의 목적은 API 호출자가 집계 서비스에서 보고서 처리 비용을 관리하는 데 도움을 주는 것입니다. 2) 이러한 제한은 없습니다. 단, 광고 기술은 여기에 설명된 대로 신호 대 노이즈 비율을 개선하기 위해 집계 키의 세부사항을 고려해야 합니다. 3) 이 안내, 특히 위의 2항에 설명된 신호 대 노이즈 안내를 참고하세요.

은밀한 추적 제한

사용자 에이전트 축소/사용자 에이전트 클라이언트 힌트

의견 테마	요약	Chrome 응답
기능 요청	서버가 콘텐츠 적응, 보안, 분석을 위한 자동화된 트래픽을 식별할 수 있도록 User-Agent 클라이언트 힌트 (UA-CH)에 Sec-CH-UA-Robot을 추가하도록 요청합니다.	이는 다른 표준 그룹에서 논의 중인 중요한 사용 사례입니다 (자세한 내용은 여기 참고). 관심 있는 당사자는 의견을 제공하여 참여하는 것이 좋습니다. 하지만 HTTP 요청 헤더가 자동화된 트래픽으로 쉽게 조작될 수 있으므로 UA-CH가 적절한 솔루션이 아닐 수 있습니다.

IP 보호 (이전 명칭: Gnatcatcher)

의견 테마	요약	Chrome 응답
IP 주소 개인 정보 보호	Google에서 사용할 수 있는 IP 주소를 그대로 두는 것은 명시된 개인 정보 보호 목표에 위배됩니다. Google은 IP 보호를 통해 데이터를 익명처리한다고 말하지만, IP 보호를 사용하려면 사용자가 Chrome에 로그인해야 하므로 Google은 여전히 사용자의 신원을 파악할 수 있습니다.	로그인 이유는 주로 프로كسي 액세스 속도 제한을 통한 사기 및 악용 방지입니다. 또한 인증 요구사항의 맥락에서 사용자의 개인 정보를 보호하기 위해 Google의 토큰 설계는 맹인 서명됩니다. 즉, 로그인 중에 발급된 토큰은 프록시 중에 사용되는 토큰과 다르므로 나중에 발급된 토큰을 사용자의 Google ID에 연결할 수 없습니다. 즉, 사기 방지를 위한 인증 요구사항에도 불구하고 시크릿 모드에서 사용자의 트래픽이 프록시되면 Google은 해당 사용자가 누구인지 알 수 없습니다.
IP 주소 개인 정보 보호	IP를 사용하는 것은 잘못된 방향으로 나아가는 것입니다. 쿠키와 달리 브라우저에서 삭제할 수 없으며 사용자는 쿠키와 동일한 투명성 제어 기능을 사용할 수 없습니다. 쿠키가 사라지면 업계는 개인 정보 보호보다 자기 보존을 우선시하여 IP를 대체 솔루션으로 사용하게 될 것입니다.	Chrome은 플랫폼으로서 사용자에게 웹에서의 브라우징 환경을 개선하는 기능을 제공하는 것을 목표로 합니다. 시크릿 모드에서 탐색하는 Chrome 사용자의 경우 서드 파티 컨텍스트에서 IP 주소 정보의 사용 가능 여부를 제한하여 교차 사이트 추적에 대한 향상된 보호 기능을 제공합니다.
마스킹된 도메인 목록	마스킹된 도메인 목록 (MDL)의 선택 기준은 무엇인가요?	Chrome에서는 MDL에 있어야 하며 따라서 서드 파티 컨텍스트에서 마스킹된 IP 주소를 수신해야 하는 도메인을 식별하기 위한 기준을 개발했습니다. Google은 다른 웹브라우저와도 협력하는 유명한 인터넷 개인 정보 보호 선도 기업인 Disconnect.me와 파트너십을 맺었습니다. Chrome은 Disconnect.me를 활용하여 Chrome의 기존 기준에 부합하는 도메인을 식별합니다. 또한 Chrome은 안정적이고 엔트로피가 높은 웹 API에서 일관된 출력을 제공하므로 엔트로피가 높은 확률적 식별자를 생성하는 데 사용할 수 있는 널리 사용되는 JavaScript 함수를 식별하는 방법을 개발했습니다. 그런 다음 이러한 함수가 서드 파티 컨텍스트의 웹사이트에 로드될 때 감지되어 이러한 특성을 가진 스크립트를 제공하는 도메인 목록이 생성되며, 이 목록은 MDL의 일부가 되어 프록시됩니다. 이러한 API 오용 패턴을 찾는 감지 파이프라인은 Google 자체 도메인을 포함한 모든 도메인을 고려합니다.
사기 방지	제안된 24시간 공개 지연 및 공개 비율이 실시간 사기 감지를 방해한다는 확률적 공개 토큰 (PRT)에 대한 의견 지연 시간을 단축 (1시간 지연)하고 요금을 인상 (최소 두 자릿수)해 달라고 요청합니다. 추가 제안사항에는 위험 신호 (VPN, 자동화된 브라우저)에 따라 차등 요금을 사용 설정하고 특정 토큰을 타겟팅하여 공개하는 것이 포함됩니다.	Google에서 인터뷰한 대부분의 개발자는 고객에게 시간별 보고서를 제공하고 하루에 여러 번 IP 차단 목록을 업데이트합니다. 지연 시간을 줄이면 더 자주 업데이트할 수 있으며 1시간 미만이면 시간별 통계에서 IVT 측정을 다시 사용 설정할 수 있지만 사용자를 다시 식별할 가능성이 높아질 수 있습니다. YouTube는 생태계 연구 및 이해관계자의 의견을 바탕으로 지연 기간을 줄이고 공개 비율을 변경하는 방안을 모색하고 있으며 여기에서 추가 의견을 기다리고 있습니다.
마스킹된 도메인 목록	광고 사용 사례가 없음에도 불구하고 MDL에 도메인이 포함된 것과 관련된 질문 이로 인해 'IP 브리징'이 IP 주소를 기반으로 프로필을 만들 수 있다는 우려가 제기되었습니다.	YouTube는 목록 기반 접근 방식에 이의신청 절차를 구현하는 것이 중요하다는 점을 잘 알고 있습니다. 이의신청을 통해 회사는 MDL의 도메인이 포함 기준을 충족하지 않으며 삭제되어야 한다고 주장할 수 있습니다. 이를 통해 해당 도메인은 시크릿 모드에서 서드 파티 컨텍스트에서 사용자의 원래 IP 주소를 계속 수신할 수 있습니다. 이제 Chrome 안정화 버전의 시크릿 모드에서 IP 보호가 출시되기 전에 도메인 소유자가 이의신청을 제출하고 결정을 받을 수 있는 충분한 시간을 제공하기 위해 이의신청 절차가 시작되었습니다. 이의신청 절차에 관한 자세한 내용은 여기를 참고하세요.
마스킹된 도메인 목록	게시자가 파트너가 MDL에 포함된 것의 의미를 조사하고 있다는 의견 IP 보호 설명서의 GeoIP 조항을 통해 안심했습니다.	Chrome은 지역 기반 사용 사례를 지원하는 것이 중요하다는 점을 인식하고 있습니다. 프록시는 국가를 포함하여 사용자의 대략적인 위치를 나타내는 IP 주소를 할당합니다. 자세한 내용은 IP 위치정보 설명을 참고하세요.
마스킹된 도메인 목록	국가 수준 타겟팅을 계속 사용할 수 있는지 여부와 관련된 MDL에 관한 질문	Chrome은 지역 기반 사용 사례를 지원하는 것이 중요하다는 점을 인식하고 있습니다. 프록시는 국가를 포함하여 사용자의 대략적인 위치를 나타내는 IP 주소를 할당합니다. 자세한 내용은 IP 위치정보 설명을 참고하세요.
사기 행위 감지	IP 보호가 사기 감지 시스템에 미치는 영향에 대한 우려 사용자에게 프록시 IP 또는 헤더가 표시되나요? SSP와 DSP에서 특정 용도에 대해 동일한 프록시 IP 주소를 보게 되나요? 불일치로 인해 사기 감지 및 OpenRTB에 영향을 줄 수 있습니다.	IP 보호가 사용 설정된 시크릿 모드에서 탐색하고 MDL의 도메인을 요청하는 사용자는 정의된 지역 피드를 기반으로 프록시 IP 주소를 받게 됩니다. 조직은 프록시된 트래픽에서 PRT가 추가 헤더로 전달되도록 요청할 수 있습니다. 이 경우 지연 기간 후 소수의 원래 IP 샘플이 공개될 수 있습니다. 많은 SSP가 서버 측 입찰 요청에서 프록시된 IP 주소를 수요 파트너에게 전달할 것으로 예상되지만 낙찰된 DSP가 노출 시 동일한 프록시 IP 주소를 볼 수 있는 것은 아닙니다.
사기 행위 감지	IP 위치 파일의 업데이트 빈도, 허위 행위 및 PRT 신고에 관한 세부정보의 업데이트 시점, 광고 기술에서 허위 활동을 감지하는 방법에 관한 질문	PRT 설명서는 목록과 마찬가지로 게시되어 있으며, 프록시 IP 주소와 매핑된 지역은 목록에 나와 있습니다. IP 주소는 시간이 지남에 따라 순환되므로 이 파일을 정기적으로 업데이트 및 변경사항을 확인하는 것이 좋습니다. 악용을 신고할 수 있는 공개 이메일 주소는 출시가 가까워지면 공지될 예정입니다.
위치정보	프록시에 사용되는 공개 IP 주소 목록 요청	IP 보호를 위해 IP 주소를 대략적인 위치에 매핑하는 파일은 여기에서 확인할 수 있습니다. 이 파일은 정기적으로 업데이트됩니다.
API 사용량	IP 보호가 기본적으로 사용 설정되어 있으며 사용자에게 선택 해제 옵션이 제공되지 않는다는 어설션	IP 보호는 Android 및 데스크톱 플랫폼의 Chrome 시크릿 모드에서 사용할 수 있습니다. 사용자는 IP 보호를 사용 중지할 수 있습니다. 기업 관리 Chrome 버전의 경우 IP 보호를 사용 설정할 수 있지만 기본적으로 사용 중지되어 있습니다.
API 사용량	Chrome Canary 및 베타 출시에서 IP 보호를 사용 설정하고 테스트하는 실험 플래그의 사용 가능 여부에 관한 문의입니다.	현재 전체 IP 보호 기능을 테스트할 수 있는 실험 플래그는 없습니다. Google 도메인으로 전송되는 프록시 트래픽만 실험에 사용됩니다.
IP 주소 개인 정보 보호	브라우저가 시크릿 모드로 전환되면 3PC 메시지 설정은 어떻게 작동하나요?	시크릿 모드에서는 기본적으로 3PC가 차단됩니다.
시크릿 모드	사용자가 Chrome에 로그인하지 않은 경우 시크릿 모드에서 IP 보호 기능이 작동하는지 명확히 설명해 주세요.	사용자가 시크릿 모드를 실행하기 전에 Chrome에 로그인하지 않은 경우 IP 보호가 활성화되지 않습니다. 이는 사기 및 악용 방지 목적으로 프록시에 대한 액세스 속도 제한을 적용하기 때문입니다. IP 보호는 클라이언트 인증을 사용하여 악의적인 행위자가 프록시를 활용하여 MDL의 서비스에 대한 공격을 증폭하는 기능을 제한합니다. 따라서 새 시크릿 창을 열기 전에 Chrome 브라우저에서 로그인한 Google 계정으로 인증된 사용자만 IP 보호 기능을 사용할 수 있습니다.
시크릿 모드	출시 전에 IP 보호의 영향을 평가하기 위한 요청: (1) 브라우저 상태 플래그 또는 집계 API 보고를 사용하여 시크릿 모드 사용량을 수치화하기 위한 제안 (2) 기능을 사용 설정하기 전에 일정 기간 동안 IP 보호 헤더 전송 (3) 추론을 위해 알려진 소수의 트래픽에 기능을 제공	Google은 IP 보호의 규모와 영향을 이해하고 측정할 수 있는 생태계의 관심을 잘 알고 있습니다. 하지만 Chrome은 사용자가 시크릿 모드로 비공개로 탐색하도록 선택할 수 있도록 노력하고 있습니다. Chrome은 시크릿 모드를 탐색하는 사용자를 감지하는 메서드를 노출하지 않으며 사용자의 탐색 모드를 드러낼 수 있는 다른 신호를 제한하기 위한 조치를 취했습니다. Google은 시크릿 모드에서 탐색하는 사용자의 개인 정보 보호에 영향을 미치지 않으면서 이 테스트를 용이하게 할 방법을 모색하고 있으며 생태계의 추가 의견을 환영합니다.

이탈 추적 감소

의견 테마	요약	Chrome 응답
규정 준수	Google이 데이터 보호법을 준수하는 이탈 추적 완화 (BTM) 기법의 사용을 승인하지 않는 것은 법적 근거가 없으며 개인 정보 보호 샌드박스 이의신청 절차를 무의미하게 만듭니다.	이전 의견 보고서에서 설명드린 바와 같이 규정 준수 상태는 BTM 적용과 관련이 없으며 Google은 BTM 구현 시 규정 준수와 관련하여 어떠한 결정도 내리지 않습니다. BTM은 다른 Chrome 개인 정보 보호 기능과 마찬가지로 데이터 공유 여부와 방식에 대한 사용자의 관리 기능을 강화하는 데 중점을 둡니다. CMA의 2분기/3분기 보고서에 언급된 서드 파티 관리 이의신청 절차는 Google에서 개별 회사의 목록 포함 또는 제외 여부를 결정하는 영역에만 적용됩니다.
규정 준수	GDPR 맥락에서 브라우저가 법적 동의가 이루어진 작업을 준수하도록 하는 방법에 관한 논의로, 브라우저가 사용자가 명시적으로 동의한 작업 (예: 리디렉션 또는 쿠키 설정)을 억제하여 법적 동의와 브라우저 개인 정보 보호 설정 간에 충돌이 발생하는 시나리오를 강조 표시합니다.	브라우저는 사용자와 웹사이트 간의 관계의 성격을 파악할 수 없습니다. 또한 현재 BTM 동작을 통해 사용자가 특정 사이트에서 이탈 추적에 명시적으로 동의할 수 있는 해결 방법이 이미 있습니다. 규정 준수에 관한 자세한 내용은 개인 정보 보호 관련 규정 준수 FAQ를 참고하세요.
이중 용도 사이트	WebView 또는 앱에서 웹으로의 전환이 BTM에 따라 '이중 사용 사이트'로 간주되는지에 관한 설명을 구합니다.	브라우저는 WebView 또는 앱에서의 전환을 통해 이탈 체인이 시작되었는지 여부를 알 수 없습니다. 따라서 BTM은 이러한 흐름을 특별히 처리하지 않습니다. 대신 흐름을 'about:blank'에서 시작된 교차 사이트 이탈로 해석하고 표준 동작을 진행합니다.

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

관련 웹사이트 세트 (이전의 퍼스트 파티 세트)

의견 테마	요약	Chrome 응답
API 사용량	IP 보호와 함께 RWS를 악용할 가능성에 대한 우려 RWS 세트 내의 조직에 IP 주소를 노출하면 조직이 시크릿 사용자 추적을 위한 휴대용 IP 주소 데이터에 액세스하기 위해 여러 RWS 세트에 가입하도록 유도할 수 있습니다.	자동 검사를 통해 적용되는 연결된 사이트, 서비스 사이트, 세트 전체에 대한 세트 요구사항은 여러 세트를 결합하려는 잠재적 인센티브를 완화합니다. IP 주소를 통해 세트 간에 사용자 활동을 결합하려면 세트에 MDL 도메인을 포함해야 하므로 세트 소유자와 도메인 소유자 간에 조정이 필요합니다. 이 같은 위험은 MDL 도메인과 협력하는 단일 사이트 (RWS가 관여하지 않음)에도 적용됩니다. 이 질문에 대한 자세한 내용은 여기에서 확인하실 수 있습니다.

Fenced Frames API

의견 테마	요약	Chrome 응답
네이티브 광고	현재 설계된 펜스 프레임이 광고가 주변 콘텐츠에 유연하게 적응해야 하는 네이티브 광고 비즈니스 모델과 호환되지 않는다는 의견이 있습니다.	YouTube는 생태계 요구사항과 현재의 펜스 프레임 서비스를 계속 평가하고 있습니다. 어쨌든 앞서 언급한 대로 2026년 이전에는 펜싱된 프레임이 필요합니다.

Shared Storage API

의견 테마	요약	Chrome 응답
API 버그	예상되는 동작이지만 Shared Storage API의 예산 책정 메커니즘으로 인해 selectURL 작업이 실행되지 않을 때 Chrome에 오류가 로깅된다고 신고합니다. 호출자가 조치를 취할 수 없는 오류이므로 Chrome에서 로깅 수준을 오류에서 경고 또는 정보로 다운그레이드하도록 요청합니다.	이 변경사항은 2025년 3월 4일부터 제공되는 Chrome M134에 구현되어 포함되었습니다.

CHIPS

의견 테마	요약	Chrome 응답
API 문서	SameSite=Lax/Strict 쿠키와 비교하여 파티션된 쿠키가 제공하는 보안 보호 기능에 관한 설명이 필요합니다. 파티션된 쿠키가 SameSite=Lax/Strict 쿠키와 동일한 수준의 XSS 및 CSRF 공격 방지를 제공하지 않는다는 점을 문서에 명시해야 한다는 제안	파티션된 쿠키에서 제공하는 시맨틱과 보호 기능을 명확히 하기 위해 설명서와 사양을 업데이트할 예정입니다.

FedCM

의견 테마	요약	Chrome 응답
UI 및 보안	FedCM UI가 Google의 이전 원탭 로그인과 너무 유사하다는 의견, 수동 프레젠테이션 추적 기능이 없어 FedCM 실적을 수치화하기 어렵다는 의견, PKCE와 관련하여 문서 언어를 강화해야 한다는 의견이 있었습니다.	Google은 이해관계자의 의견을 해결하기 위해 적극적으로 노력하고 있습니다. 현재 논의 중인 영역에는 ID 공급업체가 FedCM 실적을 추적할 수 있도록 더 나은 측정항목을 제공하는 방법과 구독 사용 사례와 관련하여 FedCM의 새로운 사용 사례를 해결하기 위한 가능한 개선사항이 포함됩니다.
API 사용량	사용자가 페이지를 새로고침하고 navigator.credentials.get을 호출하여 로그인하면 사용자가 클릭해야 계속할 수 있는 팝업 창이 표시되어 사용자 환경에 지연이 발생합니다. 신뢰 당사자 (RP)가 navigator.credentials.get에서 반환된 토큰을 캐시하여 사용자 환경을 개선할 수 있나요?	RP는 자체 쿠키를 사용하여 토큰을 저장할 수 있습니다. 그러면 RP는 자체 쿠키를 확인하여 navigator.credentials.get을 호출하기 전에 사용자가 로그인되어 있는지 확인할 수 있습니다. 이 문제에 대한 자세한 내용은 여기를 참고하세요.
다중 ID 공급자 선택	브라우저는 FedCM에서 여러 ID 공급업체 (IdP)의 로그인 옵션을 어떻게 표시하나요?	개발자 문서에서 여러 IdP가 표시되는 방식에 관한 정보를 확인할 수 있습니다. 이해관계자는 chrome://flags에서 fedcm-multi-idp 플래그를 사용 설정하여 이 기능을 실험할 수 있습니다.
브라우저 및 IdP	Chrome과 같은 브라우저가 자체적으로 IdP 역할을 할 수 있나요? 브라우저는 저장된 계정 및 프로필 데이터를 신뢰할 수 있는 인증 소스로 사용할 수 있습니다.	브라우저는 확장 프로그램을 통해 수정할 수 있으므로 브라우저에서 직접 이메일 인증을 주장하는 경우 추가 서버 기반 인증 없이는 신뢰할 수 없습니다. 따라서 순수 클라이언트 기반 솔루션은 권장하지 않습니다. 이 문제에 대한 자세한 내용은 여기를 참고하세요.
API 사양	IdentityCredential.disconnect() 알고리즘의 매개변수가 필수인지 선택사항인지에 관한 논의입니다.	이제 이 문제가 해결되었습니다. 자세한 내용은 여기에서 확인하실 수 있습니다.
API 보안	RP에 XSS 취약성이 있는 경우 FedCM 로그인 프로세스에서 토큰 유출에 대한 우려 공격자가 악성 코드에서 navigator.credentials.get을 실행하여 토큰을 획득할 수 있습니다.	FedCM은 새로운 XSS 위험을 만들지 않습니다. 이러한 위험은 웹 애플리케이션과 기존 인증 프로토콜에 내재되어 있습니다. 이러한 위험을 완화하려면 RP는 ID 토큰의 aud 클레임을 확인하고 자체 출처에서 발급된 어설션만 수락해야 합니다. 여기에 설명된 대로 현재 이러한 토큰 교환을 보호하기 위한 권장사항이 마련되어 있으며 FedCM과 함께 사용할 수 있습니다. 또한 Storage Access API는 FedCM과 함께 사용할 수 있으며, 이전 FedCM 호출이 있으면 Storage Access API 호출이 자동으로 부여됩니다. 이렇게 하면 GitHub 문제에서 설명한 삽입된 리디렉션 흐름이 사용 설정됩니다.
API 사양	client_metadata_endpoint는 FedCM의 구성 엔드포인트 응답에서 필수 입력란입니다. 빈 객체는 유효한 응답이며 Chromium은 404 응답을 자동으로 무시하므로 엔드포인트가 실제로는 선택사항으로 취급된다고 가정할 수 있습니다.	이를 반영하고 client_metadata_endpoint를 선택사항 필드로 만들기 위해 사양을 변경할 수 있다는 데 동의합니다.
API 사용량	DOM을 통해 액세스할 수 없는 브라우저 제어 사용자 인터페이스로 인해 FedCM 구현을 테스트하기가 어렵다는 우려가 제기되었습니다.	Google에서는 이러한 문제를 해결할 수 있는 회귀 테스트용 브라우저 자동화 API를 지원합니다. 이러한 API는 여기에 설명되어 있습니다.
API 사양	구성 엔드포인트 응답의 필수 부분인 login_url 매개변수가 사양의 3.2 섹션에 설명되어 있지 않습니다.	섹션 3.2에 login_url 매개변수를 포함하도록 문서에 업데이트를 제출했습니다.
API 사양	FedCM의 잠재적 추적 벡터에 대한 우려 IdP는 구성 엔드포인트 응답 (accounts_endpoint, client_metadata_endpoint)에 지정된 엔드포인트에 ID를 경로 매개변수로 삽입하고 이러한 ID를 사용하여 계정 및 클라이언트 메타데이터 요청을 연결할 수 있습니다.	IdP가 이러한 엔드포인트에 ID를 삽입한다는 증거는 없지만 여기에서 이 문제를 해결하기 위한 완화 조치를 적극적으로 고려하고 있습니다.

스팸 및 사기 퇴치

Private State Tokens API (및 기타 API)

이번 분기에 받은 의견이 없습니다.