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

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

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

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, Protected Audience, 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 응답
생태계 준비 상태	SSP는 게시자가 준비되지 않았거나 필요한 배포 작업을 하지 않는 것에 대한 우려를 제기했습니다.	개인 정보 보호 샌드박스는 게시자 교육에 중점을 두고 있으며, 여기에는 게시자와 SSP가 모두 참석하여 배포 작업을 추진하는 전용 웹 세미나와 회의가 포함됩니다.
서드 파티 쿠키 지원 중단	업계의 기술 블랙아웃으로 인해 2023년 4분기에 서드 파티 쿠키 지원 중단 (3PCD)에 대한 우려가 커졌습니다.	개인 정보 보호 샌드박스의 타임라인은 CMA와 논의되었으며, 2024년 하반기에 준비가 완료될 예정입니다. 개인 정보 보호 샌드박스에서는 3PCD 확대의 시퀀싱에 관한 자세한 정보를 게시할 예정입니다. 서약에 따라 3PCD는 CMA의 경쟁 관련 우려사항이 해결되어야 합니다.
Google Ad Manager	Google Ad Manager는 API 노출 영역을 노출하지 않으므로 테스트가 어렵습니다.	Google Ad Manager의 응답: Google Ad Manager의 이 응답에 설명된 이유로, Google Ad Manager의 Protected Audience API 통합 계획에는 최상위 입찰을 제어하지 않고 Google의 게시자 광고 서버를 지원하는 것이 포함되지 않습니다.
Google Ad Manager	Google Ad Manager에는 AdX 또는 공개 입찰 SSP에만 노출되는 비공개 가격 하한선이 있습니다.	Google Ad Manager의 공개 문서에 따르면 문맥 입찰의 낙찰자는 AdX 또는 공개 입찰을 비롯한 구성요소 입찰이 아닌 최상위 점수 로직에 전달됩니다. 또한 이 문서에서는 최상위 점수 산정 로직에 대해 다음과 같이 설명합니다. "Ad Manager는 구매자의 관심분야 그룹 입찰을 위한 Ad Manager 자체 구성요소 입찰을 비롯한 각 구성요소 입찰의 낙찰가를 비교하고, 동적 할당을 통해 선택된 최적의 문맥 광고를 비교한 후 가장 높은 입찰가를 가진 광고를 게재합니다."
Google Ad Manager	Google Ads 제품은 서드 파티 광고 제품과 동일한 규칙을 적용해야 합니다.	Google Ads 제품은 이미 서드 파티와 동일한 규칙을 적용받습니다.
Chrome을 통한 테스트	A 또는 B에 없는 브라우저의 라벨을 추가합니다.	실험이 아닌 라벨을 추가하면 시크릿 모드의 트래픽과 관련된 개인 정보 보호 문제가 복잡해질 수 있다는 조사 결과가 나왔기 때문에 현재로서는 그렇게 할 계획이 없습니다.
광고 대행사	웹사이트에 JavaScript가 없는 대행사나 회사에서 개인 정보 보호 샌드박스 API를 사용할 수 있나요?	누구나 개인 정보 보호 샌드박스 API를 호출할 수 있습니다. 기관이나 다른 사용자가 API에 직접 기술을 빌드하려는 경우 그렇게 할 수 있습니다. 클라이언트 측 API는 쿠키와 마찬가지로 클라이언트와 통합되어야 합니다. 쿠키와 마찬가지로 많은 API에는 HTTP 헤더 인터페이스도 있습니다. 이미 한 광고 업계 프레임워크인 Prebid에서 API와 클라이언트 측 통합을 빌드한 사례가 있습니다. 다른 조직도 동일한 조치를 취할 수 있습니다.
클라이언트 측 솔루션	2012년에 엔지니어가 이러한 솔루션의 확장성에 관해 우려를 표명한 적이 있는데도 Google이 개인 정보 보호 샌드박스에 클라이언트 측 솔루션을 채택하는 이유는 무엇인가요?	연구 분야로서 개인 정보 보호 강화 기술 (PET)은 2012년 이후 크게 발전했으며, 그와 함께 상업적으로 실행 가능한 애플리케이션도 발전했습니다. 개인 정보 보호 샌드박스의 핵심은 10년 전에는 실행할 수 없었던 PET 조합입니다. 또한 브라우저에 대한 소비자의 기대치와 개인 정보 보호에 대한 규제 기대치가 높아짐에 따라 개인 컴퓨팅 성능이 향상되었습니다.
머신러닝	Google은 머신러닝 목적으로 개인 정보 보호 샌드박스를 어떻게 사용할 계획인가요?	오늘날 광고 기술 생태계의 상당 부분에서 머신러닝을 사용하고 있으며 이는 앞으로도 변하지 않을 것으로 예상됩니다. 개인 정보 보호 샌드박스는 애드테크 회사 또는 다른 사용자가 머신러닝을 계속 사용하는 것을 막지 않습니다. 또한 개인 정보 보호 샌드박스 API와 통합하는 회사가 머신러닝을 사용해야 하는 것도 아닙니다. 기업은 머신러닝을 포함하든 안 하든 고객의 요구사항을 충족하는 방식으로 제품과 서비스를 계속해서 구축할 것으로 예상됩니다. 개인 정보 보호 샌드박스 통합업체가 빌드하는 모든 머신러닝은 분명히 통합업체에 알려지므로 숨겨지지 않습니다.
데이터 확인	기업은 개인 정보 보호 샌드박스를 사용하여 수신하는 데이터가 정확하고 Google이 미디어 등급 위원회 (MRC)와 같은 기관을 통해 검토를 받을 의향이 있는지 어떻게 확인할 수 있나요?	개인 정보 보호 샌드박스 API는 Chrome을 지원하는 오픈소스 플랫폼 내에 빌드됩니다. 신뢰할 수 있는 실행 환경에서 실행되도록 설계된 API의 일부도 오픈소스이며 감사 대상입니다. MRC를 포함하여 코드를 검사하려는 모든 사용자가 코드를 검사할 수 있습니다.
(이전 분기에도 보고됨) 프로덕션 지원	Chrome에서 생태계에 영향을 미치는 개인 정보 보호 샌드박스 기술적 문제 및 에스컬레이션을 지원하기 위해 마련된 절차는 무엇인가요?	Google은 광고 기술이 기술적 문제를 신고하고 이러한 문제를 해결하기 위해 필요한 에스컬레이션을 할 수 있는 다양한 채널을 제공합니다. 또한 Chrome은 생태계의 상태에 영향을 미치는 기술적 문제와 에스컬레이션을 해결하기 위한 프로세스를 더욱 구축하고 확장할 예정입니다. Chrome은 이 작업을 위한 리소스를 확보하기 위해 최선을 다하고 있습니다. 의견 및 에스컬레이션을 위한 공개 및 비공개 포럼을 참고하세요.
Chrome을 통한 테스트 모드	Chrome을 통한 테스트 모드의 타임라인 및 정확한 구현에 관한 자세한 내용	테스트 모드에 관한 블로그 게시물을 공유했으며 곧 더 많은 정보를 공유할 예정입니다. 테스트 모드 라벨 크기에 관한 제안사항을 기다리고 있습니다.
다른 업계 표준과의 통합	개인 정보 보호 샌드박스 API는 TCF v2.* 및 동의 모드 중 하나 또는 둘 다에 연결되나요?	Google은 개인 정보 보호 샌드박스 API를 TCF v2 또는 동의 모드와 직접 통합할 계획이 없습니다. 하지만 기업과 업계 협회는 개인 정보 보호 샌드박스 API와 함께 작동하도록 제품과 프레임워크를 조정할 수 있습니다. 예를 들어 TCF와 같은 프레임워크를 사용하는 경우 각 참여자는 수신하는 TCF 신호와 연결된 TCF 정책을 기반으로 자체 규정 준수 접근 방식을 결정해야 합니다. Google은 기업이 개인 정보 보호 샌드박스 구성요소에서 제공하는 다양한 기능을 언제, 어떻게 사용할지 결정할 것으로 기대합니다.

등록 및 증명

