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