의견 보고서 - 2024년 2분기 및 3분기

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

CMA에 대한 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안서의 이해관계자 참여 절차에 관한 분기별 보고서를 공개적으로 제공하기로 합의했습니다 (약속의 12항 및 17항(c)(ii) 참고). 2024년 7월 22일, Google은 Chrome에서 서드 파티 쿠키 (3PC)에 대한 지원을 중단하지 않을 것이라고 발표했으며, 대신 사용자의 선택권을 높이기 위해 업데이트된 접근 방식을 도입할 것을 제안했습니다. 따라서 Google은 CMA의 동의를 얻어 Google과 CMA가 Google의 발표 내용을 충분히 고려할 수 있도록 2024년 2분기 공개 보고서를 CMA에 제출하지 않았습니다.

이러한 개인 정보 보호 샌드박스 의견 요약 보고서는 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 응답이 없을 수 있습니다.

약어 용어집

ARA

Attribution Reporting API

CHIPS

독립적으로 파티션을 나눈 상태를 가진 쿠키

DSP

수요측 플랫폼

FedCM

Federated Credential Management

FPS

퍼스트 파티 세트

IAB

인터넷광고협회

IDP

ID 공급업체

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

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

IP

인터넷 프로토콜 주소

openRTB

실시간 입찰

연장전

Origin 무료 체험

PAT API

Protected Audience API (이전 명칭: FLEDGE)

PatCG

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

RP

신뢰 당사자

RWS

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

SSP

공급측 플랫폼

TEE

신뢰할 수 있는 실행 환경

UA

사용자 에이전트 문자열

UA-스위스

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

W3C

World Wide Web Consortium

WIPB

의도적 IP 무시

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

의견 주제	요약	Chrome 응답
서드 파티 쿠키 지원 중단 (3PCD)	서드 파티 쿠키 지원 중단에 대한 Google의 계획은 무엇이며 디지털 광고 업계에 장기적으로 미치는 영향이 평가되었나요?	Google은 사용자 선택을 우선시하는 업데이트된 접근 방식을 제안하고 있습니다. 여기에 설명된 대로 Google은 서드 파티 쿠키를 지원 중단하는 대신 Chrome에 새로운 환경을 도입하여 사용자가 웹 탐색 전반에 적용되는 정보에 입각한 선택을 할 수 있도록 하고 언제든지 선택사항을 조정할 수 있도록 할 것입니다. Google은 이 새로운 방향을 규제 기관과 논의하고 있으며, 출시하기 전에 업계와도 협력할 예정입니다.
사용자 선택	사용자 선택 공지사항으로 인해 개인 정보 보호 샌드박스 솔루션 채택에 관한 생태계의 관심이 영향을 받았습니다. 모니터링 기능과 같은 기능 요청을 비롯하여 사용자 선택 발표에 대한 의견이 다양합니다.	업데이트된 접근 방식으로 사용자 선택권이 강화되었지만 개발자가 교차 사이트 식별자의 대안으로 개인 정보 보호를 강화하는 방법을 마련하는 것은 여전히 중요합니다. 새로운 환경이 어떤 모습일지에 대한 자세한 내용은 아직 알 수 없지만, Chrome에서 쿠키가 없는 트래픽이 크게 증가할 것으로 예상됩니다. 즉, 개인 정보 보호 샌드박스 API는 비즈니스에서 계속해서 중요한 역할을 합니다. Google은 개인 정보 보호와 유용성을 더욱 개선하기 위해 개인 정보 보호 샌드박스 기술에 계속 투자할 것입니다.
사용자 선택 UI	선택 해제/동의 기능의 타임라인, 고려 중인 사용자 옵션 유형, UI가 자동 테스트 환경에 미치는 영향에 관한 질문	현재로서는 공유해 드릴 만한 일정 업데이트가 없습니다. 3PCD를 추구하지 않기로 결정한 후 Google은 생태계에 최대한 빨리 업데이트를 제공하고자 했습니다. 사용자 선택 일정에 대한 업데이트가 있으면 알려드리겠습니다.
Chrome 테스트	2024년 상반기 이후 3PCD의 시장 채택도와 경제적 영향을 측정하기 위해 Chrome에서 제공하는 테스트 라벨을 계속 사용할 수 있도록 요청합니다.	2024년 상반기 Chrome 지원 테스트가 종료되더라도 테스터가 테스트 및 조정에 라벨이 지정된 브라우저 그룹을 계속 사용하고 싶어 할 수 있습니다. Google에서는 사용자 선택 공지사항을 고려하여 음반사의 다음 단계를 평가하고 있습니다. 그동안 Chrome팀에서는 2025년 1월까지 진행되는 Chrome 마일스톤 132를 통해 라벨이 지정된 브라우저 그룹에 대한 지원을 확대하기 위한 계획을 게시했습니다.
Android의 개인 정보 보호 샌드박스	Android의 개인 정보 보호 샌드박스와 Chrome의 개인 정보 보호 샌드박스는 서로 밀접하게 연결되어 있으며, Android가 없으면 개인 정보 보호 샌드박스를 제대로 평가할 수 없습니다. 교차 기기 및 멀티 터치 측면이 포함된 일반적인 고객 여정은 Chrome의 개인 정보 보호 샌드박스와 Android의 개인 정보 보호 샌드박스 모두에 중요합니다.	Android의 개인 정보 보호 샌드박스는 CMA에 대한 Google의 약속 범위에 포함되지 않습니다. Android 타임라인 및 출시와 관련된 의견인 경우, Google에서는 Android를 개인 정보 보호 개선을 위한 독립적인 작업 흐름으로 간주하고 있으며 Android를 계속해서 진행하고 있다는 점을 제외하고는 현재로서는 공유할 업데이트 사항이 없습니다. 앞서 언급한 바와 같이 Android에서 개인 정보 보호 샌드박스 API를 사용할 수 있는 여부는 사용자가 기기를 업데이트하는 속도에 따라 달라지며 이는 Google에서 제어할 수 없습니다.
모드 B 트래픽 제한됨	모드 B에서 사용할 수 있는 광고 입찰 트래픽이 예상보다 적었습니다.	Protected Audience API (PA API)의 입찰량이 예상보다 낮을 수 있는 이유는 여러 가지가 있습니다. 예를 들면 다음과 같습니다. - PA API를 통합한 것으로 파악된 회사는 배너 형식만 포함했습니다. - 판매 측 플랫폼이 항상 입찰을 시작하지 않을 수도 있습니다. - 브라우저에 관심분야 그룹 (IG)이 없을 수 있습니다. - 입찰이 없을 수 있습니다. 그러나 PA API를 테스트하려고 했지만 트래픽을 수신하지 못한 사용자는 확인되지 않았습니다.
서비스 중단 공개 상태	개인 정보 보호 샌드박스 API에 영향을 미치는 서비스 중단 및 문제를 파악할 수 있습니다.	브라우저 외부에서 서비스가 제공되는 개인 정보 보호 샌드박스 API의 공개 상태 페이지가 있습니다. Chrome팀은 개인 정보 보호 샌드박스 기술을 비롯하여 웹의 주요 사이트와 서비스에서 사용하는 모든 중요한 API와 플랫폼의 안정성을 최우선으로 생각합니다. 지금까지 한 번의 서비스 중단이 있었습니다. 이는 1%에서 테스트하기 위한 임시 구성과 관련이 있었습니다. 곧 이번 서비스 중단과 관련된 실험용 구성이 더 이상 필요하지 않으므로 Chrome에서 API가 정상적으로 사용 설정되면 이 문제가 발생하지 않을 것으로 예상됩니다.
쿠키 그래프 연구	개인 정보 보호 샌드박스 프레임워크 내 이 자료에 설명된 CookieGraph 메서드에 관한 Chrome의 관점은 무엇인가요?	이 문서에서는 사용자가 방문한 도메인이 아닌 도메인에서 설정된 퍼스트 파티 (1P) 쿠키의 감지 및 확산에 관한 몇 가지 흥미로운 사항을 제기합니다. 이 백서에서 지적했듯이 이러한 쿠키는 사용자가 웹사이트와 상호작용하는 방식에 대한 분석과 정보를 수집하는 데 매우 유용합니다. 이 데이터는 개발자가 사용자에게 더 나은 탐색 환경을 제공하는 데 매우 중요합니다. 이 논문의 주요 주장은 퍼스트 파티 쿠키를 교차 사이트 추적 벡터로 간주하므로 잘못되었습니다. 그러나 이는 논문에 설명된 매우 공격적인 가정 아래에서만 성립합니다. 사용자가 사이트와 개인 식별 정보를 공유할 의향이 있습니다. 기기에는 사이트 전반에서 사용자를 추적하는 데 사용할 수 있는 안정적인 디지털 지문이 있습니다. 이는 퍼스트 파티 쿠키를 사용하지 않고도 악용될 수 있는 재식별 벡터이며 (예: 서버 측 데이터 공유를 통해) 서드 파티 쿠키와 같은 상태 기반 추적 메커니즘에 중점을 두고 있는 현재의 노력과는 별도로 해결해야 합니다. 마지막으로, 이 백서에서는 애널리틱스 및 광고 쿠키를 추적 쿠키와 꼭 필요한 쿠키라고 하며, 비추적 쿠키와 반드시 일치하는 것은 아닙니다. 실제로 퍼스트 파티 분석 또는 매장 검색 기능 위젯, 채팅 위젯, 부하 분산기 쿠키와 같은 파티션을 나눈 사이트 간 공급업체 서비스는 종종 하나의 도메인으로 제한될 수 있으며, 반대로 꼭 필요한 일부 쿠키는 사기 방지 목적으로 크로스 사이트 추적이 될 수 있습니다.
UX 변경사항	Chrome 112의 UX 변경사항으로 인해 Chrome 설정의 '기기 내 사이트 데이터' 섹션에 퍼스트 파티 쿠키 컨트롤이 표시되면 사용자가 모든 쿠키를 차단하기가 더 어려워질 수 있습니다.	이 변경사항은 3PC (또는 파티션되지 않은 저장소)의 제어 기능을 다른 모든 종류의 사이트 데이터와 분리하고 한 단계 끌어올리기 위한 조치의 일환으로 이루어졌습니다. 서드 파티 쿠키 관리 기능은 개인 정보 보호 및 보안 패널 아래 강화됩니다. 퍼스트 파티 쿠키 및 기타 모든 종류의 사이트 데이터(중요한 사이트 기능에 일반적으로 의존함)에 대한 제어는 '기기 내 사이트 데이터'에서 번들로 제공됩니다. Google은 이 주제에 대한 의견을 계속 모니터링할 예정이지만, 현재의 분리는 의미 있는 개인 정보 보호 설정의 검색 가능성과 기능적인 탐색 환경을 보존하는 것 사이에서 적절한 균형을 이루고 있다고 생각합니다.
청구 및 결제	테스터가 개인 정보 보호 샌드박스 API의 다른 영역 테스트에 더 많은 투자를 하고 있으므로 결제 및 지급은 완전히 테스트되지 않고 있습니다.	개발자와 회사가 테스트할 시기와 대상을 선택할 수 있습니다. API는 테스트용으로 정식 버전으로 출시되었으며 2023년 9월부터 출시된 상태입니다.
테스트	DSP가 SSP에서 수신하는 모든 실험용 트래픽에 라벨이 지정되는 것은 아닙니다. 일부 DSP는 라벨이 지정되지 않은 실험 노출 점유율이 실험 그룹과 대조 그룹에서 다를 수 있다고 제출했습니다.	Chrome은 기업이 입찰 요청에서 라벨을 전달할지 여부를 제어할 수 없습니다. 브라우저에서 라벨을 가져오는 메서드를 제공합니다. 파트너가 이러한 라벨을 직접 읽을 수 없는 경우 라벨을 파트너에게 전달하는 것은 생태계에 달려 있습니다.
Android WebView의 3PCD	지원 중단을 테스트하기 위해 Android WebView에서 '서드 파티 쿠키 단계적 지원 중단 테스트' 플래그를 사용 설정하는 방법에 관한 안내를 요청합니다.	서드 파티 쿠키는 Android WebView에서 기본적으로 차단됩니다.
모델 학습의 위험을 완화하기 위한 개인 정보 차등 보호	모델 학습에 개인 정보 차등 보호가 사용되는 이유는 무엇인가요?	개인 정보 차등 보호는 신뢰할 수 있는 실행 환경 (TEE)과 함께 데이터 유출을 방지하고 위협으로부터 민감한 정보를 보호하기 위한 모델 학습에 필수적입니다. 이 접근 방식을 사용하면 모델 가중치로 개별 사용자 데이터가 드러나지 않습니다.