의견 주제	요약	Chrome 응답
제한사항	등록 프로세스는 Google이 생태계에서 개인 정보 보호 샌드박스 API를 사용할 수 있는 회사를 결정할 수 있음을 의미합니다.	등록 및 증명 프로세스에는 본질적으로 항목의 확인 (예: 항목에 DUNS 번호가 있거나 개인정보처리방침 링크를 제공할 수 있음 등)이 포함되며, API 호출을 위해 공개 증명이 요구됩니다. 등록 요구사항을 충족할 수 있는 법인은 검증을 받습니다. DUNS 번호가 없는 회사의 경우 Dun & Bradstreet에서 무료로 번호를 받을 수 있는 신속한 절차를 제공하고 있습니다. 목표는 앞서 언급한 조치를 통해 API의 개인 정보 보호를 강화하고 개인 정보 보호 샌드박스 API에 투명성 레이어를 추가하여 이해관계자가 어떤 API를 사용하고 어떤 증명을 하고 있는지 더 잘 이해할 수 있도록 하는 것입니다. 이 문제에 관한 업계의 추가 의견을 기다리고 있으며, 이미 이 의견을 바탕으로 절차를 수립했습니다.
재등록 오버헤드	증명 파일은 12개월마다 만료되며 웹사이트를 다시 등록해야 합니다.	YouTube는 생태계의 의견을 수렴하여 접근 방식을 수정했습니다. 즉, 12개월 또는 특정 기간이 지나도 파일이 더 이상 만료되지 않습니다. 등록 개발자 가이드에 추가 컨텍스트를 제공하는 업데이트를 진행하고 있습니다.
증명 파일	증명 파일은 어떻게 사용되나요?	관련성 및 측정 API를 호출하는 모든 회사는 시정 조치 기한까지 사이트에 증명 파일을 업로드하고 API 호출을 계속할 의도가 있는 한 공개적으로 유지해야 합니다. 웹사이트는 개인 정보 보호 샌드박스에서 시간당 약 1회의 요청을 받을 수 있으며, 다른 잠재적 항목도 쿼리할 수 있습니다. 등록 시스템 자체 메커니즘을 통해 등록된 항목의 서버를 쿼리하고 증명 파일이 유효한지 확인합니다. 증명서는 투명성 보고서에 포함되며 일반 대중이 볼 수 있습니다. Google은 나머지 생태계와 관련 규제 기관과 마찬가지로 기업이 명시된 증명서에 따라 행동할 것으로 기대합니다.
등록	등록은 사이트별인가요 아니면 출처별인가요?	등록은 사이트 수준에서 이루어집니다.

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

주제

의견 주제	요약	Chrome 응답
성능	유럽 경제 지역의 주제 선택 비율이 실적에 미치는 영향에 관한 문제	우려되는 이해관계자는 이 문제에 대해 관련 데이터 보호 기관에 문의하시기 바랍니다. 이러한 우려사항을 해결하고 개인 정보 보호 기술의 적용이 법률에 의해 인센티브를 받도록 할지 아니면 추적과 마찬가지로 동의에 동일한 접근 방식을 적용하도록 할지 결정하는 데 가장 적합한 위치에 있습니다. 후자의 경우 개인 정보 보호 샌드박스의 API와 같은 API를 자주 사용할 수 없게 될 수 있습니다.
등록	업스트림 SSP의 Topics 신호를 사용하려면 다운스트림 입찰자가 Topics API에 등록해야 하나요?	초기 Topics API 호출자를 넘어서는 주제의 다운스트림 수신기는 등록할 필요가 없지만, 다른 API 사용을 위해 등록되는 경우가 많습니다. 개인 정보 보호 샌드박스 등록자 목록은 프로그램의 투명성 노력의 일환으로 프로그래매틱 방식으로 제공되므로 Topics API에 관심이 있는 호출자는 원하는 경우 주제를 전송하는 수신자가 등록되어 있는지 확인할 수 있습니다.
주제 필터링	구매자가 가져올 수 있는 항목만 공유하기 위해 다른 호출자가 페이지에서 가져오는 주제에 다른 호출자의 필터링을 적용하도록 요청합니다.	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
사이트 제외	웹사이트가 사용자의 주제에 기여하지 못하도록 제외합니다.	주제는 기본적으로 호출되지 않습니다. 주제를 선택할 때는 페이지 콘텐츠가 고려되지 않으며 모든 주제는 민감하지 않도록 선별됩니다. 웹사이트는 다음 권한 정책 헤더를 통해 사이트가 주제 계산에 포함되지 않도록 제한할 수도 있습니다. `Permissions-Policy: browsing-topics=()`
주제 관찰	게시자가 Chrome에서 페이지 콘텐츠 (예: head 또는 body)를 기반으로 주제를 분류하도록 권한을 부여할 수 있습니다.	Google은 이전에 페이지 콘텐츠를 기반으로 사이트를 주제로 분류하는 기능을 제공하는 것을 고려했으나 개인 정보 보호 및 보안 문제로 인해 이 기능을 제공하지 않기로 결정했습니다. 이 제안은 이러한 우려사항을 일부 완화할 수 있지만 어느 정도까지 완화할 수 있는지는 명확하지 않습니다. 예정된 CMA 실험 기간으로 인해 3PCD 이전에는 이 변경사항이 적용되지 않을 것으로 예상됩니다. 여기에서 추가 의견을 보내주세요.
주제 관찰	게시자에게 더 세분화된 권한 정책을 제공합니다.	게시자에게 더 세분화된 권한 정책을 제공하면 게시자 사이트가 사이트 자체의 Topics API 유용성에 부정적인 영향을 미치지 않으면서 생태계 전체에 대한 Topics API 유용성에 부정적인 영향을 미칠 수 있습니다. 이 주제에 관한 자세한 내용은 업데이트 및 관찰에 관한 별도의 권한을 지원하도록 권한 정책 업데이트 GitHub 문제를 참고하세요.
의료 및 건강 주제	주제 분류에 의학 또는 건강 카테고리의 주제가 포함되지 않는 이유는 무엇인가요?	의료 및 건강 카테고리는 민감한 주제로 간주되므로 주제 분류에서 제외됩니다.
주제 검색	DSP가 헤더를 사용하여 가져오지 않고도 Topics를 더 빠르게 가져오는 방법입니다.	헤더 메서드는 교차 출처 iframe을 만들고 여기에서 `document.browsingTopics()`를 호출하는 것보다 성능이 우수하고 비용이 적습니다. 주제를 관찰하는 최상위 컨텍스트가 주제에 액세스하는 컨텍스트와 일치해야 하므로 호출에 교차 출처 iframe을 사용해야 합니다. 이에 대해서는 여기에서 자세히 설명했습니다.
주제 검색	교차 출처 스크립트 태그 요청에서 헤더를 통해 Topics 전달을 지원해 달라는 요청입니다.	보안 관점에서는 불가능합니다. 각 문서와 그 실행 환경은 문서의 단일 출처와 연결됩니다. 동일한 환경 내에 로드되고 실행되는 서드 파티 하위 리소스는 문서 출처에서 소유한 것으로 간주됩니다. 이는 한 출처에서 다른 출처로 동의 없이 데이터가 유출되는 것을 방지하기 위함입니다. 다른 방법으로는 `<script>` 태그에 `browsingTopics` 속성을 제공하는 것입니다. 이는 보안 관점에서 깨끗해야 하며 지연 시간을 추가해서는 안 됩니다. Google은 관련 업계의 의견을 언제든지 기다리고 있습니다.
인지도	Topics API 및 API 사용 방식에 대한 대중의 인식을 개선합니다.	이 의견을 제공한 이해관계자와 협력했으며 이 문제는 GitHub에서 해결되었습니다. 앞으로도 Google은 API에 대한 생태계 이해를 계속 지원할 것이며 이해관계자의 의견을 기다립니다. 그동안 Topics API에 관해 자세히 알아보려는 이해관계자는 Chrome 개발자 가이드의 문서를 숙지하시기 바랍니다.
알림	웹사이트에서 사용자의 주제를 관찰할 때 사용자에게 알리는 알림입니다.	GitHub에서 이 의견을 처리했습니다. 사용자는 Chrome 고객센터에서 주제 제어에 대해 자세히 알아볼 수 있습니다.
머신러닝	ML을 사용하여 사용자 주제를 추론하는 방법	이 문제를 논의 중이며 추가 의견을 환영합니다.
다양한 유형의 이해관계자에게 유용함	소규모 광고 기술 회사는 브라우저에서 Topics를 계산하는 방식으로 인해 Topics를 관찰하지 못할 수 있습니다.	사용자가 지난 3주 이내에 해당 주제에 관한 페이지를 방문한 것을 관찰한 광고 기술만 주제를 수신합니다. 광고 기술이 지난 3주 동안 해당 주제에 관한 사이트에서 해당 사용자를 위해 API를 호출하지 않았다면 반환된 값은 비어 있습니다. 이 기능은 더 많은 사이트 소유자가 서비스를 사용하고 따라서 특정 사용자의 사이트 방문을 관찰할 기회가 더 많은 광고 기술이 다른 광고 기술보다 더 많은 주제를 받을 수 있음을 의미합니다. 이 기능은 이미 동일한 기본 정보를 관찰할 수 있는 당사자 (현재 서드 파티 쿠키를 통해)로만 사용자 정보의 사용 가능 여부를 제한하므로 API의 개인 정보 보호에 필수적입니다.
XHR 요청	`XMLHttpRequest` (XHR) 요청에 Topics를 포함하는 것이 지원 중단되는 시기는 언제인가요?	Chrome에서 2023년 8월에 발표한 바와 같이, Chrome은 오리진 체험판에서 정식 버전으로 전환할 때 XHR 지원을 지원 중단하기 시작했습니다. 주제의 확장이 진행되면서 XHR 지원은 OT 기능이 사용 설정된 사용자에게만 포함되었으며 개별 OT 실험 그룹이 병합될 때 완전히 지원 중단되었습니다. XHR과 함께 Topics를 사용하고 있다면 사이트가 중단되지 않습니다. 주제가 XHR 요청 헤더에 추가되지 않습니다. 요청을 `fetch`로 전환하거나 iframe 속성을 사용하거나 JavaScript API를 사용하여 주제를 가져오는 것이 좋습니다. 가져오기는 모든 최신 브라우저에서 지원되지만 Internet Explorer 또는 Opera Mini에서는 지원되지 않습니다.
분류 및 분류 기준 업데이트 프로세스	주제 분류 및 분류 기준 출시 주기와 기업이 이러한 업데이트를 준비하는 방법에 관한 자세한 내용	Google의 답변은 2분기와 동일합니다. 최근 블로그 게시물에서 공유한 바와 같이, 분류는 시간이 지남에 따라 발전할 것이며, 분류의 거버넌스는 궁극적으로 업계 전반의 이해관계자를 대표하는 외부 당사자로 전환될 것으로 예상됩니다. 또한 topics-announce 그룹에서 확대 계획을 공유했습니다.
악용	리디렉션 체인을 통한 잠재적 공격	YouTube는 이 문제를 고려하고 있으며 추가 의견을 환영합니다.
게시자 인벤토리 유형	Protected Audience 및 주제 테스트에서 지원하는 게시자 인벤토리의 유형은 무엇인가요?	Protected Audience와 Topics는 본질적으로 사용할 수 있는 인벤토리 유형에 관해 제한적이지 않습니다.
단계적 확대 시간	새 분류가 100% 적용되기까지의 램프업 시간을 권장하지 않습니다.	생태계의 의견 요청과 PATCG 회의에서의 논의를 바탕으로 새로운 분류 체계 출시 계획을 발표했습니다.

