의견 보고서 - 2024년 4분기

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

Google은 CMA에 대한 약속의 일환으로 개인 정보 보호 샌드박스 제안서의 이해관계자 참여 절차에 관한 분기별 보고서를 공개적으로 제공하기로 합의했습니다 (약속 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, PA API, Attribution Reporting API 및 기술과 관련된 질문과 의견이 접수되었습니다.

최근에 접수된 의견은 아직 Chrome에서 검토하지 않았을 수 있습니다.

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

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

의견 주제 요약 Chrome 응답
약정 서약서 G 섹션은 개인 정보 보호 샌드박스의 실행 가능성에 필수적입니다. Google의 자체 광고 비즈니스가 샌드박스 기술로만 운영된다는 보장이 없으므로 Google이 기술을 매각할 가능성과 함께 점점 줄어드는 유용성의 위험이 제기됩니다. 이러한 매각 또는 유용성 감소는 개방형 웹에서 개인 정보 보호 중심의 주소 지정 가능성에 대한 실존적 위협이 될 것입니다. Google의 자체 광고 비즈니스가 개인 정보 보호 샌드박스 기술을 전적으로 사용하는 것은 아닙니다. Google은 서드 파티가 사용하고 있는 것과 동일한 방식으로 개인 정보 보호 샌드박스 기술을 포함한 주소 지정 가능성에 대한 포트폴리오 접근 방식을 사용할 계획입니다. Google은 광고 생태계 전반에서 포트폴리오 접근 방식이 일반적이라고 생각합니다.

Google은 개발자가 개인 정보 보호 도구와 기술을 사용하는 것이 중요하다고 생각합니다. Google은 계속해서 개인 정보 보호 샌드박스 API를 제공하고 개인 정보 보호와 유용성을 더욱 개선하기 위해 투자할 것입니다.
거버넌스 제안된 거버넌스 모델에는 공식 컨설트 또는 이의신청 절차에서 책임성을 위한 구체적인 메커니즘이 포함되어 있지 않습니다. 오답입니다. (i) 의사결정 시스템 및 관련 게시물과 (ii) 이의신청 절차 모두 책임성을 위한 구체적인 메커니즘을 제공합니다. 또한 모니터링 수탁자가 그 기능을 세부적으로 감독합니다.
거버넌스 모델에 교차 플랫폼 표준의 생성 및 유지관리에 관한 조항이 포함되어 있지 않다는 의견 어떤 거버넌스 모델도 다른 행위자(이 경우 브라우저)가 표준을 채택하도록 강요할 수 없습니다. 따라서 Google은 표준을 크로스 플랫폼으로 채택해야 하는 모델을 제안하지 않았습니다. Google은 제안서를 작성하고 제안서 구현 경험을 공유하는 것이 일반적인 활동인 표준 포럼에 계속 참여할 예정입니다.
거버넌스 컨설트 기간을 2개월 이상으로 연장하는 것이 좋습니다. 제안된 거버넌스 모델은 제안된 변경사항의 영향을 분석할 수 있는 충분한 시간을 생태계에 제공하지 않습니다. 3주 기간은 특정 변경사항에 대한 전체 의견 기간이 아닙니다. 기존의 의견 주기 (훨씬 더 긴 기간)가 계속되기 때문입니다. 대신 컨설트 절차는 전략적 결정을 위한 기존 절차 내에 새로운 공식적인 의견 제출 기간을 제공합니다. 따라서 서드 파티는 기능 개발 과정에서 GitHub, W3C, IAB Tech Lab과 같은 광고 표준 기관을 비롯한 다양한 포럼을 통해 계속해서 의견을 제공할 수 있습니다. 이러한 방식으로 의견을 수렴하면 생태계는 개발 프로세스를 크게 지연시키지 않고 제안된 변경사항에 대한 의견을 분석하고 공유할 수 있습니다.
거버넌스 향후 거버넌스 계획에 관한 세부정보 요청 제안된 거버넌스 모델의 요약은 CMA의 2024년 2분기/3분기 보고서 (여기의 3~5페이지)에 설명되어 있습니다.
예외 요청 동의한 사용자의 서드 파티 쿠키 (3PC)에 액세스하기 위한 예외를 요청합니다. 특정 데이터 처리 목적으로 기기 액세스 및 저장에 동의한다고 해서 사용자가 Chrome에서 3PC 설정을 재정의하려는 것은 아닙니다. 사용자의 3PC 설정을 사이트 수준에서 재정의할 수 있게 허용하면 오용될 가능성이 상당히 높아지며, Chrome에서 예외 요청으로 이어질 수 있는 모든 사이트의 동작을 감사하는 것은 불가능합니다.
개인 정보 보호 샌드박스 개인 정보 보호 샌드박스 API 선택률 요청 YouTube는 이 정보를 생태계와 공유할 계획이 없습니다. 개발자는 현재 코드가 배포된 위치에서 API를 호출하여 개인 정보 보호 샌드박스 API의 가용성을 추정할 수 있습니다.
Origin 트라이얼 오리진 트라이얼을 연장할 계획이 있나요? 오리진 트라이얼이 2025년 4월 14일까지 연장되었습니다.
개인 정보 보호 샌드박스 비즈니스 가치를 강조하고 임원진의 승인을 얻을 수 있는 기술적이지 않은 간결한 개인 정보 보호 샌드박스 설명을 요청하세요. 최근에 privacysandbox.com(여기)에 이 정보를 제공하는 비즈니스 리소스 섹션이 추가되었습니다.
모드 B 브라우저가 '모드 B'인 경우 현재 쿠키 저장소 (1PC, 3PC, 로컬 저장소)는 유지되나요, 지워지나요? 현재 쿠키 저장소는 삭제되지 않습니다. 3PC는 퍼스트 파티 컨텍스트에서 계속 액세스할 수 있습니다.
Chrome의 3PC에 대한 접근 방식이 업데이트됨 향후 Chrome에서 3PC가 완전히 삭제되나요? Google은 사용자 선택을 우선시하는 업데이트된 접근 방식을 제안하고 있습니다. 여기에 설명된 대로 Google은 서드 파티 쿠키를 지원 중단하는 대신 Chrome에 새로운 환경을 도입하여 사용자가 웹 탐색 전반에 적용되는 정보에 입각한 선택을 할 수 있도록 하고 언제든지 선택사항을 조정할 수 있도록 할 것입니다. Google은 이 새로운 방향을 규제 기관과 논의하고 있으며, 출시하기 전에 업계와도 협력할 예정입니다.
Chrome 테스트 Chrome을 통한 테스트 라벨을 계속 사용할 수 있도록 요청합니다. 개인 정보 보호 샌드박스팀은 기업에서 쿠키 지원 중단 라벨을 계속 사용하고자 하는 점을 잘 알고 있습니다. 라벨의 사용 가능 여부를 연장하는 프로세스는 출처 체험판 연장과 유사합니다. 이 과정에서 실험은 한 번에 세 개의 Chrome 마일스톤으로만 연장될 수 있습니다. 예를 들어 쿠키 지원 중단 라벨에 대한 Chrome의 최근 실험 연장 의도 (I2EE)는 Chrome M130~M132까지 연장되었습니다. 이렇게 하면 2월 초의 M133 안정화 버전 출시까지 라벨을 지원할 수 있습니다. 추가 확장 프로그램도 동일한 프로세스를 거치므로 blink-dev 이메일 그룹에서 업데이트를 확인하는 것이 좋습니다.

등록 및 증명

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

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

주제

의견 주제 요약 Chrome 응답
사양 분류 모델이 Android (앱 이름 기준)와 Chrome (호스트 이름 기준) 간에 공유되나요? 아니요. 분류가 다르므로 별도의 모델입니다.
주제 분류의 세분성 주제는 너무 일반적이어서 퍼스트 파티 정보를 활용할 때 유용하지 않습니다. 주제 분류는 유용성과 개인 정보 보호의 균형을 유지하는 것을 목표로 합니다. Google은 주제를 더 구체화할 수 있는 메커니즘을 평가했지만, 보안 및 개인 정보 보호 고려사항을 비롯한 여러 가지 우려사항으로 인해 궁극적으로 이를 하지 않기로 결정했습니다.

광고 기술은 머신러닝, 개인 정보 보호 API의 개인 정보 보호 신호와 같은 사용 가능한 모든 도구를 문맥 데이터, 광고 소재 데이터, 퍼스트 파티 데이터와 함께 결합하여 최상의 결과를 얻을 수 있습니다. 자세한 내용은 여기를 참고하세요.
API 사용량 Topics API의 적용 범위가 좁습니다. 노출 범위가 낮은 일반적인 이유는 다음과 같습니다.
- 사용자 제어/선택 해제
- 게시자 제어/선택 해제
- 사이트 자격요건 (안전하지 않은 사이트, WebView, iOS용 Chrome, 시크릿 모드 등은 주제와 일치하도록 승인되지 않음)
- 사용자 제한사항 (18세 미만이거나 시크릿 모드를 사용하는 Chrome 사용자는 관찰 및 주제 할당이 불가능함)
- 판매자 관찰 요구사항 (호출자가 자격요건을 충족하는 주제와 관련된 사이트에서 이전에 사용자를 본 적이 있어야 함)
- 구현 최근성 (호출자 관찰을 확장하는 데 약 4주가 소요됨)
API 사용량 Topics API 사용에 관한 정보 요청: Networking 탭에 전송되고 포착된 호출이 있는 것처럼 보이지만 chrome://topics-internals/ 에는 관찰자가 기록되지 않았습니다. HTTP 헤더 메커니즘을 사용하여 Topics API와 상호작용하는 경우 주제는 Sec-Browsing-Topics 요청 헤더로 전송되지만 서버가 Observe-Browsing-Topics: ?1 응답 헤더로 응답하는 경우에만 관찰됩니다. 자세한 내용은 여기를 참고하세요.
Chromium 참여도 데스크톱의 경우 Chrome은 Chromium을 기반으로 하는 다른 브라우저와 동일한 관찰 및 순위 맥락을 공유하나요?

모바일의 경우 Android Chrome은 Chromium / 인앱 Chromium을 기반으로 하는 다른 Android 브라우저와 동일한 관찰 및 순위 컨텍스트를 공유하나요?
Chrome은 기기의 다른 브라우저와 주제 데이터를 공유하지 않습니다.
사양 Topics API는 사용자의 페이지 조회가 '주제 기록 항목'으로 간주되는지 어떻게 결정하나요? 주간 주제 계산을 사용하려면 페이지 방문에 '관찰' 호출이 있어야 합니다 (어떤 호출자로부터든 호출 가능). '관찰' 호출이 없으면 방문이 주제 기록에 고려되지 않습니다.
보안 Topics API는 한 호출자가 다른 호출자의 관찰 주제를 가져오는 것을 어떻게 방지하나요? 여기에서 설명을 확인하세요.
분류 Topics API 내의 트리 구조 분류는 각 에포크의 관찰에 어떻게 사용되나요? 상위 5개 주제를 계산할 때는 분류자가 제공한 원래 주제만 고려되며 순위는 (i) 페이지 방문 빈도 및 (ii) 우선순위 점수 (사양 참고)에 따라 결정됩니다.

각 인기 주제 5개에 대해 호출자가 관찰한 횟수를 계산할 때는 기본 주제 또는 그 하위 주제를 관찰한 호출자가 포함됩니다.
사양 응답의 5% 무작위 노이즈에 관한 추가 정보 요청 각 에포크에는 항상 5개의 인기 주제가 있습니다. 방문 기록에 5개 주제가 포함되지 않은 경우 5개가 될 때까지 주제가 무작위로 선택됩니다. 이러한 주제를 패딩된 주제라고 합니다. 호출자는 지난 몇 주 동안 주제가 있는 사이트에서 사용자를 관찰 (API를 호출)하지 않는 한 이러한 무작위로 채워진 주제 중 하나를 수신하지 않습니다.

API가 호출되면 사용자별, 사이트별, 시대별 해시가 계산됩니다. 이 해시가 노이즈 주제를 반환할 확률보다 낮으면 사용자별, 사이트별, 에포크별 무작위 주제가 반환되도록 선택됩니다. 그러나 호출자가 해당 사용자/사이트/에포크에 대해 노이즈가 제거된 상응하는 주제를 관찰한 경우에만 노이즈가 제거되지 않은 주제가 반환됩니다 (예: 필터링되지 않음)(설명 참고). 이 필터링을 사용하면 관찰 기능과 관계없이 지정된 호출자의 5% 의 경우 노이즈가 있는 주제가 반환됩니다.
사양 교차 주 중복 주제는 어떻게 작동하나요? API가 주 중에서 독립적으로 선택한 후 병합하나요? 각 주 (에포크)의 주제는 독립적으로 계산됩니다. 각 에포크에서 반환되도록 선택된 특정 주제는 호출자가 있는 사이트에 따라 다릅니다.

주제가 특정 호출자의 여러 에포크에서 반복될 수 있다는 점을 고려하지 않으므로 다른 주제를 선택하는 것이 좋습니다. 이 문제에 관한 추가 의견은 여기에서 보내주세요.

Protected Audience API

의견 주제 요약 Chrome 응답
A/B 테스팅 여기에 설명된 공유 저장소 솔루션은 지연 시간을 추가하고 오류율이 높습니다 (즉, 상당한 비율의 트래픽이 인구통계 ID 없이 종료됨). 엔트로피가 낮은 ID (예: 3비트)만으로도 개인 정보 보호에 큰 영향을 미치지 않으면서 효과적인 A/B 테스트를 진행할 수 있습니다. 공유 저장소 솔루션은 여전히 실행 가능한 접근 방식이라고 생각하지만 이 요청을 고려하고 있으며 이 기능이 우선순위가 높은 경우 생태계의 추가 의견을 환영합니다.
보고 reportWin()에서 비트를 추가로 요청합니다. 특히 PA API의 새로운 클릭 및 디스플레이 보고가 6~8비트를 사용하고 다른 PA API 보고에 사용할 수 있는 나머지 비트가 효과적으로 줄어들 것으로 예상되기 때문입니다. Google은 더 이상 개인 정보 보호 문제로 인해 modelingSignals 비트를 현재 12비트 이상으로 늘리는 것을 고려하지 않습니다.

Google은 개인 정보 보호 샌드박스에서 비트 제한 없이 안전한 환경에서 ML 학습 니즈를 지원하는 것을 목표로 하는 비공개 모델 학습 제안에 대해 생태계의 의견을 요청합니다.
관심분야 그룹 관심분야 그룹 (IG)의 수명 주기를 30일로 요청하는 것은 충분하지 않습니다. 블로그 게시물에서 언급한 바와 같이, YouTube는 IG의 수명을 90일로 연장할 계획이며 여기에서 설명을 제공하고 있습니다.

현재 구현 작업을 진행 중이며 출시 일정이 확정되는 대로 공유해 드리겠습니다.
관심분야 그룹 IG 위임을 위한 동적 업데이트 요청 YouTube는 여러 이해관계자의 요청을 인지하고 있으며 해결책을 모색하고 있습니다.

Google은 개발이 진행되는 대로 GitHub에서 업데이트를 공유하고 생태계의 추가 의견을 기다립니다.
기기 내 기기 내 PA API 솔루션에 계속 투자할 수 있도록 생태계에 더 많은 가치를 제공합니다. 개인 정보 보호 샌드박스팀은 개발자에게 브라우저에서 더 많은 개인 정보 보호 옵션을 제공하기 위해 PA API를 비롯한 개인 정보 보호 강화 기술 (PET) 기반 API를 계속 개발하고 있습니다. 이러한 기술은 이제 일부 개발자가 오해한 것처럼 1% 가 아니라 Chrome 브라우저 전반에서 대규모로 사용할 수 있습니다. 사용자가 3PC를 사용 설정했는지 여부와 관계없이 개발자는 많은 기업이 브라우저 외부에서 다른 PET 기반 솔루션을 채택하는 것처럼 제품에 PET 기반 솔루션을 통합할 수 있습니다. 많은 개발자는 사이트 전반에서 도달범위를 개선하기 위해 확정적인 퍼스트 파티 잠재고객 신호를 확장하여 기기 내 PA API 솔루션에 이미 투자하고 있습니다. 일부 개발자는 더 많은 서드 파티 쿠키가 사용 중지된 경우에만 개인 정보 보호 샌드박스 API 또는 기타 PET 기반 솔루션을 사용하도록 선택하며, 이러한 개발자는 서드 파티 쿠키를 유지할 브라우저 수를 추측할 수 있는 정보를 기다리고 있습니다. 이러한 개발자는 제품 결정을 내리기 위해 원하는 정보를 찾을 때까지 기다릴 것입니다.
관심분야 그룹 SSP가 IG 생성 및 관련 역할에 참여하도록 허용합니다. SSP는 이를 부가 가치의 중요한 부분으로 보고 있으며 게시자가 SSP를 통해 IG를 판매할 수 있도록 지원하고자 합니다. Google은 여러 이해관계자로부터 고급 IG 위임을 지원해 달라는 요청을 받았으며, SSP가 이 프로세스에 기여하는 부가 가치를 확인했습니다.

Google은 다양한 당사자가 잠재고객 확장 프로세스에 참여할 수 있는 최적의 솔루션을 찾기 위해 연구하고 있습니다. 개발이 진행되는 동안 GitHub에서 업데이트를 공유하고 생태계의 추가 의견을 기다리겠습니다.
보고 forDebuggingOnly와 Private Aggregation API 간에 '0이 아닌 입찰가' 보고 수가 일치하지 않습니다. 두 가지 이유로 불일치가 발생할 것으로 예상됩니다.

첫째, Private Aggregation API 디버그 모드는 기기에서 3PC가 허용된 경우에만 사용할 수 있지만 forDebuggingOnly API는 항상 샘플링되지 않은 상태로 사용할 수 있습니다 (이러한 마지막 동작은 여기에 자세히 설명된 대로 결국 변경될 예정).

둘째, 비공개 집계 API에는 기여도 한도가 있지만 forDebuggingOnly에는 없습니다.

그러나 이 의견에 따르면 예상치 못한 불일치를 일으키는 다른 요인이 있을 수 있으며, YouTube는 이 문제를 해결하기 위해 서드 파티 이해관계자와 협력하고 있습니다.
클릭 가능성 클릭 가능성 신호에 대한 업데이트된 제안서에 언급된 대로, 조건을 충족하는 'attributionsrc' 속성에서 시작한 요청에 새 HTTP 응답 헤더를 반환하여 조회수와 클릭수가 등록되며, 이 응답 헤더에는 집계된 수치에 이러한 조회수와 클릭수를 포함할 수 있는 다른 당사자를 나타내는 데 사용할 수 있는 출처 목록이 포함됩니다. 광고 기술이 출처를 임의로 설정할 수 있다는 의미인가요? 집계된 조회수 및 클릭수에 조회수 또는 클릭 이벤트를 제공하는 광고 기술('제공 출처')은 응답 헤더에 선택적 매개변수를 포함할 수 있으며, 이를 통해 'Protected Audience 입찰에서 generateBid() 호출에 제공될 계산된 조회수 및 클릭수에 이 이벤트가 포함될 수 있는 IG 소유자 출처 1개 이상' ('요건을 충족하는 출처')을 지정할 수 있습니다. 이는 클릭 가능성 설명서에 명시되어 있습니다.

하지만 이러한 조회수와 클릭수는 조회수 및 클릭수 집계에 자동으로 포함되지 않습니다. 대신 각 광고 기술은 IG에서 조회 및 클릭 이벤트를 포함해야 하는 '제공 출처' 집합을 지정해야 하며, 이러한 제공 출처의 데이터만 해당 광고 기술의 generateBid() 호출에 표시되는 조회 및 클릭수에 기여합니다.

이 메커니즘은 양측의 동의가 필요하며 악의적인 플레이어가 다른 광고 기술의 조회수 및 클릭수에 영향을 미치는 것을 방지합니다. 또한 '제공' 광고 기술이 '요건을 충족하는 출처'를 임의로 설정해도 해당 요건을 충족하는 출처가 해당 제공 출처를 IG에 명시적으로 의도적으로 포함하지 않는 한 이러한 요건을 충족하는 출처의 조회수 및 클릭수에 영향을 미치지 않습니다.
비공개 모델 학습 DP-SGD (개인 정보 차등 보호 - 확률적 경사하강법)는 백프로프 중에 계산된 경사의 희소성을 파괴하므로 학습 프로세스가 상당히 느려질 수 있습니다. 이 문제를 해결하기 위해 고려 중인 기법이나 이 문제에 대한 의견이 있나요? Google은 DP-SGD에서 희소성을 보존하는 몇 가지 기법 (예: 이 기법)을 알고 있으며 비공개 모델 학습 인프라에서 이러한 종류의 기법을 지원하는 방법을 모색하고 있습니다.

상황이 진행되면 업데이트를 공유할 예정이며 여기에서 추가 의견을 보내주세요.
제외 타겟팅 여기에 설명된 IG 부정적 필터링 기능 출시에 관한 업데이트를 요청합니다. 여기에 명시된 답변에 따라 PA API 입찰에서 제외 IG를 지원할 계획입니다.

출시 일정이 확정되면 공유해 드리겠습니다. 여기에서 추가 의견을 보내주세요.
입찰 입찰 시 여러 IG를 결합할 수 있나요? 현재 PA API로는 불가능합니다. PA API는 IG가 단일 사이트에서 사용자에 관해 알고 있는 정보와 관련이 있다는 설계를 기반으로 하며, 이는 전반적인 생태계와의 논의에서 핵심이 되어 왔습니다. 이 접근 방식을 사용하면 광고 기술이 광고주가 웹 전반에서 퍼스트 파티 잠재고객을 확장하는 데 도움이 되는 다양한 솔루션을 구축할 수 있습니다.

Microsoft의 Ads Selection API 제안서에서는 잠재고객이 여러 사이트의 정보를 기반으로 하는 다른 디자인을 제안하고 있습니다.

Google은 YouTube의 접근 방식을 계속 모니터링할 예정이지만, Chrome에서 이와 유사한 변경사항을 고려하기 전에 개인 정보 보호 커뮤니티를 비롯한 생태계에서 더 많은 논의를 거칠 수 있기를 바랍니다.
네이티브 광고 PA API가 네이티브 광고의 다양한 형식과 렌더링 요구사항을 적절하게 지원할 수 있는지, PA API가 효과적인 네이티브 광고에 필요한 광고 소재 유연성과 최적화를 허용하는지에 관한 우려사항 Google은 네이티브 광고를 추가로 지원하기 위해 적극적으로 연구하고 있으며 생태계의 추가 의견을 환영합니다.
보고 입찰 스크립트와 리소스를 경쟁하고 실행 중인 입찰 프레임에서 벗어나면 손실될 수 있는 보고 스크립트의 견고성을 개선해 달라는 요청입니다. 곧 GitHub에 답변을 게시할 예정이지만, 이러한 우려사항이 실제로 유효한 보고에 큰 영향을 미치지는 않을 것으로 예상됩니다.
매크로 대체 입찰 구성에서 전달된 매크로 대체가 일부 서드 파티 구성에서 작동하지 않음 근본 원인은 일부 모드 A/B 라벨이 지정된 트래픽에 이 기능이 사용 설정되어 있지 않았기 때문입니다. 최근 YouTube에서는 모든 모드 A/B 라벨이 지정된 트래픽에서 이 기능과 동일한 상황에 적용되는 다른 기능을 사용 설정하기 시작했습니다. 2025년 1분기에 이 변경사항이 적용될 예정입니다.
여기에서 추가 의견을 보내주세요.
문서 generateBid() 내 browserSignals 객체의 최근 값 측정 단위에 관한 문서에 불일치가 있는 것으로 보이므로 설명을 요청합니다. 이에 대해 여기에서 자세히 설명하고 문서를 업데이트했습니다. 정답은 측정 단위가 밀리초입니다.
보고 서드 파티 보고 요청: DSP 및 SSP는 Chrome에서 노출 알림을 수신하지만 중간 레이어 기술 제공업체는 기본적으로 수신하지 않습니다. 현재 여기에서 이 기능 요청에 대해 논의하고 있으며 추가 의견을 기다리고 있습니다.
관심분야 그룹 병렬 IG 입찰 워크플로를 사용할 때 interestGroupBuyers를 동적으로 제외하는 방법에 관한 안내를 요청합니다. 여기에서 관련 안내를 확인하실 수 있습니다.
네이티브 광고 특정 페이지 로드에 대한 독립적인 PA API 입찰은 동일 페이지 광고 필터링을 방지합니다. '네이티브'라고 알려진 맞춤 콘텐츠 위젯을 비롯하여 하나의 단위에 여러 광고가 있는 네이티브 광고를 추가로 지원하는 것은 현재 활발히 연구 중인 분야이며, 현재 설계로는 동일 페이지 광고 필터링을 지원하지 않을 수 있으며, 펜스 프레임과 같은 기타 보호 조치로 인해 이 기능이 더 이상 지원되지 않을 수도 있습니다.
네이티브 광고 URL 기반 신호를 사용하는 기존 PA API 기능(예: 광고 소재 스캔, 보고 등)은 네이티브 광고 소재에 사용되는 JSON 객체를 처리하도록 조정해야 할 수 있습니다. 네이티브 광고 지원을 확대하는 것은 현재 활발히 연구 중인 분야이며, 네이티브 광고 렌더링을 지원하도록 PA API를 조정하는 것이 가능한지 평가하고 있습니다.
광고 인증 PA API의 서드 파티 브랜드 안전성은 perBuyerSignals의 지연 시간 및 캐싱 제한으로 인해 영향을 받으며, 이는 동적 콘텐츠에 문제가 됩니다. Google은 SSP와 DSP가 캐시된 데이터가 브랜드 안전성과 관련성을 유지할 수 있도록 트래픽 형성 목표와 브랜드 안전성 최대 TTL의 균형을 맞추는 캐싱에 최적의 TTL을 결정해야 한다고 인식합니다. 이 문제를 조사 중이며 새로운 소식이 들어오면 전달해 드리겠습니다.
광고 인증 입찰 후 브랜드 안전성 측정을 수행하려면 SSP에서 FullpageURL 매크로를 대체해야 합니다. deprecatedReplaceInURN은 SSP가 이 신호를 제공하기 위한 현재 제안사항입니다.
광고 인증 입찰 후 확인에 SSP에서 사용하는 매크로 형식이 표준화되지 않으면 데이터 처리 및 분석에 불일치와 오류가 발생할 수 있습니다. SSP와 광고 검증자는 직접 협력하여 매크로 사용에 관한 명확한 가이드라인과 사양을 정의하여 SSP 전반에서 매크로 형식의 표준화를 추진하고 일관성을 보장하며 데이터 처리 및 분석 오류를 방지해야 합니다. 이는 IAB Tech Lab과 같은 광고 표준 조직에 적합한 활동입니다.
광고 인증 광고주와 광고 인증자는 디버깅 및 문제 해결을 위해 동일한 게시자 컨텍스트의 입찰 전 및 입찰 후 확인을 연결하는 메커니즘이 필요합니다. 입찰 후 확인을 위한 한 가지 옵션은 이벤트 수준 보고에 통합된 입찰 및 캠페인 기반 신호를 사용하는 것입니다. 이렇게 하면 입찰 전 결정 로그와 조인할 수 있습니다. YouTube는 이를 달성하기 위한 가능한 패턴을 모색하고 있으며, 진행 상황에 따라 업데이트를 공유할 예정입니다.
광고 인증 입찰 전의 신뢰할 수 있는 키-값 (TKV) 서버 솔루션 (DSP 소유 및 광고 검증자 소유)을 살펴보고 입찰 후의 펜싱된 프레임 제한을 해결하기 위한 요청입니다. Google은 이 요청을 평가하고 있으며, 여기에서 에코시스템의 추가 의견을 받아 사전 입찰 브랜드 안전성을 지원하고 당사자 간의 조정 요구사항을 완화할 수 있는 솔루션을 찾고자 합니다.
네이티브 광고 네이티브 광고에 대한 판매 측 입찰 후 렌더링 감사를 요청합니다. 네이티브 광고 지원을 확대하는 것은 현재 활발히 연구 중인 분야이며, 네이티브 광고 렌더링을 지원하기 위해 이와 같은 기존 기능을 조정하는 방안을 고려하고 있습니다.

Protected Auction (입찰 서비스)

의견 주제 요약 Chrome 응답
지연 시간 지연 시간을 적절하게 완화하지 못했습니다. B&A 서비스는 장기적으로 이 문제를 완화할 수 있지만, Google은 Chrome의 3PC를 변경하기 전에 B&A 서비스를 광범위하게 제공할 것을 약속하지는 않았습니다. 지난 몇 분기 동안 기기 내 지연 시간을 여러 번 개선했습니다. 또한 필요에 따라 B&A 서비스를 구축하고 확장하고 있습니다. 이러한 기능을 활용하는 방법에 관한 자세한 내용이 포함된 지연 시간 권장사항 가이드가 최근 업데이트되었습니다. 또한 새로운 지연 시간 개선사항을 지속적으로 개발하고 있으며, 그중 일부는 여기에서 확인할 수 있습니다.
(이전 분기에도 보고됨)

입찰 보안
기기 내 입찰 조작 시도를 방지/완화하기 위한 접근 방식에 관한 추가 설명 요청 (예: Google에서 이를 심각한 위험으로 간주하는지 여부 포함) Google의 답변은 이전 분기와 동일합니다.

"PA API 광고의 보고 메커니즘은 현재 사람과 봇 트래픽을 구분하는 데 사용되는 정보를 보관합니다. 또한 현재 도메인 기반의 도메인 포함 또는 제외 기법을 PA API에서 사용할 수 있습니다. 자세한 내용은 IAB Tech Lab의 개인 정보 보호 샌드박스 보고서에 대한 Google의 대응에서 확인하실 수 있습니다."
온프레미스 솔루션 비공개 클라우드 지원 부족으로 인해 대규모 공급업체가 개인 정보 보호 샌드박스 또는 B&A를 채택하지 않을 수 있다는 우려와 이를 지원하기 위한 길고 불투명한 로드맵 Google은 개인 정보 보호 샌드박스 서비스가 실행되는 인프라를 확장하기 위해 노력하고 있습니다. 최근 Azure 클라우드 지원을 발표했으며 비공개 클라우드에 유사한 개인 정보 보호 및 보안 보호 조치를 제공할 수 있는 솔루션을 계속해서 조사하고 있습니다.

10월에 공유드린 이후, 온프레미스 신뢰할 수 있는 실행 환경 (TEE)에서 Chrome 사용자의 개인 정보를 보호하기 위한 잠재적 접근 방식을 계속 연구하면서 진전을 이루었습니다. 이제 생태계 이해관계자와 함께 다양한 접근 방식을 검증할 단계에 이르렀으며, 1분기에 의견을 수집할 계획입니다. 생태계의 의견과 협업은 가능한 솔루션을 개선하는 데 도움이 됩니다.
테스트 PA API 보고 솔루션 (실시간 보고 및 비공개 집계)을 테스트하기 위해 TEE를 만들 수 있나요? 집계 서비스 테스트의 경우 광고 기술은 테스트 데이터와 로컬 테스트 도구를 사용하여 기능 테스트의 요약 보고서를 생성할 수 있습니다. 여기에서 로컬 테스트 Codelab을 참고하세요.

TEE에서 집계를 테스트하려면 광고 기술이 위의 Codelab 기본 요건에 언급된 대로 등록 프로세스를 완료해야 합니다.

이 요청에 관한 추가 의견이 있으시면 여기에서 보내주세요.
거래 K/V 통합 비즈니스 사용 사례를 위해 KV에서 거래 기반 정보를 가져올 수 있는 기능을 요청합니다. 이 기능 요청을 평가 중이며 GitHub에서 업데이트를 제공할 예정입니다.
불만족스러운
거래 측정항목
SSP가 낙찰되지 않은 시점과 이유를 파악할 수 있는 신호 또는 기능을 요청합니다. 이 요청을 평가 중이며 GitHub에서 업데이트를 제공할 예정입니다.
기능 요청 개인 정보 보호 샌드박스에 광고 그룹을 각 거래 ID 세트와 일치시키는 데 도움이 되는 사전 구조를 제공해 달라고 요청합니다. Google에서는 거래 ID 저장과 관련하여 IG 크기를 줄이는 다른 방법과 함께 이 요청을 평가하고 있습니다. GitHub에서 업데이트를 제공할 예정입니다.
성능 입찰 스크립트 크기로 인해 놓칠 수 있는 광고 입찰 기회를 측정하는 솔루션 이 요청을 평가하는 중이며 여기에서 추가 의견을 보내주세요.
사양 현재 B&A는 사양에서 prevWins를 대체한 최신 필드 prevWinMs 대신 prevWins 필드만 읽습니다. B&A가 prevWins의 밀리초 단위 지속 시간을 generatebid()에 전달하지 않는 것은 맞습니다. Chrome은 페이로드 오버헤드를 줄이기 위해 시간을 초 단위로 전송합니다. 여기서 해결 방법은 B&A에서 초를 밀리초로 변환하는 것입니다. B&A는 이를 기기 내 입찰과 호환되도록 browserSignals에 prevWins와 prevWinsMs를 모두 제공합니다.

참고로 웹의 기기 내 입찰에서도 prevWins와 prevWinsMs는 동일한 값에 해당하며 prevWinsMs = prevWins * 1000입니다.

YouTube에서 문제를 해결하는 데 최우선으로 노력하고 있습니다.
문서 판매자 프런트엔드 (SFE)를 테스트하는 방법에 관한 문서가 명확하지 않습니다. 배포가 완료된 직후 테스트 안내와 빌드에 Bazel을 사용하는 방법을 추가로 제공하면 도움이 될 것입니다. 이 Codelab은 더 광범위한 생태계에서 SFE를 더 쉽게 테스트할 수 있도록 가이드로 게시되었습니다.
배포 B&A용 사전 빌드된 바이너리를 제공할 계획이 있나요? B&A용 사전 빌드된 바이너리를 제공하는 것을 고려하고 있지만 구체적인 일정은 없습니다. 그때까지 광고 기술은 자체적으로 바이너리를 빌드하고 제공된 해시를 사용하여 유효성을 검사할 수 있습니다.
배포 모든 오케스트레이션 유형 (서버, 클라이언트, 혼합)을 지원해야 하나요? 아니면 다른 유형보다 우선순위를 두어야 하는 유형이 있나요? 광고 기술이 구현하는 모드에 관한 구체적인 권장사항은 없습니다. 선택은 다양한 요인에 따라 달라지지만 궁극적으로는 고객에게 가장 유리한 방법을 선택해야 합니다.
테스트 B&A 빌드 중에 실패한 테스트에 관한 설명을 요청합니다. 이는 불안정한 테스트로 인한 결과일 수 있습니다. Google은 광고 기술에 모든 build_and_test_all_in_docker 빌드 명령어에 --no-tests 플래그를 사용하여 테스트 실행을 건너뛰라고 안내했습니다.
로그 GCP의 로그 탐색기에서 테스트 모드일 때는 SFE를 실행하는 VM 인스턴스에 로그가 태그되지만 프로덕션 모드일 때는 로그가 VM 인스턴스에 태그되지 않는 이유를 명확히 설명해 주세요. 정확히 어떤 로그가 표시되었는지에 따라 다르므로 일반화하기는 어렵지만 일반적으로 다음과 같습니다.

- non_prod의 로그는 클라우드 제공업체 (이 경우 GCP)에서 리디렉션한 stderr 로그일 수 있으며 GCP에서 태그를 추가했습니다.

- VM에서 생성된 로그는 일반적으로 VM 인스턴스로 태그가 지정되지만 바이너리에서 생성된 로그는 GCP에서 태그가 지정되지 않습니다.

- 프로덕션의 로그는 TEE의 OpenTelemetry에 의해 내보내지며 태그가 다릅니다.

여기에는 non_prod 및 prod에서 사용할 수 있는 항목에 관한 세부정보가 나와 있습니다.
B&A OTEL 로깅이 사용 중지된 경우 보안 비밀 누락 시 403 오류가 발생함 이 문제는 4.1 업데이트에서 수정되었으며 문서가 이에 따라 수정되었습니다.
B&A GCP Terraform 구성의 outputs.tf 파일이 누락되어 오류가 발생함 이제 이 문제가 해결되었습니다.
테스트 테스트 모드에서 비공개 키를 가져올 때 오류가 발생합니다. 이 경우 서버가 TEST_MODE=true로 실행되고 있는지 확인하세요.

여기에서 설명을 참고하세요.
로드맵 getInterestGroupAdAuctionData가 두 개 이상의 판매자 출처를 허용하고 판매자 출처를 B&A 페이로드 암호문으로 매핑하는 계획이 있나요? 예. navigator.getInterestGroupAdAuctionData()가 여러 판매자를 허용하도록 지원을 추가할 계획입니다.
KV 사양 KV URL (trustedScoringSignalsURL)을 약속으로 전송할 수 있나요? 여기에서 설명을 참고하세요.
B&A 비공개 입찰이 실행되기 위해 클라이언트 (브라우저)에 필요한 기능을 입찰자 측에 알리기 위한 새 플랫폼 헤더 생성을 요청합니다. 현재 여기에서 이 기능 요청에 대해 논의하고 있으며 추가 의견을 기다리고 있습니다.
트래픽 형성 특히 DSP의 경우 B&A 서버 호스팅에서 발생하는 추가 비용을 줄이기 위한 제안서입니다. 현재 여기에서 이 제안서에 대해 논의하고 있으며 추가 의견을 환영합니다.
Bring-Your-
Own-Binary
모든 바이너리가 지원된다는 점을 명시적으로 설명하도록 설명 자료 업데이트를 고려해 보세요. 이제 업데이트되었습니다. 여기에서 설명을 확인하세요.
KV 호출 generateBid()는 모든 키-값 (KV) 저장소 호출이 완료될 때까지 기다리거나 독립적으로 실행되나요? KV 일괄 처리는 타이밍에 어떤 영향을 미치나요? 여기에서 설명을 참고하세요.
성능 입찰 스크립트 재사용 및 스크립트에 캐시 제어 헤더 설정 권장과 관련된 추가 문서를 요청합니다. 여기에 문서가 추가되었습니다.
성능 기기 내 입찰 지연 시간을 줄이기 위해 리소스 (예: 입찰 스크립트)를 비동기식으로 로드하는 기능을 고려하고 살펴보도록 요청합니다. 현재 여기에서 이 기능 요청에 대해 논의하고 있으며 추가 의견을 기다리고 있습니다.
동의 로깅 CONSENTED_DEBUG_TOKEN을 설정하여 동의 로깅을 사용하려고 할 때 표시되는 오류에 관한 설명이 필요합니다. 이 경우 CONSENTED_DEBUG_TOKEN이 보안 비밀 관리자에 있는지, ENABLE_OTEL_BASED_LOGGING이 true로 설정되어 있는지, TELEMETRY_CONFIG가 mode: PROD로 설정되어 있는지 확인합니다.

여기에 있는 설명서를 참고하세요. 이 설명서는 여기에 있는 소스를 참조합니다.
로그 forDebuggingOnly 이벤트를 B&A를 통해 사용할 수 있나요? 2024년 4월부터 단일 판매자 입찰에 B&A의 forDebuggingOnly가 제공되었습니다. 곧 복수 판매자 입찰에도 이 기능을 사용 설정할 계획입니다.
Worklet 로그 워크렛 로깅을 ChromeDriver와 호환되도록 요청합니다. 이 요청을 평가하는 중이며 여기에서 추가 의견을 보내주세요.

디지털 광고 측정

Attribution Reporting (및 기타 API)

의견 주제 요약 Chrome 응답
디버그 보고서 Chrome의 3PC에 대한 업데이트된 접근 방식에 따라 광고 기술은 ARA 디버그 보고서를 어떻게 사용할 수 있나요?

3PC를 유지하고 개인 정보 보호 샌드박스 API를 사용 설정한 사용자의 경우 광고 기술이 여전히 ARA 디버그 보고서에 액세스할 수 있어야 하나요?
광고 기술은 3PC와 ARA가 모두 사용 설정된 사용자와 관련하여 쿠키 기반 및 쿠키 없는 디버깅 솔루션에 액세스할 수 있습니다. 쿠키가 사용 중지된 경우 집계 디버그 솔루션에만 액세스할 수 있습니다.

디버그 솔루션에 관한 자세한 내용은 여기여기를 참고하세요.
기능 감지 서버 측에서 ARA의 기능 감지를 실행하는 방법에 관한 안내를 요청합니다. 현재 ARA 기능 지원은 사용자 에이전트 문자열에 표시된 Chrome 버전을 사용하여 식별할 수 있습니다.

이와 관련하여 추가 생태계 의견을 보내주세요.
기능 요청 ARA 집계 shared_info에 사용되는 source_registration_time이 더 세분화되도록 요청합니다 (예: 1일 대신 1시간 또는 1분으로 반올림). 또한 시간대를 고려하도록 구성할 수 있습니다 (현재 UTC만 해당). source_registration_time 필드를 가장 가까운 날짜로 반올림하는 것은 광고 기술이 특정 사용자를 특정 소스 등록에 연결할 수 있는 기능을 완화하는 데 사용되는 개인 정보 보호 메커니즘입니다. 현재 source_registration_time은 UTC를 기반으로 하며 광고 기술은 이를 고려하도록 광고 보고서를 조정할 수 있습니다.

이 요청과 관련하여 추가 생태계 의견이 있으면 여기에서 보내주세요.
사양 특히 배열 값과 함께 사용되는 경우 'trigger_data' 및 'priority'의 사양을 명확히 해 달라는 요청 이러한 필드는 배열 값을 허용하지 않습니다. 설명의 대괄호는 배열을 나타내는 것이 아니라 텍스트가 예시 값이 아니라 설명이 포함된 자리표시자임을 나타냅니다.

대괄호 안의 텍스트에서 알 수 있듯이

- trigger_data는 int-64입니다.
- priority는 signed int-64입니다.

두 필드 모두 배열 값을 허용하지 않습니다. 또한 ARA에 헤더 검사기 도구를 사용하여 다양한 값을 실험하고 문서가 혼란스러운 경우 오류가 발생하는지 확인하는 것도 좋습니다.
Accelerated Mobile Pages (AMP) 광고 지원 ARA에서 AMP 광고를 지원하나요? AMP를 지원하는 방법에 관한 Google의 제안은 여기에서 확인할 수 있으며 추가 의견도 환영합니다.
사양 ARA의 다층 삽입 광고에서 '소스 사이트'로 간주되는 URL은 무엇인가요? 최상위 사이트의 URL입니다.
(이전 분기에도 신고됨)

기능 요청
event_report_window 최솟값을 3,600초 (1시간)에서 1,800초 (30분)로 낮추도록 요청합니다. 최소 보고 기간을 결정하려면 유용성과 개인 정보 보호 고려사항 간의 균형을 유지해야 합니다.

개인 정보를 보호하고 특정 유형의 기록 재구성 공격을 완화하려면 이벤트 수준 보고서의 최소 보고 기간(1시간)이 필수적입니다.

이 요청에 관한 추가 의견이 있으시면 여기에서 보내주세요.
소음 데이터를 정확하게 해석하고 활용할 수 있도록 ARA 이벤트 수준 보고서에서 노이즈가 구현되는 방식을 자세히 알아봅니다. 자세한 내용은 여기여기를 참고하세요.
보고 집계 보고서 shared_info에 더 이상 기본적으로 source_registration_time이 포함되지 않습니다. 이는 API 변경사항으로 인한 것이며 여기에서 자세히 설명되어 있습니다.
보고 chrome://attribution-internals/ UI의 'Aggregatable Reports'(집계 가능한 보고서) 탭에 filtering_id가 없습니다. filtering_id는 현재 행을 클릭할 때 '트리거 등록' 탭 세부정보에 표시되므로 유효성을 확인할 수 있습니다. '집계 가능한 보고서' 탭에 표시하는 것이 유용하다는 점을 인식하고 여기에서 이 문제를 해결했습니다.
기여 분석 소스 기여 분석 소스의 작동 방식에 관한 설명 요청 여기에서 설명을 확인하세요.
앱-웹 기여 분석 소스가 OS인지 웹인지 확실하지 않은 구현에 관한 안내를 요청합니다. 여기에서 안내를 확인하세요.

Aggregation Service

의견 주제 요약 Chrome 응답
기능 요청 AgS에 대해 구성 가능한 제한 시간 또는 장기 실행의 작업 상태에 대한 더 많은 가시성을 요청합니다. 장기 실행 작업 모니터링을 지원하는 기능을 고려하고 있습니다.

이와 관련하여 추가 생태계 의견을 보내주세요.
Terraform service_account_token_creator_list가 설정되지 않은 경우에도 Terraform이 계정 IAM 정책을 수정하려고 시도합니다. 개발자는 로컬 modules/adtech_setup/main.tf 파일에 추가된 권한을 추가할 수 있습니다.
문서 요청 집계 서비스 상태를 모니터링하는 방법을 설명하는 문서 또는 Codelab 요청 서비스 및 작업 상태를 모니터링하는 데 사용할 수 있는 기존 알람에 관한 설명은 coordinator-services-and-shared-libraries 저장소의 관련 운영자 Terraform 파일 (alarms.tfmonitoring.tf)에서 확인할 수 있습니다.

집계 서비스 작업을 모니터링하는 방법에 관한 추가 문서와 안내가 게시될 예정입니다.
확장 확장 문제를 모니터링하려면 어떻게 해야 하나요? 집계 서비스의 더 큰 규모를 설명하는 이 가이드의 업데이트된 버전이 게시되었습니다.

현재 머신이 작업 규모를 지원할 수 없어 실패가 발생했음을 나타내는 직접적인 신호는 없습니다. 간접 신호에는 실패 전 메모리 사용량 90%, 반복적으로 실패하는 작업 등이 있습니다. 이러한 신호의 필요성에 관한 추가 생태계 의견을 보내주세요.
사양 AgS 보고서 일괄 실행의 일반적인 실행 시간은 얼마인가요? 여기에서 안내를 참고하세요.

Private Aggregation API

의견 주제 요약 Chrome 응답
기능 요청 음수를 포함한 부동 소수점 값의 기여를 2^16의 민감도로 contributeToHistogramOnEvent에 허용하도록 요청 현재 여기에서 이 제안서에 대해 논의하고 있으며 추가 의견을 환영합니다.

은밀한 추적 제한

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

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

IP 보호 (이전 명칭: Gnatcatcher)

의견 주제 요약 Chrome 응답
위치정보 IP 보호 지역 정보 파일 요청 IP 보호를 위해 IP를 대략적인 위치에 매핑하는 파일은 여기에서 확인할 수 있습니다. 이 파일은 정기적으로 업데이트됩니다.

이탈 추적 감소

의견 주제 요약 Chrome 응답
허용 목록 업데이트된 입장에서는 더 이상 허용 목록이나 Google의 의사결정 절차와 무관한 유사한 메커니즘을 다루지 않습니다. Google은 이탈 추적 완화 (BTM)와 관련된 허용 목록을 만들 계획이 없습니다. 보호 조치는 모든 도메인에 동일하게 적용됩니다.
규정 준수 ICO는 개인 정보 보호 관련 규정 준수에 대한 권한을 보유해야 합니다. 규정 준수 상태는 BTM 적용과 관련이 없으며 Google은 BTM 구현 시 규정 준수와 관련된 어떠한 결정도 내리지 않습니다.
경쟁 Google은 BTM (또는 기타 조치)을 사용하여 PET 경쟁자를 폐쇄한 후 경쟁자가 시장에 다시 진입할 수 있는지 여부를 재량권에 따라 결정할 수 있는 것으로 보입니다. 현재의 이의신청 절차로 인해 PET 경쟁업체가 BTM 또는 유사한 조치를 일시적으로 사용할 수 없게 될 수 있습니다. 현재 BTM 제안은 이탈 추적 기법을 목표로 합니다. Google은 유사한 기법이 포함될 수 있는 특정 사용 사례를 중단하지 않는 것을 목표로 하고 있지만, BTM에서 개별적으로 예외를 제공할 계획은 없습니다. 따라서 Google이 경쟁사의 존재에 대해 재량권을 행사하는 문제는 발생하지 않습니다.

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

의견 주제 요약 Chrome 응답
(이전 분기에도 보고됨)

관련 웹사이트 세트 (RWS) 도메인 한도
현재 연결된 도메인 5개라는 제한은 교차 사이트 측정 사용 사례를 달성하기에 충분하지 않습니다. YouTube의 대답은 이전 분기와 비슷합니다.

현재로서는 숫자 제한을 늘릴 계획이 없습니다. 이 한도는 사용자 개인 정보 보호 고려사항, W3C의 생태계 이해관계자의 의견, 다른 브라우저의 유사한 구현 고려사항을 기반으로 설정되었습니다.
자세한 내용은 블로그 게시물 (1, 2)을 참고하세요.

숫자 제한을 초과하는 교차 사이트 쿠키 액세스가 필요한 사용 사례를 검토하고 ID 사용 사례, 인증된 삽입, 광고 사용 사례에 관한 안내를 활용하는 것이 좋습니다.

이 문제에 관한 추가 의견이 있으시면 여기에서 보내주세요.

Fenced Frames API

의견 주제 요약 Chrome 응답
네이티브 광고 분리 프레임에서 네이티브 광고를 렌더링하는 경우 iframe과 게시자 페이지 간의 통신 제한으로 인해 게시자의 스타일을 상속하는 것이 제한되어 문제가 발생합니다. 펜싱된 프레임 시행 후 지원을 비롯한 네이티브 광고에 대한 추가 지원은 현재 연구 중인 영역입니다.

이 문제에 관한 추가 의견이 있으시면 여기에서 보내주세요.

Shared Storage API

의견 주제 요약 Chrome 응답
API 사용량 다른 개인 정보 보호 샌드박스 API가 작동하는 경우에도 일부 기기에서는 Shared Storage API를 사용할 수 없습니다. 이 동작은 공유 저장소 홀드백 실험에 참여하는 일부 사용자 (약 1%)에게만 적용됩니다. 이 실험 설정은 다양한 시나리오에서 API의 성능과 채택을 평가하는 데 사용됩니다.
API 사용량 공유 저장소에 대한 쓰기는 게시자 출처에서 발생하나요 아니면 입찰 스크립트 출처에서 발생하나요? 초기 테스트에서 게시자 출처가 스크립트 출처와 다른 경우 쓰기가 이루어지지 않았습니다. 이 문제는 해결되었으며 devtools 버그가 있을 수 있는 경우에만 계속 열려 있습니다. 자세한 내용은 여기를 참고하세요.

공유 스토리지는 generateBid 호출의 입찰 컨텍스트에서 구매자 출처에 씁니다. 게시자 페이지가 다른 도메인에 있더라도 게시자 출처에 연결되지 않습니다.
API 사용량 악의적인 행위자가 공유 저장소 보고서를 읽을 수 없도록 하는 보호 조치는 무엇인가요? 공유 저장소는 origin을 호출하여 파티션화되므로 악의적인 행위자나 광고 기술이 다른 광고 기술에서 공유 저장소 데이터를 읽을 수 없습니다. 비공개 집계 보고서는 TLS를 통해 동일한 출처로 직접 전송되므로 가로챌 수 없습니다.

CHIPS

의견 주제 요약 Chrome 응답
파티션된 쿠키 특히 Partitioned 속성을 사용할 때 Chrome과 Firefox의 여러 localhost 포트에서 쿠키가 일관되지 않게 처리됩니다. Firefox는 포트가 다른 localhost를 별개의 파티션 키로 취급합니다. 이 동작은 보안 원칙에 부합하지만 사양 및 Chrome의 접근 방식과는 다릅니다.

이 문제는 HTML 사양 논의에서 다른 브라우저와 논의할 예정이며, 이로 인해 CHIPS 파티션 키가 변경되면 생태계에 알릴 예정입니다. 이 문제에 관한 추가 의견이 있으시면 여기에서 보내주세요.
파티션된 쿠키 Clear-Site-Data 초안은 여기에서 참조된 이전 논의와 달리, 내보내는 사이트의 파티션 외부에서 삭제를 허용합니다. 이는 표준 사양 문서의 버그이며 곧 수정할 예정입니다. 올바른 동작은 설명서의 이 섹션에 지정되어 있으며 스토리지 파티셔닝 설명서 저장소의 다른 브라우저와 일치하는 동작입니다. Chrome의 구현은 이미 올바르게 작동합니다.

FedCM

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

스팸 및 사기 퇴치

Private State Tokens API (및 기타 API)

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