등록 및 증명

의견 테마	요약	Chrome 응답
등록	등록된 출처와 www 하위 도메인이 있는 광고 기술의 출처 간에 증명 등록이 작동하는 방식에 관한 설명 요청	광고 기술은 https://example.com에서만 온보딩하면 됩니다. https://example.com/.well-known/privacy-sandbox-attestations.json에 증명을 배치하면 https://www.example.com가 하위 도메인이므로 적용됩니다.
API 사양	저장소에 증명 파일의 JSON 스키마를 추가하는 제안	이 제안을 검토 중이며 여기에서 추가 의견을 보내주시면 감사하겠습니다.

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

주제

의견 테마	요약	Chrome 응답
주제 가중치	주제에서 가장 중요한 것은 특정 신호의 희귀성입니다. 현재의 설계는 관찰된 각 주제 옆에 가중치 값을 추가할 수 있도록 개선되어야 합니다. 가중치는 주제를 사용하는 모든 브라우저와 비교하여 브라우저의 주제에 대한 상대적 가중치입니다.	신호의 희귀성이 가장 중요한 신호인 이유를 자세히 알아보겠습니다. 이 사용 사례의 유용성에 관한 생태계의 추가 의견은 여기에서 보내주세요.
주제 신뢰성	Google은 시간이 지남에 따라 Topics의 신뢰성을 보다 확실하게 보장해야 합니다.	API 변경은 생태계의 의견을 바탕으로 계속 진행되며 변경 전에 공개적으로 논의될 예정입니다. 수정된 거버넌스 구조에 대한 제안은 추가적인 보장을 제공할 것입니다.
분류 기준	게시자 사이트가 의미 있는 목적을 달성하기에 적합하지 않게 잘못 분류되거나 너무 상위 수준의 주제가 할당되는 경우가 많습니다.	주제 분류에 관한 설명에 설명된 대로 사이트는 가장 인기 있는 사이트가 포함된 사람이 선별한 재정의 목록과 기기 내 머신러닝 모델을 조합하여 분류됩니다. Chrome은 사이트가 주제 분류에 참여할 수 있는 옵션을 계속 평가하고 있습니다. 유용성 개선은 개인 정보 보호 및 악용 위험과 비교하여 평가해야 합니다. 예를 들어 다음과 같은 위험이 있습니다. - 사이트에서 자체 라벨링을 사용하여 다양한 (잠재적으로 민감한) 의미를 주제에 인코딩하는 방법을 사용합니다. - 사이트에서 주제를 공격하여 다른 사용자에게 유용성을 떨어뜨립니다 (예:의미 없는 노이즈로 사용자의 주제를 스팸함). 누구나 chrome://topics-internals 또는 이 colab을 통해 제공되는 도구를 사용하여 이러한 구성요소를 검사할 수 있습니다. 테스트를 통해 시간이 지남에 따라 분류가 개선될 것으로 예상되며, 잘못 분류될 수 있는 사이트의 예시를 보내 주세요.
API 질문	Topics API가 악성 콘텐츠로 수익을 창출하는 SSP에 지속적이고 경쟁 방해적인 이점을 제공한다는 우려	서드 파티 쿠키와 마찬가지로 해당 개체가 등록되고 증명되는 한 브라우저는 Topics 반환 대상에 구속받지 않습니다.
(이전 분기에도 보고됨) 다양한 유형의 참여자에게 유용성	현재 주제 분류기는 페이지 호스트 이름만 사용하여 해당 주제를 정의하므로 다양한 콘텐츠가 있는 대규모 사이트는 일반적인 주제를 제공하는 반면 소규모 사이트는 광고 가치가 더 높은 틈새 주제를 제공합니다.	Google의 응답은 이전 분기와 비슷합니다. 서드 파티 쿠키와 마찬가지로 사이트마다 제공하는 정보의 가치에 차이가 있습니다. 틈새 관심 사이트는 일관성이 없는 가치 기여를 합니다. 즉, 모든 틈새 관심 사이트는 상업적으로 가치가 있는 맥락을 제공하지 않으므로 더 적은 가치를 기여합니다. 다음은 Topics API의 이점을 누릴 수 있는 사이트입니다. Google은 사이트 수준이 아닌 페이지 수준으로 분류의 가능성을 고려했지만, 이러한 분류에는 수많은 개인 정보 보호 및 보안 관련 우려가 있습니다.
분류 기준	소규모 사이트는 분류가 잘못되거나 아예 분류되지 않아 가치 교환에 참여할 수 없는 경우가 많습니다.	주장되는 피해와 관련하여 잘못 분류될 수 있는 특정 사이트는 다른 사이트보다 더 큰 피해를 입지 않습니다. 사이트의 문맥 정보는 항상 사이트의 입찰에 사용할 수 있으므로 잘못 분류된 경우에도 올바른 주제와 비슷한 정보를 제공할 수 있기 때문입니다. 주제는 일반적으로 자체 사이트가 아닌 외부 웹사이트에서 잠재적으로 유용한 광고 정보를 수집하는 데 사용됩니다.
분류 버전	이전 버전과의 호환성을 보장하려면 분류 버전에 어떻게 액세스할 수 있나요?	분류 버전은 주제 사용 설정 가져오기 요청과 함께 전송되는 요청 헤더의 일부입니다. 예를 들어 헤더가 '(1 2);v=chrome.1:2:5, ();p=P000000000'이면 버전은 chrome.1:1:2입니다. 여기서 chrome.1은 구성 버전이고 2는 분류 버전이며 5는 모델 버전입니다. 이 내용은 사양에 설명되어 있으며 설명에도 추가되었습니다.
Topics 데이터	주제 데이터가 업데이트되는 방식에 관한 설명을 요청합니다.	분류 업데이트가 지정되지 않았습니다. 이를 통해 브라우저 공급업체는 유연하게 구현할 수 있습니다. 그렇더라도 Chrome의 V1에서 V2로의 분류 업데이트에 관한 휴리스틱은 다음과 같습니다. - V1 및 V2의 주제에 대해 단일 분류 트리가 유지됩니다. - 동일한 주제 ID는 동일한 의미를 나타냅니다. - 트리는 커지기만 합니다. 새 주제나 연결을 추가할 뿐 줄어들지는 않습니다. - 하지만 일부 주제 또는 링크는 버전에서 '비활성' 상태일 수 있으며, 이로 인해 삭제 또는 재구성된 것처럼 보일 수 있습니다. 예: - 이제 '픽업 트럭'에 '트럭, 밴, SUV'가 중간 상위 요소로 포함됩니다. - 'Foreign Language Study'에 'Education'이 두 번째 상위 요소로, 기존 'Reference'가 비활성화됩니다. '비활성' 주제의 영향: 이러한 주제는 새로운 분류에 사용되지 않습니다. 그러나 사용자 차단을 시행할 때는 이 주제를 여전히 고려합니다. 사용자가 V1에서 주제를 차단한 경우 V2에서는 하위 주제가 차단된 상태로 유지됩니다. 이는 하위 주제가 V2의 다른 상위 주제 아래에 표시되더라도 마찬가지입니다.
분류 기준	잘못된 분류의 원인과 해결 방법을 파악하고자 합니다.	먼저 Chrome에서 사이트의 주제를 결정하는 것은 광고 목적으로 사용자의 관심분야를 결정하기 위한 Topics 알고리즘의 입력으로만 사용된다는 점을 지적하고자 합니다. 다른 더 일반적인 분류 목적으로 개발되지 않았습니다. Google은 분류 모델의 전반적인 정확성에 관심을 두고 있으며, 가능한 경우 정밀도/재현율을 개선하려고 하지만, 개별 사이트 분류 수준이 아닌 전 세계 수준에서 이를 수행합니다. 잘못 분류되는 경우 잘못 분류된 개별 사이트에 해가 되는 것이 아니라 다른 사이트에서 광고를 선택할 때 주제 신호의 품질이 저하되기 때문입니다. 잘못 분류된 사이트에서 광고를 선택하면 사이트의 실제 주제가 이미 사이트에서 파악되므로 광고 검색어에 대한 입력으로 사용할 수 있습니다. 여기에서 추가 의견을 보내주세요.
API 테스트	Chromium에서 Topics 및 일반적으로 개인 정보 보호 샌드박스 API를 테스트할 수 있나요?	Topics API는 Chromium과 함께 제공되지 않고 Chrome과 함께 제공됩니다.
주제 호출자	광고 기술이 개인 정보 보호를 준수하는 방식으로 고급 분석 비용을 지원할 수 있도록 TEE 서비스를 활용하는 Topics의 부가 가치를 개선해 달라는 요청입니다.	여기에서 유사한 의견에 응답해 드렸습니다. 역빈도를 고려한 결과, 역빈도를 모델링한 후에는 구매자와 판매자가 제공한 값에 따라 주제 가치와 잘 상관되지 않는 것으로 나타났습니다. 여기에서 추가적인 의견을 보내주세요.
API 사양	브라우저 관심분야 동질 집단 설정이 Topics API를 차단할 수 있나요?	여기에서 이 의견에 답변해 드린 바 있습니다. Topics API는 FLoC의 발전된 버전이며 FLoC의 권한 정책을 준수합니다. 설명서에 설명된 대로 '참고: FLoC의 이전 Permissions-Policy: interest-cohort=()도 주제 계산을 차단합니다.'
주제 순위	'상위 5개 주제'를 확인할 때 조건을 충족하는 각 호출자를 기준으로 웹사이트 방문 빈도를 계산하나요, 아니면 항상 브라우저의 전체 방문 기록을 기반으로 계산하나요? 또한 주제는 각 발신자에 대해 별도로 순위가 매겨지나요?	방문 기록 하위 집합의 빈도를 기준으로 합니다. 방문 기록 항목 (페이지)은 페이지에 Topics 호출자가 하나 이상 있는 경우에만 참여할 수 있습니다. 주제 기록 저장소에 관한 자세한 내용은 여기를 참고하세요. Topics API 개선사항에 관한 공지사항에 명시된 바와 같이 순위는 빈도와 바이너리 우선순위 수준에 따라 달라집니다 (자세한 내용은 여기와 여기 참고). 그러나 호출자의 빈도에 따라 달라지지 않습니다. 그렇다고 해서 모든 호출자가 다음 에포크에서 상위 5개 주제를 모두 가져올 수 있는 것은 아닙니다. 설명서에 설명된 대로 '지난 3주 이내에 사용자가 해당 주제에 관한 사이트를 방문한 것을 관찰한 호출자만 주제를 수신할 수 있습니다.' 브라우저는 어떤 호출자가 어떤 상위 5개 주제를 관찰했는지 추적해야 합니다 (사양의 호출자 도메인이 있는 상위 5개 주제에 해당). 이 문제에 관한 추가 의견은 여기에서 보내주세요.