Protected Audience API (이전의 FLEDGE)

의견 주제	요약	Chrome 응답
최상위 입찰	Google Ad Manager에 최상위 Protected Audience API 입찰을 제어할 권한을 부여하지 않고도 Google의 게시자 광고 서버를 사용할 수 있습니다.	Google Ad Manager의 응답: Google Ad Manager의 Protected Audience API 계획에는 다음과 같은 이유로 최상위 Protected Audience 입찰을 제어하지 않고 Google의 게시자 광고 서버를 지원하는 내용이 포함되어 있지 않습니다. 게시자 광고 게재 시장에서 고객에게 적절하게 광고를 게재하려면 Google의 게시자 광고 서버가 최상위 Protected Audience 입찰을 계속 제어해야 합니다. 게시자 광고 서버로서 Google의 역할은 게시자가 오버부킹 없이 직접 판매된 캠페인을 협상할 수 있도록 예측 정보를 제공하고 직접 예약의 속도를 조절하여 최적으로 게재하는 것입니다. 이렇게 하려면 최종 입찰을 실행하여 자격요건을 충족하는 모든 직접 및 간접 수요를 비교해야 합니다. 예측 및 속도는 게시자가 광고 서버에서 기대하는 핵심 기능입니다. 정확한 예측 없이는 게시자가 인벤토리를 과도하게 판매하여 비즈니스 평판을 위험에 빠뜨릴 수 있습니다. 광고주와의 예약 계약을 이행하지 못하면 게시자-광고주 직접 관계가 손상되어 게시자 비즈니스에 상당한 영향을 미칠 수 있으므로 속도 조절도 중요합니다. 요컨대, Google에서는 게시자 광고 서버의 최상위 Protected Audience 입찰 실행 활동을 게시자 광고 서버의 다른 활동과 구분하지 않습니다.
`directFrom SellerSignals`	`directFrom SellerSignals` 를 사용하면 Google Ad Manager에서 게시자가 문맥 입찰의 가격을 보지 못하도록 할 수 있습니다.	Chrome 응답: `runAdAuction()`에 전달된 정보는 판매자가 자체 iframe에서 `runAdAuction()`를 호출하지 않는 한 판매자로부터 온 것으로 알려지지 않습니다. 복수 판매자 입찰에서는 모든 판매자가 `runAdAuction()`를 호출하는 프레임을 만들 수 없습니다. `directFromSellerSignals`는 판매자의 출처에서 로드된 하위 리소스 번들에서 콘텐츠를 로드하여 이 문제를 해결했습니다. 이렇게 하면 판매자 입찰 구성에서 입찰로 전달된 정보의 진위성과 무결성을 조작할 수 없습니다. 게시자가 Protected Audience API를 사용하여 기술 제공업체가 Protected Audience 입찰에 전달하는 정보를 파악하려는 경우 기술 제공업체에 이 기능을 요청할 수 있습니다. Google Ad Manager의 답변: Google은 오랜 기간 입찰 공정성에 중점을 두고 노력해 왔습니다. 여기에는 미보장 광고 항목 가격을 비롯한 게시자의 미보장 광고 소스의 가격이 입찰에 참여하기 전에 다른 구매자와 공유되지 않는다는 약속이 포함되며, 이는 나중에 프랑스 경쟁 당국에 대한 약속에서 재확인되었습니다. Protected Audience 입찰의 경우 Google은 `directFromSellerSignals`를 활용하여 약속을 지키고 복수 판매자 입찰에서 입찰이 완료되기 전에 입찰 참여자의 입찰가를 다른 입찰 참여자와 공유하지 않을 계획입니다. 명확히 하자면 최상위 입찰 동향 추가 설명 업데이트에 설명된 대로 Google은 문맥 입찰의 가격도 자체 구성요소 입찰과 공유하지 않습니다.
정보 노출	민감한 비즈니스 로직과 계약 세부정보가 브라우저에 노출될 수 있습니다.	웹브라우저를 사용하는 사용자는 브라우저에서 발생하는 모든 것을 볼 수 있습니다. 브라우저 내에서 광고 입찰이 진행되는 경우, 해당 브라우저의 소유자는 입찰이 진행되는 모습을 볼 수 있습니다. 여기에는 여러 당사자가 입찰에 참여하는 금액도 포함됩니다. 브라우저는 사용자의 에이전트이므로 이를 변경하려고 시도하는 것은 가능하거나 바람직하지 않다고 생각합니다. 하지만 브라우저를 사용하는 사용자만 이러한 작업을 볼 수 있습니다. Protected Audience API를 사용하여 실행되는 기기 내 입찰은 Google을 비롯한 서버에서 관찰할 수 없습니다.
`PerBuyerExperiment GroupId`	현재 값 범위 `PerBuyerExperiment GroupId` 를 사용하면 구매자가 문맥 데이터를 신뢰할 수 있는 서버 요청과 연결할 수 있습니다.	이러한 방식으로 Protected Audience API를 사용하면 API 사용자가 개인 정보 보호 샌드박스 보호 기능을 우회하려고 하지 않는다는 개인 정보 보호 샌드박스의 필수 증명과 일치하지 않습니다. 향후 키-값 서버가 신뢰할 수 있는 실행 환경 (TEE)에서 실행되어야 한다는 요구사항이 이 공격에 대한 기술적 보호를 제공할 것입니다.
동일 출처 정책	하위 도메인을 허용하도록 동일 출처 정책을 완화합니다.	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
API 버전 관리	Protected Audience API 변경사항에 관한 버전 관리 및 출시 노트 요청	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
멀티 SSP 입찰	최상위 입찰 신호가 구성요소 신호 `auctionSignals`와 JSON 병합을 실행하도록 허용합니다.	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.
입찰가 한도	입찰에 참여하는 광고 구성요소 수의 한도를 20개에서 40개로 늘립니다.	Google은 이 요청을 검토 중이며, 이 기능이 유용한 이유에 관한 생태계의 추가 의견을 기다리고 있습니다.
(이전 분기에도 보고됨) Protected Audience 입찰 실적	Protected Audience 입찰의 지연 시간이 길다는 테스터의 신고가 접수되고 있습니다.	지연 시간 문제와 관련하여 Protected Audience API는 일반적으로 판매자가 입찰자가 사용할 수 있는 시간과 리소스의 양을 결정할 수 있는 제어 기능을 빌드하고 구매자가 사용 가능한 리소스를 가장 잘 사용하는 방법을 결정할 수 있는 도구를 빌드하는 기존의 표준 패러다임을 따랐습니다. 이러한 관리 기능과 도구는 현재 일반적으로 사용할 수 있지만 구매자와 판매자가 채택한 후에만 모든 이점을 누릴 수 있습니다. 또한 Chrome은 입찰 속도를 높이기 위한 다양한 인프라 개선 작업을 계속하고 있습니다 (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). 지연 시간 관련 작업의 두 가지 측면, 즉 구매자와 판매자에게 유용한 새로운 도구와 Chrome 엔지니어가 조사해야 하는 관찰된 병목 현상에 관한 신고에 관한 의견을 보내주세요.
구매 측 필터링	관심분야 그룹을 기반으로 한 구매 측 필터링 지원을 추가했습니다.	SSP와 DSP가 이를 처리하기 위해 디자인을 변경할 수 있는 몇 가지 방법을 제안했습니다. 일부 작업을 DSP의 키/값 서버로 이동합니다. SSP가 일부 문맥 시그널을 생성하여 DSP에 제공합니다. DSP의 문맥 시그널을 캐싱하는 SSP
게시자 관심분야 그룹 제어	게시자가 만든 관심분야 그룹의 사용을 위임하려는 게시자를 지원합니다.	Google은 이 요청에 대해 여러 당사자와 논의를 진행했습니다. 게시자가 만든 관심분야 그룹을 '위임'하는 것과 관련된 모든 사용 사례를 이제 수용할 수 있으며, 향후 일부 사용 사례가 더 원활하게 진행될 수 있도록 추가 지원을 구축해야 한다고 생각합니다.
(2분기에도 신고됨) 신뢰할 수 있는 실행 환경	비공개 클라우드 환경에서 신뢰할 수 있는 실행 환경 (TEE) 지원	Google의 답변은 이전 분기와 비슷합니다. Google은 퍼블릭 클라우드 기반 솔루션 이외의 옵션에 대한 지원을 계속 모색하고 있지만 현재로서는 온프레미스 TEE를 지원할 계획이 없습니다. 현재로서는 개인 정보 보호 샌드박스 보안 요구사항과 온프레미스 배포에서 발생하는 심각한 문제를 고려할 때 클라우드 기반 배포를 계속 확장하고 개선하는 것이(예: AWS 외에도 Google Cloud 지원) 생태계에 가장 도움이 된다고 생각합니다. 하지만 개인 정보 보호 및 보안 제약 조건을 고려할 때 이러한 요구사항이 왜 필요하고 실행 가능한지에 관한 추가 의견을 보내주세요.
신뢰할 수 있는 실행 환경	부하 분산기와 같은 TEE 제공 경로의 구성요소는 모든 트래픽을 관찰하고 각 요청의 IP 주소 정보를 보유할 수 있습니다.	현재 IP 주소는 입찰 및 입찰 서비스와 기기 내 Protected Audience 입찰의 경우 모두 신뢰할 수 없는 판매자의 광고 서비스에 요청 헤더의 메타데이터로 전달됩니다. 자세한 내용은 메타데이터 전달을 참고하세요. 장기적으로는 IP 프록시를 통해 광고 기술 및 추적기 트래픽을 프록시하여 구성요소가 게재 경로의 모든 트래픽을 관찰하지 못하도록 할 계획입니다.
TTL (수명)	서비스가 새 키를 요청해야 하는 시간(TTL)이 설정되나요? 아니면 유연하거나 동적일 예정인가요?	TTL은 일반적으로 정적입니다. 현재 공개 키의 TTL은 8일이며, 7일마다 순환이 발생합니다. 집계 서비스의 경우 비공개 키의 TTL도 동일합니다. 입찰 서비스의 경우 비공개 키와 공개 키가 요청이 아닌 경로에서 N시간마다 가져와 메모리에 캐시되므로 키가 회전하고 서버에서 이러한 키를 선택하는 사이에 N시간 이내의 지연이 발생합니다. 키 순환과 만료 사이에 1일의 버퍼가 있는 이유는 키 생성에 실패하더라도 서비스가 계속 작동할 수 있도록 하기 위함입니다. 서비스 중단에 더 탄력적으로 대응할 수 있도록 TTL을 연장하는 방안을 고려하고 있습니다. 키가 유출되면 키 생성을 수동으로 강제하고 키를 더 빨리 무효화할 계획입니다. 조정자 중단 시에도 서비스가 계속 작동할 수 있도록 공개 키는 현재 클라이언트에 24시간 동안 캐시됩니다.
트래픽 형성	입찰 서비스의 트래픽 셰이핑 지원	구매자는 게시자 퍼스트 파티 데이터 또는 문맥 데이터를 기반으로 Protected Audience 입찰에 대한 수요를 표시할 수 있습니다. 판매자는 판매자의 광고 서버 또는 Ad Exchange 서버에서도 유사한 결정을 내릴 수 있습니다. 모델은 퍼스트 파티 데이터와 Protected Audience 입찰의 집계 보고서를 기반으로 학습할 수 있습니다. 판매자는 이 정보를 사용하여 Protected Audience 입찰 수요가 없는 경우 입찰 서버에 요청을 전송하지 않을 수 있습니다. 이는 트래픽을 형성하는 효과적인 방법이라고 생각합니다.
구성요소 입찰	구성요소 판매자와 공유되는 최상위 auctionSignals는 무엇인가요?	구성요소 입찰의 구매자는 구성요소 판매자로부터만 신호를 수신합니다. 곧 헤더 입찰 및 Protected Audience 입찰과 결합된 입찰의 전반적인 시퀀스에 관한 문서를 공유할 예정입니다.
동영상 렌더링	Protected Audience 및 펜스 처리된 프레임을 사용한 동영상 렌더링 지원	Protected Audience API는 iframe을 사용하는 메커니즘을 사용하여 동영상 렌더링을 지원합니다. 하지만 아직 펜싱된 프레임과 호환되는 솔루션을 설계하지 못했습니다. 이것이 펜싱된 프레임 시행을 2026년으로 미루기로 결정한 이유 중 하나입니다. 즉, 파트너가 지금 격리된 프레임을 적용하기로 결정하면 동영상 지원이 부족해질 수 있습니다.
최대 게재빈도 설정	(이전 분기에도 보고됨) 캠페인 및 광고 그룹 내 사용자별 게재빈도 제어	Google의 응답은 이전 신고와 동일합니다. Protected Audience는 기기 내 입찰 및 문맥 및 브랜딩 캠페인에도 최대 게재빈도 설정을 지원합니다. 공유 저장소 및 사이트별 한도는 추가 최대 게재빈도 설정 제어에도 사용할 수 있습니다.
광고 환경설정	Protected Audience는 광고주 사이트별로 선택 해제하거나 차단 목록에 추가하는 방법 또는 동일한 소유자의 모든 관심분야 그룹을 탈퇴하는 방법을 제공하나요?	사용자는 Protected Audience API 및 기타 개인 정보 보호 샌드박스 기능에 대한 액세스를 차단하는 여러 가지 방법을 사용할 수 있습니다.
입찰 스크립트의 소스 URL에 대한 동일 출처 정책	스크립트 또는 JSON 로드 URL을 지정하는 모든 필드가 소유자와 동일한 출처여야 한다는 요구사항을 완화합니다.	Google은 현재 이 요청을 검토 중이며 생태계의 추가 의견을 환영합니다.
`forDebuggingOnly`	3PCD 후에 `forDebuggingOnly .reportAdAuctionWin`가 남아 있으면 오용될 수 있습니다.	지난 몇 년 동안 서드 파티 쿠키가 지원 중단된 후 Protected Audience의 기능 공백에 관한 생태계의 의견을 수렴해 왔으며, Google은 개인 정보 보호 샌드박스의 목표를 손상시키지 않으면서 3PCD 이후 이를 지원할 계획을 수립하기 위해 노력하고 있습니다. 생태계에서 원하는 누락된 기능에 관한 추가 제안과 의견을 보내주시면 감사하겠습니다.
여러 관심분야 그룹	동일한 입찰에서 여러 관심분야 그룹을 사용합니다.	이는 기본 개인 정보 보호 모델이 변경되므로 현재 Protected Audience API에서 지원되지 않습니다. 여기에서 추가 논의를 환영합니다.
기기 내 입찰	Android용 Chrome에서 기기 내 Protected Audience 입찰을 지원하나요?	예, Android의 Chrome에서 기기 내 입찰이 지원됩니다.
(2023년 2분기에 보고됨) 클릭 관련 데이터	browserSignals에 클릭 관련 데이터를 추가합니다.	이 기능 요청은 계속해서 평가 중이며 우선순위를 두어야 하는 이유에 관한 추가 의견을 보내주세요.
신뢰할 수 있는 실행 환경 제공업체	여러 클라우드 제공업체의 신뢰할 수 있는 실행 환경 제품에 중대한 차이가 있나요?	큰 차이는 없지만 생태계는 공개 배포 가이드를 검토하여 필요에 가장 적합한 솔루션을 확인하는 것이 좋습니다. Google Cloud AWS
(이전 분기에 보고됨) 제외 관심분야 그룹 타겟팅 지원	제외 관심분야 그룹 타겟팅을 지원하는 API: 사용자가 관심분야 그룹에 속하지 않는 경우에만 광고를 게재합니다.	이 기능을 구현하기 위해 요청을 논의하고 있습니다.
콘텐츠 위반	사용자가 보호된 프레임에서 Protected Audience API로 게재된 악성 광고를 신고할 수 있는 기능을 지원합니다.	Google은 기존 펜스 프레임 광고 보고 메커니즘이 사용자 제작 '악성 광고' 보고 흐름을 원하는 광고 기술에 적합한 옵션이라고 생각합니다. 이렇게 하면 현재 업계 표준과 크게 다르지 않은 방식으로 악성 광고를 신고할 수 있습니다. 서드 파티 쿠키가 삭제된 후 페인스드 프레임 렌더링이 광범위하게 사용되기 전까지의 기간을 포함하여 공백이 남아 있는 경우 추가 기능 요청을 보내주세요.
Private Aggregation API 보고	사용자가 관심분야 그룹에서 보낸 시간을 어떻게 계산할 수 있나요?	Chrome M116 이상에서는 pull/639에 정의된 대로 최신성을 사용할 수 있습니다.
K-익명성 서버	K-Anonymity 서버에 관한 자세한 내용	여기에서 k-익명성 서버에 관한 자세한 내용을 공유했으며 추가 의견을 보내주세요.
동적 광고 소재 URL	k-익명성을 유지하면서 사전 선언 없이 광고 소재 URL을 지원합니다.	이 기능 요청에 대해 논의 중이며 이 기능이 우선순위에 포함되어야 하는 이유에 관한 추가 의견을 보내주세요.
K-익명성 요구사항	관심분야 그룹 업데이트에 대한 k-익명성 요구사항이 다시 도입되나요?	이 GitHub 게시물에 명시된 입장은 변경되지 않을 것으로 예상됩니다. 이 게시물에서 발표한 바와 같이, Google은 Protected Audience 관심분야 그룹 업데이트에 적용되는 k-익명성 요구사항을 삭제하기로 결정했습니다. 이 요구사항은 API의 전반적인 개인 정보 보호에 큰 영향을 미치지 않으며, 관련 기술이 더 개발되고 배포 및 채택된 후에 더 직접적인 다른 보호 조치 (예: IP 주소 개인 정보 보호 또는 신뢰할 수 있는 업데이트 서버)를 고려할 계획입니다.
입찰 서비스 베타 테스트	입찰 서비스 베타 테스트는 언제 시작되나요?	타임라인 및 로드맵에 명시된 대로 입찰 서비스 테스트의 첫 번째 단계는 2023년 11월에 시작됩니다.
로드블로킹	광고 네트워크의 광고 소재 조정을 지원해 달라는 요청입니다 (SSP와 DSP가 동일한 회사 또는 속성에 있음).	이 사용 사례에 관한 의견을 보내 주셔서 감사합니다. 더 많은 애드테크에서 이 기능을 지원하는 데 관심이 있는지 알아보고 있습니다. 추가 의견이 있으시면 언제든지 보내주세요.
네이티브 광고	네이티브 광고의 펜스 프레임 지원	YouTube에서는 이 사용 사례를 지원하는 방안을 고려하고 있으며 가능한 해결 방법을 논의하고 있습니다.
K-익명성	k-anon 기준을 충족하는 관심분야 그룹 광고를 극대화하려면 어떻게 해야 하나요?	이 주제에 관한 전술적 안내를 공유했습니다.
POST 지원	POST 요청을 통한 입찰 데이터 전송을 지원합니다.	이 기능 요청을 평가 중이며 이 기능이 우선순위로 고려되어야 하는 이유에 관한 추가 GitHub 문제 제출을 환영합니다.
보고 세부사항	여러 개의 광고로 구성된 광고가 포함된 격리된 프레임 광고 보고의 보고 세부사항은 무엇인가요?	현재 설계에서는 제품 ID 또는 위치를 캡처할 수 없습니다. 사용자 개인 정보 보호가 침해될 수 있기 때문입니다. `reserved.top_navigation`만 호출할 수 있으며, 이는 광고 구성요소 펜싱된 프레임에서 사용자 활성화(예: 클릭)가 발생하여 최상위 탐색으로 이어질 때 전송됩니다.
광고 입찰	구성요소 입찰에 참여하는 SSP가 다른 구성요소 입찰을 직접 트리거할 수 있나요?	`componentSeller`는 `componentAuctions`도 포함할 수 없습니다. 복수 판매자 입찰에는 두 가지 수준만 있습니다. 1. 구성요소가 동시에 입찰됩니다. 2. 최상위 입찰 (각 `componentAuction`의 낙찰 광고가 경쟁하는 입찰)
입찰 서비스 사용 가능 여부	Chrome에서 지원하는 테스트 단계에서 입찰을 사용할 수 있나요?	Chrome에서 지원하는 테스트 단계에서는 입찰 서버를 사용할 수 없습니다.
입찰 신호	브라우저가 입찰 신호를 요청하고 삭제하도록 허용합니다.	이 요청에 대해 논의 중이며, 이 요청을 우선순위에 두어야 하는 이유에 관한 추가 의견을 환영합니다.
`generateBid()`	`updateURL`를 통해 interestGroup의 `userBiddingSignals`를 업데이트할 수 있습니다.	YouTube는 이 제안을 검토 중이며 추가 의견과 논의를 환영합니다.
게시자 인벤토리 유형	Protected Audience 및 TOPICS 테스트에서 어떤 유형의 게시자 인벤토리가 지원되나요?	Protected Audience와 Topics는 본질적으로 사용할 수 있는 인벤토리 유형에 관해 제한적이지 않습니다.
서버 간 통합	Protected Audience에는 SSP와 DSP 간의 직접 통합이 필요한가요?	DSP가 처리된 정보를 기기 내 입찰 기능에 전달하기 위해 자체 서버에서 문맥 신호를 처리할 필요가 없는 경우 SSP와 DSP 간의 직접 통합은 필요하지 않습니다.
B&A의 `bid_currency` 필드	입찰 서비스에서 `bid_currency` 필드를 지원합니다.	B&A는 아직 `bid_currency`를 지원하지 않지만 2024년 1월 말까지 지원할 계획입니다. 여기의 타임라인을 참고하세요.
`perBuyerSignals`	`perBuyerSignals`에 크기 제한이 있나요?	구매자별 신호 수에는 제한이 없지만 데이터를 너무 많이 보내면 브라우저 성능에 악영향을 미칠 수 있습니다.
교차 사이트 사용 사례	여러 웹사이트에서 Protected Audience API 관심분야 그룹을 사용할 수 있나요?	Protected Audience는 turtledove/issues/282에 설명된 대로 이러한 사용 사례를 위해 설계되지 않았습니다.
관심분야 그룹 HTTP 요청	HTTP 헤더에 관심분야 그룹 Blob을 포함합니다.	YouTube는 이 요청을 검토 중이며 이 요청에 관한 추가 의견을 환영합니다.
광고 품질 관리	교차 사이트 정보와 관련된 광고 품질 관리 손실	Google에서는 이 의견을 고려하고 있으며 추가 의견을 환영합니다.
Chrome DevTools	발신 Protected Audience 네트워크 요청이 Chrome 개발자 도구 네트워크 탭에 표시됩니다.	YouTube에서는 네트워크 탭에서 이 기능을 사용 설정하기 위해 노력하고 있으며, 이 기능이 우선순위에 포함되어야 하는 이유에 관한 추가 의견을 환영합니다.
신뢰할 수 있는 실행 환경	개인 정보 보호에 영향을 미치는 측정항목 및 그 정도에 관한 세부정보가 신뢰할 수 있는 실행 환경 모니터링에 관한 설명에 언제 추가되나요?	이 정보로 설명을 업데이트하는 중입니다. 업데이트된 설명서는 2023년 11월까지 제공될 예정입니다.
`directFrom SellerSignals`	`directFrom SellerSignals`가 웹 번들로 패키징되지 않는 이유는 무엇인가요?	이 결정의 근거는 '여기'에서 확인하실 수 있습니다.
노출 위임	선택된 관심분야 그룹의 결과가 또 다른 타겟팅 액션인 경우 노출 위임을 실행할 수 있는 방법이 있나요?	중첩된 여러 입찰은 다음 두 가지 이유로 Google의 개인 정보 보호 목표와 호환되지 않습니다. 첫째, 입찰의 낙찰자가 펜싱된 프레임 내에서 렌더링할 때, Google의 Protected Audience 개인 정보 보호 목표에는 맥락을 알지 못하는 결과물 광고 렌더링이 포함됩니다. 즉, 주변 페이지의 URL 또는 퍼스트 파티 쿠키는 개인 정보 침해입니다. 이러한 환경에서는 중첩된 입찰이 불가능합니다. 둘째, Protected Audience 모델에 따르면 각 입찰의 낙찰자는 추가 사이트 하나의 데이터만을 기반으로 해야 합니다. 중첩된 입찰은 이를 복합하는 방법으로, 여러 사이트 프로필을 기반으로 광고를 선택할 수 있습니다.
저장 데이터 기준	키/값 서비스 신뢰 모델의 비저장 데이터 기준을 자세히 설명합니다.	키-값 서비스의 데이터는 리드스루 캐싱을 실행하는 대신 메모리에 로드되고 메모리에서 제공됩니다.
구매자 데이터 신호	DSP에서 수신하는 `buyer_data` 신호에 정의된 크기 제한이 있나요?	현재 DSP에서 수신하는 `buyer_data` 신호에 브라우저에서 부과하는 제한은 없습니다.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 주제	요약	Chrome 응답
교차 기기	Attribution Reporting API의 교차 기기 지원을 계획합니다.	교차 기기는 3PC 외에도 새로운 개인 정보 보호 문제를 야기하며 사용자가 사용할 수 있는 다양한 기기와 플랫폼을 고려할 때 기술 배포 문제를 추가로 야기합니다. Google은 잠재적 해결책을 모색하고 있지만 현재 기여도 보고에서 지원하는 중요한 사용 사례에 중점을 두고 있으며 서드 파티 쿠키가 삭제되기 전에 교차 기기 지원을 도입할 계획은 없습니다.
(이전 분기에도 보고됨) 트리거 데이터 크기	트리거 데이터 크기가 3비트로 제한되는 이유는 무엇인가요?	크기는 3비트 및 8개의 고유한 값으로 제한되어 사용자에 관한 교차 사이트 및 교차 컨텍스트 정보의 양이 제한됩니다. 생태계 참여자는 이벤트 수준 보고의 현재 매개변수가 충분한지 여부에 관한 의견을 제출할 수 있습니다.
전환 유입경로	전환에 사용된 여러 도메인을 보고합니다.	이 사용 사례는 여러 대상을 추가할 수 있기 때문에 가능합니다. 추가 의견을 보내주세요.
다른 국가에서 지원되는 동일한 도메인	도메인은 동일하지만 국가 TLD가 여러 개인 웹사이트에서 Attribution Reporting이 작동하나요?	이 문제는 질문을 제기한 이해관계자와 논의 및 해결되었습니다. 광고 기술에서 여러 국가 TLD를 사용해야 하는 경우 국가 TLD마다 하나씩 등록을 여러 번 해야 합니다.
Protected Audience 및 기여 분석 보고	광고 기술은 Protected Audience 입찰의 조회 후 전환과 기여 분석 보고의 클릭 후 전환에 모두 액세스할 수 있나요?	예. 개인 정보 보호 샌드박스는 Protected Audience 내에서 VTC와 CTC를 모두 지원해야 합니다.
집계 가능한 보고서 지연	집계 가능한 보고서 지연을 더욱 줄입니다.	YouTube는 이 문제와 관련하여 최근 의견을 수렴했으며 여기에서 아이디어를 공유했습니다. 생태계의 추가 의견을 기다리고 있습니다.
집계 가능한 보고서 지연	서버 미디에이션을 도입하여 지연을 줄입니다.	YouTube는 이 제안을 검토 중이며 추가 의견을 기다리고 있습니다 .
이벤트 수준 보고서 지연	이벤트 수준 보고서 지연을 줄입니다.	유연한 이벤트 수준 구성에 설명된 전체 버전의 유연한 이벤트 수준 제안서를 사용하면 노이즈를 절충하여 이벤트 수준 보고 지연을 최대 1시간까지 줄일 수 있습니다.
소스별 보고 출처	소스 보고 사이트당 최대 소스 보고 출처를 제한하면 광고 기술이 단일 게시자 출처에 대해 서로 다른 보고 출처의 소스를 등록하지 못하도록 할 수 있습니다.	이 문제는 문제를 제기한 이해관계자와 논의되었으며, 리디렉션과 관련된 다른 잠재적 솔루션을 시도하기 전에 소스 보고 사이트당 보고 출처 1개를 사용하는 잠재적 솔루션이 테스트되고 있습니다. 이 제한과 관련된 추가 생태계 의견도 언제든지 보내주세요.
문제 신고	Attribution Reporting API의 오류나 문제를 Chrome에 신고하려면 어떻게 해야 하나요?	현재 광고 기술은 발생하는 Attribution Reporting API 오류를 GitHub에서 문제로 신고하는 것이 좋습니다. Chrome 관련 문제가 있는 경우 Chromium 버그를 만드는 것이 좋습니다. 문제 신고 방법 및 위치에 관한 링크는 응대 및 의견 공유에서 확인할 수 있습니다.
중복 삭제	여러 파이프라인과 기기에서 전환 중복을 제거하려면 어떻게 해야 하나요?	기기와 측정 파이프라인 간에 중복을 제거하는 것은 오늘날 광고 기술이 3PC와 관련하여 직면한 알려진 현재의 과제입니다. Attribution Reporting API를 사용하면 광고 기술이 특정 전환을 등록할 시기를 결정하고 특정 메타데이터를 추가하여 전환을 추적하는 데 사용한 측정 파이프라인 (즉, 집계 키의 일부)을 나타낼 수 있습니다. 이 측정 파이프라인은 다른 측정 파이프라인과 비교할 수 있습니다. 이와 관련하여 추가 생태계 의견을 보내주세요.
중복 삭제 및 우선순위	중복 삭제 전에 우선순위를 먼저 요청합니다.	YouTube에서는 이 요청을 검토 중이며 추가 의견을 기다리고 있습니다.
사기 방지	악의적인 사용자가 이벤트 수준 데이터를 조작할 위험이 있습니다.	이벤트 수준 보고서가 지원되지 않는 이유는 무엇인가요?에 설명된 이유로 이벤트 수준 보고에는 보고서 확인이 작동하지 않습니다.
전환 유형	기여 분석 보고서에서 조회연결과 탐색을 구분하려면 어떻게 해야 하나요?	다음과 같은 기본 제공 필터링 옵션이 있습니다. `source_type`. 자세한 내용은 여기에서 확인하세요.

