개인 정보 보호 샌드박스 제안 및 Chrome의 대응에 대해 받은 생태계 의견을 요약한 2023년 2분기 분기 보고서입니다.
CMA에 대한 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안서의 이해관계자 참여 절차에 관한 분기별 보고서를 공개적으로 제공하기로 합의했습니다 (약속의 12항 및 17항(c)(ii) 참고). 이러한 개인 정보 보호 샌드박스 의견 요약 보고서는 GitHub 문제, privacysandbox.com에 제공된 의견 양식, 업계 이해관계자와의 회의, 웹 표준 포럼 등 의견 개요에 나열된 다양한 소스에서 Chrome이 수신한 의견을 집계하여 생성됩니다. Chrome은 생태계로부터 받은 의견을 환영하며, 학습한 내용을 디자인 결정에 통합할 방법을 적극적으로 모색하고 있습니다.
의견 주제는 API별로 발생 빈도에 따라 순위가 매겨집니다. 이는 Chrome팀이 특정 주제와 관련하여 받은 의견의 양을 집계하고 수의 내림차순으로 정렬하여 수행됩니다. 일반적인 의견 주제는 공개 회의(W3C, PatCG, IETF), 직접적인 의견, GitHub, Google 내부 팀 및 공개 양식을 통해 자주 제기되는 질문을 검토하여 확인했습니다.
구체적으로 웹 표준 기관 회의의 회의록을 검토하고 직접적인 의견의 경우 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 목록, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 홍보 활동에 참여하는 팀 간에 조정하여 각 API와 관련하여 나타나는 주제의 상대적 발생 빈도를 확인했습니다.
Chrome의 의견에 대한 응답에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 응답, 이 공개 보고서 작성의 목적을 위한 구체적인 입장을 결정하는 데서 비롯되었습니다. 현재 개발 및 테스트의 중점을 반영하여 특히 Topics, Protected Audience, Attribution Reporting API와 관련된 질문과 의견이 접수되었습니다.
현재 보고 기간이 종료된 후에 받은 의견은 아직 Chrome에서 고려하지 않았을 수 있습니다.
약어 용어집
- CHIPS
- 독립적으로 파티션된 상태의 쿠키
- DSP
- 수요측 플랫폼
- FedCM
- Federated Credential Management
- FPS
- 퍼스트 파티 세트
- IAB
- 인터넷광고협회
- IDP
- ID 공급업체
- IETF : 인터넷 엔지니어링 태스크포스
- 인터넷 엔지니어링 태스크포스
- IP
- 인터넷 프로토콜 주소
- openRTB
- 실시간 입찰
- 연장전
- Origin 무료 체험
- PatCG
- 비공개 광고 기술 커뮤니티 그룹
- RP
- 신뢰 당사자
- SSP
- 공급측 플랫폼
- TEE
- 신뢰할 수 있는 실행 환경
- UA
- 사용자 에이전트 문자열
- UA-CH
- 사용자 에이전트 클라이언트 힌트
- W3C
- World Wide Web Consortium
- WIPB
- 의도적 IP 무시
일반적인 의견이며 특정 API/기술이 아님
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 데이터 거버넌스 및 규정 준수 | 규제 요구사항을 준수하여 개인 정보 보호 샌드박스를 사용하는 방법에 관한 생태계 가이드입니다. | 다른 신기술과 마찬가지로 각 회사는 개인 정보 보호 샌드박스를 사용하는 것이 법규를 준수하는지 확인할 책임이 있습니다. Google은 다른 회사에 법적 조언을 제공할 수 없습니다. 하지만 YouTube는 이 문제가 생태계에서 중요한 관심사라는 점을 잘 알고 있습니다. Google은 각 API에 대해 광범위한 기술 문서를 게시하여 필요한 법적 평가의 기반을 제공하고 있으며, 규제 요구사항을 준수하기 위한 기업의 노력을 지원하기 위해 추가 자료도 제공하기 위해 노력하고 있습니다. |
| CMA 정량적 테스트 제안서 | CMA 정량적 테스트 제안서에 대한 자세한 정보 | Google은 서드 파티 쿠키 지원 중단 및 개인 정보 보호 샌드박스 제안서 도입이 생태계에 미치는 영향을 파악할 수 있는 실험을 설계하기 위해 CMA와 협력하고 있습니다. CMA는 4월에 테스트 및 체험 기간에 예상되는 사항에 관한 대략적인 가이드를 게시한 후 6월에 세부적인 가이드를 게시했습니다. CMA의 정량적 테스트 제안에 관한 질문이나 의견은 CMA에 직접 공유하시기 바랍니다. |
| Chrome을 통한 테스트 모드 | 테스트 일정에 관한 자세한 정보 및 설명 | 5월 18일에 Chrome을 통한 테스트의 두 가지 모드에 관한 자세한 정보를 공유하는 블로그 게시물을 게시했습니다. 이 세부정보는 최종본이 아니며 2023년 3분기에 진행되는 과정에서 추가 구현 가이드를 게시할 예정입니다. |
| 파티션된 저장소 | Chrome을 통한 테스트 중에 파티션된 저장소가 사용되나요? | 스토리지 파티셔닝은 서드 파티 쿠키 지원 중단 실험 전에 모든 사용자에게 제공됩니다. 따라서 실험의 모든 부문에서 사용 설정됩니다. 이 기간 동안 사이트는 지원 중단 무료 체험을 사용 설정하여 파티션되지 않은 스토리지를 복구할 수 있습니다. |
| 제작 지원 | Chrome에서 생태계에 영향을 미치는 개인 정보 보호 샌드박스 기술적 문제 및 에스컬레이션을 지원하기 위해 마련된 절차는 무엇인가요? | Google은 광고 기술이 문제를 신고하고 필요한 에스컬레이션을 할 수 있도록 다양한 채널을 제공합니다. 의견 및 에스컬레이션을 위한 공개 및 비공개 포럼에 대한 자세한 내용은 의견 개요를 참고하세요. |
| 등록 타임라인 | 현재 등록 기간이 너무 짧습니다. | Google은 아직 시정 조치 기한을 평가하고 있으며, 생태계의 의견을 바탕으로 더 적합한 일정을 결정하고자 합니다. |
| D-U-N-S 번호 | 등록 및 증명에 필요한 D-U-N-S 번호 요구사항에 대한 자세한 내용 | 참여자는 Dun & Bradstreet 웹사이트에서 D-U-N-S 번호를 받는 데 필요한 요구사항을 확인할 수 있습니다. 요구사항은 시장마다 다르므로 참여자는 관심 있는 특정 시장의 웹사이트를 확인해야 합니다. 그러나 일반적으로 참여자는 비즈니스 이름, 주소, 비즈니스 소유자 또는 관리자의 연락처 정보와 같은 비즈니스에 관한 기본 정보를 제공해야 합니다. 비즈니스의 연간 수익과 같은 재무 정보도 제공해야 할 수 있습니다. 신청이 완료되면 D&B에서 신청서를 검토하고 신청이 승인되면 D-U-N-S 번호를 발급합니다. |
| 오리진 트라이얼에서 정식 버전으로 전환 | 오리진 트라이얼에서 정식 버전으로 전환하면 현재 오리진 트라이얼 테스터에게 영향을 미치나요? | 7월부터 테스터는 정식 버전의 관련성 및 측정 API에 액세스할 수 있습니다. 이렇게 하면 오리진 체험판 사용 가능 여부와 정식 버전 사용 가능 여부가 겹치게 됩니다. |
| AdExchanger 연구 | 설문조사 방법론에 대한 자세한 정보 | 설문조사에서는 응답자에게 비즈니스의 동기화율과 수익을 추정해 달라고 요청했습니다. 응답자가 개별 질문에 답변하는 방법은 각자 알아서 결정했습니다. |
| 매개변수 값 | 노이즈 수준, 익명성 기준점, 개인 정보 보호 예산과 같은 매개변수 값은 어떻게 결정되나요? | 이 GitHub 설명에서는 개인 정보 보호 샌드박스 API의 보다 일반적인 원칙을 설명합니다. 아직 많은 값이 확정되지 않았으므로 이 주제에 관한 의견을 보내주시기 바랍니다. |
관련성 높은 콘텐츠 및 광고 표시
주제
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 개인 정보 보호 | 개인 정보 보호에 관한 Topics API 평가 연구 | Google은 연구 커뮤니티와 적극적으로 협력하여 논문, 보고서, 워크숍 프레젠테이션에서 Topics API의 개인 정보 보호 속성에 관한 연구 결과를 발표하고 있습니다. 연구 커뮤니티의 외부 회원들이 이 분야에 참여하는 것을 기쁘게 생각합니다. Topics API는 대규모로 사용자를 추적하기 어렵게 만들어 웹에서의 일반적인 추적으로부터 사용자를 보호합니다. 이 논문은 Topics API를 통해 이를 실행하고 있음을 보여줍니다. 서드 파티 쿠키보다 더 높은 수준의 개인 정보 보호 기능을 제공하며 사용자가 즐겨 방문하는 사이트를 지원하는 동시에 사용자를 보호합니다. |
| 주제 분류가 충분히 세분화되지 않음 | 광범위한 주제 분류에는 지역별 주제를 비롯한 더 세분화된 주제가 포함되지 않습니다. | 이전에 생태계에서 제기한 의견에 따라 6월 15일에 생태계의 의견을 반영하여 수많은 개선사항을 통합한 새로운 업데이트된 분류를 자세히 설명하는 블로그 게시물을 게시했습니다. Google은 개정된 분류 작업의 일환으로 Raptive (이전 명칭: CafeMedia) 및 Criteo와 같은 생태계 전반의 여러 회사와 협력했습니다. 업데이트된 분류에서는 광고주 관심분야와 더 일치하는 카테고리를 위해 덜 유용하다는 의견이 있었던 카테고리를 삭제하는 한편, 민감할 수 있는 주제를 제외하기 위한 노력은 계속 유지합니다. 생태계는 최신 분류를 검토하고 변경사항에 관한 의견을 제공하는 것이 좋습니다. |
| 분류 및 분류 기준 업데이트 프로세스 | 주제 분류 및 분류 기준 출시 주기와 기업이 이러한 업데이트를 준비하는 방법에 관한 자세한 내용 | 최근 블로그 게시물에서 공유한 바와 같이, 분류는 시간이 지남에 따라 발전할 것이며, 분류의 거버넌스는 궁극적으로 업계 전반의 이해관계자를 대표하는 외부 당사자로 이전될 것으로 예상됩니다. 또한 topics-announce 그룹에서 확대 계획을 공유했습니다. |
| 퍼스트 파티 신호에 미치는 영향 | 최근 분류 업데이트에서 주제 수가 증가하면 매우 가치가 높아질 수 있으며, 그 결과 다른 퍼스트 파티 관심분야 기반 신호의 가치가 떨어질 수 있습니다. | 2023년 1분기 보고서에서 CMA는 'Google이 광고 기술 공급망 전반의 여러 시장 참여자와 제안된 새로운 분류에 대해 논의하고 있는 것으로 알고 있습니다. 일부 대규모 게시자는 주제의 유용성이 높아질수록 퍼스트 파티 데이터 기반 솔루션에 대한 경쟁이 심해질 것이라고 말했지만, Google의 초기 견해는 유용성이 높을수록 전반적인 경쟁에 도움이 된다는 것입니다. 특히 소규모 게시자가 서드 파티 쿠키 지원 중단 후에도 인벤토리에서 계속 수익을 창출하는 데 도움이 됩니다." Google의 견해는 CMA의 이 의견과 일치합니다. |
| 다양한 유형의 이해관계자에게 유용함 | SSP 및 DSP 역할을 하는 광고 기술은 다른 생태계 참여자보다 상당한 이점을 가질 수 있습니다. | Google의 답변은 이전 분기와 동일합니다. "Google은 CMA에 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안을 설계하고 구현하며, 규모와 관계없이 디지털 광고의 경쟁과 게시자 및 광고주에 미치는 영향을 고려하겠다고 약속했습니다. Google은 이러한 약속을 준수하기 위해 CMA와 긴밀하게 협력하고 있습니다. 개인 정보 보호 샌드박스 테스트가 진행되면서 Google에서 평가할 주요 질문 중 하나는 새로운 기술이 다양한 유형의 이해관계자들에게 어떤 영향을 미치는지입니다. 이 점에서 의견은 매우 중요합니다. 특히 기술 설계를 더욱 개선하는 데 도움이 되는 구체적이고 실행 가능한 의견이 필요합니다. Google은 정량적 테스트에 대한 접근 방식을 개발하기 위해 CMA와 협력했으며, 시장 참여자에게 더 많은 정보를 제공하고 제안된 접근 방식에 대해 의견을 제공할 수 있는 기회를 제공하기 위해 CMA가 실험 설계 관련 메모를 게시하는 것을 지지합니다." |
| 하위 주제 | 주제 선택 기준이 브라우저 방문 빈도이므로 세그먼트 분열로 인해 하위 주제가 상위로 올라가지 못하게 되나요? | Chrome은 현재 다른 순위 방법론을 평가하고 순위를 개선할 수 있는 다른 신호를 모색하고 있습니다. Google은 향후 수정된 계획을 생태계에 전달할 예정입니다. |
| 민감도 | Topics API의 목표는 Topics API에서 얻거나 파생된 사용자 정보가 오늘날의 추적 방법을 사용하여 파생될 수 있는 정보보다 개인적으로 민감하지 않아야 한다는 것입니다. | Google은 Topics API가 현재 기술보다 훨씬 더 높은 수준의 개인 정보 보호 기능을 제공하고, 사용자의 재식별을 크게 제한하며, 민감한 주제를 제외하도록 설계되었다고 생각합니다. 주제를 퍼스트 파티 데이터와 연관시키거나 결합하여 민감한 카테고리를 만들 수 있다는 점을 알고 있지만 Topics API는 사용자 개인 정보 보호를 위한 한 걸음이라고 생각하며 API를 지속적으로 개선하기 위해 노력하고 있습니다. |
| 분류 구조 | 주제 분류에 ID, 버전 관리, 기타 메타데이터 구조 추가 | 현재 API 응답에는 분류 ID가 포함되어 있습니다. 장기적인 거버넌스를 향해 나아가면서 Topics 객체를 검토하고 필요한 경우 버전 관리에 추가 메타데이터를 포함하는 것이 좋습니다. |
| 게시자 관리 | 게시자는 사이트를 어떤 주제로 분류해야 하는지 결정할 수 있어야 합니다. | 사이트가 잘못 분류되면 Topics 신호가 전반적으로 약간 덜 유용해질 수 있지만, 잘못 분류된 특정 사이트는 다른 사이트보다 더 나쁘거나 더 좋지 않습니다. 이는 사이트의 문맥 정보를 사이트의 입찰에 항상 사용할 수 있으므로 잘못 분류된 경우에도 올바른 주제와 비슷한 정보를 제공할 수 있기 때문입니다. 이 주제에 관한 의견은 언제든지 환영합니다. 게시자가 분류를 관리하도록 허용하면 위험이 있습니다. 사이트가 의도적으로 사이트를 잘못 분류하여 모든 사용자의 유용성을 저하시킬 수 있거나 덜 일반적인 주제에 민감한 의미를 암호화하여 사용자 개인 정보 보호를 해칠 수 있습니다. |
| Chrome 확장 프로그램 | Chrome 확장 프로그램이 현재 쿠키 관리 확장 프로그램과 마찬가지로 주제를 관리하고 필터링하도록 허용 | GitHub에서 논의한 바와 같이 이미 가능합니다. 하지만 생태계의 추가 의견도 환영합니다. |
| 정식 버전으로 전환 | 오리진 트라이얼에서 정식 버전으로 전환할 때 Topics API에 영향을 미치나요? | Origin 무료 체험판에서 정식 버전으로 전환하는 사용자의 데이터는 손실되지 않습니다. |
| 개인정보처리방침 | 호스트 이름에는 Topics API에서 공개할 수 있는 비공개 정보가 포함될 수 있습니다. | Google은 여기에 설명된 대로 개인 정보를 보호하기 위한 여러 완화 조치를 취하고 있습니다. |
| 사기 및 악용 | 허위 방문으로 인한 주제 조작을 방지하는 방법 | 완화 조치는 여기에 설명되어 있습니다. |
| 주제 분류 기준 | 웹사이트에서 주제 분류를 변경하도록 요청할 수 있나요? | 이 주제에 관한 생태계의 의견을 듣고자 하며 여기에서 의견을 보내주세요. |
| 주제 제공업체 사이트 | 여러 주제의 콘텐츠를 호스팅하는 특정 웹사이트를 '특수 주제 제공업체 사이트'로 지정하고 웹페이지에 제공된 태그를 기반으로 분류기를 학습합니다. | 여기에서 제안서에 관해 논의하고 있으며 추가 의견을 환영합니다. |
Protected Audience API (이전의 FLEDGE)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 트래픽 형성 | 초당 쿼리 수 (QPS) 로드를 최적화하기 위한 SSP 기반 필터링의 성능 영향 | Google은 트래픽 셰이핑에 상당한 시간을 할애했으며 SSP는 캐싱을 활용하는 것이 좋습니다. |
| 테스트 볼륨 | SSP와 DSP에서 대규모 트래픽을 확보하기 위해 노력하고 있으므로 Protected Audience를 테스트하기가 어렵습니다. | Google은 Protected Audiences를 도입하고 테스트하기 위해 SSP 및 DSP 파트너와 지속적으로 협력하고 있습니다. 정식 버전이 출시되었으며 PA가 사용 설정된 트래픽의 비율이 높아짐에 따라 파트너가 테스트하기가 더 쉬워질 것으로 기대합니다. |
| 복잡성 | Protected Audience 솔루션을 구현하려면 상당한 노력과 비용이 필요합니다. | Google은 개인 정보 보호 샌드박스를 비롯한 새로운 기술을 도입하기가 쉽지 않다는 점을 잘 알고 있습니다. 개인 정보 보호 샌드박스팀은 다양한 이해관계자와 긴밀히 협력하여 이해관계자의 노력을 교육하고 지원하며 생태계 채택을 지원하기 위한 다른 요인을 지속적으로 평가하고 있습니다. |
| 신뢰할 수 있는 실행 환경 | 비공개 클라우드 환경에서의 신뢰할 수 있는 실행 환경 (TEE) 지원 | 클라우드 기반 솔루션 외의 옵션을 지원할 수 있는지 모색하고 있지만, 개인 정보 보호 샌드박스를 평가하는 데 시간이 많이 걸리는 온프레미스 보안 제한사항으로 인해 현재 온프레미스 TEE를 지원하는 것은 불가능합니다. 개인 정보 보호 샌드박스 보안 요구사항과 온프레미스 배포에서 발생하는 심각한 문제를 고려할 때 클라우드 기반 배포 (예: AWS 외에도 GCP 지원)를 지속적으로 확장하고 개선하는 것이 생태계에 가장 유익하다고 생각합니다. 그러나 이러한 요구사항이 필요한 이유에 관한 추가 의견을 보내주세요. |
| 비용 구조 | 입찰 서비스 제안서를 사용하면 클라이언트 측 모델에 비해 광고 기술의 비용과 복잡성이 증가합니다. | 현재 입찰 서버에서 입찰 워크플로를 지원하는 데 드는 비용을 추정하기 위한 가이드를 개발하고 있습니다. 이 가이드는 광고 기술 사용량과 상관관계가 있으며 Google의 설계 목표 중 하나를 달성합니다. |
| K-Anon 타임라인 | 계획된 k-익명성 제약 조건은 언제 `renderUrl`에 적용되나요? | 시정 조치 일정에 관한 설명을 준비 중이며 곧 발표할 예정입니다. |
| runAdAuction 제한 | Chrome에서 runAdAuction가 상단 페이지에서만 호출될 수 있도록 제한할 수 있나요? |
Google의 설계는 runAdAuction가 상단 페이지에서 호출될 수 있도록 완전히 지원하지만, 게시자가 상위 도메인에서만 호출할 수 있도록 제한하는 것은 더 해로울 수 있습니다.생태계에서는 특히 개인 정보 보호 샌드박스가 게시자와 광고주의 부담을 최소화해야 한다고 제안했습니다. 이 의견은 사이트 소유자가 사이트를 운영하는 데 서드 파티 도구를 사용할 수 있다는 웹 개발의 일반적인 원칙에 부합합니다. 개인 정보 보호 샌드박스의 목표는 게시자와 광고 기술의 작동 방식을 규정하지 않고도 건전한 생태계를 조성하는 것이었습니다. 게시자가 사이트에서 runAdAuction를 호출하는 방법과 호출자를 선택할 수 있도록 허용함으로써 게시자는 요구사항에 가장 적합한 경로를 유연하게 찾을 수 있습니다. |
| 구현 지원 | Chrome에서 다중 판매자 입찰의 오픈소스 구현을 빌드하거나 기여할 수 있나요? | 개인 정보 보호 샌드박스는 서드 파티 쿠키나 기타 크로스 사이트 식별자를 사용하지 않는 개인 정보 보호 기술을 개발하는 것을 목표로 합니다. Google은 광고 기술이 작동하는 방식을 규정하지 않고도 건전한 생태계를 조성하고자 합니다. Google은 GitHub 저장소에서 API가 작동하는 방식에 관한 안내를 게시했으며 업계와 함께 솔루션을 모색하고 있습니다. Google의 핵심 역할은 플랫폼 기술을 빌드하는 것이지 이러한 기술을 사용하는 전략을 지시하는 것이 아니므로 Google은 특정 구현을 빌드할 계획이 없습니다. Google의 기술을 통해 광고 기술 회사는 소비자에게 적합한 개인 정보 보호 가이드라인을 적용하여 고객에게 최상의 서비스를 제공할 수 있습니다. |
| 복수 판매자 입찰 | Chrome은 구성요소 입찰과 '문맥적' 낙찰자를 강제로 공유하나요? | Protected Audience API는 복수 판매자 입찰을 시작하는 당사자가 구성요소 입찰에 정보를 전달할 수 있는 기능을 제공하도록 설계되었습니다 (참고: 입찰을 시작하기 전만 해당). 하지만 브라우저에서 정보가 문맥적 낙찰자인지 여부를 구분할 방법이 없으므로 특정 정보의 차단 또는 요구를 시행할 수 없습니다. |
| 동의 추적에 대한 사용자 환경설정 | 광고 기술이 PA에 사용자 동의 추적을 올바르게 구현하는 방법을 묻는 경우 | Google의 답변에는 1분기에 언급한 내용이 포함되어 있습니다. "특정 광고의 경우 관련 광고 기술이 표시되는 광고 소재 또는 광고 소재가 선택되는 방식을 제어할 수 있는 최적의 위치에 있습니다." 5월 WICG Protected Audience 회의에서 이 문제와 관련된 여러 시나리오를 논의했으며 이 문제에 관한 추가 의견 및 논의를 환영합니다. |
| 맞춤 잠재고객 | 맞춤 잠재고객 생성과 관련된 SSP 사용 사례가 Protected Audience API에서 지원되나요? | Protected Audience API를 사용하면 SSP 및 기타 광고 기술 제공업체가 맞춤 잠재고객을 소유하고 관리할 수 있습니다. SSP가 PA API와 통합하는 방법에 관한 추가 안내는 개발 중이며 SSP 및 기타 광고 기술 제공업체가 통합 작업을 지원할 수 있도록 제공될 예정입니다. |
| 형식 | Protected Audience API에서 동영상이 지원되나요? | 동영상 광고는 VAST XML 또는 HTML (궁극적으로 VAST XML을 동영상 플레이어에 로드할 수 있는 아웃스트림 광고) 중 한 가지 방법으로 게재됩니다. 구매자는 renderURL을 통해 두 형식 중 하나를 반환할 수 있습니다. Attribution Reporting API를 지원하도록 VAST 사양이 최근 업데이트되었습니다. 동영상 광고를 게재하는 사이트는 Protected Audience API를 통해 광고가 게재되는 방식을 준비해야 합니다. 즉, 게재위치 태그가 Protected Audience iframe의 URL을 동영상 플레이어로 전달할 수 있어야 합니다. 펜싱 프레임의 경우 2026년 이전에 펜싱 프레임을 사용해야 하는 요구사항이 적용되기 전에 동영상 요구사항을 해결하기 위해 노력할 것입니다. |
| 예산 소진 속도 | 속도 조절 사용 사례는 Protected Audience API와 어떻게 작동하나요? | 의견을 보내주셔서 감사합니다. 지금까지는 주로 DSP의 문제였으므로 더 많은 SSP 파트너가 이 요청을 더 자세히 제출해 주시기 바랍니다. |
| 업데이트 빈도 | dailyUpdate의 호출 빈도 (하루에 관심분야 그룹당 최대 1회)는 제품 정보 업데이트와 같은 특정 사용 사례에 충분하지 않을 수 있습니다. |
의견을 보내주셔서 감사합니다. 광고 기술이 K/V 조회와 같이 다양한 주기로 업데이트되는 신호를 사용할 수 있도록 하는 다른 솔루션도 있습니다. |
| 광고 품질 관리 | 게시자는 광고 품질 관리를 어떻게 구현하나요? | 현재 Protected Audience API는 게시자가 입찰 구성의 일부로 설정할 수 있는 특정 제어 기능 (예: 광고와 연결된 라벨을 기반으로 하는 차단 목록)을 SSP에 알릴 수 있는 기능을 제공합니다. 생태계에 필요한 추가 기능에 관한 의견도 보내주세요. |
| 디버깅 | forDebuggingOnly 기능은 언제 삭제되나요? |
서드 파티 쿠키 지원 중단으로 인한 손실 이벤트에 대해 forDebuggingOnly를 지원 중단할 계획입니다. 2026년(가장 빠르면)부터 낙찰 이벤트에 forDebuggingOnly를 지원 중단할 계획입니다. |
| 교차 기기 관심분야 그룹 | 인증된 사용자 에이전트의 교차 기기 관심분야 그룹을 사용 설정하기 위한 제안 | Google에서는 이 제안을 평가하고 있지만, 교차 기기 타겟팅의 높은 특이성은 이 GitHub 문제에서 논의된 바와 같이 심각한 개인 정보 보호 문제를 야기합니다. |
| (1분기에도 신고됨) 동적 리마케팅 | 서드 파티 쿠키 지원 중단 후에도 Protected Audience API를 통해 동적 리마케팅을 계속할 수 있나요? | 여기에 설명된 대로 Protected Audience를 사용하면 이 사용 사례를 실행할 수 있습니다. |
| 관련 데이터 클릭 | browserSignals.에 클릭 관련 데이터 추가 |
현재 Google에서는 예비 순위를 제공하기 위해 클릭이 발생한 시점에 관해 명확히 설명해 달라고 요청하고 있습니다. |
| (2022년 4분기에 신고됨) Protected Audience의 사용자 정의 함수 | Protected Audience API에서 사용자 정의 함수 (UDF)는 어떻게 지원되나요? 이는 최종 사용자가 API의 기능을 확장하도록 프로그래밍할 수 있는 함수입니다. | 이 문제를 제기한 광고 기술에서도 아직 UDF로 무엇을 할 수 있는지 평가하고 있으므로 적어도 정식 버전이 출시될 때까지는 조치를 취할 수 있는 의견이 없다고 언급했습니다. |
| 통화 | 통화 금액은 부동 소수점을 사용하여 표시해서는 안 됩니다. | 이 문제는 여기에서 자세히 설명했습니다. |
| DSP 이외의 광고 선택 기능 | Protected Audience API 입찰에서 광고 서버는 어떤 역할을 하나요? | Google은 광고 서버에서 입찰 후 광고 선택 / 동적 광고 소재 최적화 서비스를 계속 제공해 달라는 요청을 알고 있습니다. 현재 Google에서는 현재 Protected Audience API와 이러한 요청 간에 존재하는 세부적인 격차 분석을 평가하고 있습니다. |
| GenerateBid | generateBid에서 광고 관심분야 그룹당 두 개 이상의 후보 광고를 반환하고 이러한 후보에 대해 `scoreAd`에서 점수를 부여하는 Google Ads의 제안을 지원합니다. |
현재 평가 중입니다. 여기에서 추가 의견을 보내주세요. |
| 입찰 순서 | Protected Audience API 입찰이 다른 모든 입찰의 결과에서 입력을 받을 수 있도록 마지막으로 실행되어야 하나요? | Protected Audience API가 마지막으로 실행되도록 하는 기술적 요구사항은 없습니다. |
| 사용자가 시작하지 않은 탐색 | 사용자가 시작하지 않은 탐색 노출 | YouTube에서는 이 요청을 검토하고 여기에서 논의 하고 있으며 추가 의견을 환영합니다. |
| 캐싱 | SSP는 사용자 상태가 변경되는 경우 캐시에서 특정 DSP의 perBuyerSignals를 빌드해서는 안 됩니다. | Google은 perBuyer 신호의 모든 사용 사례에 캐싱이 적용되지 않는다는 점을 알고 있으며 추가 옵션을 평가하고 있습니다. 캐싱이 사용 사례에 적합한지 여부에 관한 생태계의 추가 의견을 기다리고 있습니다. |
| Attribution Reporting 및 Protected Audience | Attribution Reporting API와 Protected Audience API는 어떻게 함께 작동하나요? | 현재 Attribution Reporting API 모드 (이벤트 수준 및 요약 보고서) 모두에서 Protected Audience API를 통합할 수 있습니다. 6월 1일에 개선된 Protected Audience API 및 Attribution Reporting 통합에 관한 자세한 정보를 공유했습니다. 여기에서 자세히 알아보세요. |
| 서버 엔드포인트 | 최종 설계에서 서버 엔드포인트가 신뢰할 수 있는 집계 서버가 되나요? | 서버 엔드포인트는 수집 및 변환된 보고서를 처리하는 데 사용되는 신뢰할 수 있는 집계 서버와는 별개로 광고 기술에서 유지 관리하는 엔드포인트입니다. 현재 보고 엔드포인트에 대한 변경사항은 계획되어 있지 않습니다. 현재 설계는 집계 가능한 보고서 자체 (암호화된 페이로드 포함)가 교차 사이트 데이터를 유출하지 않도록 하기 위한 것이므로 신뢰할 수 있는 엔드포인트는 필요하지 않습니다. 또한 광고 기술마다 원하는 일괄 처리 전략이 다를 수 있습니다. 여기에서 추가 의견을 보내주세요. |
| WebIDL | 현재 Protected Audience API 사양은 WebIDL 사양과 호환되지 않습니다. | Google은 이 의견을 평가하고 여기에서 문제를 논의하고 있습니다. |
| 동의 관리 | Protected Audience API에서 동의 신호 전달은 어떻게 처리되나요? | 문맥 정보는 Protected Audience API의 범위에 해당하지 않습니다. YouTube에서는 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다. |
| 계정 기반 마케팅 | 계정 기반 마케팅 사용 사례가 가능할까요? | Protected Audience API는 다양한 잠재고객 기반 마케팅 사용 사례를 지원합니다. Google은 Protected Audience API가 이 특정 사용 사례를 가장 잘 지원할 수 있는 방법을 계속해서 파악하고 있으며, 생태계의 이 문제에 관한 추가 의견을 기다리고 있습니다. |
| 구성요소 입찰 | 구성요소 입찰 참여자는 어떤 점수를 받나요? | 구성요소 입찰은 관심분야 그룹에 직접 점수를 매기지 않습니다. 대신 DSP가 generateBid 함수에서 제출하는 광고 및 입찰가에 점수를 매깁니다. generateBid() 함수는 관심분야 그룹별로 실행되며 DSP는 generateBid를 실행할 때 다음을 반환합니다. return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| 외부 기여 | 키/값 서버 GitHub 코드베이스에 대한 외부 참여를 지원해 달라는 요청 | YouTube는 GitHub 코드에 대한 외부 참여를 지원하기 위해 관련 프로세스를 업데이트하고 있습니다. |
| 관심분야 그룹 크기 | IG에서 지원할 수 있는 최대 키 수는 얼마인가요? | 현재 한 IG의 크기 제한은 50KB이며 키도 여기에 포함됩니다. 크기 제한에 대한 추가 논의를 환영합니다. |
| 일괄 처리 | K/V 서버 호출 수를 줄이려면 어떻게 해야 하나요? | HTTP Cache-Control 헤더를 사용하여 K/V 호출 수를 줄일 수 있습니다. 예를 들어 구성요소 입찰 전반에서 캐시될 수 있으며 단일 페이지의 광고 슬롯 전반에서 캐시될 수도 있습니다. |
| 버전 제어 | 여러 버전의 광고 기술 코드 지원 | 입찰 서비스는 여러 버전의 광고 기술 코드를 지원합니다. 입찰 API에서 SelectAd 요청은 입찰 요청 (예: 입찰 / 입찰 및 보고)에 사용되는 코드 버전을 지정할 수 있습니다. |
| 공유 저장소 | 입찰 서비스에서 공유 저장소에 쓰기를 지원합니다. | 현재 입찰 서비스는 공유 저장소를 지원하지 않지만 이러한 사용 사례가 생태계에 중요한 이유에 관한 추가 의견을 보내주세요. |
| 웹-앱 | 관심분야 그룹의 웹-앱 공유를 지원합니다. | 웹-앱은 현재 Chrome 및 Android 전반의 Protected Audience API 배포 범위에 포함되지 않지만, 이 사용 사례의 중요성에 관한 생태계의 의견을 듣고자 합니다. |
| K-익명성 | K-익명성 대체 처리 방법 | YouTube에서는 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다. |
디지털 광고 측정
Attribution Reporting (및 기타 API)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 대체 VTC 이벤트 수준 보고서 구성 | 대체 VTC 이벤트 수준 보고서 구성에 관한 의견 | 현재 이벤트 수준 구성이 최적화되지 않았다는 의견이 접수되어 최적의 글로벌 구성에 관한 의견을 요청하고 있습니다. 이 문제와 관련하여 추가 의견을 보내주세요. 유연한 이벤트 수준 설명도 이 문제를 해결하는 데 도움이 될 것입니다. |
| 유연한 이벤트 수준 구성 | 유연한 이벤트 수준 구성 기능의 상태는 어떠한가요? | 유연한 이벤트 수준 구성에 관한 문서를 공유했습니다. 이 기능은 아직 제안서 단계이며 생태계에 가치가 있는지 여부에 관한 추가 의견을 모으고 있습니다. |
| 유연한 이벤트 수준 구성 | 서로 다른 당사자의 상반된 신고를 조정하려면 어떻게 해야 하나요? | 대부분의 보고 시나리오는 집계 보고서를 사용하여 처리되지만 유연한 이벤트 수준 구성 제안은 특히 최적화 사용 사례에 가장 많이 사용되는 이벤트 수준 보고서의 유연성을 높이기 위한 것입니다. 이 시나리오와 관련하여 생태계 관련 의견/의견을 보내주세요. |
| 소스 등록 | 소스 등록이 트리거 등록 후에 발생하면 어떻게 되나요? | 현재 소스 등록이 트리거 등록 후에 발생하면 소스와 트리거를 서로 연결할 수 없습니다. 이는 특이 사례 시나리오인 것으로 보입니다. 이 문제와 관련하여 추가 의견이 있으시면 보내주세요. 많은 광고 기술에서 발생하는 시나리오인 경우 문제를 해결하기 위해 노력하겠습니다. |
| 여러 광고 대행사와 협력하기 | 광고주가 여러 광고 대행사와 협력하는 경우 DSP는 Attribution Reporting API를 어떻게 사용할 수 있나요? | 이 API는 리디렉션을 지원하므로 광고주가 여러 광고 대행사와 협력하는 경우에도 사용할 수 있습니다. 또한 API에서 개인 정보 보호를 개선하기 위해 리디렉션과 관련하여 몇 가지 제한사항이 적용됩니다. 또한 광고 기술에서 제기한 특정 시나리오에 Shared Storage API를 활용하는 잠재적 해결 방법도 확인했습니다. 이 시나리오와 관련하여 추가 의견이 있으면 보내주세요. 보내주신 의견을 바탕으로 계속해서 개선해 나가겠습니다. |
| 대상 한도 | 자동 새로고침 광고 사용 사례는 대상 제한의 영향을 받을 수 있습니다. | 5월 1일 WICG 회의에서 이 문제를 논의했으며 합리적인 한도에 관한 의견을 받고 있습니다. 브라우저가 소스 사이트로 표현되는 '대상' eTLD+1의 수를 제한할 수 있다는 내용을 이벤트 수준 보고서가 포함된 Attribution Reporting 설명에 추가했습니다. (pull 요청 참고) |
| Attribution Reporting 및 Protected Audience | Attribution Reporting API와 Protected Audience API는 어떻게 함께 작동하나요? | 현재 Attribution Reporting API 모드 (이벤트 수준 및 요약 보고서) 모두에서 Protected Audience API를 통합할 수 있습니다. 6월 1일에 개선된 Protected Audience API 및 Attribution Reporting 통합에 관한 자세한 정보를 공유했습니다. 여기에서 자세히 알아보세요. |
| 유연한 이벤트 수준 구성 | 이제 매개변수를 구성할 수 있으므로 노이즈 시뮬레이션에 관한 권장사항을 공유합니다. | 누구나 테스트하려는 유연한 이벤트 수준 구성의 정보 이득과 노이즈 영향을 평가하는 데 사용할 수 있는 GitHub의 공유 코드가 있습니다. 코드로 테스트하고 의견을 공유하고자 하는 사용자의 의견을 기다립니다. |
| 교차 앱 및 웹 기여 분석 측정 | 교차 앱 및 웹 기여 분석 측정은 언제 사용할 수 있나요? | Google은 5월 9일에 Attribution Reporting API를 통한 교차 앱 및 웹 기여 분석 측정 실험을 발표했습니다. Chrome 115에서는 관련성 및 측정 API의 정식 버전이 출시될 예정이지만, 교차 앱 및 웹 기여 분석 측정은 현재 Chrome 115에서 정식 버전으로 출시되지 않을 예정입니다. |
| 전환 중복 삭제 | 독립형 측정 솔루션을 ARA와 어떻게 조정할 수 있나요? | 현재 표준 관행과 마찬가지로 광고주는 서드 파티 독립 측정 제공업체와 협력하여 전환 보고 중복을 제거합니다. 이벤트 수준 보고를 위해 전환 중복 삭제 방법에 관한 리소스를 제공했습니다. |
| 기여 분석 보고 데이터베이스 업데이트 중 데이터 손실 | Chrome에서 공지된 대로 기여 분석 보고 데이터베이스를 업데이트하면 데이터가 손실되나요? | Chrome 안정화 버전 115부터 일부 Chrome 사용자를 대상으로 관련성 및 측정 API가 기본적으로 사용 설정됩니다. 잠재적인 문제를 모니터링하면서 정식 버전이 점진적으로 확대될 예정입니다. 목표는 2023년 3분기까지 몇 주에 걸쳐 100% 가용성에 도달하는 것입니다. 이는 관련성 및 측정 출처 체험판 종료와 동시에 진행됩니다. 7월부터 테스터는 정식 버전으로 제공되는 이러한 API에 액세스할 수 있도록 등록할 수 있습니다. 이렇게 하면 등록을 통해 원본 체험판 사용 가능 여부와 정식 버전 사용 가능 여부가 겹치게 됩니다. 오리진 체험판 토큰은 9월 19일까지 유효하지만, 진행 중인 테스트를 중단하지 않고 오리진 체험판에서 원활하게 전환할 수 있도록 만료 전에 API를 등록하는 것이 좋습니다. 이 공지사항에 언급된 바와 같이 이전 버전 (M113 이하)에서 등록된 데이터는 업데이트 후 이전되지 않으므로 데이터가 손실될 수 있습니다. 이 데이터 손실은 디버그 보고에 표시되지 않으며 114에서 115로의 데이터 손실을 방지하기 위해 노력할 것입니다. |
| 결제 | 전환당비용 청구에 기여 분석 보고서 사용 | 이 도움말에 설명된 대로 Attribution Reporting API는 이벤트 수준 및 요약 보고서에 노이즈가 추가되므로 전환당비용 청구 요구사항에 적합하지 않을 수 있습니다. 생태계 참여자는 GitHub에서 Attribution Reporting API가 다양한 결제 모델에 미치는 영향에 관한 의견을 공유해 주시기 바랍니다. |
Aggregation Service
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 집계 가능한 보고서 지연 변경 | 생태계의 의견에 따라 집계 가능한 보고서 지연을 [10~60분] 에서 [0~10분] 으로 변경하는 제안에 긍정적인 반응 | 제안된 변경사항에 대한 긍정적인 반응을 확인할 수 있어 기쁘게 생각하며 생태계에서 Google의 제안에 계속해서 의견을 제공해 주시기 바랍니다. |
| 온프레미스 솔루션 | 집계 서비스를 온프레미스 데이터 센터에 배포할 수 있나요? | 클라우드 기반 솔루션 외의 옵션을 지원할 수 있는지 모색하고 있지만, 개인 정보 보호 샌드박스를 평가하는 데 시간이 많이 걸리는 온프레미스 보안 제한사항으로 인해 현재로서는 온프레미스 TEE를 지원할 수 없습니다. 개인 정보 보호 샌드박스 보안 요구사항과 온프레미스 배포에서 발생하는 심각한 문제를 고려할 때 클라우드 기반 배포 (예: AWS 외에도 GCP 지원)를 지속적으로 확장하고 개선하는 것이 생태계에 가장 유익하다고 생각합니다. 그러나 이러한 요구사항이 필요한 이유에 관한 추가 의견을 보내주세요. |
| 여러 기간의 보고서 재처리 | 여러 기간의 보고서를 다시 처리할 수 있는 기능 | 다양한 기간에 대해 일괄 처리를 분할할 수 있는 기능을 제공해 달라는 유사한 요청도 있었습니다. 한 가지 제안은 보고서를 여러 일괄 처리로 분할할 수 있도록 광고 기술 정의 라벨로 공유 ID를 확장하는 기능을 허용하는 것입니다. Google은 이 절차를 평가하는 초기 단계에 있으며 이 제안서가 발전함에 따라 생태계를 계속 업데이트할 예정입니다. |
| 신뢰할 수 있는 실행 환경의 개인 정보 보호 관련 고려사항 | 신뢰할 수 있는 실행 환경의 개인 정보 보호 관련 영향에 대한 긍정적인 감정 | Google은 제안과 관련하여 생태계로부터 긍정적인 반응을 얻게 되어 기쁘게 생각하며, Google이 계속해서 반복하고 개발하는 과정에서 추가 의견을 보내주시기 바랍니다. |
| 서비스 약관 | 집계 서비스 서비스 약관에 동의해야 하는 기한은 언제인가요? | 이용약관 동의 기한은 아직 지정되지 않았지만, 등록이 지연되지 않도록 생태계 기업은 최대한 빨리 이용약관에 동의하시기 바랍니다. 궁금한 점이 있으면 언제든지 문의해 주시기 바랍니다. |
| 주요 발견사항 | 키 검색 기능을 사용하면 테스터가 성능과 정확성을 개선하기 위해 교차 네트워크 기여 분석의 요약 보고서를 처리하기 위해 가능한 키 조합의 명시적 목록이 없어도 집계 보고서를 쿼리할 수 있습니다. | Google은 현재 가능한 해결 방법과 해결 방법을 모색하고 있으며 생태계의 추가 의견을 환영합니다. |
Private Aggregation API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 신고 출처 | 보고 출처는 어떻게 정의되나요? | 보고 출처는 항상 비공개 집계 호출자의 스크립트 출처입니다. |
| 128비트 키 공간 | 128비트 키 공간 제한에 관한 명확성 | 이 키스페이스 제한을 더 명확하게 하고 페이지 간의 불일치를 해결할 예정입니다. 해싱 전략을 사용하여 이 키 공간을 유지하는 것이 좋습니다. |
| 보고서당 최대 기여도 | 현재 보고서당 20개의 기여 제한이 너무 낮습니다. | 최대 참여 횟수를 늘리는 대신 한도에서 자르지 않고 보고서를 분할하는 방안을 고려하고 있습니다. Google은 이 제안서가 발전함에 따라 생태계와 소통할 예정입니다. |
| 도달범위 보고 | 교차 플랫폼/교차 기기 도달범위 보고를 요청합니다. 도달범위는 브랜드 광고의 기본 측정항목입니다. 광고주는 도달범위 및 게재빈도 보고에 교차 플랫폼/교차 기기 근사치를 사용하여 캠페인을 분석하고 지출을 할당합니다. 도달범위 모델은 서드 파티 환경에 게재된 광고를 측정하기 위한 신호로 서드 파티 쿠키를 사용하므로 서드 파티 쿠키가 지원 중단되면 광고 기술에서 대체 솔루션을 요청했습니다. |
개인 정보 보호 샌드박스팀은 서드 파티 쿠키 지원 중단 후 교차 도메인 도달범위 방법론을 지원하는 기능을 모색하고 있습니다. 생태계의 추가 의견을 기다리고 있습니다. |
은밀한 추적 제한
사용자 에이전트 축소/사용자 에이전트 클라이언트 힌트
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| (2023년 1분기에도 신고됨) 추가 폼 팩터 힌트 | TV, VR과 같은 추가 폼 팩터를 제공하기 위한 사용자 에이전트 클라이언트 힌트 (UA-CH) 요청 | YouTube는 아직 몇 가지 주요 설계 결정('TV'와 같은 단일 값을 제공할지 또는 폼 팩터 기능 목록을 제공할지 여부)을 검토하고 있지만 이 아이디어의 프로토타입 제작에 계속 관심을 가지고 있습니다. |
| 개인 정보 보호 예산 | 개인 정보 보호 예산 제한으로 인해 요청이 너무 많이 전송되면 UA-CH 요청이 비결정론적일 수 있습니다. | 현재 개인 정보 보호 예산 제안에 관한 새로운 업데이트는 없지만 서드 파티 쿠키가 지원 중단되기 전에 UA 클라이언트 힌트 요청을 제한하지 않기로 약속했습니다. |
| 사이트 호환성 | 웹사이트에서 UA-CH 브랜드를 사용하여 특정 브라우저의 사이트 액세스를 제한하고 있습니다. | 브랜드 목록을 사용하는 유효한 사용 사례가 있으며 그중 하나가 바로 호환성입니다. UA는 이러한 문제를 해결하기 위해 여러 브랜드를 보유할 수 있습니다. |
IP 보호 (이전 명칭: Gnatcatcher)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 사기 및 악용 | 기업은 IP 보호를 통해 사기 방지 조치를 어떻게 설정할 수 있나요? | Google은 사기 방지 사용 사례의 중요성과 이러한 사용 사례에 미칠 수 있는 영향을 잘 알고 있습니다. YouTube는 올여름에 사기 방지 지원에 관한 자세한 내용을 게시할 계획입니다. Google은 사기 방지 사용 사례를 더 효과적으로 지원할 수 있는 방법에 관한 생태계의 의견을 모으고 있습니다. |
| GeoIP | GeoIP 테스트 및 배포 일정에 대한 자세한 정보 | Chrome에서는 최근 GeoIP 계획에 관한 새로운 정보를 게시했습니다. 3분기에 배포 일정에 관한 자세한 정보를 게시할 예정입니다. IP 보호는 초기에 소수의 트래픽을 대상으로 사용자 선택 기능으로 출시될 예정입니다. 이 제안서에는 기업에 상당한 변화가 수반될 수 있다는 점을 고려하여 기능을 더 광범위하게 출시하기 전에 생태계가 조정하고 의견을 제공할 시간을 드리고자 합니다. |
| 계정 인증 | 프록시 서버를 통한 계정 인증은 정확히 어떻게 작동하나요? | 이미 초기 고려사항을 공유했지만 계정 인증에 대한 자세한 내용은 올여름에 발표할 예정입니다. |
이탈 추적 감소
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 테스트 안내 | 이탈 추적 감소를 테스트하는 방법에 관한 정보 | Google에서는 5월에 이탈 추적 완화를 테스트하는 방법에 관한 자세한 내용을 담은 블로그 게시물을 게시했습니다. |
| 문서 | 이탈 추적 제안서의 명확성 | 현재 제안서는 아직 진행 중이며 Chrome은 생태계에 명확한 정보와 정보를 제공하기 위해 제안서를 계속 업데이트하고 있습니다. Google에서는 더 자세한 내용을 제공하기 위해 노력하고 있으며 추가 의견을 환영합니다. |
| 쿠키 삭제 | 이탈 추적 완화 기능을 사용하면 도메인의 모든 쿠키가 삭제되나요? | 이탈 추적 완화 (BTM)는 여기에 설명된 대로 모든 저장소와 모든 캐시를 삭제합니다. |
| 이탈 추적 감소 우회 | 팝업 또는 새 탭을 사용하여 리디렉션을 실행하면 이탈 추적기 분류가 우회될 수 있습니다. | 이탈 추적 완화 사양은 아직 개발 중입니다. 지금까지는 동일 탭 리디렉션에 주로 집중했지만 향후 팝업 흐름을 개선할 계획입니다. 여기에서 추가 의견을 보내주세요. |
개인 정보 보호 예산
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 인접 타겟팅 | 개인 정보 보호 예산은 근접 타겟팅 사용 사례에 영향을 줄 수 있습니다. | 이 문제에 대한 의견을 받았으며 생태계의 잠재적 영향에 대해 자세히 알고 싶습니다. |
크로스 사이트 개인 정보 보호 경계선 강화
퍼스트 파티 세트
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| (이전 분기에도 보고됨) 도메인 한도 | 연결된 도메인 수 확대 요청 | Chrome은 확인된 사용 사례의 개인 정보 보호와 유용성 간의 균형을 맞출 수 있는 연결된 하위 집합의 적절한 숫자 제한을 평가하고 있습니다. Chrome은 초기부터 연결된 하위 집합의 정확한 숫자는 아직 확정되지 않았다고 공유했습니다. |
| 삽입된 사용 사례 | 퍼스트 파티 세트, CHIP, 공유 저장소가 필요한 삽입된 사용 사례 지원 | Chrome은 이 사용 사례에 관한 의견을 접수했으며, 팀에서 조사 중이며 추가 의견을 환영합니다. |
| 저장소 관리 | 불일치 또는 태만이 있는 경우 GitHub 저장소에서 퍼스트 파티 세트를 삭제하는 정책에 관한 정보 | Chrome에서 이 사용 사례에 관한 의견을 받았습니다. 담당 팀에서 조사 중이며 추가 의견을 기다리고 있습니다. |
| 사용자 교육 | Chrome은 퍼스트 파티 세트의 사용자 인식과 이해도를 높이고 이를 통해 도입을 유도해야 합니다. | Chrome은 퍼스트 파티 세트에 관해 사용자를 교육하기 위해 노력하고 있으며, 이 문제와 관련하여 고객센터 도움말 (Chrome UI에서 링크됨)을 게시했습니다. Chrome은 적절한 상황에서 사용자에게 가장 효과적으로 정보를 제공하는 방법을 계속해서 연구하고 있습니다. |
| 3PCD 게시 | 서드 파티 쿠키 지원이 중단된 후에도 서드 파티 쿠키는 퍼스트 파티 세트 내에 계속 존재합니다. | requestStorageAccess 및 requestStorageAccessFor를 사용하면 명확하게 정의된 특정 사용 사례에 서드 파티 쿠키를 다시 사용할 수 있지만, 이제는 Chrome의 서드 파티 쿠키와 마찬가지로 기본적으로 사용할 수 있는 대신 사이트에서 적극적으로 호출해야 합니다.단일 세트 내에서의 호출에는 사용자 승인이 필요하지 않지만, 사용자는 설정에서 이 동작을 선택 해제하여 이를 방지할 수 있습니다. 사용자는 고객센터 도움말 (Chrome UI에서 링크)에서 자세한 내용을 확인할 수 있습니다. FPS가 100%까지 증가함에 따라 기존 개발자 가이드를 확장할 계획입니다. |
| 퍼스트 파티 세트 제출 | 필요한 .well-known/first-party-set의 이름을 바꿔 .json 확장자를 포함합니다. |
특정 웹 호스팅 요금제가 지원되도록 이러한 변경사항이 적용되었습니다. |
| IANA 등록 | first_party_sets.JSON는 IANA에 등록되어야 합니다. |
Google에서 제안을 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
Fenced Frames API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 광고 차단 | 펜싱된 프레임은 광고 차단 프로그램이 광고를 더 쉽게 차단할 수 있도록 할 수 있습니다. | 확장 프로그램은 iframe과 상호작용하는 것과 비슷한 방식으로 분리된 프레임과 상호작용할 수 있습니다. 펜싱된 프레임이 이동하려는 실제 URL도 확장 프로그램에 표시되므로 iframe에서와 마찬가지로 차단에 URL 일치 규칙을 적용할 수 있습니다. 모든 펜싱된 프레임을 무조건 차단하면 펜싱된 프레임의 광고 외 사용 사례가 중단될 수 있습니다. |
Shared Storage API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 더 광범위한 채택 | 공유 저장소는 여러 브라우저에서 사용할 수 있는 업계 전반의 표준이어야 합니다. | Google은 이러한 의견을 환영하고 확인합니다. Chrome은 제안을 지지하고 의견을 구하며 채택을 유도하기 위해 W3C 포럼에 계속해서 적극적으로 참여하고 있습니다. |
| 출력 게이트 | 공유 저장용량 출력 게이트가 너무 제한적입니다. | Google은 이 의견을 고려하고 있으며 출력 게이트가 너무 제한적인 이유에 관한 추가 생태계 의견을 환영합니다. |
| 규정 준수 | 공유 저장소는 데이터 보관 정책과 같은 규정 준수를 어떻게 처리하나요? | 공유 저장소는 저장된 데이터의 전체 기간과 만료를 제어하는 로직을 구현하고 맞춤설정할 수 있는 유연성을 제공합니다. 광고 기술은 쓰기 타임스탬프를 기반으로 공유 스토리지 데이터를 업데이트하거나 지울 수 있습니다. |
| A/B 테스팅 | Shared Storage API와 Protected Audience API의 A/B 테스트를 실행하려면 어떻게 해야 하나요? | 이 문제와 관련하여 추가 안내를 게시하기 위해 노력하고 있으며 향후 더 자세한 내용을 공유할 수 있기를 바랍니다. |
| 공유 저장용량 한도 | 공유 저장용량 한도가 초과되면 어떻게 되나요? | 한도에 도달하면 더 이상 입력이 저장되지 않습니다. |
| 동일한 페이지 로드에서 여러 번 액세스 | 동일한 페이지 로드에서 공유 저장소에 여러 번 액세스하면 어떻게 되나요? | 이를 처리하는 가장 좋은 방법은 window.sharedStorage.append(key, value) 함수를 사용하는 것입니다. 광고가 여러 개인 경우 충돌이 발생할 수 있으므로 각 광고의 값을 업데이트하지 않습니다. append 함수는 새 값을 기존 값의 끝에 추가하기만 합니다. |
| iframe 기능 | 서드 파티 쿠키 지원 중단 후 더 이상 작동하지 않는 특정 iframe 기능을 공유 저장소에서 지원하나요? | 서드 파티 쿠키 지원 중단 후 iframe의 로컬 저장소는 최상위 사이트에 의해 파티셔닝되지만 iframe 자체는 차단되지 않습니다. iframe의 로컬 스토리지에 있는 데이터는 여러 최상위 사이트에 복제할 수 없지만 로컬 스토리지는 iframe 내에서 계속 사용할 수 있습니다. |
CHIPs
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 파티션 한도 | 파티션된 사이트당 10KiB는 여전히 상당한 크기이므로 줄이고 싶습니다. | Firefox는 이미 CHIPS에 긍정적인 입장을 표명했습니다. Webkit 지원의 경우 개발자는 파티션된 스토리지보다 파티션된 쿠키가 선호되는 사용 사례와 관련하여 이 GitHub 문제에 대해 Apple에 직접 의견을 제공하는 것이 좋습니다. |
| 인증된 삽입 | CHIP은 인증된 삽입에 영향을 미치는 다양한 파티셔닝으로 인해 현재 SSO 로그인 절차에 영향을 줄 수 있습니다. | Google은 Storage Access API (사용자 메시지 포함)를 활용하여 인증된 삽입 사용 사례를 지원할 계획이며 최근에 프로토타입 제작 인텐트를 전송했습니다. |
| 평생 정책 | 잠재적인 전체 기간 정책이 퍼스트 파티 쿠키에 적용되나요? | 현재 퍼스트 파티 쿠키에 전체 기간 한도를 적용할 계획은 없습니다. |
FedCM
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| OAuth 승인 지원 | 프로필 외 OAuth 범위 승인에 관한 조정 | Google은 서드 파티 쿠키 지원 중단 후 기본 인증을 넘어 승인을 지원하는 가장 좋은 방법에 관한 의견을 W3C FedID CG를 통해 웹 ID 커뮤니티로부터 적극적으로 수렴하고 있습니다. |
| SAML 지원 | SAML 지원 요구사항 준수 | Google은 서드 파티 쿠키 지원 중단 이후 OpenID Connect 지원 외에도 SAML 지원 요구사항에 관한 연구 및 교육 커뮤니티의 의견을 적극적으로 수렴하고 있습니다. |
스팸 및 사기 퇴치
Private State Tokens API (및 기타 API)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 새로운 신호 탐색 | 여러 파트너가 브라우저에서 제공하는 기기 무결성 또는 사용자 신뢰 신호를 탐색하는 것에 긍정적인 반응을 보였습니다. 일반적으로 새로운 목적 지향적 신호가 현재 수준의 사기 감지를 유지하기에 충분한지 여부에도 주의를 기울입니다. | Google은 사기 방지 및 웹 안전 커뮤니티와 함께 새로운 제안을 모색하고 우려사항을 파악하고 공유할 수 있어 기쁩니다. 이러한 이유로 '스팸 및 사기 방지'가 개인 정보 보호 샌드박스의 핵심 작업 흐름이 되었으며, Google은 사용자 개인 정보를 개선하는 동시에 웹 안전을 유지하는 데 계속해서 투자하고 있습니다. |
| PST에 대한 긍정적인 의견 | 여러 파트너가 다양한 사기 방지 또는 웹 안전 사용 사례에 PST를 테스트하거나 활용하는 데 관심을 보였습니다. | PST를 활용하는 새로운 솔루션을 추가로 모색하는 데 대한 지원과 관심을 보내주셔서 감사합니다. Chrome 개발자 사이트에서 리소스와 샘플 코드를 확인할 수 있으며, 추가 의견도 환영합니다. |
| 사기 및 악용 | 식별자를 더 이상 사용할 수 없는 서드 파티 쿠키 지원 중단 후 측정에서 광고 사기 방지 / 감지에 관한 안내입니다. | Google은 사기 방지 목적으로 서드 파티 쿠키에서 손실된 신호의 일부를 복구하는 데 도움이 되는 비공개 상태 토큰과 같은 도구를 도입했지만 새로운 개인 정보 보호 설정을 적용했습니다. Google은 다른 개인 정보 보호 샌드박스 변경사항과 함께 기능을 보존하기 위해 새로운 사기 방지 및 악용 방지 제안에 적극적으로 투자하고 있습니다. |
| 발급기관에서 출처 정보로의 비율 | 발급자-출처 정보 비율이 순 사용자를 식별하기에 충분히 높습니다. | 비공개 상태 토큰을 사용하여 전달할 수 있는 사용자 데이터를 더 명확하게 설명하도록 사양을 업데이트했습니다. 설계상 한 번에 최대 6개의 공개 키를 사용할 수 있으며, 이는 특정 사용자의 '상태'를 나타낼 수 있습니다. 이러한 키 세트는 60일마다만 업데이트할 수 있으므로 (긴급 키 순환이 필요한 드문 경우 제외) 시간이 지남에 따라 사용자 데이터를 추가로 조인하는 속도가 느려집니다. 새로운 웹 API는 제공되는 유용성과 제공되는 순수한 신규 사용자 정보 간에 균형을 유지합니다. Google은 PST가 서드 파티 쿠키 지원 중단의 영향을 받는 주요 사기 방지 사용 사례를 지원하는 동시에 사용자 개인 정보를 보호하는 데 적절한 균형을 맞추고 있다고 판단합니다. |
| 통합 가져오기 | fetch 통합은 복잡하고 불필요합니다. |
fetch를 활용하는 데는 장단점이 있으며 웹 생태계 내에서 표준화를 더욱 추진하고자 하지만 표준의 구체적인 모습을 파악할 때까지는 이러한 변경사항을 적용하기에는 이르다고 생각합니다. 표준이 등장하면 웹 개발자를 해당 표준으로 책임감 있게 전환하는 데도 최선을 다할 것입니다. |
| 스토리지 위치 | 비공개 상태 토큰 키 구성은 PrivacyPass 프로토콜과 동일한 위치에 저장해야 합니다. | Origin 체험판을 테스트하는 동안 개발자들은 .well-known 디렉터리 대신 일반 URL에 키를 저장하는 유연성을 선호한다고 말했습니다. PrivacyPass의 키 약속 형식은 키 세트가 암시적 '공개 메타데이터' 값을 허용하도록 설계된 버전에 적합하지 않습니다. PrivacyPass의 변형이 공개 메타데이터 (POPRF, 부분 RSA 블라인딩 또는 키 세트)로 표준화되는 경우 이를 지원하기 위해 향후 버전의 PST로 전환할 수 있습니다. |
| API의 헤더 구현 | API의 헤더 구현과 관련된 질문 | API가 표준화되고 이 API의 생태계 사용이 성숙해짐에 따라 이 API의 표준 비헤더 버전을 모두 지원하고 사용 빈도가 충분히 낮거나 발급/사용 요청을 다른 데이터와 연결하는 표준 방법에 관한 개발자 도구/지원이 충분한 경우 헤더 버전을 지원 중단할 수 있기를 바랍니다. 여기에서 문제를 논의하고 있습니다. |
| 등록 | 발급기관이 브라우저 공급업체에 등록하도록 하는 것이 실용적일까요? | 비공개 상태 토큰의 발급자 등록 절차를 설명하도록 사양을 업데이트했습니다. 자체 프로세스를 사용하지만, 나머지 개인 정보 보호 샌드박스 작업의 등록 계획과 유사합니다. 이 계획에서는 발급기관에 PST를 사용할 방법을 공개적으로 선언하고 사용자 개인 정보를 보호하는 기술적 제한사항을 확인하도록 요청합니다. |