Protected Audience API (이전의 FLEDGE)

의견 주제	요약	Chrome 응답
(이전 분기에도 보고됨) 비용	온프레미스 광고 기술 데이터 센터에 비해 퍼블릭 클라우드에서 TEE를 실행하는 데 더 많은 비용이 드나요?	현재 TEE 보안 모델은 퍼블릭 클라우드 구현 관행의 이점을 활용합니다 (자세한 내용은 퍼블릭 클라우드 TEE 요구사항 설명 참고). 예를 들어 현재 하드웨어 기반 TEE는 모든 물리적 공격을 방어하지는 못합니다. Google에서 지원하는 기존의 퍼블릭 클라우드 제공업체인 AWS와 GCP는 직원을 포함한 물리적 액세스 위험에 대한 완화 조치를 설계하고 구현했습니다. 일부 광고 기술은 클라우드 서비스를 운영하는 것이 온프레미스 광고 기술 데이터 센터보다 비용이 더 많이 든다고 언급했지만, 비용이나 기타 이점 때문에 퍼블릭 클라우드에서 운영하는 광고 기술도 있습니다. Google은 퍼블릭 클라우드 외부 등 TEE 지원을 확대하기 위한 옵션을 계속해서 평가하고 있습니다. Google은 이러한 노력의 일환으로 온프레미스 데이터 센터를 조사하고 있으며, 생태계와 협력하여 이러한 지원을 제공할 수 있는 잠재적 솔루션을 모색하고 있습니다. 현재 연구 단계에서는 이것이 생태계에 실행 가능한 솔루션이 될 것이라고 보장할 수 없습니다.
PA API 및 Google Ad Manager (GAM)	GAM은 공정한 시장 결과를 달성할 수 없습니다. GAM이 적시에 광고를 게재하지 못하고, PA API를 사용하여 게재된 광고 수를 보고하지 않으며, 광고를 게재하기 위해 어떤 방법을 선택할지(예: 특정 슬롯에 대해 PA API 사용 중지) 구성 가능성을 제공하지 않습니다.	Google Ad Manager 응답: GAM은 PA API 수요로 인한 추가 게시자 수익이 추가 PA API 입찰 지연으로 인해 발생하는 비용보다 크도록 PA API를 통한 광고 게재 시 지연 시간을 최적화하기 위해 노력하고 있습니다. 초기 테스트 결과 게시자가 서드 파티 쿠키가 없는 트래픽에서 PA API를 통해 순수익을 창출하는 것으로 확인되었습니다. 이는 PA API의 추가 수요가 지연 시간으로 인한 모든 비용보다 크다는 것을 나타냅니다. Google의 접근 방식에 대한 자세한 내용은 FAQ를 참고하세요. 또한 GAM은 PA API를 통해 게재되는 광고에 대한 보고를 게시자에게 제공합니다. 여기에는 GAM이 구성요소 판매자인 경우 게재되는 광고와 GAM이 최상위 판매자인 경우 다른 구성요소 판매자를 통해 게재되는 광고가 포함됩니다. 신고와 관련해 자세히 알아보려면 애드센스 고객센터를 참조하세요. 마지막으로 GAM을 사용하면 게시자가 UI 내 컨트롤을 통해 트래픽에서 PA API 사용을 사용 설정하거나 중지할 수 있습니다 (자세한 내용은 고객센터 참고). Google은 게시자가 원하는 추가 관리 기능에 관한 의견을 고려할 준비가 되어 있으며, 표준 기능 우선순위 지정 절차에 따라 모든 기능 요청을 우선적으로 처리할 것입니다.
PA API 및 GAM/AdX	Google은 AdWords에서 자체적으로만 구매하는 것처럼 GAM에서 최종 판매 결정을 내리지 않은 PA API 노출은 구매하지 않겠다는 입장을 취한 것으로 보입니다. GAM/AdX에서 다른 거래소와 마찬가지로 대체 최상위 판매자에게 구성요소 입찰 구성을 제출할 수 있기 때문에 이는 시장 위치를 악용하는 것으로 보입니다.	Google Ads Platform의 관리자 답변: 그건 Google의 입장이 아닙니다. Google의 구매 측 플랫폼 (Google Ads 및 DV360)은 Google 이외의 거래소에서 노출수를 구매합니다. 이는 PA API 노출 및 비 PA API 노출에 모두 적용됩니다.
시장 반응	Mozilla의 우려: Google의 Protected Audience는 광고주 및 Google을 보호보다 우선시합니다.	Mozilla의 평가에 감사드리며, 앞으로도 공개 표준 포럼에서 Mozilla의 의견을 계속 수렴할 것입니다. 평가의 주제는 PA API의 현재 구현이 계획된 모든 보호 조치를 아직 시행하지 않는다는 것입니다. Google은 PA API를 통한 시장 출시 접근 방식을 통해 가능한 한 빨리 개인 정보 보호를 도입하고 구현하는 것과 개인 정보 보호를 장려하는 것 사이에서 적절한 균형을 맞추고자 노력했습니다. 이를 위해 Google은 API와의 통합을 개선하고 향후 보호 조치 (예: 펜스 프레임의 VAST 기능)에 통합할 수 있는 더 많은 의견을 수집할 시간을 확보하기 위해 시간이 지남에 따라 개인 정보 보호 제한을 적용하기 위한 로드맵을 수립했습니다. 또한 Mozilla는 최근 개인 정보 보호 및 디지털 광고에 대한 Mozilla의 '자유롭고 개방적인 인터넷 사용으로 개인 정보를 보호해서는 안 됩니다', '제품과 인프라를 통해 온라인 광고 개선'이라는 최근의 발표도 환영합니다.
(이전 분기에서도 보고됨) 입찰 결과	단일 입찰이 상응하는 점수와 함께 여러 렌더링 URL을 반환하도록 요청하여 네이티브 광고가 더 쉽게 중복을 제거하고 UX 및 지연 시간 문제를 방지할 수 있습니다.	이전 분기의 반응과 비슷합니다. 단일 PA API 입찰에서 여러 RenderURL과 각각의 점수를 공유하는 것을 고려했지만 개인 정보 보호 문제로 인해 구현하지는 않았습니다. Google은 한 페이지에서 사용자에게 동일한 광고를 여러 번 표시하지 않기 위한 사용자의 요구사항을 이해하며 이 요청을 평가하고 있습니다. PA API에서 네이티브 광고 사용 사례를 최적으로 지원하기 위해 필요한 추가 지원에 관한 생태계의 추가 의견을 여기에서 보내주세요.
성능	PA API에 영향을 미치는 지연 시간 관련 우려 사항	지연 시간에 대한 우려가 제기되어 Google에서는 PA API의 일부로 SSP가 DSP 지연 시간에 한도를 설정하고 지연 시간을 줄일 수 있는 개선사항을 적용할 수 있는 여러 기능을 개발했습니다. 이러한 기능을 활용하는 방법에 관한 자세한 내용이 포함된 지연 시간 권장사항 가이드가 최근 업데이트되었습니다. 또한 새로운 지연 시간 개선사항도 지속적으로 개발 중이며, 그중 일부는 여기에서 확인할 수 있습니다.
최상위 판매자	Google은 게시자가 대체 최상위 PA API 입찰 판매자를 선택할 수 있도록 해야 합니다.	PA API는 단일 판매자와 복수 판매자 디자인 모두에서 입찰을 시작하는 사용자에 구속받지 않습니다. PA API 입찰을 지원할지 여부와 방법에 대한 개별 회사의 선택은 각 회사의 몫입니다.
(이전 분기에도 보고됨) 제외 타겟팅	광고주가 특정 잠재고객에게 광고를 게재하고 싶지 않은 사용 사례에 대한 해결 방법을 요청합니다.	Google은 추가 (문맥) 입찰을 통해 제외 IG 타겟팅을 지원합니다. 이를 통해 광고주는 특정 잠재고객에게 광고를 게재하지 않을 이유가 없습니다. 자세한 내용은 이 설명 및 이 GitHub 문제를 참고하세요. PA API 입찰에 대한 제외 IG 타겟팅을 지원하는 솔루션도 모색하고 있으며 여기에서 추가 의견을 보내주세요.
(이전 분기에도 보고됨) 네이티브 광고	네이티브 광고에 대한 펜싱된 프레임 지원 요청	Google은 이 사용 사례에 대한 지원을 고려 중이며 여기에서 가능한 해결 방법과 솔루션을 논의 중입니다.
WebView	Chrome에 연결된 IG를 WebView에서 실행되는 입찰에 사용할 수 없는 시나리오에 관한 설명을 요청합니다.	충분한 개인 정보 보호 인프라를 사용할 수 있게 되면 이러한 사용 사례를 지원하려고 합니다. 현재로서는 더 이상 공지할 사항이 없지만 여기에서 추가 의견을 보내주세요.
부정적인 IG	신규 헤더 기능을 통해 제외 IG를 지원하도록 updateURL 처리를 요청합니다.	이 요청을 평가하는 중이며 여기에서 추가 의견을 보내주세요.
다양성 필터링	PA API에서 여러 판매자와 여러 입찰을 통해 네이티브 광고를 실행할 때 다양성 필터링을 구현하는 방법에 관한 안내를 요청합니다.	이 요청은 여기에서 논의 중이며 추가 의견을 보내주세요.
(이전 분기에도 신고됨) 차단 필터	다중 판매자를 통해 PA API에서 네이티브 광고를 실행할 때 '게시자 차단'(필터) 규칙을 적용하는 방법에 대한 안내 요청	여기에서 안내를 확인할 수 있으며 추가 의견도 환영합니다.
제한사항	하위 도메인 수준이 아닌 도메인 수준에서 제한을 허용하도록 요청합니다.	하위 도메인 또는 출처 수준의 제한은 웹의 기본 보안 모델을 따르므로 기본 설계입니다. 이러한 내용은 여기 및 여기에서 자세히 설명했습니다.
신뢰할 수 있는 입찰	신뢰할 수 있는 입찰 신호 요청에서 사용자 에이전트 및 관련 클라이언트 힌트 요청입니다.	이 기능 요청은 추적 중이며 여기에서 추가 의견을 보내주세요.
(이전 분기에도 보고됨) 여러 IG	동일한 입찰에서 여러 IG를 사용합니다.	이는 기본 개인 정보 보호 모델이 변경되므로 현재 PA API에서 지원되지 않습니다. 추가 논의는 여기에서 환영합니다.
(이전 분기에도 보고됨) 실적	로직을 클라이언트로 더 많이 이동하면 페이지 성능과 UX가 저하되어 웹사이트 SEO 점수가 저하될 수 있습니다.	이 문제를 논의 중이며 여기에서 추가 의견을 보내주세요.
입찰의 작동 방식	PA API는 입찰 동향 (예: 참여자, 입찰된 각 구성요소의 낙찰자 등)에 관한 정보를 줄여 게시자의 추적 가능성을 감소시키고 계약이 유지되고 있는지 파악하기 어렵게 만듭니다.	여기에서 거래 추적에 관한 솔루션을 제안했습니다. DealID 및 SeatID를 저장하고 이벤트 수준 보고를 통해 generateBid에서 scoreAd 또는 이그레스로 전파할 수 있도록 일부 기존 필드를 수정하고 IG 객체 내에 새 필드를 만들 계획입니다. 이렇게 하면 거래의 사용 사례를 충분히 뒷받침할 수 있습니다. Google은 광고 기술에서 입찰 동향과 게시자에 대한 추적 가능성 유지에 중요하다고 생각하는 다른 메타데이터에 관한 의견을 환영합니다. Google은 광고 기술이 참조하는 메타데이터의 구체적인 예와 어떤 당사자에게 어떤 당사자에게 전송해야 하는지를 제공하는 것이 좋습니다.
GAM	AdX 수요에 액세스하기 위해 GAM을 게시자 광고 서버로 사용해야 한다는 요구사항에 대한 우려	Google Ad Manager에서 제공한 응답: GAM에서는 게시자가 거래소 기능에 액세스하기 위해 광고 서버 기능을 사용할 필요가 없습니다.
(이전 분기에도 보고됨) 구성요소 입찰	PA API 구성요소 입찰 낙찰자는 GAM에 표시되므로 불평등한 정보 접근성에 대한 우려가 제기됩니다.	Google의 답변은 이전 분기와 동일합니다. Google Ad Manager에서 제공한 답변: "Google은 오랫동안 입찰의 공정성에 중점을 두고 노력해 왔습니다. 여기에는 미보장 광고 항목 가격을 포함하여 게시자의 미보장 광고 소스에서 제공하는 가격은 입찰에 참여하기 전에 다른 구매자와 공유되지 않는다는 약속이 포함되며, 이는 나중에 프랑스 경쟁 당국에 대한 Google의 약속에서 재확인되었습니다. PA API 입찰의 경우 Google은 약속을 지키고 다중 판매자 입찰에서 입찰이 완료되기 전에 입찰 참여자의 입찰가를 다른 입찰 참여자와 공유하지 않을 계획입니다. 명확히 말씀드리자면 Google은 이 업데이트에 설명된 대로 Google의 입찰을 포함한 어떠한 구성요소 입찰에도 문맥 입찰의 가격을 공유하지 않습니다. 또한 구매자가 SSP에 제공한 신호를 포함하여 구성요소 입찰 구성에 대한 정보를 자체 입찰의 일부로 사용하지 않습니다. 실제로 구성요소 판매자가 최상위 판매자와 난독화된 방식으로 구성요소 입찰 구성을 지정할 수 있도록 PA API가 변경되었습니다."
GAM	GAM이 IG 또는 PA API 구성요소 입찰 생성에 참여하지 않은 경우 GAM은 최상위 입찰 실행/보고에 대한 수익 공유를 요청하나요?	Google Ad Manager에서 제공한 응답: 게시자가 GAM을 광고 서버로 사용하도록 선택하면 GAM에서 최상위 입찰을 실행하고 광고 서버 기능에 대해 광고 게재 수수료를 청구합니다 (PA API 입찰 외부에 적용되는 것과 동일한 광고 게재 수수료). 그러나 낙찰된 광고가 GAM 외부 구성요소 판매자(즉, GAM이 IG 또는 PA API 구성요소 입찰 생성에 참여하지 않은 판매자)로부터 나온 경우 GAM은 결제를 처리하지 않으며 미디어 수수료를 청구하지 않습니다.
클릭 가능성	클릭 이벤트 등록 시 동일한 개인 정보 차등 보호가 적용되나요?	'클릭수'는 generateBid() 함수 내에서 browserSignal로만 사용할 수 있으므로 이 기능은 현재 'k-anon' 제한사항이 적용되지 않을 예정입니다. 이벤트 수준 보고에서는 새 속성으로 사용할 수 없습니다.
성능	문맥 입찰 요청에 대한 무조건적인 응답으로 인해 높은 이그레스 비용.	Google은 개인 정보 보호 문제로 인해 어떤 DSP에 IG가 있는지에 관한 정보를 직접 제공할 수 없습니다. 그러나 Google은 개인 정보를 보호하면서 유용한 정보를 제공할 수 있는 대체 솔루션을 모색하고 있습니다.
네이티브 및 아웃스트림 광고	네이티브 및 아웃스트림 광고와 관련된 Chrome의 관점에 대한 업데이트 요청	Chrome의 위치는 해당 사용 사례에 따라 다릅니다. 동영상의 경우 Chrome의 입장은 생태계가 Google API를 사용하여 실행 가능한 인스트림 동영상 솔루션으로 수렴하도록 장려하는 것이라고 할 수 있습니다. 지금까지 Google이 알고 있는 구체적인 제안은 GAM의 제안뿐이었습니다. 네이티브의 경우 여기에서 의견을 적극적으로 수렴하고 있으며, 곧 더 많은 탐색 단계를 통해 광고 기술을 참여시킬 계획입니다.
실시간 모니터링 (RTM)	라벨이 지정된 트래픽은 RTM 보고서를 전송하지 않습니다.	Google은 이 문제를 인지하고 있으며 해결하기 위해 노력하고 있습니다. 제공되는 대로 여기에서 새로운 소식을 알려드리겠습니다.
잠재고객 확장 지원	PA API의 잠재고객 확장/판매자 선별 잠재고객 지원 업데이트 요청	이 사용 사례에 대한 해결 방법을 제공하기 위해 노력하고 있습니다. Google은 무엇을 구축하고 지원해야 하는지에 관한 생태계의 의견을 수집하고 있습니다. 업데이트가 있으면 알려드리겠습니다. 여기에서 추가 의견을 보내주세요.
디버깅	Chrome의 개발자 도구에는 PA API의 세부적인 성능을 모니터링하는 패널이 없습니다. 예를 들어 전체 실적은 IG 수 또는 구매자 수에 의해 영향을 받을 수 있습니다.	이 구체적인 의견은 모니터링을 지원하는 Chrome 개발자 도구 UI의 기능과 관련이 있지만, 10월 7일에 광고 기술이 모니터링 및 알림의 기반으로 사용할 수 있는 맞춤 이벤트를 구성할 수 있는 기능이 도입되었습니다. 자세한 내용은 여기를 참고하세요. 이번 업데이트를 통해 의견의 상당 부분이 해결되기를 바랍니다. 지원되는 데이터 포인트 또는 개발자 환경과 관련이 있든 관계없이 이 기능에 관한 추가 의견이 있으면 여기에 있는 해당 GitHub 토론에서 알려주세요.
신호	DSP가 문맥 입찰 결과와 관계없이 perBuyerSignals가 SSP로 전송되도록 할 수 있는지 여부에 관한 우려사항	문맥 입찰은 하나의 DSP에서 낙찰된 입찰가가 하나뿐이거나 후속 PA API 입찰에서 이길 수 있는 하나의 입찰가만 낙찰받는 것으로 가정합니다. PA API 흐름의 경우 SSP는 제출할 수요 (기기 내 IG 형식)가 있는지 확인하려는 모든 DSP를 초대합니다. 문맥 입찰에서 패배한 DSP가 PA API 입찰에 참여하도록 '다시 초대'될 수 있으며 실제로 매우 가능성이 높습니다. 이 '초대 재신청'은 DSP가 수락하기로 결정한 경우 해당 캠페인에 대해 광고 인증자가 DSP가 고려해야 하는 신호(있는 경우)를 SSP에 전달하는 것을 말합니다. 즉, PA API 입찰에서는 문맥 입찰에서 발생한 사항과 관계없이 DSP가 항상 perBuyerSignals를 SSP에 제출할 수 있는 방법이 있습니다.
신호	generatedBid()에 전달된 browserSignals 객체에 prevClicks 추가 요청입니다.	이 요청은 클릭 정도 신호를 지원하기 위한 Google의 제안을 통해 해결할 수 있습니다. 이 기능은 최근 블로그 게시물 및 해당 설명에서 발표되었습니다. 여기에서 이 제안서에 관한 추가 의견을 보내주세요.
(이전 분기에도 보고됨) 모델링 신호	모델링 신호의 비트 수를 12비트에서 30비트로 늘리도록 요청합니다.	여기에서 이 의견에 대한 반론 제안을 보내드렸습니다. Google은 업계와 적극적으로 소통하여 Google의 제안에 대한 업계의 의견을 파악하고 있으며 현재 업계에 미치는 이점과 Chrome 사용자 및 기타 이해관계자에 미치는 영향을 고려하고 있습니다.
문서	키-값 (K/V) 서버 및 TEE를 사용하는 방법에 관한 안내를 요청합니다.	K/V 맥락에서 TEE를 사용하는 방법에 관한 안내는 여기에 있는 K/V 서비스 신뢰 모델 설계 세부정보에서 확인할 수 있습니다.
부정적 IG의 전체 기간	부정적 IG의 전체 기간을 365일로 연장해 달라는 요청	네거티브 IG는 광고 게재를 방지하는 데 사용되지만 악의적인 행위자는 여전히 이를 사용하여 사용자에 대한 정보를 공개할 수 있으므로 재식별 위험이 발생할 수 있습니다 (예: 악의적인 행위자가 공격하는 한 가지 방법은 부정적인 IG가 포함된 고가 입찰가를 반복적으로 배치하여 사용자가 특정 사이트를 방문했는지 여부를 학습하는 것입니다). TTL을 365일로 유지하면 악의적인 행위자가 네거티브 IG에 대해 훨씬 더 많은 데이터를 보유하게 되어 개인 정보 보호 관련 위험이 훨씬 커집니다. 따라서 사용자 개인 정보 보호를 위해 이 요청을 지원해 드릴 수 없습니다.
API 사양	perBuyerSignals의 일부로 전달할 값으로 무엇을 삽입할 수 있나요? 판매자가 임의로 정의할 수 있나요?	perBuyerSignals는 판매자가 입찰 내에서 제공하려는 모든 정보를 구매자에게 제공할 수 있는 곳입니다. 어떤 항목을 삽입할지는 생태계에서 결정해야 하지만 여기에서 추가로 논의할 수 있습니다.
광고 크기 매크로 대체	광고 크기 매크로 대체가 작동하지 않는 문제에 대한 안내를 찾고 있습니다.	곧 자세한 내용을 공개할 예정입니다.
입찰 후 SSP 매크로 대체: 최상위 URL 스푸핑	인증 공급업체가 개인 정보 보호 샌드박스 프레임워크 내에서 최상위 URL을 인증할 수 있도록 Chrome에서 도입할 수 있는 메커니즘은 무엇인가요? 펜싱된 프레임 내에서 SSP에서 제공한 최상위 URL의 정확성을 보장하기 위해 사용할 수 있는 대체 데이터 포인트나 신호가 있나요?	Google에서는 현재 여기에서 추가 의견을 수렴하고 있습니다.
기능 요청	updateURL 가져오기 및 실시간 보고 포스트백에서 엔트로피가 낮은 UACH를 제공하도록 요청합니다.	이러한 요청은 여기에서 논의 중이며 여기 및 여기에서 추가 의견을 보내주세요.
기능 요청	지정된 클라이언트가 forDebuggingOnly.reportAdAuctionWin() 및 forDebuggingOnly.reportAdAuctionLoss()를 통해 다운샘플링된 forDebuggingOnly 이벤트 수준 보고서를 전송하도록 트리거되었을 때 신뢰할 수 있는 서버가 디버깅 설계가 활성화되도록 동의하도록 요청합니다.	현재 추적 중인 요청이며, 새로운 소식이 들어오면 생태계에 업데이트를 제공할 예정입니다. 여기에서 추가 의견을 보내주세요.
API 사용량	순 사용자 도달범위 및 노출 도달범위를 집계하는 방법에 관한 안내를 요청합니다.	공유 저장소 워크렛 내에서 IG를 읽은 다음 비공개 집계 보고서를 보낼 수 있는 방법을 다루기 위한 제안에 대해 논의하고 있습니다. 자세한 내용은 여기에서 확인하실 수 있으며, 제안서 및 생태계와의 유용성에 관한 의견을 보내주시기 바랍니다.
API 사용량	게시자가 테스트해야 하는 항목, 중요한 API, 사용 설정해야 하는 API, 사용 설정할 API가 무엇인지에 대한 명확성이 부족합니다.	게시자와 생태계에서 게시자의 역할을 더 효과적으로 지원하기 위한 노력이 진행 중입니다.
API 사용량	광고 입찰 워크렛 이벤트에 이벤트 리스너를 추가할 수 있나요?	이는 일반 이벤트를 통해서는 불가능하지만 Chrome Devtools 프로토콜 이벤트를 사용하면 이 사용 사례를 부분적으로 해결할 수 있습니다. 일반 이벤트는 격리/개인 정보 보호 속성에 영향을 줄 수 있지만 자세한 내용은 여기를 참고하세요.
K-익명성	광고 렌더링 요구사항에 관한 설명을 요청합니다 (예: 광고가 게재될 수 있었다면 최소 50명이 광고를 보았을 것임).	개발자 문서에서는 향후 개발에 대한 Google의 기대사항을 개략적으로 설명합니다. 특히 초기 k-익명성 기준점이 k=10명임을 설명합니다. blink-dev 메일링 리스트는 Chrome에서 실시간으로 일어나고 있는 일에 관한 업데이트를 제공합니다. k-익명성 메일링 리스트 대화목록에 설명된 대로 현재 Chrome 안정화 트래픽의 약 1% 에 대해 k-익명성 요구사항을 실험적으로 적용하고 있으며 명시적으로 라벨이 지정된 슬라이스 ('모드 A' 및 '모드 B')에는 적용하지 않습니다.
마찰	TEE K/V 채핑을 일시적으로 제거하거나 모든 N개의 샤드를 호출해야 하는 것에서 유용성과 개인 정보 보호 기능 (예: K/V 성능/비용)?	이러한 유형의 요청은 차펠링을 제어할 수 있는 비프로덕션 인스턴스에서만 처리됩니다. 프로덕션 인스턴스의 경우 여전히 채핑이 필요합니다. 비프로덕션 사용에 대한 의견을 받으면 상황을 평가할 수 있습니다.
마찰	디버그/비프로덕션 K/V 바이너리에서 채핑을 사용 중지하기 위한 플래그 추가 요청입니다.	이 플래그는 출시 1.0.0과 함께 제공됩니다.
API 버그	설정에서 API가 사용 설정되어 있음에도 Chrome 126으로 업그레이드한 후 API가 작동하지 않았습니다.	이 문제는 개발 목적으로 사용자가 사용 설정한 'enable-fenced-frames' Chrome 플래그와 관련된 것으로 확인되었습니다. 이 플래그를 기본값으로 재설정하면 문제가 해결됩니다.
보고	구매자의 판매자와 무관하게 실시간 Reporting API를 사용 설정하도록 요청합니다.	이 요청은 여기에서 검토 중입니다. RTM 솔루션이 최근에 출시되었으며, 특히 이미 이 기능을 온보딩한 광고 기술의 의견을 기다립니다.
보고	서드 파티 보고 요청: DSP 및 SSP는 Chrome에서 노출 알림을 수신하지만 중간 레이어 기술 제공업체는 기본적으로 수신하지 않습니다.	이 요청을 검토 중이며 여기에서 추가 의견을 보내주세요.

