이 페이지는 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의 내부 팀과 공개 양식을 통해 표시되는 자주 묻는 질문(FAQ)의 토론 주제를 검토하여 파악했습니다.

구체적으로는 웹 표준 기구 회의를 위한 회의록을 검토했으며, 직접적인 의견을 위해 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 리스트, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 봉사 활동에 관여한 팀 간에 조율하여 각 API와 관련하여 나타나는 주제의 상대적 보편성을 판단했습니다.

의견에 대한 Chrome의 응답에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 응답, 이 공개 보고 활동의 목적을 위한 입장을 파악하여 개발되었습니다. 현재 주력하고 있는 개발 및 테스트와 관련하여 특히 Topics, Protected Audience, Attribution Reporting API와 관련하여 받은 질문과 의견이 많았습니다.

현재 보고서 기간이 끝난 후에 수신된 피드백은 아직 Chrome 응답으로 간주되지 않을 수 있습니다.

약어 용어집

칩: 독립적인 파티션을 나눈 상태를 가진 쿠키
DSP: 수요측 플랫폼
FedCM: Federated Credential Management
FPS: 퍼스트 파티 세트
IAB: 인터넷광고협회
IDP : IDP: ID 공급업체
IETF : 인터넷 엔지니어링 태스크포스: 인터넷 엔지니어링 태스크포스
IP: 인터넷 프로토콜 주소
openRTB: 실시간 입찰
연장전: 오리진 트라이얼
PatCG: 개인 광고 기술 커뮤니티 그룹
RP: 신뢰 당사자
서비스 제공업체: 공급측 플랫폼
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년 이후 연구 분야로 크게 발전했으며 이에 따라 상업적으로 실행 가능한 애플리케이션이 등장했습니다. 개인 정보 보호 샌드박스의 중심에는 PET의 조합이 있으며, 이는 10여 년 전만 해도 불가능했을 조합입니다. 또한 브라우저에 대한 소비자의 기대치와 개인 정보 보호에 대한 규제 기대치가 높아지면서 개인 컴퓨팅 성능이 향상되었습니다.
머신러닝	Google에서 머신러닝 목적으로 개인 정보 보호 샌드박스를 어떻게 사용할 계획인가요?	오늘날 대부분의 광고 기술 생태계는 머신러닝을 사용하고 있으며 그렇게 될 것 같지 않습니다. 개인 정보 보호 샌드박스는 광고 기술 회사 또는 다른 사람이 머신러닝을 계속 사용하는 것을 막지 않습니다. 개인 정보 보호 샌드박스의 API와 통합하는 회사에도 머신러닝을 사용할 필요가 없습니다. 기업이 머신러닝 포함 여부에 관계없이 고객의 니즈를 충족하는 방식으로 제품과 서비스를 계속 빌드할 것으로 예상하는 것은 당연한 일입니다. 개인 정보 보호 샌드박스 통합자가 빌드하는 모든 머신러닝은 명확하게 알려져 있으므로 가려지지 않습니다.
데이터 확인	개인 정보 보호 샌드박스를 사용하여 수신한 데이터가 정확하고 Google이 미디어 평가 위원회 (MRC)와 같은 기관을 통해 검토를 받을 의향이 있는지 확인하려면 기업에서 어떻게 해야 하나요?	개인 정보 보호 샌드박스 API는 Chrome을 지원하는 오픈소스 플랫폼 내에서 빌드됩니다. 신뢰할 수 있는 실행 환경에서 실행해야 하는 API 부분도 오픈소스이며 감사가 가능합니다. MRC를 포함하여 코드를 검사하려는 누구나 코드를 검사할 수 있습니다.
(이전 분기에도 보고됨) 프로덕션 지원	Chrome에서 생태계에 영향을 미치는 개인 정보 보호 샌드박스 기술 문제 및 에스컬레이션을 지원하기 위해 마련되어 있는 프로세스는 무엇인가요?	Google은 광고 기술이 기술적 문제를 보고하고 이러한 문제를 해결하는 데 필요한 에스컬레이션을 지원할 수 있는 다양한 채널을 제공합니다. 또한 Chrome은 생태계 상태에 영향을 주는 기술적 문제와 에스컬레이션을 해결하기 위한 프로세스를 추가로 빌드하고 확장할 계획입니다. Chrome은 이를 위해 리소스를 확보하기 위해 최선을 다하고 있습니다 의견 및 에스컬레이션과 관련된 공개 및 비공개 포럼에 관한 자세한 내용은 개발자 게시물을 참고하세요.
Chrome에서 지원하는 테스트 모드	Chrome에서 지원하는 테스트 모드의 일정과 정확한 구현에 관한 추가 정보	테스트 모드에 관한 블로그 게시물을 공유해 드렸으며 곧 자세한 정보를 공유해 드리고자 합니다. 테스트 모드 라벨의 크기에 관한 제안을 보내주시기 바랍니다.
기타 업계 표준 통합	개인 정보 보호 샌드박스 API가 TCF v2.* 와 동의 모드 중 하나에 연결되나요, 아니면 둘 다에 연결되나요?	개인 정보 보호 샌드박스 API를 TCF v2 또는 동의 모드와 직접 통합할 계획은 없습니다. 그러나 기업 및 업계 무역 그룹은 개인 정보 보호 샌드박스 API와 함께 작동하도록 제품과 프레임워크를 조정할 수 있습니다. 예를 들어 TCF와 같은 프레임워크의 경우 각 참여자는 수신한 TCF 신호 및 관련 TCF 정책에 따라 자체 규정 준수 접근 방식을 결정해야 합니다. 기업에서는 Google의 개인 정보 보호 샌드박스 구성 요소가 제공하는 다양한 기능을 언제 어떻게 사용할 것인지 결정해야 합니다.