Aggregation Service

의견 주제	요약	Chrome 응답
예산 복구	일부 광고 기술에서는 보고서에 실패, 오류 또는 삭제가 있는 경우 보고서를 다시 처리할 수 있는 기능을 요청했습니다.	YouTube는 개인 정보를 보호하는 방식으로 이 문제를 해결하기 위한 방법을 모색하고 있습니다.
사이트 등록	여러 광고 기술에서 지역, 광고주별로 데이터를 분할하는 등의 사용 사례를 위해 동일한 계정에서 여러 출처를 처리하는 지원을 요청했습니다. 클라이언트 API 등록이 이제 출처 기반이 아닌 사이트 기반이므로 광고 기술에서도 이러한 동작이 예상됩니다. 출처 등록에서 사이트 등록으로 이전하면 고객 등록 절차와의 일관성을 통해 광고 기술 온보딩 프로세스가 간소화됩니다.	조합 서비스의 출처 등록에서 사이트 등록으로의 이전이 곧 시작될 예정이며 생태계의 의견을 기다립니다.
출시 및 지원 중단 계획	집계 서비스 기능 및 패치의 출시 및 지원 중단 일정이 게시되었습니다. 이 계획의 목표는 광고 기술이 Google의 출시 정책을 확인하여 향후 출시 및 지원 중단에 대비하고 안정적이고 안전한 버전의 서비스를 실행할 수 있도록 지원하는 것입니다.	최근 집계 서비스 출시 및 지원 중단 계획에 관한 제안서를 게시했으며 추가 의견을 기다리고 있습니다.
코디네이터	집계 서비스에서 조정자가 다운되면 어떻게 되나요?	시스템이 제대로 작동하려면 두 조정자를 모두 완전히 사용할 수 있어야 합니다. 클라이언트 라이브러리에서 재시도를 통해 짧은 가용성 중단을 수용합니다. 두 조정자 중 하나의 가용성이 더 오래 중단되면 집계 작업이 실패합니다. 개인 정보 보호 예산이 아직 소진되지 않은 경우 작업을 다시 실행할 수 있습니다. 서비스 실패로 인해 광고 기술 저장소에 요약 보고서가 작성되지 않고 예산이 소비된 경우 현재 디버그 보고서를 사용하여 로컬 테스트 도구를 통해 결과를 가져오는 것이 좋습니다. 또한 광고 기술이 작업을 다시 실행할 수 있도록 실패 시 예산을 복구할 수 있는 기능도 개발하고 있습니다.