Protected Auction Services

의견 주제	요약	Chrome 응답
TEEs	기술 표준에 따른 수동 온보딩에 대한 Google의 요구사항은 클라우드 공급업체 선택에 큰 제약이 됩니다. Google이 생각하는 것처럼 클라우드 제공업체 부서를 방문하지 않고도 적용된 기술 표준을 준수할 수 있습니다. 2025년 (초기)에 대체 제공업체의 늦은 지연은 Google 솔루션에 대한 팁을 제공하는 네트워크 효과를 가져올 것이기 때문에 용납되지 않습니다.	집계 서비스는 일부 광고 기술 사용 사례를 해결하기 위해 TEE 서비스에서 실행해야 하는 유일한 서비스입니다. 집계 서비스는 Amazon Web Services (AWS)와 Google Cloud Platform (GCP)을 모두 지원합니다. 광고 기술의 의견을 바탕으로 현재로서는 이러한 지원이 적절하다고 판단됩니다. 추가 클라우드 제공업체 - Google은 퍼블릭 클라우드 제공업체의 TEE 기준을 자세히 게시했습니다. 이는 TEE 솔루션이 개인 정보 보호 샌드박스의 개인 정보 보호 및 보안 목표를 충족하도록 하기 위한 것입니다. 구체적으로 개인 정보 보호 샌드박스 TEE 서버는 암호화되지 않은 교차 사이트 사용자 데이터 (예: 집계 서비스용 게시자 및 광고주 사이트의 데이터)를 처리합니다. API의 사용자 개인 정보 보호 목표를 충족하려면 이러한 키가 안전해야 합니다. 마찬가지로 API가 기업의 기밀 비즈니스 정보를 계속 보호할 수 있도록 하려면 안전한 환경이 필요합니다 (예: 다른 PA API 입찰 참여자가 구매자의 독점 비즈니스 데이터에 액세스하지 못하도록 방지). 현재로서는 잠재적으로 악의적인 운영자로부터 사용자 데이터를 완전히 보호하는 TEE 기술이 없습니다. 따라서 클라우드 제공업체의 신뢰성을 검증하기 위한 여러 요구사항이 포함되어 있습니다. '클라우드 제공업체국'에서 언급하는 항목이 무엇인지 확실하지 않으며 이는 요구사항의 일부가 아닙니다. 요구사항에 대한 의견이 있으시면 알려주세요. 또한 YouTube는 설명서에 정의된 절차를 사용하여 제출한 요청을 비롯한 신규 제공업체에 대한 지원 여부를 계속 평가하고 있습니다. 지금까지 Azure 지원 요청만 접수되었으며 현재 평가 중입니다.
B&A	설계가 계속 진화하고 있으므로 B&A 서비스의 기술적 복잡성과 실현 가능성을 평가하기는 어렵습니다.	이러한 우려사항을 해결하기 위해 GitHub에 B&A 설계, 사용 가능 여부의 타임라인, PA API를 지원하는 기능의 로드맵을 설명하는 자세한 설명을 제공했습니다. Google은 B&A를 배포하고 GitHub에서 생태계의 의견을 수집하려는 광고 기술을 지원하고 있습니다.
B&A	B&A를 사용하거나 기기에서 TEE 사용으로 이전하기 위해 B&A에 TEE 사용 비용을 계산하는 더 나은 방법 및 안내를 찾고 있습니다.	Google에서는 최근 비용을 보다 정확하게 측정하기 위한 도구가 포함된 K/V 서버 인스턴스 크기 조정 가이드를 게시했습니다.
K/V 서버	광고 확인자가 K/V 서버에 대한 전체 페이지 URL을 사용하여 광고 확인을 수행할 수 있도록 요청합니다.	Google은 현재 광고 인증 목적으로 TEE에서 실행되는 K/V 서버에 전체 페이지 URL을 제공할 가능성을 평가하고 있습니다. K/V BYOS에서는 전체 페이지 URL을 사용할 수 없습니다.
입찰 보안	악의적인 행위자가 민감한 정보에 액세스하거나 명의 도용자로 활동하지 못하도록 하는 입찰 보안 기능을 찾고 있습니다. 재생 공격으로부터 입찰을 보호하는 기능은 무엇이며 보안 보호 조치를 구현하는 방법은 무엇인가요?	B&A의 현재 보안 모델은 입찰 무결성을 보호할 수 있습니다. B&A는 악의적인 행위자로부터 광고 기술의 신호와 코드의 기밀성을 보호하는 TEE에서 실행됩니다. B&A 아키텍처에서 암호화된 B&A 요청 페이로드 (요청 암호문)는 클라이언트에서 신뢰할 수 없는 광고 서버를 통해 SellerFrontEnd 서비스 (SFE, TEE에서 SSP가 실행)로 전송됩니다. 요청 암호문에는 타임스탬프 기반 생성 ID가 포함됩니다. SFE는 요청의 타임스탬프를 검사하고 서버 시간의 +/- n초 이내에 있지 않은 재생된 요청을 거부합니다. 또한 B&A는 서버 간 통신을 위해 패딩 처리된 고정 크기 응답 페이로드를 반환할 수 있습니다. 이러한 솔루션은 악의적인 행위자가 콘텐츠에 대해 자세히 알아보기 위해 동일한 요청 페이로드를 재생하려고 시도할 때 시스템을 통한 재생 공격을 완화하는 데 도움이 될 수 있습니다. B&A는 설명 자료에서 보안 모델을 문서화하고 업데이트하는 중입니다.
K/V 서버를 통한 신호	Chrome의 신뢰할 수 있는 입찰 신호 요청의 일부로 K/V 서비스를 통해 전송된 perBuyerSignals를 포함하도록 요청합니다.	전체 페이지 URL을 포함하여 TEE에서 실행되는 K/V 서버로 전송된 perBuyerSignals의 정보를 포함하는 가능성을 평가하고 있습니다.
K/V 서버	K/V 및 B&A의 개인 정보 보호 제약 조건을 단계적으로 도입할 수 있는 타임라인을 요청합니다.	TKV 도입에 단계적인 접근 방식을 원하는 개발자의 의견을 이해하며 K/V 및 B&A와 관련된 구체적인 요청에 감사드립니다. 하지만 신중한 평가 결과 현재로서는 이러한 API의 개인 정보 보호 기능을 완화하지 않기로 결정했습니다. Google은 채핑과 같은 이러한 조치가 사용자 개인 정보를 보호하고 개인 정보 보호 샌드박스에 대한 신뢰를 유지하는 데 매우 중요하다고 생각합니다.
K/V 서버	호환되는 구성을 통해 K/V 저장소를 확장하는 방법에 관한 안내를 찾고 있습니다.	최근에 게시된 K/V 서버 인스턴스 크기 조정 가이드를 참고하세요. 이 도구는 각 매개변수 조합에서 QPS (설명서에서는 'RPS'라고 함)를 제공합니다.
K/V 서버	K/V 서버 요청에 판매자 정보를 추가합니다.	이 문제를 논의 중이며 여기에서 추가 의견을 보내주세요.
K/V + B&A 서비스	K/V 및 B&A의 출시 일정 또는 로드맵을 명확히 해 달라고 요청합니다.	K/V 및 B&A 모두에 단계와 타임라인이 있습니다. 기기 내 PA API 입찰과 함께 K/V 서버를 사용하는 경우 (B&A와 비교) 여기에서 공개 타임라인을 확인할 수 있습니다. K/V의 '정식 버전'이 정의되는 방식에 관한 내용은 베타 및 GA의 기능 세트를 정의하는 로드맵 섹션을 참고하세요. B&A의 경우 여기에서 공개 타임라인을, 여기에서 로드맵을 확인하세요. Google에서는 확장 테스트를 '완전 안정적인 프로덕션 규모 테스트'라고 정의합니다. 이 단계의 구체적인 기능은 여기에서 확인하세요. B&A에는 알파 및 베타 단계도 있으므로 확장 테스트에는 이전 단계의 기능 중 일부가 포함됩니다. K/V 및 B&A 모두에서 이러한 단계 정의가 언제 어떤 기능을 사용할 수 있는지 명확하게 하는 데 도움이 되는지 알려주세요. 여전히 문제가 있다면 알려주세요. 계획에 도움이 되도록 더 구체적인 정보를 제공해 드리겠습니다.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 주제	요약	Chrome 응답
시장 반응	경쟁 기여 분석 시스템이 엄격한 범위 내에서 이벤트 수준 보고 및 요약/집계 보고만 사용해야 한다는 요구사항은 경쟁에 대한 임의의 제한입니다. 데이터 보호 규정 준수를 위한 보호 조치 (예: 익명처리)가 마련되어 있더라도 이벤트 수준에서 실시간 기기별 재타겟팅 및 기여 분석을 방지합니다.	언급된 설계는 API의 개인 정보 보호 목표(예: 한 사이트에서 다른 사이트로 전달되는 교차 사이트 정보 보호)를 기반으로 합니다. 예를 들어 ARA는 이벤트 보고서를 통한 이벤트 수준 기여 분석을 지원합니다. 이벤트 보고서는 최소 1시간 지연됩니다. 이는 여기에 설명된 대로 타이밍 측정 채널 공격을 사용하여 이벤트 수준 보고서를 광고주 사이트의 사용자 ID와 연결하기 어렵게 하기 위해 필요한 조치입니다. 또한 ARA 외에도 고의로 식별 데이터를 제공하는 사용자로부터 정보를 직접 수집하는 등 기여 분석을 수행하는 다른 방법이 있습니다. 개인 정보 보호 샌드박스 API의 현재 개인 정보 보호 범위로 달성할 수 없는 사용 사례에 관한 의견을 보내주세요.
다양한 바닥용	ARA 및 Shared Storage API가 다중 노출 영역 사용 사례를 지원하는지 여부와 이를 입증할 수 있는 위치를 확인해 달라고 요청합니다.	현재 ARA 및 공유 저장소는 다중 노출 영역 (교차 기기) 기여 분석을 지원하지 않습니다. 동일한 기기에서 교차 앱 및 웹 기여 분석 (ARA를 통해)이 지원됩니다.
(이전 분기에도 보고됨) 교차 기기	ARA는 교차 기기 전환을 지원하나요?	Google의 대응은 이전 분기와 비슷합니다. 교차 기기는 3PC 외에도 새로운 개인 정보 보호 문제를 야기하며 사용자가 사용할 수 있는 다양한 기기와 플랫폼을 고려할 때 기술 배포 문제도 추가로 야기합니다. Google은 잠재적인 해결책을 모색하고 있지만 현재 ARA에서 지원하는 중요한 사용 사례에 중점을 두고 있으며 교차 기기 지원에 대한 일정은 아직 없습니다.
확장	Attribution Report API (ARA)가 현재 구성되어 있으며 모든 Chrome 사용자에게 안정적으로 출시 및 확장할 수 있는지에 대한 우려사항	ARA는 현재 모든 Chrome 사용자에게 제공되며 정상적으로 작동하고 있습니다. 또한 ARA를 테스트하는 광고 기술 회사의 수가 계속 늘어나고 있어 안정성과 확장성을 지속적으로 테스트하고 모니터링하고 있습니다. 여기에서 이 문제와 관련된 추가 생태계 의견을 보내주세요.
(이전 분기에도 보고됨) 중복 삭제	게시자가 동일한 광고 클릭에 대해 동일한 유형의 전환을 여러 번 중복 삭제하는 등 요약 보고서의 기여 분석 후 로직을 효과적으로 실행할 수 없도록 ARA에서 기기의 기여 분석 메커니즘을 제한하는 방법에 대한 우려사항	Google의 답변은 이전 분기와 동일합니다. 기기와 측정 파이프라인 간에 중복을 제거하는 것은 오늘날 광고 기술이 3PC와 관련하여 직면한 알려진 현재의 과제입니다. ARA를 사용하면 광고 기술은 특정 전환을 등록할 시점을 결정하고 전환을 추적하는 데 사용한 측정 파이프라인 (예: 집계 키의 일부)을 나타내는 특정 메타데이터를 추가할 수 있으며, 이를 다른 측정 파이프라인과 비교할 수 있습니다. 여기에서 이 문제와 관련된 추가 생태계 의견을 보내주세요.
전환 추적	여러 도메인의 전환으로 작동하는 기능을 요청합니다.	이 요청은 여기에서 논의 중이며 추가 생태계 의견을 환영합니다.
보고	브라우저는 전환을 전송하기 위해 최소 이틀에서 최대 30일까지 대기합니다. 이는 대다수의 이해관계자 광고주가 거의 실시간으로 작동하는 실적 기반 광고주라는 점에서 우려할 수 있습니다.	이벤트 수준 보고서의 기본 설정에는 2일, 7일, 30일의 기본 보고 기간이 있습니다. 유연한 이벤트 수준 보고를 사용하면 광고 기술이 기본값에서 보고 기간의 수와 길이를 변경할 수 있습니다. 보고 기간은 최소 1시간으로 변경할 수 있으므로 실적 기반 광고주의 사용 사례에 도움이 될 수 있습니다. 여기에서 이와 관련된 추가 생태계 의견을 기다리고 있습니다.
온라인에서 오프라인으로 이어지는 기여 분석	ARA를 통해 온라인에서 오프라인으로 연결되는 광고를 구현할 수 있는 옵션이 있나요? 아니면 오프라인에서 온라인으로 이어지는 기여도를 측정하는 다른 방법이 있나요?	현재 ARA에서 온라인 사용자로부터 발생한 오프라인 전환의 측정 사용 사례를 지원할 계획은 없습니다. 이러한 유형의 지원을 위해서는 고려해야 할 중요한 개인 정보 보호 및 보안 문제가 있습니다. 이 지원의 사용 사례에 관한 추가 생태계 의견은 여기에서 보내주세요.
디버그 보고	앱에서 웹으로의 기여 분석을 위한 Chrome (소스/트리거) 등록에 액세스할 수 있도록 광고 ID를 저장하거나 검색하는 방법은 무엇인가요?	디버그 보고서를 사용 설정하려면 광고 기술이 앱과 웹에서 이미 사용자를 조인할 수 있음을 Google에 증명해야 합니다. 이는 디버그 보고서에서 새로운 정보가 공개되지 않도록 하기 위함입니다. 광고 기술은 사용자별로 고유한 조인 키를 제공하여 조인을 증명할 수 있습니다. 이 조인 키는 AdID이거나 퍼스트 파티 조인 키일 수 있습니다. 광고 기술이 AdID를 사용하는 경우 Chrome은 기본적으로 브라우저에서 AdID 액세스를 지원하지 않으며 API는 각 광고 기술에 웹 등록 중에 AdID를 전달하는 자체 메서드가 있을 것으로 예상합니다.
버킷 세부사항	광고주별로 다른 버킷 전략을 사용할 수 있나요?	다양한 참여 예산 확장 접근 방식을 실험하여 사용 사례에 가장 적합한 접근 방식을 찾는 것이 좋습니다. ARA는 다양한 광고 기술 사용 사례를 충족할 수 있도록 유연하고 맞춤설정이 가능하도록 설계되었습니다. 따라서 광고주 또는 카테고리별로 다양한 버케팅 전략을 실험해 보는 것이 좋습니다. 다양한 버케팅 전략을 사용하면 광고주가 추적하고자 하는 측정값과 측정값의 양에 차이가 있는 경우에 유용할 수 있습니다.
문서	ARA용 앱<>웹 구현 관련 추가 문서 요청	ARA에 대한 앱<>웹 문서가 여기에 공개되었습니다.
성능	ARA 관련 요청 수는 해당 사이트를 운영하는 데 필요한 keepalive 요청 수에 비해 게시자 서버에 상당한 부하를 줄 수 있습니다. 단일 요청으로 소스 이벤트를 일괄 처리하면 서버의 부하를 줄이는 데 도움이 될 수 있습니다. JSON 인코딩된 객체 배열을 허용하는 것이 좋습니다.	API와 JavaScript 로직을 함께 사용하면 특정 로직에 따라 소스 이벤트를 일괄 처리할 수 있습니다. 현재 이 요청을 검토하고 있으며 여기에서 생태계의 추가 의견을 기다리고 있습니다.
기능 요청	서버 간 통합 지원이 없으므로 해결 방법 제안을 제안합니다.	현재 ARA에서는 서버 간 통합 지원을 구현할 계획이 없습니다. 서버 간 통합을 지원하려면 고려해야 할 많은 개인 정보 보호 문제가 있습니다. 서버 간 지원의 추가 사용 사례에 관한 생태계의 의견은 여기에서 보내주세요.
문서	ARA의 주요 부분과 몇 가지 간단한 사용 사례를 통해 이를 시작하고 실행하는 방법을 설명하는 '빠른 시작' 가이드를 요청하세요.	ARA에 관한 빠른 시작 가이드는 여기에서 확인할 수 있습니다. 올해 이 문서를 추가로 개선하기 위해 노력하고 있으며, 추가 문서가 필요한 특정 사용 사례 또는 시나리오에 관한 추가 의견은 여기에서 보내주세요.
API 사용량	여러 소수 값의 기여도를 확장하는 방법에 관한 권장사항을 요청합니다.	다양한 참여 예산 확장 접근 방식을 실험하여 사용 사례에 가장 적합한 접근 방식을 찾는 것이 좋습니다. 값이 작은 경우가 많은 시나리오의 경우 다양한 에피론 값을 실험하여 에피론의 노이즈가 사용 사례에 허용될 수 있는 변곡점을 파악하는 것이 좋습니다. 자세한 내용은 ARA의 요약 보고서 최적화 에 관한 연구 논문을 참고하세요.
유연한 이벤트 수준	유연한 이벤트 수준 (트리거 사양 여러 개)은 언제 구현되나요?	현재 유연한 이벤트 수준은 소스당 생성할 수 있는 보고서 수, 보고 기간의 수 및 길이, 트리거 데이터의 카디널리티 등 등록 구성 측면의 맞춤설정을 지원합니다. 현재 추가적인 유연한 이벤트 수준 개선사항과 관련된 생태계 의견을 추가로 수집하고 있지만 현재는 구현할 계획이 없습니다. 여기에 나열된 유연한 이벤트 수준 개선사항의 이점을 누릴 수 있는 사용 사례에 관한 추가 의견을 보내주세요.
버킷 처리	버킷의 집계된 참여 제한과 향후 확장성 및 이전 버전과의 호환성을 고려하도록 요청합니다.	이 요청을 검토 중이며 여기에서 추가 의견을 보내주세요.
Epsilon	ARA가 정식 버전으로 전환되면 엡실론 범위는 어떻게 되나요?	ARA는 2023년 3분기에 Chrome에서 정식 버전으로 출시되었습니다. 현재로서는 엡실론 값 기간을 수정할 계획이 없습니다. 수정된 거버넌스 구조에 대한 제안은 수정이 예상되는 경우 추가 보장을 제공합니다.
보고	Trigger-unknown-error 보고서에는 보고서 본문에 소스 속성이 포함되지 않습니다.	사양에 명시된 대로 trigger-unknown-error의 보고서 본문에 다른 필드가 있어야 하는 것은 아닙니다. 오류의 근본 원인에 따라 소스 관련 필드가 표시되기도 하고 표시되지 않기도 하므로 보고서 본문의 필드를 설명하는 표가 혼동을 줄 수 있음을 확인했습니다. 예를 들어 소스 일치 로직이 실행되기 전에 내부 오류가 발생할 수 있습니다. 이 경우 디버그 보고서를 채우는 데 사용할 수 있는 소스 데이터가 없게 됩니다. 이 점을 명확히 하기 위해 문서가 업데이트되었습니다.
API 사용량	두 가지 측정 목표인 개수와 값을 사용할 때 기여도 예산과 에피론을 모두 분할해야 하나요?	두 가지 측정 목표를 사용하는 경우 기여도 예산을 두 목표 간에 분할하는 것이 좋습니다.
보고	ARA는 멀티 터치 기여 분석 또는 지원 보고서 (즉, 기여 보고)를 지원하나요?	ARA는 현재 멀티 터치 기여 분석 또는 판매자의 데이터 기반 보고서를 지원하지 않습니다. 현재로서는 이를 구현할 계획이 없습니다. 사용 사례 및 우선순위에 관한 추가 의견은 여기에서 보내주세요.
API 버그	ARA의 경우 문서에 소스 및 트리거 집계 키 조각을 결합하는 데 XOR이 사용된다고 설명되어 있지만 실제로는 OR이 사용되고 있습니다. 이러한 불일치는 구현 시 혼란과 잠재적인 오류를 초래합니다.	오류임을 반영하도록 문서가 업데이트되었습니다.

