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