Private Aggregation API

의견 주제	요약	Chrome 응답
Blob URL	공유 저장소에서 Blob URL을 지원하도록 요청합니다.	Chrome M116에 Blob URL 지원이 추가되었습니다.

은밀한 추적 제한

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

의견 주제	요약	Chrome 응답
JavaScript API	User Agent Client Hints JavaScript API의 사용 가능 여부	이 기능은 동결 및 축소된 UA에서 기본적으로 제공되는 것 이상의 엔트로피가 높은 데이터에 적극적으로 액세스하려는 파트너를 위한 핵심 솔루션이므로 이 기능을 삭제할 계획은 없습니다.
기기 및 폼 팩터 정보	웹사이트가 웹사이트를 방문하는 기기가 지원할 수 있는 입력, 출력, 기타 정보를 이해하는 기능	생태계의 의견을 바탕으로 이 요청에 대한 지원을 추가했습니다.

IP 보호 (이전 명칭: Gnatcatcher)

의견 주제	요약	Chrome 응답
운영 가능 서드 파티 트래픽	설명에서 '자격요건을 충족하는 서드 파티 트래픽'은 무엇을 의미하나요?	YouTube는 이 문제의 중요성을 잘 알고 있으며, 자격 요건을 충족하는 서드 파티 트래픽과 그렇지 않은 서드 파티 트래픽을 파악하기 위해 적극적으로 노력하고 있습니다. 이 주제에 관한 의견은 언제든지 환영합니다.
네트워크 트래픽 감사	기업이 네트워크의 네트워크 트래픽 감사를 실행할 수 있도록 지원합니다.	퍼스트 파티 사이트에 삽입된 서드 파티 트래픽만 영향을 받으므로 필터링이 필요한 트래픽의 양이 제한됩니다. 또한 사용자에게 IP 보호를 사용할지 여부를 선택할 수 있는 옵션을 제공할 계획이며, 기업에서 관리하는 Chrome의 경우 IP 보호를 사용 중지하는 기업 정책이 적용됩니다. 마지막으로, IP 보호를 사용 중지하기 위해 네트워크 운영자에게 제공할 수 있는 제어 기능 (있는 경우)을 모색하고 있습니다. 이 주제에 관한 의견은 언제든지 환영합니다.
액세스 제어	IP 보호는 액세스 제어에 IP 주소를 사용하는 웹 서비스에 영향을 줄 수 있습니다.	Google은 사기 방지 사용 사례의 중요성과 이러한 사용 사례에 미칠 수 있는 영향을 잘 알고 있습니다. Google은 일반적으로 IP 주소를 사용해 온 사기 방지 사용 사례를 더 효과적으로 지원할 수 있는 방법에 관한 생태계 의견을 모으고 있습니다.
2홉 프록시 간 통신	프록시 간에 정보가 없도록 하는 방법	프록시 상호작용을 설계하는 중입니다. Google의 목표는 비즈니스, 절차, 기술적 수단을 통해 이러한 정보 공유가 발생할 가능성을 최소화하는 것입니다.
Google 이외의 인증	Google 이외의 인증 지원	초기 고려사항을 공유한 바 있으나 향후 계정 인증에 관한 자세한 내용을 게시할 계획입니다.
위치 추적기 분류	IP 보호팀은 추적기 및 그 변형을 구성하는 요소를 어떻게 결정하나요?	YouTube는 이 문제의 중요성을 잘 알고 있으며, 자격 요건을 충족하는 서드 파티 트래픽과 그렇지 않은 서드 파티 트래픽을 파악하기 위해 적극적으로 노력하고 있습니다. 이 주제에 관한 의견은 언제든지 환영합니다.
애널리틱스	IP 보호는 분석 서비스의 정확성에 영향을 미칠 수 있습니다.	Google은 IP 보호의 영향을 더 자세히 파악하고 생태계의 추가 의견과 사례를 기다리고 있습니다.
프록시	사용자가 프록시를 사용 중이거나 프록시를 수동으로 정의한 경우 IP 마스킹은 어떻게 작동하나요?	Google에서는 IP 보호가 다른 프록시에 미칠 수 있는 영향을 파악하고 있습니다. 현재로서는 공유할 계획이 없습니다. 이 주제에 관한 의견은 언제든지 환영합니다.
프리미엄 제품	IP 보호는 유료 기능인가요?	IP 보호는 핵심 브라우저 환경의 일부로 Chrome 사용자에게 제공됩니다. 유료 기능이 아닙니다.
프록시 서버	사용자 세션 중에 동일한 프록시 서버가 사용되나요?	HTTP/S 연결은 단일 프록시 쌍을 사용하고 원본에 단일 마스킹된 IP 주소를 표시합니다. 그 외에도 여러 HTTP/S 연결이 동일한 서버를 사용해야 한다는 엄격한 제약 조건은 없습니다.
플랫폼 지원	IP 보호는 어떤 플랫폼에서 지원되나요?	IP 보호는 처음에는 Android 및 데스크톱용 Chrome에서 사용할 수 있습니다. YouTube는 다른 플랫폼으로 보호를 확대하는 방법을 계속해서 평가하고 있습니다.
선택 해제	사용자가 IP 보호를 사용 중지할 수 있나요?	YouTube는 사용자에게 IP 보호를 사용할지 여부를 선택할 수 있는 옵션을 제공할 계획입니다.
익명처리	IP 보호에 따라 어떤 유형의 요청이 익명처리되나요?	요건을 충족하는 서드 파티 도메인에 대한 HTTP/S 및 DNS 요청은 개인 정보 보호 프록시를 통해 익명처리됩니다. 포함할 도메인을 결정하는 방법에 관한 설명은 향후 제공될 예정입니다. 나머지 트래픽 (예: 나머지 DNS 요청 또는 기타 HTTP/S 트래픽)은 영향을 받지 않습니다.
데이터 가시성	IP 보호의 첫 번째 홉 중에 네트워크 주소에 액세스할 수 있습니다.	2홉 프록시 모델에서 첫 번째 홉 (Google에서 제어)은 소스 클라이언트 IP와 두 번째 홉에 연결하라는 요청만 보지만 두 번째 홉 (외부 CDN에서 제어)은 첫 번째 홉의 튜플 (프록시 IP + 포트)과 대상 IP만 봅니다. 출처에서 반환된 응답의 경우 두 번째 홉은 요청과 연결된 첫 번째 홉 프록시+포트에 응답을 전달할 수 있으며 원래 클라이언트 IP에 관해 아무것도 알 필요가 없습니다. 첫 번째 홉은 대상 IP에 관해 아무것도 알지 못한 채 클라이언트에 응답을 반환하기만 합니다. 이렇게 하면 첫 번째 홉은 클라이언트 IP와 두 번째 홉만 학습하고 두 번째 홉은 대상 IP만 학습합니다.
WebView	향후 Android WebView에서 IP 보호를 사용할 수 있나요?	현재로서는 공유할 계획이 없지만 YouTube는 이 보호 기능을 최대한 광범위하게 제공하는 것을 목표로 하고 있습니다.