Aggregation Service

의견 주제	요약	Chrome 응답
집계 작업	집계 작업에서 여러 접두사를 허용하도록 요청합니다.	이 의견을 조사 중이며 여기에 제안서를 게시했습니다. 여기에서 제안서에 관한 의견을 보내주세요.
기능 요청	service_account_token_creator_list가 설정되지 않았거나 비어 있는 경우 계정 IAM 정책 수정이 건너뛰어지도록 terraform 스크립트를 변경해 달라는 요청이 있습니다.	여기에서 이 문제를 조사하고 있습니다. 생태계에 관한 추가 의견을 기다리고 있습니다.
API 사용량	Terraform 계획이 항상 변경사항을 표시하는 것과 관련하여 설명이 필요합니다.	이 문제는 AgS 2.8 출시에서 해결되었습니다.
API 사용량	유연한 참여 필터링을 통해 집계 빈도에 대한 광고주별 설정을 구성하기 위한 권장사항을 찾고 있습니다.	현재 ARA를 통해 광고주별로 일괄 처리할 수 있습니다. 유연한 기여 분석 필터링은 광고 기술이 보고서의 기여도를 다양한 빈도로 세분화하려는 고급 사례에 사용할 수 있습니다. 광고 기술은 여기에서 일괄 처리에 대해 자세히 알아보고 여기에서 ARA와 함께 필터링 ID를 사용하는 방법을 자세히 알아볼 수 있습니다. ID 필터링에 관한 추가 문서도 준비 중입니다.
기능 요청	집계 서비스 (AgS)에서 `log_sum_exp` 지원을 요청합니다.	이 이해관계자에게 사용 사례에 대한 자세한 내용을 문의했습니다. 자세한 내용이 확인되는 대로 알려드리겠습니다.
기능 요청	AgS에 문제가 있거나 배포된 AgS에 잠재적인 문제가 있을 때마다 더 많은 로그/통계/기타 측정항목을 볼 수 있도록 요청합니다.	더 많은 오류, 완화 조치, 설명을 포함하도록 문서를 업데이트하여 여기에 게시했습니다. 문서화되어 있지 않거나 사용 가능한 오류/측정항목/로그 등에 관한 추가 의견과 유용한 세부정보를 여기에 보내주세요.
API 테스트	테스트 기간 후 엡실론의 최종 값은 얼마인가요?	현재로서는 엡실론 값 기간을 수정할 계획이 없습니다. 테스터는 다양한 매개변수를 실험하고 의견을 제공해 주시기 바랍니다.
보고	보고서가 생성되지만 반환 코드에 여전히 PRIVACY_BUDGET_AUTHORIZATION_ERROR가 표시됩니다.	Google에서는 이 오류를 방지하기 위해 올바른 보고 출처 및 집계 가능한 보고서를 지정하는 방법에 대한 안내를 제공했습니다. 특히 반복되는 오류가 있는 경우 문제에 대한 추가 의견을 보내주세요.
주요 발견	키 검색 제안서의 계획은 무엇인가요?	키 검색 제안서의 출시 일정은 아직 정해지지 않았지만 여기에서 제안서에 대한 생태계의 의견을 수렴하고 있습니다.
맞춤설정	집계 서비스에 사용할 수 있는 맞춤설정 옵션을 찾고 있습니다.	집계 서비스 맞춤설정은 TEE 내에서는 불가능하지만 TEE 외부의 일부 구성요소에 대해서는 가능합니다. 이는 TEE 내에서 유지해야 하는 개인 정보 보호 및 보안 표준 때문입니다. Google에서는 광고 기술이 아키텍처와 맞춤설정 가능한 구성요소를 이해하는 데 도움이 되도록 문서를 업데이트하고 있습니다. 특정 맞춤설정을 지원할 수 없으므로 가능한 경우 광고 기술은 표준 구성을 사용하는 것이 좋습니다.
스팟 인스턴스와 주문형 인스턴스 비교	시스템을 스팟 인스턴스와 주문형 인스턴스로 테스트했나요? 스팟 인스턴스를 사용할 때 일시적으로 사용할 수 없을 수 있다는 점 외에 구체적인 단점이 있나요?	Google에서는 광고 기술에 주문형 인스턴스를 사용하는 것이 좋으므로 스팟 인스턴스 테스트를 우선적으로 하지 않았습니다. 스팟 인스턴스의 단점은 예산이 소진되는 동안 작업이 중단된다는 점입니다. 예산이 소진되고 광고 기술이 요약 보고서를 수신하기 전에 작업이 중단된 경우 광고 기술은 작업을 다시 시도할 수 없으며 예산 복구를 요청해야 합니다. 예산 복구는 개인 정보 보호를 위한 심각한 장애가 발생한 경우에만 권장됩니다. 광고 기술은 비용을 최소화하기 위해 자동 확장을 구성하는 것이 좋습니다. 자동 확장에 0을 선택하면 작업이 요청될 때까지 실행 중인 인스턴스가 없음을 의미합니다. 이 경우 요청 시 인스턴스가 스핀업되므로 지연 시간이 증가할 수 있습니다.
알려진 오류 및 해결 방법	'서비스 오류'가 표시되는 집계 서비스 작업과 관련하여 설명 필요	이 문제는 여기에서 해결되었습니다. 또한 더 자세한 설명을 위해 일부 오류 메시지를 업데이트했습니다. 예를 들어 이전에는 이러한 오류가 내부 오류로 표시되었던 것과 달리 AWS에서 더 구체적인 권한/인증 오류가 발생하기 시작했습니다. 오류 코드 및 완화 단계에 관한 문서가 여기에서 업데이트되었습니다. 문서에 나와 있지 않거나 사용 가능한 오류와 유용한 세부정보에 관한 추가 의견은 여기에서 보내주세요.