등록 및 증명

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

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

주제

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

Protected Audience API (이전의 FLEDGE)

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

디지털 광고 측정

Attribution Reporting (및 기타 API)

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

집계 서비스

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

Private Aggregation API

의견 테마	요약	Chrome 응답
Blob URL	Shared Storage에서 Blob URL을 지원하기 위한 요청입니다.	Chrome M116에 Blob URL 지원이 추가되었습니다.

비밀 추적 제한

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

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

IP 보호 (이전 명칭: Gnatcatcher)

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

이탈 추적 감소

의견 테마	요약	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개 도메인으로 늘렸습니다. Google은 관련 도메인 한도를 다른 주요 브라우저에서 제공하는 비교 가능한 구현과 가장 일치하는 5개의 도메인 (기본 도메인 1개 포함)으로 늘리기로 했습니다.
서드 파티 쿠키	관련 웹사이트 세트는 서드 파티 쿠키가 사용 중지된 상태에서만 작동하나요?	관련 웹사이트 세트는 사용자가 서드 파티 쿠키를 차단하지 않은 경우에도 작동합니다. 하지만 관련 웹사이트 세트 및 Storage Access API가 없어도 관련 쿠키를 사용할 수 있으므로 관찰 가능한 효과가 없습니다.
적법한 수정사항	관련 웹사이트 세트 저장소가 비소유자가 세트를 수정하지 못하도록 하는 방법은 무엇인가요?	제출 가이드에 따라 누구나 GitHub에서 PR을 제출하여 `first_party_sets.JSON` 파일을 수정할 수 있습니다. 하지만 PR이 승인되면 (기술 검증 통과 등) Google에 의해 일주일에 한 번 (동부 표준시 기준 화요일 오후 12시)에 수동으로 표준 FPS 목록에 일괄 병합합니다. 악의적인 행위자가 자신이 소유하지 않은 세트를 수정하려고 해도 `.well-known` 파일을 수정할 수 없어서 검증이 실패하므로 문제가 되지 않습니다.
도메인 하이재킹	도메인 도용으로 관련 도메인 데이터가 승인되지 않은 당사자에게 노출될 수 있습니다.	이는 이 Protected Audience GitHub 문제에 설명된 대로 불가능합니다.

Fenced Frames API

의견 테마	요약	Chrome 응답
콘텐츠 위반	사용자가 의심스러운 광고를 신고하도록 허용합니다.	의심스러운 광고 신고는 Fenced Frames를 통해 방지되지 않습니다. 사용자는 여전히 광고와 상호작용하고 일반적인 방법으로 의심스러운 광고를 광고 기술에 신고할 수 있습니다.
주변 사이트와의 상호작용	주변 웹사이트 또는 최상위 웹사이트와의 상호작용을 허용합니다.	Google에서는 이 요청이 필요한 이유를 파악하고 생태계의 추가 의견을 기다리고 있습니다.
네이티브 광고	네이티브 광고에서 펜스된 프레임을 지원합니다.	Google에서는 사용 사례 지원을 고려하고 있으며 가능한 해결 방법 및 솔루션에 대해 논의하고 있습니다.

Shared Storage API

의견 테마	요약	Chrome 응답
교차 도메인	로컬 저장소에 대해 도메인 간 통신을 허용합니다.	이 사용 사례는 현재 Shared Storage의 개인 정보 보호 출력 게이트와 일치하지 않지만 파티션을 나누지 않은 저장소에 관한 제안이 발전함에 따라 추가 컨텍스트를 도입해도 좋습니다.
Blob URL	Shared Storage에서 Blob URL을 지원하기 위한 요청입니다.	Chrome M116에 Blob URL 지원이 추가되었습니다.

칩