이탈 추적 감소

의견 주제	요약	Chrome 응답
상호작용 추적	사용자 상호작용은 어떻게 추적되나요?	이탈 추적 감소는 다음 두 가지 유형의 사용자 상호작용을 추적합니다. html 사양에 정의된 사용자 활성화입니다. 기본적으로 클릭, 키 누르기, 터치 스크린 탭 등이 여기에 해당합니다. 성공적인 webauth 어설션 사용자가 보안 키를 탭하거나 패스키를 인증 수단으로 사용하는 경우입니다. 이러한 상호작용은 상호작용이 발생한 페이지의 최상위 사이트와 연결됩니다. 예를 들어 사용자가 삽입된 iframe을 클릭하면 상호작용이 삽입된 사이트가 아닌 최상위 사이트와 연결됩니다. 상호작용은 스키마 없는 etld+1 및 상호작용 시간이 포함된 데이터베이스에 저장됩니다. 상호작용은 45일 동안 관련 도메인을 이탈 추적 완화 상태 삭제로부터 보호합니다.
허용 목록에 추가된 예외	도메인을 제외할 수 있나요?	Google은 이 요청을 검토 중이며 생태계의 추가 의견을 기다리고 있습니다.

개인 정보 보호 예산

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

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

의견 주제	요약	Chrome 응답
중앙 집중식 접근 방식	관련 웹사이트 세트를 관리하기 위한 중앙 집중식 저장소 접근 방식에 대한 우려	쉽게 액세스할 수 있는 공개 저장소는 제출물에 대한 책임성을 제공하므로 RWS 설계의 핵심입니다. 서드 파티 쿠키 기능은 궁극적으로 Storage Access API 또는 rSAFor API를 사용하여 제공되며, RWS 멤버십은 Storage Access API의 메시지를 통한 것과 달리 자동으로 부여된 액세스 권한을 제공합니다. Google은 RWS 제출 절차와 같은 접근 방식이 자동으로 부여된 서드 파티 쿠키 액세스에 적절한 요구사항이라고 생각합니다.
json 파일 이름 변경	API 이름이 변경되면 호스팅된 JSON 파일 이름도 변경해야 하나요?	예, 제출 가이드라인이 변경되었으며 기본 도메인은 `/.well-known/related-website-set.json`에서 JSON 파일을 제공해야 합니다. RWS 목록의 기존 세트는 변경할 필요가 없지만 기존 세트에 수정사항이 제출된 경우 JSON 파일을 변경해야 합니다.
(이전 분기에도 보고됨) 도메인 한도	연결된 도메인 수 확대 요청	8월 31일 블로그 게시물에서 발표한 바와 같이 생태계의 의견을 바탕으로 연결된 도메인 한도를 5개 도메인으로 상향했습니다. 연결된 도메인 제한을 다른 주요 브라우저에서 제공하는 가장 유사한 구현과 가장 일치하는 5개 도메인 (기본 도메인 1개 포함)으로 늘리기로 결정했습니다.
서드 파티 쿠키	관련 웹사이트 세트는 서드 파티 쿠키가 사용 중지된 경우에만 작동하나요?	관련 웹사이트 세트는 사용자가 서드 파티 쿠키를 차단하지 않은 경우에도 작동합니다. 하지만 관련 웹사이트 세트와 Storage Access API 없이도 관련 쿠키를 사용할 수 있으므로 눈에 띄는 효과는 없습니다.
적법한 수정사항	관련 웹사이트 세트 저장소는 소유자가 아닌 사용자가 세트를 수정하지 못하도록 어떻게 방지하나요?	제출 가이드에 따라 누구나 GitHub에서 PR을 제출하여 `first_party_sets.JSON` 파일을 수정할 수 있습니다. 하지만 PR이 승인되면(기술 검증 등 통과) Google에서 일주일에 한 번(화요일 오후 12시(동부 표준시)) 표준 FPS 목록에 일괄 수동으로 병합합니다. 악의적인 행위자가 소유하지 않은 세트를 수정하려고 시도해도 문제가 되지 않습니다. `.well-known` 파일을 수정할 수 없으므로 유효성 검사가 실패하기 때문입니다.
도메인 도용	도메인 도용은 관련 도메인 데이터를 승인되지 않은 당사자에게 노출할 수 있습니다.	이 Protected Audience GitHub 문제에 설명된 대로 불가능합니다.