Private Aggregation API

의견 주제	요약	Chrome 응답
키 디자인	비공개 집계 키 설계 가이드 요청	비공개 집계별 가이드는 없지만 집계 서비스 부하 테스트 프레임워크 및 고급 키 관리 가이드를 리소스로 사용할 수 있습니다.
기여도 예산	참여 예산은 어느 수준에서 계산되고 제한되나요?	기여 예산은 10분 순환 기간의 경우 2^16이고 24시간 순환 기간의 경우 2^20입니다.

은밀한 추적 제한

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

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

IP 보호 (이전 명칭: Gnatcatcher)

의견 테마	요약	Chrome 응답
Android	Android에 IP 보호를 출시할 계획은 무엇인가요?	Google은 IP 보호를 비롯한 Android의 은밀한 추적 방지 기능을 모색하고 있지만 현재로서는 공유할 공식 계획이 없습니다.
API 사용량	IP 보호에 대한 사기 방지 예외가 있는지 또는 적용 예정인지에 관한 질문	Google은 IP 주소를 기반으로 웹에서 사용자를 추적하지 않도록 보호하는 동시에 악용 방지를 위해 IP 주소를 사용하는 등 서버의 정상적인 운영 중단을 최소화하는 것 사이에서 균형을 유지하기 위해 노력하고 있습니다. 현재로서는 자세한 내용을 제공해 드릴 수 없지만 가까운 시일 내에 제공할 예정이오니 계속해서 논의를 이어가시기 바랍니다.
악의적인 행위자 식별	악의적인 IP 주소에 대한 기존 보안 조치의 효과에 대한 우려	IP 보호는 퍼스트 파티 요청을 프록시하지 않으므로 대부분의 침입 감지 시스템은 영향을 받지 않을 것으로 예상됩니다. 향후 시크릿 모드 사용자의 사기 방지 및 사이트 중단 문제를 해결하기 위한 추가 세부정보를 제공할 계획입니다.
IP 주소 마스킹	뉴스 게시자 사이트 (퍼스트 파티)가 광고 사이트 (서드 파티)와 동일한 도메인을 사용하는 경우 두 사이트 모두에서 IP 주소가 마스킹되나요? 그렇지 않다면 두 가지를 어떻게 구분하나요?	IP 보호는 현재 어떤 서드 파티 트래픽이 프록시를 통과하는지 식별하기 위해 목록 기반 접근 방식을 제안합니다. 그러나 출처가 이 목록에 포함되어 있더라도 퍼스트 파티 컨텍스트에서 액세스하면 프록시되지 않습니다. Google에서는 초기에 우선순위가 부여될 구체적인 서드 파티 도메인과 IP 보호를 위한 퍼스트 파티 및 서드 파티 컨텍스트를 정확하게 정의하는 방법에 관한 세부정보를 마무리하고 있습니다.
IP 주소 마스킹	IP 보호 및 사기 방지 시스템에 미치는 영향에 대한 우려	퍼스트 파티는 Google의 IP 보호 계획의 영향을 받지 않으므로 포럼과 같은 사이트는 분쟁 해결을 위해 IP 주소에 액세스할 수 있어야 합니다. 향후 광고 사기 문제를 해결하기 위한 추가 세부정보를 제공할 예정입니다.
IP 주소 마스킹	영향을 받는 도메인의 헤더에서 IP가 마스킹되나요?	사용자의 현재 위치를 나타내는 사전 프록시 IP 주소를 기반으로 사용자가 지역별로 할당됩니다. 자세한 내용은 여기를 참조하세요.

이탈 추적 감소

의견 주제	요약	Chrome 응답
API 사양	탭이 닫힐 때 Chrome에서 확장된 탐색을 처리하는 동작에 관한 설명이 필요합니다.	여기에서 이 문제를 해결하고 사양을 업데이트했습니다.
Nav Tracking	교차 사이트 요청의 엔트로피를 줄이기 위해 유한한 링크 세트를 포함하는 추적 완화 접근 방식을 설명합니다.	YouTube는 여기에서 다른 브라우저 공급업체와 이 주제에 대해 계속 논의하고 있으며, 생태계에서 이 문제에 관한 추가 의견과 구체적인 제안을 기다리고 있습니다.

개인 정보 보호 예산

GitHub 설명 및 개발자 사이트에 설명된 대로 개인 정보 보호 예산은 더 이상 개인 정보 보호 샌드박스 제안서의 일부로 적극적으로 고려되지 않고 있습니다.

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

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

의견 주제	요약	Chrome 응답
(이전 분기에도 보고됨) 관련 웹사이트 세트 (RWS) 도메인 한도	RWS 내 연결된 도메인의 한도 상향 요청	YouTube의 대답은 이전 분기와 비슷합니다. 현재로서는 숫자 제한을 늘릴 계획이 없습니다. 이 한도는 사용자 개인 정보 보호 고려사항, W3C의 생태계 이해관계자 의견, 다른 브라우저의 유사한 구현 고려사항을 바탕으로 설정되었습니다. 자세한 내용은 블로그 게시물 (1, 2)을 참고하세요. 숫자 제한을 초과하는 교차 사이트 쿠키 액세스가 필요한 사용 사례를 검토하고 ID 사용 사례, 인증된 삽입, 광고 사용 사례에 관한 안내를 활용하는 것이 좋습니다. 사용자 세션이 로그인 작업에 연결된 경우 제휴 사용자 인증 정보 관리 (FedCM) API를 사용하여 기능을 유지하는 것이 좋습니다. 여기에서 필요할 수 있는 다른 사용 사례에 관한 의견을 보내주시기 바랍니다.
교차 사이트 쿠키 처리	하위 도메인에서 설정된 크로스 사이트 쿠키가 기본 도메인의 후속 요청에서 전달되지 않습니다. 올바른 CORS 및 사용자 인증 정보 구성을 사용해도 문제가 지속됩니다.	후속 가져오기 요청에서 교차 사이트 쿠키를 전송하려면 전체 출처 (예: 하위 도메인 포함)를 지정해야 하는 requestStorageAccessFor API의 올바른 사용에 관한 안내는 여기에서 확인하실 수 있습니다.
사용자 선택	사용자 선택이 출시된 후 RWS에서 사용하는 requestStorageAccessFor에 관한 추가 정보, 특히 현재 서드 파티 앱에 대한 액세스를 허용하는 암시적 또는 명시적 사용자 동작이 새 시스템에서 어떻게 작동하는지에 관한 추가 정보 요청	사용자 선택 모드(즉, 사용자가 서드 파티 쿠키를 유지하거나 제한하도록 선택했는지와 관계없음)에서 RWS의 동작은 서드 파티 쿠키가 허용된 Chrome의 기존/출고 동작과 일치하거나 RWS가 사용 설정된 상태에서 서드 파티 쿠키가 차단된 Chrome의 동작과 일치할 것으로 예상됩니다 ('관련 사이트에서 내 그룹 활동을 볼 수 있도록 허용' 설정). requestStorageAccess를 호출하기 전에 먼저 hasStorageAccess를 호출하여 삽입된 콘텐츠가 이미 파티션되지 않은 교차 사이트 쿠키에 액세스할 수 있는지 확인하는 것이 좋습니다. 사용자가 서드 파티 쿠키를 허용하도록 선택한 경우 hasStorageAccess 메서드가 true를 반환합니다. 서드 파티가 허용되는 경우 requestStorageAccessFor에서 현재 사용자 동작이 필요하지 않습니다. 이 경우 올바른 동작이 무엇인지 논의하고 명시하기 위해 새로운 GitHub 문제를 공개했으며, 생태계의 추가 의견을 기다리고 있습니다.
API 사용량	'상업적' 목적으로 RWS를 사용하는 것에 관한 명확성이 부족하여 채택이 지연되고 있다는 우려가 있습니다. 이해관계자는 타겟팅 광고를 위해 게시물을 그룹화하는 데 관심을 보였습니다.	RWS의 의도된 용도는 핵심 사이트 기능과 핵심 사용자 여정을 지원하는 것입니다. 타겟팅 광고와 관련된 사용 사례에는 Google의 전용 광고 API를 사용하는 것이 좋습니다.
API 사용량	localStorage 데이터는 설정할 수 있지만 쿠키는 설정할 수 없는 requestStorageAccess 관련 문제 신고	SameSite 속성의 오타로 인해 이 문제가 발생했습니다. 맞춤법이 올바른지 확인하고 3PC의 경우 명시적으로 None으로 설정합니다.
API 사양	'contact' 필드의 잘못된 배치, 일관성을 보장하기 위한 'oneOf' 키워드 사용을 비롯한 개선 제안 등 저장소 전반의 JSON 스키마 불일치	Google은 이 의견을 조사하고 있으며 가까운 시일 내에 스키마를 개선할 수 있는 방안을 모색할 예정입니다. 여기에서 추가 의견을 보내주세요.
RWS에 대한 서드 파티 (3P) 액세스	사용자의 동의를 얻은 후 아울렛이 RWS API 데이터에 액세스할 수 있는 서드 파티 도메인도 표시할 수 있도록 허용합니다.	서드 파티가 자체 파티션되지 않은 데이터를 RWS 사이트 데이터와 결합하도록 허용하면 개인 정보 보호 샌드박스의 크로스 사이트 추적 보호 기능이 손상됩니다. 그러나 Google은 서드 파티가 RWS로 파티션 분할된 데이터를 유지할 수 있는 가능성을 고려하고 있으며, 여기에서 이러한 솔루션의 설계 관련 의견을 수렴하고 있습니다.