Fenced Frames API

의견 주제	요약	Chrome 응답
콘텐츠 위반	사용자가 의심스러운 광고를 신고할 수 있도록 허용합니다.	펜싱된 프레임은 의심스러운 광고 신고를 방지하지 않습니다. 사용자는 여전히 광고와 상호작용하고 평소와 같이 광고 기술에 의심스러운 광고를 신고할 수 있습니다.
주변 사이트와의 상호작용	주변 또는 최상위 웹사이트와의 상호작용을 허용합니다.	Google은 이 요청이 필요한 이유를 파악하고 생태계의 추가 의견을 기다리고 있습니다.
네이티브 광고	네이티브 광고의 펜스 프레임 지원	YouTube에서는 이 사용 사례를 지원하는 방안을 고려하고 있으며 가능한 해결 방법을 논의하고 있습니다.

Shared Storage API

의견 주제	요약	Chrome 응답
교차 도메인	로컬 저장소의 도메인 간 통신을 허용합니다.	이 사용 사례는 현재 공유 저장소의 개인 정보 보호 출력 게이트와 일치하지 않지만, 파티션되지 않은 저장소에 관한 제안을 발전시키는 과정에서 추가 컨텍스트를 보내주세요.
Blob URL	공유 저장소에서 Blob URL을 지원하도록 요청합니다.	Chrome M116에 Blob URL 지원이 추가되었습니다.

CHIPs