Fenced Frames API

의견 테마	요약	Chrome 응답
API 질문	네트워크 액세스 권한이 없는 펜싱된 프레임이 광고주의 브랜드 안전성과 사기 방지 기능을 어떻게 손상시킬 수 있는지에 대한 우려	YouTube는 펜싱 프레임을 시행하기 위한 계획의 일환으로 이 문제를 추적하고 있습니다. YouTube는 곧 펜스 프레임 시정 조치와 호환되는 솔루션을 모색할 예정이며, 충분히 유의미한 제안이 있으면 공유할 예정입니다.
API 질문	Fenced Frames API는 여전히 2026년으로 예정되어 있나요?	공지사항에 명시된 바와 같이 2026년 이전에는 펜싱된 프레임이 필요하지 않습니다.
API 버그	reportEvent()가 교차 출처 하위 프레임에서 클릭 데이터를 전송하면 setReportEventDataForAutomaticBeacons()가 최상위 프레임의 데이터를 덮어쓰지 않습니다.	이 문제를 논의 중이며 여기에서 추가 의견을 보내주세요.

Shared Storage API

의견 테마	요약	Chrome 응답
앱 광고	Android의 개인 정보 보호 샌드박스에는 Shared Storage API에 상응하는 API가 없습니다.	Google에서는 사용 사례 요구사항 및 플랫폼 제약 조건에 따라 Android를 기반으로 솔루션을 평가하고 있습니다. 현재로서는 공유할 계획이 없지만 이 문제에 관한 생태계의 추가 의견을 기다립니다.
API 사용량	Shared Storage API 구현을 위해 JavaScript 워크렛을 추가로 사용해야 하는지에 대한 혼란이 있습니다.	Google에서는 이 의견을 조사하고 Share Storage API에 추가 워크렛 스크립트가 필요한 이유를 설명하는 문서를 업데이트할 수 있는지 검토하고 있습니다.
불안정	Shared Storage API는 개인 정보 보호 비판에 따라 크게 변경되거나 중단될 수 있으므로 신뢰할 수 없는 기반이 됩니다.	공유 저장소 인프라를 크게 변경하거나 중단할 계획은 없습니다. 발표된 주요 변경사항은 펜싱된 프레임이 필요하고 이벤트 수준 보고가 지원 중단되는 Select URL 출력 게이트입니다. 하지만 이 변경사항은 2026년 이후에 적용될 예정입니다.

CHIPS

의견 주제	요약	Chrome 응답
파티션된 쿠키	Chrome은 Firefox와 달리 프레임 조상 기준으로 파티션 키를 구분하지 않으므로 불일치가 발생합니다.	Chrome은 '상위 체인 비트'를 채택하여 Firefox 동작과의 보안 문제와 불일치를 해결했습니다. 자세한 내용은 여기에서 확인하세요.
파티션된 쿠키	저장용량 액세스 수준이 다른 삽입된 iframe은 동일한 파티션을 나눈 쿠키를 공유하고 덮어쓰기 때문에 인증 상태에 불일치가 발생합니다.	이 특정 구성의 경우 Storage Access API 호출과 함께 파티션되지 않은 쿠키를 사용하는 것이 좋습니다. 자세한 내용은 여기에서 확인하세요.
파티션된 쿠키	3PC가 사용 중지되면 파티션된 쿠키 저장소가 삭제되나요? 이 동작을 테스트할 방법이 있나요?	현재로서는 알려드릴 내용이 없습니다. 그러나 개발자는 Chrome DevTools Application>Cookies 패널을 통해 파티션된 쿠키를 수동으로 삭제하여 이 기능을 테스트할 수 있습니다.

FedCM

의견 주제	요약	Chrome 응답
ID 공급업체 (IdP) 등록 범위 및 조직 선택 도구	현재의 동일 출처 정책에서 동일 사이트 정책으로 IdP 등록을 확장하는 방법에 관한 질문 이 변경사항을 통해 더 광범위하고 유연한 ID 관리가 가능해집니다. 예를 들어 대학의 시작 페이지에서 별도의 출처별 등록 없이 여러 하위 도메인 기반 ID 공급자를 등록할 수 있습니다. 디버그 가능성 개선, 자동 미디에이션을 위해 승인된 클라이언트 처리, 쿠키 동작 명시, 팝업 문구 맞춤설정 허용, 시간 초과 문제 해결에 대한 의견	Google은 이 의견을 수렴하고 조직 선택 도구를 FedCM에 통합하는 방법을 고려하고 있습니다. YouTube는 이 접근 방식을 지속적으로 개선해 나가면서 생태계의 추가 의견을 기다리고 있습니다. 여기에서 의견을 보내주세요.
IdP 쿠키	기기 결합 세션 사용자 인증 정보 (DBSC) 제안서의 일부로 수명이 짧은 세션 쿠키를 구현하는 것이 미치는 영향에 관한 토론 만료된 IdP 쿠키를 갱신하기 위해 사용자에게 표시되는 모달이 필요한 FedCM의 사용자 환경에 대한 우려가 제기되었습니다.	제안된 DBSC는 사용자 상호작용 없이 쿠키를 갱신할 수 있어야 하며, 이를 통해 지속적인 사용자 경험을 보장해야 합니다. 이 문제에 대한 자세한 내용은 여기를 참고하세요.
API 사양	'providers' 배열의 크기가 1이 아닌 경우 FedCM API 사양에서 'NetworkError'를 사용하는 것이 적절한지에 관한 질문	Google은 'TypeError'가 네트워크 문제보다는 코딩 오류를 반영하기 때문에 이러한 상황에 더 적합하다는 데 동의합니다. YouTube는 다중 IdP 지원을 진행하면서 향후 업데이트에서 이 변경사항을 고려하고 이 제한을 삭제할 가능성을 모색할 예정입니다. 여기에서 추가적인 의견을 보내주세요.

스팸 및 사기 퇴치

Private State Token API (및 기타 API)

의견 주제	요약	Chrome 응답
지원 중단 체험판 및 모드 B	지원 중단 체험판, 모드 B 테스트, Private State Tokens (PST)의 잠재적 지원 중단, 사기 방지 사용 사례에 더 적합한 새 API의 가능성에 대한 우려	지원 중단 체험판 및 모드 B 테스트는 변경되지 않습니다. 새로운 소식이 있으면 개발자 블로그를 통해 전달해 드리겠습니다. PST를 중단할 계획은 없으며 GitHub에서 지속적인 기능 개발 및 업데이트에 대해 논의하고 있습니다. 새로운 API는 발표하지 않았지만 PST에서 사기 방지 사용 사례를 더 효과적으로 처리하는 방법에 관한 의견을 보내주세요.
API 의견	사기 방지 사용 사례를 해결하기 위해 토큰을 취소하는 기능을 요청합니다.	발급기관은 사용하는 키를 변경하여 모든 토큰을 취소할 수 있지만 API를 사용하면 개별 토큰 취소를 실행할 수 없습니다. 발급기관이 토큰 발급과 사용을 연결하도록 허용해야 하므로 두 이벤트 간의 추적을 방지하는 PST 개인 정보 보호 모델이 위반됩니다.