개인 정보 보호 샌드박스 제안 및 Chrome의 응답에 관해 받은 생태계 의견을 요약한 2023년 4분기 분기별 보고서입니다.
CMA와의 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안의 이해관계자 참여 프로세스에 관한 분기별 보고서를 공개적으로 제공하는 데 동의했습니다 (약정의 문단 12 및 17(c)(ii) 참고). 개인 정보 보호 샌드박스 의견 요약 보고서는 의견 개요에 나열된 다양한 소스에서 Chrome이 받은 의견을 집계하여 생성됩니다. 여기에는 GitHub 문제, privacysandbox.com에서 제공하는 의견 양식, 업계 이해관계자와의 회의, 웹 표준 포럼이 포함되나 이에 국한되지 않습니다. Chrome은 생태계의 의견을 환영하며 얻은 정보를 디자인 결정에 통합하는 방법을 적극적으로 모색하고 있습니다.
의견 테마는 API별 보급률에 따라 순위가 매겨집니다. Chrome팀은 주어진 테마와 관련하여 받은 의견의 양을 집계하여 수량을 기준으로 내림차순으로 구성합니다. 일반적인 의견 테마는 공개 회의(W3C, PatCG, IETF), 직접 의견, GitHub 및 Google의 내부 팀과 공개 양식을 통해 표시되는 자주 묻는 질문의 토론 주제를 검토하여 파악했습니다.
보다 구체적으로는 웹 표준 기관 회의를 위한 회의록을 검토했으며, 직접 의견을 제공하기 위해 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 리스트, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 봉사 활동에 참여한 팀 간에 협력하여 각 API와 관련하여 나타나는 주제의 상대적인 보급률을 판단했습니다.
의견에 대한 Chrome의 대응에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 답변, 이 공개 보고 활동의 목적을 위한 입장을 판단한 내용을 토대로 개발되었습니다. 현재 주력하고 있는 개발 및 테스트 환경을 반영하기 위해 Topics, Protected Audience, Attribution Reporting API와 관련하여 특히 질문과 의견이 접수되었습니다.
현재 보고서 기간이 끝난 후에 받은 의견에 아직 Chrome 응답으로 간주되지 않을 수 있습니다.
약어 용어집
- 칩
- 독립적으로 파티션을 나눈 상태가 있는 쿠키
- DSP
- 수요측 플랫폼
- FedCM
- 제휴 사용자 인증 정보 관리
- FPS
- 퍼스트 파티 세트
- IAB
- 양방향 광고협회(Interactive Advertising Bureau)
- ID 공급업체
- ID 공급업체
- IETF : 인터넷 엔지니어링 태스크포스
- 인터넷 엔지니어링 태스크포스
- IP
- 인터넷 프로토콜 주소
- openRTB
- 실시간 입찰
- 연장전
- 오리진 트라이얼
- PatCG
- 개인 광고 기술 커뮤니티 그룹
- RP
- 신뢰 당사자
- 소셜 서비스 제공업체
- 공급측 플랫폼(SSP)
- TEE
- 신뢰할 수 있는 실행 환경
- UA
- 사용자 에이전트 문자열
- UA-CH
- 사용자 에이전트 클라이언트 힌트
- W3C
- 월드 와이드 웹 컨소시엄(World Wide Web Consortium)
- WIPB : 인터넷 보안 위원회
- 의도적인 IP 무시
일반적인 피드백(특정 API나 기술 없음)
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
3PCD 타임라인 | 3PCD 타임라인에 관한 자세한 정보를 공유하세요. | 테스트를 용이하게 하기 위해 Chrome은 2024년 1월 4일부터 기본적으로 사용자 1% 의 서드 파티 PC를 제한했습니다. Chrome은 CMA의 남아 있는 우려사항을 해결하기 위해 2024년 3분기부터 서드 파티 쿠키에 대한 지원을 점진적으로 중단하고 2024년 남은 기간 동안 계속 진행할 계획입니다. |
3PCD 타임라인 | 2024년 4분기 3PCD 도입 시기는 연말연시 시즌과 연계되어 게시자에게 부정적인 영향을 미칠 수 있기 때문에 그에 따른 영향입니다. | 서드 파티 PC를 지원 중단하기에 완벽한 시기는 없습니다. 1년 넘게 2024년 하반기에 서드 파티 PC를 지원 중단하겠다는 Google의 의도가 분명히 있었습니다. 정지 기간의 잠재적인 시기 등 CMA에 대한 YouTube의 약속은 변경되지 않았습니다. 4분기 시기에 대한 우려는 잘 알고 있지만, 일정을 변경하자 업계에 대한 준비 수준이 낮아진 것이 아닙니다. |
Chrome 테스트 (모드 A/b) | 모드 A와 모드 B에 대한 테스트 설정이 인스턴스별 또는 Chrome 프로필별로 이루어지나요? | Google에서는 여기에 있는 문서에 이 맥락에서 Chrome 브라우저가 Chrome 클라이언트(기기에 설치된 Chrome)를 나타낸다는 설명을 게시했습니다. 각각의 개별 사용자 데이터 디렉터리는 고유한 클라이언트를 구성합니다. |
무료 체험판 지원 중단 | 3PCD 무료 체험에 대한 자세한 정보를 공유하세요. | 3PCD 무료 체험에 관한 자세한 내용은 여기를 참고하세요. |
무료 체험판 지원 중단 | 2024년 1월 전에는 모든 사이트에 지원 중단 체험판 토큰을 제공할 시간이 부족합니다. | 지원 중단 트라이얼 등록이 시작되는 시점과 Chrome에서 진행하는 테스트 기간 중 쿠키의 1% 가 차단하기 시작하는 시점 사이에는 짧은 시간이 있습니다. 이러한 시간 제한을 해결하기 위해 Chrome은 참여 오리진에 참여 중인 오리진에서 지원 중단 체험판 토큰을 배포하는 동안 유예 기간을 제공합니다. 2024년 4월 1일까지 진행되는 유예 기간 동안, 지원 중단 트라이얼에 등록된 출처는 아직 토큰을 배포하지 않았더라도 Chrome에서 서드 파티 쿠키에 액세스할 수 있습니다. 이 유예 기간의 목적은 전환 단계에서 웹 호환성 문제가 발생하지 않도록 하는 것입니다. 유예 기간이 끝난 후에도 서드 파티 쿠키에 계속 액세스하려면 프로그램에 참여하는 출처에서 유예 기간이 끝나기 전에 지원 중단 체험판 토큰을 배포해야 합니다. |
Chrome 테스트 (모드 A/b) | 모드 B는 샘플에 너무 작아서 성능 저하를 정확하게 측정할 수 없습니다. | 트래픽의 비율과 웹의 사용자 및 기능에 미치는 위험 요소 간에는 신중한 균형을 유지해야 합니다. |
컨트롤 테스트 | 상당한 규모의 개발 리소스를 보유한 대규모 게시자만 테스트 기간 동안 실적을 파악하고 CMA에 전달할 수 있습니다. | 이미 게시자 서비스 제공업체가 더 광범위한 생태계와 통계를 공개적으로 공유하고 있으며, 개인 정보 보호 샌드박스 테스트가 증가함에 따라 이러한 추세는 계속될 것으로 예상됩니다. 또한 개인 정보 보호 샌드박스 API를 기반으로 빌드하는 애드테크 회사에서 라벨을 기반으로 한 보고와 같이 고객이 요구하는 기능을 계속 개발할 것으로 예상됩니다. |
타사 데이터 | 서드파티 데이터 회사에 대한 우려 | 서드 파티 데이터 회사에는 다양한 유형이 있습니다. 일부는 크로스 사이트 추적의 불확실한 방법으로 전환되어 두 배가 될 수 있습니다. 개인 정보 보호를 강화하는 기술을 사용하고 고객과 함께 새로운 가치 제안을 개발하는 기업도 있습니다. Google은 사용자 및 규제 당국의 요구가 점점 더 커지고 있는 방향으로 나아갈 방법을 찾고 있습니다. 변화는 진화와 혁신의 기회를 가져옵니다. |
Google Ad Manager | 게시자가 개인 정보 보호 샌드박스를 테스트할 수 있는 방법에 관한 Google Ad Manager 안내가 더 필요합니다. 보고서가 그 영향을 이해하기에 충분하지 않습니다. | Google Ad Manager 제공 답변: Google Ad Manager는 고객센터에서 Chrome에서 지원하는 테스트 라벨을 사용하여 테스트를 수행하는 방법을 설명했습니다. Ad Manager는 현재 게시자에게 Topics 및 Protected Audience에 관한 보고를 제공합니다. 의견 보고서가 작성된 시점을 기준으로 Ad Manager는 Protected Audience API를 통해 게재된 노출수를 보고할 수 있으며 특정 노출에 Topics API의 데이터가 있었는지 여부를 표시할 수 있습니다. Chrome에서 지원하는 라벨을 기반으로 한 세분화 보고와 같이 보다 정교한 보고에 관심이 있는 게시자는 Chrome에서 직접 라벨을 읽고 (Chrome 문서 사용) Ad Manager에 대한 광고 요청에서 키-값으로 전달하고, 키-값 보고로 전달하여 라벨에 대해 보고할 수 있습니다. |
테스트 인센티브 | 개인 정보 보호 샌드박스를 테스트하기에 충분한 시간과 향후 중요한 API 변경사항이 발생할 수 있다는 광고주의 우려 | 더 많은 시간을 원한다는 사람도 있지만, 업계에서는 타임라인을 변경하면 생태계의 대비 태세가 약화되는 것이 아니라 오히려 더 악화될 것이라는 의견을 반복적으로 들었습니다. 서드 파티 쿠키 지원 중단 타임라인은 CMA의 남아 있는 경쟁 관련 우려사항을 해결하기 위해 노력하고 있지만, 모든 사용자가 2024년에 3PCD에 대비하는 것이 좋습니다. 다른 기술과 마찬가지로 개인 정보 보호 샌드박스 API도 계속해서 발전할 것입니다. 이러한 발전은 기술의 발전과 생태계의 입력 방식에서 비롯됩니다. Google은 변화를 이룰 것이며 기술의 변화로 인해 사용이 무기한 저해되어서는 안 된다고 생각하지 않으므로 앞으로도 책임을 질 것입니다. |
CTV : 스마트 TV | 선형 또는 CTV 동영상을 지원하는 경로가 없습니다. | Google은 CTV 사용 사례를 더 많이 탐구하기를 기대하지만 CTV 기기용 API가 Chrome의 3PCD를 방해하지는 않을 것이라고 생각합니다. |
광고주 광고 서버 | Google에서 광고 타겟팅을 DV360으로 전환하는 것으로 보입니다. 광고주 광고 서버에는 어떤 지원이 제공되나요? | Chrome에서 제공한 응답: PA API는 광고주 광고 서버에서 iFrames / Fenced Frames 및 Beacon 보고를 사용하여 사용자에게 표시되는 광고를 게재하고 측정할 수 있도록 설계되었습니다. 또한 업스트림 및 다운스트림 업체와 협력하여 현재와 같이 게재 흐름에 통합할 예정입니다. |
Google Ads 데이터 관리 도구 | 최근에 발표된 'Google Ads 데이터 관리 도구'는 고객 일치 타겟팅 및 향상된 전환을 기반으로 하며, 광고주는 퍼스트 파티 고객 데이터를 Google과 공유하여 서드 파티에서 수행하는 모든 마케팅 기능을 유지할 수 있도록 지원합니다. 이 새로운 기능은 CMA에 대한 Google의 약속과 어떻게 일치하나요? | Google Ads 제공 답변: Google Ads 데이터 관리 도구는 광고주가 고객 일치 타겟팅 (CM) 및 향상된 전환 (EC)에 사용할 광고주 데이터 스토리지 시스템 (클라우드 시스템)의 퍼스트 파티 데이터 업로드를 용이하게 하므로 기술 리소스가 적은 중소 규모 비즈니스가 더 쉽게 이용할 수 있습니다. Google Ads 데이터 관리 도구는 Google O&O 또는 서드 파티 게시자에 게재되는 광고의 주소 지정 가능 여부 또는 측정 가능성과 관련하여 CM 또는 EC가 새로운 기능을 사용하도록 설정하지 않습니다. Google의 광고 플랫폼은 다른 광고 기술 회사와 동일한 방식으로 개인 정보 보호 샌드박스 기술에서 사용할 수 있는 기능을 사용할 수 있습니다. |
크롬 설정 | Chrome의 내부 설정 페이지에 쿠키 크기에 대한 자세한 정보가 표시됩니다. | 요청하신 기능은 이미 Chrome 개발자 도구에서 사용할 수 있습니다. 설정 페이지에서 이 기능을 우선적으로 제공해야 하는 이유에 대한 추가 의견도 보내주시기 바랍니다. |
휴리스틱 | 3PCD 중에 중요한 사용자 환경을 유지하기 위해 Chrome은 어떤 휴리스틱을 배포하고 있나요? | GitHub에서 이 질문에 대한 답변을 확인하세요. |
브라우저 버전 | 안정화 버전이 불안정한 Chrome 브라우저와 다른가요? | 정식 출시 주기와 Chrome 메이저 버전이 대략적으로 비교하면 됩니다. |
규정 준수 | Chrome에서 SOX 관련 보고서를 제공할 수 있나요? | Chrome은 SOX 관련 보고서를 제공하지 않습니다. 개인 정보 보호 샌드박스 API는 Chrome에서 사용자가 방문하는 웹사이트에 제공하는 여러 웹 API 중 하나입니다. 모든 웹 API와 마찬가지로 API 호출자는 개인 정보 보호 샌드박스 API를 사용하기 위해 Chrome과 계약을 체결하지 않습니다. 액세스 권한은 API 호출자가 기술 요구사항을 충족하는지, 사용자가 적절한 설정을 사용 설정했는지에 따라 달라집니다. 이 경우 API 호출자는 저장할 데이터, 배치할 입찰, 요청할 보고 등을 포함하여 API 사용 방법을 결정합니다. |
규정 준수 | 더 많은 질문에 답변하기 위해 개인 정보 보호 샌드박스 규정 준수 FAQ를 확대합니다. | 의견을 보내주셔서 감사합니다. 계속해서 FAQ를 구성할 계획입니다. |
Chrome 질문 | Chrome에서 서드 파티 쿠키 지원 중단이 Android WebView (삽입된 브라우저)에서 서드 파티 PC를 사용할 수 있는지에 영향을 미치나요? | Google에서는 현재 교차 앱 및 웹 기여 분석 측정을 사용 설정하는 것 외에 3PCD 또는 개인 정보 보호 샌드박스 API 출시 및 테스트 단계에는 WebView를 포함하지 않습니다. |
API 질문 | 스폰서 제품의 클릭수와 노출수는 어떻게 추적할 수 있나요? | 이 사용 사례는 Attribution Reporting API에 적용됩니다. |
타임라인 | 3PCD 일정이 변경된 이유는 무엇인가요? | 여기에서 이유를 살펴보았습니다. |
Chrome 확장 프로그램 SSO | 3PCD 이후 웹사이트와 Chrome 확장 프로그램 간에 싱글 사인온(SSO) 사용 사례를 허용합니다. | 이 문제를 논의 중이며 추가 사용 사례에 관한 의견을 보내주시기 바랍니다. |
API 사용량 | Google에서 API를 테스트할 파트너 목록을 확인할 수 있나요? | 자신을 공개적으로 확인한 테스터의 세부정보는 GitHub에서 다음 API를 통해 확인할 수 있습니다. - Topics API - Protected Audience API - Attribution Reporting API - 공유 저장소 - CHIP |
Utiq 이니셔티브 | Utiq 이니셔티브에 대한 Chrome의 관점은 무엇인가요? | 자세한 내용은 여기를 참조하세요. |
Chrome 질문 | 서드 파티 PC 없이 탐색하는 사용자를 어떻게 감지하나요? | 서드 파티 쿠키를 감지하기 위한 명시적인 설정은 없습니다. 일반적인 '기능 감지' 접근 방식의 경우 iframe / 크로스 사이트 요청을 만들고 필요한 사용 사례와 유사한 쿠키를 설정하는 것이 가장 가까운 솔루션이 될 것입니다. |
Chrome 질문 | 시크릿 모드에서 탐색하는 것은 플래그 테스트를 실행하는 것과 같나요(--test-third-party-cookie-phaseout 명령줄 플래그를 사용하여 Chrome을 실행)? | 시크릿 모드는 플래그와 다릅니다. 이 플래그는 서드 파티를 차단할 뿐만 아니라 FedCM 및 서드 파티 스토리지 파티셔닝도 사용 설정합니다. |
Chrome 질문 | 1% 발생 시 각 지역/국가에 예상되는 3PCD의 영향에 대한 자세한 내용 | 고객은 지역적 차이가 있을 수 있지만 전 세계에서 무작위로 1% 에 포함됩니다. 예를 들어 기기와 Chrome 버전의 배포에 차이가 있을 수 있습니다. |
개인 정보 보호를 강화하는 대체 기술 | 개인 정보 보호를 강화하는 대체 기술은 Chrome 및 Android에서 데이터 독점을 방지하기 위해 개인 정보를 보호하는 교차 도메인 추적을 실행하도록 허용해야 합니다. | Google에서 제공하는 기본 구성 요소뿐만 아니라 개인 정보 보호 샌드박스가 아닌 구성 요소를 바탕으로 개인 정보 보호 강화 기술을 개발할 수 있는 많은 기회가 개발자에게 있습니다. |
CookieGraph 연구 | 개인 정보 보호 샌드박스 프레임워크 내 이 자료에 설명된 대로 CookieGraph 메서드에 관한 Chrome의 관점은 무엇인가요? | 현재 이 문서를 검토 중이며 추가적인 의견을 보내주시기 바랍니다. |
등록 및 증명
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
등록이 제한적임 | Google에서는 개인 정보 보호 샌드박스 API의 구체적인 이용약관을 도입했습니다. 약관에 따라 게시자가 동의한 방문자를 신원 솔루션 내에서 테스트 및/또는 통합하는 방문자에 특화되어 있는 회사를 효과적으로 차단해야 합니다. 이용약관에 따라 개인 정보 보호 샌드박스 내에서의 운영 권한이 부당하게 제한됩니다. | 등록 및 증명 프로세스에는 API 이용약관 동의가 포함되지 않습니다. 등록 및 증명은 개인 정보 보호 샌드박스 API를 호출하는 개발자와 이들이 액세스하는 데이터를 사용하는 방식에 관한 투명성을 개선하기 위한 메커니즘입니다. 특히 증명은 증명 개발자가 사이트 또는 앱에서 사용자를 식별하는 데 API를 사용하지 않으며 API의 개인 정보 보호 기능을 우회하지 않는다는 공개 진술입니다. 증명에는 개발자의 다른 데이터 또는 기술 사용에 대한 진술을 할 필요가 없습니다. |
개인 정보 보호 샌드박스 등록 | 증명을 위해 담당자 / 이메일 주소를 업데이트하는 방법 | 등록 정보는 등록 양식을 사용하여 업데이트할 수 있습니다. 자세한 내용은 여기에서 확인할 수 있습니다. |
개인 정보 보호 샌드박스 등록 | 증명을 사용할 수 없는 경우 액세스 차단 시나리오를 명확히 설명해 주시겠어요? | 개인 정보 보호 샌드박스에서는 기술 담당자가 등록된 사이트의 증명 파일을 다시 설정할 수 있는 3주 후, 등록된 회사의 (측정 및 관련성 API) 액세스를 거부합니다. |
개인 정보 보호 샌드박스 등록 | 비프로덕션 엔드포인트를 사용하여 로컬 환경에서 API를 테스트하려면 어떻게 해야 하나요? | 이 질문에 대한 답변을 여기에서 확인할 수 있습니다. |
관련성 있는 콘텐츠 및 광고 표시
주제
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
다양한 유형의 이해관계자를 위한 유용성 | 게시자는 주제가 데이터 기반 판매에 미치는 영향을 우려하고 있습니다. 규모가 더 큰 사이트에는 일반적인 '뉴스' 주제가 할당되며, 데이터를 특정 게시자에 연결하지 않습니다. 전문 게시자는 그 대가로 제한된 정보에 대한 데이터를 제공합니다. | Google은 보다 일반적인 관심 도메인을 가진 사이트가 틈새 관심분야 도메인을 제공하는 사이트에 비해 세부 주제를 덜 제공할 가능성이 높다는 점을 잘 알고 있습니다. 그러나 모든 틈새 사이트가 상업적으로 가치 있는 주제를 제공하는 것은 아닙니다. 또한 이러한 상황은 서드 파티 쿠키 기반 광고 관련성 시스템에서 일부 사이트가 다른 사이트보다 더 많은 가치를 제공한다는 현 상황을 반영합니다. 게시자는 Topics (및 개인 정보 보호 샌드박스)를 통해 제휴 광고 기술 회사에서 자신의 정보가 사용되는 방식을 더 세밀하게 제어할 수 있습니다. 또한 Topics를 통해 제공되는 정보는 기존 신호보다 훨씬 구체적입니다. |
게시자 광고 서버 | 전용 광고 서버를 사용하는 게시자 광고 서버는 Topics API를 직접 관찰하지 못할 수 있습니다. | 여기에서 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다. |
증명 | 컨텍스트 간 정보 전송으로 인해 알려진 바람직하지 않은 결과를 해결하기 위해 증명 요구사항 확대 | 현재, 증명은 이러한 광범위한 위험을 다루는 것이 아니라 API 악용 문제를 해결하기 위한 것입니다. |
Topics 트래픽 양 | 현재 발생하는 노출수는 테스트하기에 충분하지 않습니다. | Chrome은 프로그래매틱 생태계에서 제공되는 Topics의 양에 관한 의견을 인지하고 있습니다. Google은 브라우저 내부 및 관련 테스터 사이에서 발생할 가능성이 있는 이유를 조사하고 있습니다. 필요한 경우 Chrome은 사용자 개인 정보를 보호하면서 적용 범위를 늘리고 충분한 규모로 테스트를 지원하기 위해 사용 가능한 잠재적 API 설계 변경사항을 평가합니다. |
API 사용량 | Topics API 비율 제한이 있나요? | 악용을 방지하고 사용자의 웹 환경을 보호하기 위해 Topics 속도 제한이 있습니다. 자세한 내용은 여기에서 확인하실 수 있습니다. |
V2 분류 | 공개 RTB 프로토콜에 포함될 주제 세부정보에 대한 IAB의 가이드라인이 있나요? | 예. Open RTB 프로토콜 내에 Topics를 포함하는 것에 대한 IAB의 가이드라인은 여기에서 확인할 수 있습니다. |
퍼스트 파티 신호에 미치는 영향 | 세분화된 주제 분류 v2를 이 세분화된 세분화 (상위 주제)의 가장 높은 값을 반환하는 프로세스와 결합하여 광고의 데이터 시장을 왜곡합니다. | Google의 대응은 3분기와 동일합니다. "Topics 분류가 더 세분화되면 게시자 퍼스트 파티 데이터 기반 솔루션 또는 직접 거래에 의존하는 솔루션과 같은 다른 솔루션의 매력이 간접적으로 감소할 수 있지만, Topics API를 개발하는 과정에서 주요 목표는 모든 이해관계자 모두를 위해 3PCD 이후 관심 기반 광고 사용 사례를 최대한 효과적으로 지원하는 것입니다. Google은 Topics의 유용성을 높이면 전반적인 경쟁이 개선되고 생태계 전체에 도움이 된다고 믿습니다." |
테스터 목록 | 게시자 중 Topics 및 PA API를 어떻게 채택하고 있나요? | Google은 이러한 정보를 공유할 수 없습니다. 테스터 목록을 참고하여 게시자가 테스트 상태 공유에 동의할 수 있습니다. |
주제 선택 | 사용자가 관심 있는 주제를 적극적으로 선택할 수 있도록 허용하시겠어요? | Google은 사용자가 적극적으로 주제를 추가할 수 있도록 지원하는 방안을 고려해 왔습니다. 단기적으로는 이 문제를 해결할 계획은 없지만, 더 장기적으로 탐색할 의향이 있습니다. |
주제 선택 | 광고 기술이 사이트에 주제를 관찰하는 코드를 가지고 있다면 관찰할 수 있는 주제가 무엇인지 알 수 있나요? | 광고 기술 회사는 사이트와 관련된 주제를 결정할 수 있습니다. 지연 시간 비용이 발생할 수 있으므로 API는 이 정보를 실시간으로 공유하지 않습니다. |
V2 분류 | Topics는 최대 3개의 주제를 반환할 수 있으므로 분류 v2가 출시될 때 예상되는 동작은 무엇인가요? | API는 여전히 최대 3개의 주제를 반환하며 응답에 각 주제에 대한 관련 분류 버전을 포함합니다. |
(이전 분기에도 보고됨) 주제 관찰 |
게시자가 페이지 콘텐츠 (예: 머리 또는 본문)에 따라 주제를 분류할 권한을 Chrome에 부여하도록 허용합니다. | 이에 대한 Google의 대응은 3분기와 동일합니다. "Google에서는 이전에 페이지 콘텐츠에 따라 사이트를 주제별로 분류하는 기능을 제공하는 방안을 고려했으나, 개인 정보 보호 및 보안 문제로 인해 더 이상 진행하지 않기로 결정했습니다. 이 제안으로 이러한 우려를 어느 정도 완화할 수 있지만 어느 정도까지는 명확하지 않습니다. 향후 CMA 실험 기간으로 인해 3PCD 이전에는 이러한 변경사항이 적용되지 않을 것으로 예상됩니다. 추가 의견이 있으면 여기에서 보내주세요." |
주제 선택 | 도메인이 일반적이라는 가정하에 도메인이 Topics로 어떻게 분류되고 있나요? | Google에서는 호스트 이름만 사용하여 사이트를 Topics로 분류합니다. 광범위하게 분류된 사이트는 이로 인해 영향을 받지 않습니다. 이는 사이트의 문맥 정보가 사이트의 입찰에 항상 사용되어 광범위한 주제에 보다 구체적인 정보를 제공하기 때문입니다. |
V2 분류 | 주제가 다른 표준 (예: IAB)에 더 부합하기를 바랍니다. | 게시자가 IAB와 Topics 분류 간에 더 긴밀한 조정을 원하는 이유를 자세히 알아보고자 합니다. Topics API를 채택하기 위해 취해야 할 단계는 무엇이며, 더 뚜렷한 분류가 이러한 단계에 어떤 영향을 주나요? Google에서는 Topics 분류와 IAB 콘텐츠 분류 간의 매핑을 공개하는 것을 고려하고 있습니다. 이렇게 하면 게시자가 직면한 문제를 해결할 수 있는지 이해하는 데 도움이 될 수 있습니다. |
데이터 저장 및 사용량 | 데이터가 저장되는 방식과 데이터가 전송되는 위치에 대해 더 자세히 알고 계신가요? | 주제 정보는 생성되어 사용자 기기에 로컬로 저장됩니다. 요청 시 API는 호출자에게 최대 3개의 주제를 반환합니다. Google의 관점에서 발신자는 Topics 정보를 처리하고 저장할 때 현지 규정을 준수할 책임이 있습니다. 또한 모든 호출자는 사이트 전체에서 사용자를 재식별하는 데 Topics를 사용하고 있지 않음을 증명해야 합니다. 자세한 내용은 개인 정보 보호 관련 규정 준수 FAQ를 참고하세요. |
V2 분류 | v1에서 v2로 전환하는 동안 Topics Taxonomy Upgrade의 영향과 브라우저 상태에 미치는 영향 | 이전 분류로 추론된 주제는 계속 사용할 수 있으며 만료 (4주 후)될 때까지 광고 기술에서 가져올 수 있습니다. |
API 설명 | Topics API의 사용자 환경에 오해의 소지가 있습니다. | 이 의견을 UX팀에 공유했습니다. |
API 질문 | Yahoo 도메인이 일반적이라는 점을 고려하여 Topics로 어떻게 분류되고 있나요? | Google에서는 호스트 이름만 사용하여 사이트를 Topics로 분류합니다. 광범위하게 분류된 사이트는 이로 인해 피해를 입지 않는다는 점을 이해해야 합니다. |
주제 가용성 비율이 낮음 | 테스터에게 Google Ad Manager로부터 적은 양의 Topics를 받고 있습니다. | Google Ad Manager는 노출 범위를 개선하기 위해 몇 가지 최적화를 실행했습니다. 즉, 구매자의 노출 범위가 증가했을 것입니다. 적용 범위를 제한할 수 있는 몇 가지 예상 요인이 있습니다 (예: 사용자 환경설정, 호출자의 관찰 요구사항, 일부 지연 시간/타임아웃). |
Protected Audience API (이전 명칭: FLEDGE)
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
차별화 | SSP가 새로운 입찰에서 차별화를 가져오는 방식이 명확하지 않기 때문입니다. | Protected Audience 또는 기타 개인 정보 보호 샌드박스 API를 전면에 내세우는 여러 전략 계획에 대해 들었습니다. 더 큰 그림으로 보면 생태계의 판매측에서는 보편적인 교차 사이트 식별자가 줄어드는 것을 개인 정보 보호뿐만 아니라 상업적 측면에서도 긍정적인 단계라고 보는 경우가 많습니다. 이러한 변화를 수용하는 중소기업과 대기업은 기회를 찾을 가능성이 높습니다. |
광고 렌더링 | 광고 렌더링을 위한 유일한 수단인 Chrome은 혁신을 저해합니다. Protected Audience 렌더링은 네이티브 광고에 관한 오늘날의 표준의 실현 가능성을 떨어뜨립니다. | 지금까지 브라우저에서 광고를 렌더링하는 데는 항상 브라우저 기술을 사용하여 렌더링해 왔습니다. 이 사실은 변하지 않습니다. 이 문제는 향후 Protected Audience와 함께 Fenced Frames를 사용해야 한다는 계획에만 해당하는 문제일 수 있습니다. 이러한 계획을 '미래'로 내놓는 이유 중 하나는 바로 Fenced Frames 기술이 광고 렌더링에 관한 생태계의 혁신과 차별화를 지원하기를 원하기 때문입니다. 관심 있는 개발자와 기업은 네이티브 광고 접근 방식을 지원하는 방법을 비롯하여 Fenced Frames의 방향에 대해 의견을 구해야 할 때가 있습니다. |
입력 | Concern Protected Audience API (PA API)는 많은 광고 기술이 개인 정보 보호 샌드박스 API를 살펴보기 시작하면서 거의 완전한 것으로 제공되었습니다. | API는 사용 과정에서 얻은 교훈과 Chrome 내부 및 외부에서 얻은 새로운 아이디어를 바탕으로 계속 발전할 것입니다. 현재 정식 버전으로 제공되는 관련성 및 측정 API는 안정적이지만 그렇다고 개발이 중단된 것은 아니며 추가적인 의견을 환영합니다. |
입찰 설계 | Protected Audience 설계는 모든 잠재고객 구축 및 광고 선택 로직을 구매측 플랫폼에 배치하므로 SSP가 플랫폼에서 실행되는 캠페인에 대한 잠재고객 구축 및 광고 선택 로직을 제공하는 기능을 제거할 수 있습니다. | Protected Audience는 잠재고객을 만드는 사람과 잠재고객에 대해 입찰하는 사람에 구애받지 않습니다. SSP는 입찰에 사용 가능한 관심분야 그룹 (IG)을 만들 수 있습니다. SSP가 입찰 로직을 제공할 수도 있는데, 이는 많은 SSP가 대행사에게 직접 보내는 방향과 일치하는 것으로 보입니다. 항상 추가 사용 사례를 위한 여지는 있지만 Protected Audience의 기반은 잠재고객 생성 및 활성화에 대한 다양한 접근 방식을 지원할 수 있을 만큼 유연합니다. 또한 이러한 기반의 개인 정보 보호 특성은 원시 사용자 수준 데이터가 사이트 간에 공유되지 않음을 의미합니다. |
입찰 설계 | Protected Audience 입찰은 광고주와 게시자 간의 총 중개자 수 또는 특정 광고 기회의 중복을 줄이기 위한 생태계 공급 경로 최적화 (SPO)의 노력과 반대되나요? | 아니요. Protected Audience에서 낙찰된 광고는 최대 2개의 판매자 항목 (예: SSP 및 게시자 광고 서버)을 통과하며 구매자가 게시자와의 직접 통합을 구축하는 경우에는 극히 적은 수의 판매자 항목을 통과합니다. 여러 중개자를 통해 동일한 요청을 복제할지는 여전히 게시자가 결정합니다. Protected Audience는 어느 쪽으로든 영향을 미치면 안 됩니다. Protected Audience 입찰은 크로스 사이트 사용자 데이터가 유출되지 않도록 오늘날의 서버 간 실시간 시스템 외부에서 이루어집니다. 이 경우 광고 요청이 중복된다고 말하는 경우도 있습니다. 개인 정보 보호를 기술적으로 입증할 수 있으려면 몇 가지 절충점이 필요합니다. 그러나 장기적으로 보면 생태계에서 기존의 서버 측 입찰 없이 Protected Audience를 사용하기로 결정할 수도 있습니다. 이러한 선택을 통해 공급 경로를 더욱 최적화할 수 있습니다. |
입찰 설계 | Protected Audience는 SSP가 페이지에서 실행되는 '마지막' 입찰이 되는 경우가 드물지만 API 설계에 의해 이 모델로 강제 전환되는 모델로 전환됩니다. | 이에 동의하지 않습니다. 앞서 살펴본 얼리 어답터의 구현은 구성요소 입찰에 참여하는 SSP가 Protected Audience 입찰이 실행되기 전에 발생하는 문맥 입찰의 결과를 능가하는 데 도움이 됩니다. Protected Audience의 SSP 구성요소 입찰 출력은 전체 문맥 입찰이 실행된 후 마지막으로 고려됩니다. |
입찰 설계 | 문맥 입찰은 Protected Audience 입찰에 정보를 제공하는 입찰 기회에 관한 데이터 신호를 제공하는 데만 관련이 있을 수 있습니다. | 문맥 입찰은 거래, 퍼스트 파티가 아닌 잠재고객 타겟팅 캠페인, 수많은 상황별 시나리오 등 여러 가지 이유로 여전히 관련성이 있을 것으로 예상됩니다. 또한 IG가 없거나 Protected Audience의 입찰가가 하한선에 도달하지 못하거나 광고 품질 규칙을 준수하지 못하는 경우에도 유용합니다. |
트래픽 형태 | DSP는 고정된 QPS로 운영됩니다. Protected Audience 입찰에 적합하게 되면 기존 인프라의 유용성이 저하됩니다. | 아시다시피, 초당 쿼리 수와 관련하여 변경되는 점은 많은 SSP가 DSP에 요청을 보낼지 여부를 결정하는 기능으로 크로스 사이트 ID를 사용한다는 것입니다. 이는 게시자가 Protected Audience 입찰을 실행하려는지와 관계없이 적용됩니다. Google은 여러 SSP의 트래픽 형태를 살펴본 후 캐싱 및 컨텍스트 기반 필터링을 비롯한 솔루션을 찾았습니다. 시간이 지남에 따라 개발자는 비공개 집계를 활용하여 DSP 입찰 선호도를 더 잘 이해하고 그에 따라 필터링할 수 있을 것으로 예상됩니다. 궁극적으로 교차 사이트 식별자를 중심으로 구축된 일부 기존 인프라는 더 이상 유용하지 않을 것입니다. |
사용 가능한 신호 | 입찰이 발생할 때 사용할 수 있는 모든 신호의 명확성이 부족하며 문맥 입찰의 순서 지정 방식은 불리합니다. | 일반적으로, 입찰자의 경우, IG가 생성될 때 문맥 입찰과 실시간 키-값 조회를 통해 정보가 제공될 수 있습니다. 채점자의 경우 입찰이 구성될 때 페이지 및 문맥 입찰에 대한 문맥 정보, 광고 renderUrl의 실시간 키-값 조회를 비롯한 정보를 제공할 수 있습니다. |
(이전 분기에 보고됨) 동영상 렌더링 |
Protected Audience 및 Fenced 프레임을 사용한 동영상 렌더링 지원 | Google의 응답은 이전 분기와 동일합니다. "Protected Audience API는 iframe에 의존하는 메커니즘을 사용하여 동영상 렌더링을 지원합니다. 하지만 아직 분리 프레임과 호환되는 솔루션을 설계하지 못했으며 이 때문에 분리 프레임 시행을 2026년으로 연기하기로 했습니다. 즉, 파트너가 지금 펜스된 프레임을 시행하기로 결정하면 해당 파트너는 동영상을 지원하지 않게 됩니다." |
동영상 렌더링 | iframe 내 동영상에 대한 PA API 지원은 HTML5 동영상으로 제한되며 널리 사용되는 VAST 표준을 지원하지 않습니다. | 현재 Protected Audience에서 사용할 수 있는 iframe 렌더링 메커니즘을 사용하여 VAST 기반 광고를 구현할 수 있습니다. 이를 위해서는 구매자, 판매자 및 게시자 광고 플랫폼 측면에서 새로운 엔지니어링이 필요하다는 점을 인지하고 있으며, Google은 VAST가 과거에 사용하던 방식에서 쉽게 전환할 수 있도록 계속 노력할 것입니다. |
(이전 분기에 보고됨) 최상위 수준 입찰 |
Google Ad Manager에 최상위 PA API 입찰에 대한 관리 권한을 부여하지 않고 Google의 게시자 광고 서버를 사용할 수 있습니다. | Google의 대응은 이전 분기와 동일합니다. 'Google Ad Manager 제공 응답: Google Ad Manager의 Protected Audience API 계획에는 다음과 같은 이유로 최상위 Protected Audience 입찰을 제어하지 않는 Google의 게시자 광고 서버 지원이 포함되지 않습니다. 게시자 광고 게재 시장에서 고객에게 적절한 서비스를 제공하려면 Google의 게시자 광고 서버가 최상위 Protected Audience 입찰을 계속 제어해야 합니다. 게시자 광고 서버로서 우리의 역할은 게시자가 초과 예약 없이 직접 판매 캠페인을 협상하고, 직접 예약의 속도를 조절하고 최적으로 게재할 수 있도록 예측을 제공하는 것입니다. 이렇게 하려면 최종 입찰을 실행하여 요건을 충족하는 모든 직접 및 간접 수요를 비교해야 합니다. 예측 및 예산 소진 속도는 게시자가 광고 서버에 기대하는 핵심 기능입니다. 정확한 예측 없이는 게시자가 인벤토리를 초과 판매하여 비즈니스 평판을 떨어뜨릴 수 있습니다. 광고주와의 예약 계약을 이행하지 못하면 게시자와 광고주의 직접 관계에 타격을 주어 게시자 비즈니스에 상당한 영향을 미칠 수 있으므로 예산 소진 속도 또한 중요합니다. 따라서 Google에서는 최상위 수준의 Protected Audience 입찰을 실행하는 게시자 광고 서버의 활동을 게시자 광고 서버의 다른 활동과 별개로 간주하지 않습니다.' |
(이전 분기에 보고됨) directFrom SellerSignals |
directFromSellerSignals 를 사용하면 Google Ad Manager에서 게시자가 문맥 입찰의 가격을 보지 못하게 할 수 있습니다. |
Google의 응답은 이전 분기와 동일합니다. 'Chrome 응답: runAdAuction()에 전달된 정보는 판매자가 자체 iframe에서 runAdAuction()을 호출하지 않는 한 판매자로부터 온 것으로 알려져 있지 않습니다. 다중 판매자 입찰에서는 모든 판매자가 runAdAuction()을 호출하는 프레임을 생성하도록 하는 것이 불가능합니다. directFromSellerSignals는 판매자의 출처에서 로드된 하위 리소스 번들에서 콘텐츠를 로드하여 이 문제를 해결했습니다. 이렇게 하면 판매자 입찰 구성에서 입찰에 전달된 정보의 신뢰성 및 무결성을 조작할 수 없습니다. 기술 제공업체가 Protected Audience 입찰에 전달하는 정보를 파악하기 위해 Protected Audience API를 사용하려는 게시자는 해당 기술 제공업체에 이 기능을 요청할 수 있습니다. Google Ad Manager 제공 답변: Google은 수년간 입찰 공정성에 주력해 왔습니다. 미보장 광고 항목 가격을 비롯한 게시자의 미보장 광고 소스의 가격은 입찰에 참여하기 전에 다른 구매자와 공유되지 않으며, 이후 프랑스 경쟁청에 대한 약속에서 다시 한 번 말씀드립니다. Protected Audience 입찰의 경우 directFromSellerSignals를 활용하여 약속을 지키고 다중 판매자 입찰에서 입찰이 완료되기 전에 입찰 참여자의 입찰가를 다른 입찰 참여자와 공유하지 않습니다. 명확히 하자면 이 업데이트에 설명된 대로 문맥 입찰의 가격을 자체 구성요소 입찰과도 공유하지 않습니다." |
(이전 분기에 보고됨) K-익명성 값 |
'K'에서 'k-anon'까지의 값은 어떻게 결정되며 언제 게시되나요? | Google은 2023년 12월에 K-익명성 값을 게시했습니다. 3PCD 프로세스가 시작된 후 k-익명성 기준점을 최종 값인 50 (k=50)으로 올리고 업데이트 기간을 1시간 (p=1)으로 설정합니다. K-익명성 값 50은 유용성과 개인 정보 보호 사이의 최적의 균형을 제공하는 것으로 평가되었습니다. 이 값은 기본적인 봇 공격을 차단하고 개인 정보 차등 보호를 유지하기에 충분하며, API가 의도한 사용 사례에 계속 유용할 만큼 충분히 낮습니다. |
(이전 분기에 보고됨) forDebugOnly |
3PCD 이후 계속되는 경우 forDebugOnly.reportAdAuctionWin이 오용될 수 있습니다. | 디버깅 사용 사례를 장기적으로 계속 지원하는 방법에 관한 제안을 여기에서 공유했습니다. 제안에 관한 추가 의견을 보내주시기 바랍니다. |
(이전 분기에 보고됨) 동일 출처 정책 |
하위 도메인을 허용하도록 동일 출처 정책의 완화를 요청합니다. | 이 요청은 검토 중이며 여기에서 논의했습니다. |
(이전 분기에 보고됨) 광고 구성요소 크기 |
광고 구성요소 수를 20개에서 40개로 늘립니다. | 10월 4일 WICG 통화와 이 GitHub 문제를 통해 이 요청에 대해 논의해 왔으며 2024년 1분기 말까지 해결할 계획입니다. |
(이전 분기에 보고됨) 키-값 서버 키 만료 |
해당 IG가 만료된 후 서버 키를 삭제하는 방법을 설명합니다. | TTL 관리는 복잡성을 줄이기 위해 TEE 외부에서 수행하는 것이 더 좋으며 여기에서 추가 의견을 보내주시기 바랍니다. |
관심분야 그룹 트리거 | 단일 IG가 단일 구성요소 입찰 내에서 여러 generateBid를 트리거할 수 있나요? | 브라우저가 IG의 generateBid() 함수를 호출할 때마다 해당 IG는 입찰가를 반환할 수 있습니다. 예를 들어 다중 판매자 입찰에서 IG가 구성요소 입찰 중 하나에서 매번 여러 번 호출될 수 있습니다. 이 동작을 활성화/지원하기 위해 IG 소유자가 명시적으로 취해야 할 조치는 없습니다. |
규정 준수 관련 질문 | 사용자의 Chrome 브라우저를 통해 수집되는 동의의 범위는 어떻게 되나요? | 자세한 내용은 개인 정보 보호 관련 규정 준수 FAQ에서 '개인 정보 보호 샌드박스는 Chrome의 개인 정보 보호 관련 규정 준수에 어떻게 접근하나요?'를 참고하세요. |
멀티 태그 입찰 | 다중 태그 입찰을 사용하려면 어떻게 해야 하나요? | Google은 이 요청을 평가하고 있습니다. 여기에서 추가 의견을 보내주시기 바랍니다. |
IP 보호 가용성 | 공지된 날짜까지 IP 보호가 준비되지 않은 경우 펜스 프레임 시행 및 이벤트 수준 보고 삭제와 같은 Protected Audience 기능 일정에 어떤 영향을 미치나요? | 여기에서 언급했듯이 Protected Audience 일정은 다른 개인 정보 보호 기능 출시 일정과 연결되어야 합니다. |
modelingSignals | 표시 및 클릭 정보만 인코딩할 수 있는 모델링 신호 외에 새 필드를 요청합니다. | Google은 이를 통해 얻을 수 있는 유틸리티를 잘 알고 있으며 요청을 평가하고 있습니다. 여기에서 추가 의견을 보내주시기 바랍니다. |
음성 IG | 일반 IG가 음의 IG 이름을 지정하도록 허용할 수 있나요? | 현재 설명에 따라 그렇게 할 수는 없지만, 이것이 요구사항인 이유에 대한 생태계의 추가 의견을 환영합니다. |
API 사용량 | generateBid() 수준에서 집계 보고서를 생성한 다음 | 비공개 집계는 generateBid 내에서 호출할 수 있습니다. |
매크로 | IFrame의 매크로를 통해 perBuyerSignals에서 서드 파티로 신호를 라우팅합니다. | 여기에서 이 사용 사례에 대해 논의하고 있으며 추가 의견을 기다리고 있습니다. |
API 사용량 | 신뢰할 수 있는 점수 신호 가져오기에서 오류가 반환되어도 scoreAd()는 계속 호출되나요? | 가져오기 호출이 실패해도 ScoreAd()가 계속 실행됩니다. |
API 사용량 | 델타/스냅샷 파일의 riegeli 파일에 metadata.sha_num을(를) 씁니다. | 차단 해제할 수 있도록 현재 샤드_번호에 대한 지원이 추가됩니다. 예를 들어 리겔리는 Avro만큼 잘 채택되지는 않지만 버려지지는 않습니다. TEE에는 훨씬 더 많은 제약 조건과 오버헤드가 있기 때문에 사용자 환경보다 성능을 우선시하는 단점을 감수했습니다. Google은 요청으로 파일을 생성하는 gRPC 서비스 제공을 고려하고 있습니다. Avro와 같은 다른 형식의 경우 실적에 미치는 영향도 평가할 수 있습니다. |
API 테스트 | PA API 및 Measurement API는 성과 증분 테스트를 어떻게 지원하나요? | 개인 정보 보호 샌드박스에는 반사실적인 입찰 이전의 성과 증분을 측정할 수 있는 방법이 없습니다. 공유 저장소 및 비공개 집계를 사용할 수 있지만 반사실적은 입찰 후에만 사용할 수 있습니다. |
API 사용량 | 일일 업데이트에 입찰WasmHelperURL을 사용하면 k-익명성 기준점에 영향을 미치나요? | k-익명성은 더 이상 IG 업데이트에서 고려되지 않으므로 임곗값에 영향을 주지 않고 BidWasmHelperURL을 업데이트할 수 있습니다. |
API 사용량 | PA API에 대한 오류 알림을 받을 수 있나요? | PA API 문제를 해결하는 데 필요한 오류 알림 유형에 대한 생태계 의견을 환영합니다. |
광고 크기 | 광고 크기는 입찰에 표시되지 않으며 보고할 수도 없습니다. | 이 pull 요청으로 문제를 해결하는 중입니다. |
API 사용량 | 입찰에 참여하지 않는 경우 IG에 대해 업데이트 IG 엔드포인트가 호출되나요? | 예. 특정 입찰에서 입찰하지 않았더라도 특정 소유자의 모든 IG에 대해 updateURL이 호출됩니다. 유일한 요구사항은 다음과 같습니다. - 소유자가 특정 입찰에 포함되어야 합니다 (즉, trafficConfig 내에서 구매자로 포함됨). - 지정된 소유자의 관심분야 그룹이 지난 24시간 이내에 업데이트된 적이 없어야 합니다. |
PA API의 사전 입찰 | 테스트 단계에는 어떤 버전의 Prebid.js가 필요한가요? | 기술 문서에 따르면 버전은 8.9.0 이상이어야 합니다. |
PA API에서 퍼스트 파티 데이터 활성화 | IG의 정의 및 사용을 위해 퍼스트 파티 데이터를 어떻게 활성화할 수 있나요? | 이 작업에 '권한 위임' 및 '제외 관심분야 그룹'을 사용할 수 있습니다. |
PA API 및 서버 측 태그 지정 | PA API는 서버 측 태그 지정과 어떻게 작동하나요? | 사용자 브라우저의 기본 태그는 API 호출을 서버 측의 나머지 태그로 리디렉션해야 하며, 이렇게 해야 사용자가 호출을 등록할 수 있습니다. |
Chrome 테스트 (모드 A/b) | SSP가 RTB 입찰 요청에서도 이러한 라벨을 전달할 것으로 예상하시나요? 그렇다면 어떻게 전달되나요? | 그렇습니다. SSP에서 DSP로 라벨이 전달될 것으로 예상됩니다. 법인은 라벨에 액세스하고, 이 기기 확장 프로그램을 통해 수정되지 않은 상태로 파트너와 값을 공유하는 것이 좋습니다. |
데이터 저장 및 사용량 | 데이터가 저장되는 방식과 데이터가 전송되는 위치에 대해 더 자세히 알고 계신가요? | Google에서는 법적 지침을 제공하는 대신 데이터 저장, 보관 및 기타 개인 정보 보호 문제에 대한 Google의 접근 방식 및 일반적인 생각을 제공합니다. 도움이 될 만한 개인 정보 보호 관련 규정 준수 FAQ는 여기를 참고하세요. |
API 안전성 | generateBid() 함수의 반환 값을 조작하는 악성 클라이언트 측 코드에 대한 우려입니다. | 이 문제에 대해 여기 에서 논의했으며 일부 의견이 비공개 집계 제안서에 통합되었습니다. |
커스텀 대상 | 맞춤 대상 reportEvent 호출을 사용할 때 allowReportingOrigins에서 IG의 일부로 사전 등록된 맞춤 보고 출처가 registerAdBeacon을 사용하여 reportWin의 DSP에 의해 선언되어야 하는지 알게 되었나요? | 아니요. reportWin에 다시 등록할 필요는 없으며 여기에 설명된 대로 reportEvent에서 바로 사용할 수 있습니다. |
API 제한 | 생성 및 업데이트 중의 IG 크기 | 업데이트 크기가 IG 생성의 새로운 한도 (50KB)에 맞게 1MB로 업데이트되었습니다. |
K-anon 제한사항 | 크기가 다른 광고를 위한 K-anon | Google은 2023년 12월에 K-익명성에 대해 '2025년 이후부터' 광고 크기 확인을 시작할 예정임을 명시한 K-익명성 값을 게시했습니다. 10월 11일 WICG 호출에서 설명한 대로 크로스 사이트 추적 벡터가 될 수 있으므로 크기를 제외하는 방법은 없습니다. |
API 안전성 | 악성 플레이어가 페이지의 '호스트 이름'을 위조할 수 있나요? | API는 게시자 호스트 이름으로 설정된 하위 키를 지원합니다. 브라우저가 키를 설정하고 있기 때문에 이 메커니즘을 우회하기가 어려워 보입니다. |
API 사용량 | ForDebugOnly 함수는 프로덕션 용도로 사용하지 않는 것이 좋습니다. | 3PCD 이후 문제 해결 외에는 forDebugOnly 함수가 전혀 적합하지 않다고 생태계에 다시 주장하려고 합니다. |
더 많은 디버깅 도구 필요 | ScoreAd() 전에 발생할 수 있는 문제를 이해하기 위해 ForDebugOnly로는 충분하지 않습니다. | 이 차이에 대한 추가 의견을 수집하고 있으며 여기에서 추가 의견을 보내주시기 바랍니다. |
관심분야 그룹의 영구 선택 해제 | 사용자가 특수 IG의 생성을 영구적으로 선택 해제할 수 있도록 허용해 달라는 요청입니다. | Google의 전략은 현재 사용자가 의미 체계를 이해할 수 없기 때문에 사용자가 IG 수준에서 선택 해제하는 것을 허용하지 않는 것이었습니다. |
문서 개선 | 사양 및 설명에서 renderUrls 매개변수에 동일한 대문자를 사용합니다. | 의견을 보내 주셔서 감사합니다. 곧 문서 업데이트를 진행하겠습니다. |
Protected Audience 거래 지원 | Protected Audience Deal 지원을 위한 추가 옵션 요청 | Chrome팀에서는 현재 3PCD를 통해 이 문제를 지원하기 위해 어떤 조치를 취할 수 있는지 검토하고 있습니다. |
매크로 | IG의 크기를 최대 IG 크기 미만으로 유지하려면 매크로 지원이 필요합니다. | 설명의 최근 업데이트에서 이 요청이 부분적으로 해결되었습니다. |
이벤트 수준 ReportLoss API | 이벤트 수준 ReportLoss API 요청입니다. | 이벤트 수준의 손실 보고서는 심각한 개인 정보 보호 위험을 초래할 수 있지만, 이 요청의 근본적인 목표는 Private Aggregation API를 적절하게 수정하여 달성할 수 있다고 생각합니다. 추가 의견이 있으면 여기에서 보내주세요. |
API 사용량 | 입찰가 점수가 0보다 클 경우 forDebugOnly 메서드는 어떻게 작동하나요? | 점수가 0 이하이면 자동 손실입니다. 따라서 reportAdAuctionloss가 호출됩니다. |
표준화 | PA API generateBid() 함수의 입력/출력 값 사용자 간 정렬이 없습니다. | 이러한 문제 (또는 유사한) 문제를 IAB Tech Lab에 제기하는 모든 파트너는 해당 문제를 해결하는 것이 좋습니다. 이 그룹은 특히 Protected Audience와 같은 API의 업계 표준을 위해 노력하고 있습니다. |
API 안전성 | Google이 볼 수 있는 IG의 데이터는 무엇인가요? | k-익명성은 강력한 개인 정보 보호 기능을 기반으로 하여 사용자의 민감한 정보가 Google을 포함한 어느 당사자에게도 유출되지 않도록 합니다. Google은 또한 이러한 위험을 최소화하기 위해 이 레이어의 타사 구현 (Fastly)을 개발하고 있습니다. |
Chrome 테스트 (모드 A/b) | 제한된 'k-anon' 사용자를 테스트에서 제외할 수 있나요? | 여기에 설명된 대로 보고에 k-익명성 상태가 표시됩니다. |
브랜드 안전성 | 차단된 사이트 또는 키워드 목록에 따라 광고가 게재되지 않는 브랜드 안전성 사용 사례를 지원합니다. | 이러한 브랜드 안전성 사용 사례는 PA API로 이미 가능해야 합니다. 광고 캠페인에서 일부 도메인을 제외 타겟팅하기 위해 IG 자체에 도메인 차단 목록을 저장할 수 있습니다. 각 도메인이 너무 많은 공간을 차지하는 경우 Bloom 필터를 사용하면 됩니다. 또는 광고 캠페인을 식별하는 키와 키-값 요청에 포함된 도메인 이름의 조합을 기준으로 답변을 조회하는 UDF를 사용하여 키-값 서버에서 허용 또는 거부 결정을 반환할 수 있습니다. 또한 Protected Audience API를 사용하면 SSP와 DSP가 페이지 컨텍스트에 대한 모든 정보를 입찰에 전달할 수 있습니다. 예를 들어 민감한 주제 목록이나 페이지의 키워드 목록이 여기에 포함될 수 있습니다. DSP의 입찰 로직은 이 정보를 광고가 표시되어서는 안 되는 위치에 대해 저장된 정보와 비교할 수 있으며 적절한 경우 입찰하지 않도록 선택할 수 있습니다. 불가능하다고 생각되는 구체적인 사용 사례에 관한 생태계의 의견을 환영합니다. |
권한 위임 | 권한 위임은 어떻게 작동하나요? | 여기에서 권한 위임에 관한 문서를 공유했습니다. |
일괄 요청 | 일괄 요청을 지원하기 위해 일부 PA API URL에는 POST 요청을 사용합니다. | 제안이 있다면 언제든지 여기를 통해 추가 의견을 보내주시기 바랍니다. |
API 개선 | 사용하면 안 되는 필드 (예: X-fledge-bidding-signals-format-version) | Google은 이 문제를 논의 중이며 추가 의견을 기다리고 있습니다. 여기 |
API 개선 | 서드 파티 광고 게재 및 측정 공급업체에 GDPR 동의 전달 요청입니다. | 이 기능은 여기에 설명된 대로 지원 중단된ReplaceInURN 매크로 대체 API를 사용하여 지원됩니다. |
동적 광고 소재 최적화 | Protected Audience는 동적 광고 소재 최적화를 어떻게 지원하나요? | 여기에서 이 사용 사례에 대해 논의하고 가능한 해결 방법을 공유해 드립니다. |
API 개선 | 입찰에서 낙찰된 IG에 해당하는 주로 IG 이름을 가져올 수 있는 서드 파티 광고 게재 URL에 대한 요청입니다. | 이러한 요청은 사용자의 추적 위험을 높일 수 있습니다. 이 문제를 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
API 안전성 | 'IG blob'의 크기로 인해 선택된 IG에 관한 정보가 유출될까 걱정하지 마세요. | Chrome B&A API 설명의 개인 정보 보호 고려사항 섹션에서 언급했듯이 blob 크기는 navgator.getInterestGroupAdAuctionData()의 입력에 의존하지 않으며 기기의 모든 IG를 패키징할 뿐입니다. 이렇게 하면 페이지에서 blob 크기가 비교적 일관되게 유지되고 크로스 사이트 정보가 유출될 가능성이 제한됩니다. 바로 이러한 이유로 이와 같이 설계한 것입니다. |
Chrome 테스트 (모드 A/b) | 쿠키 설정 및 Chrome에서 지원하는 테스트와 관련하여 첫 번째 로드 누락에 대한 다른 SSP의 입장은 무엇인가요? | 많은 분들이 이 상황을 인정하였으나, YouTube에서 큰 우려사항은 듣지 못했지만, 중대한 문제라면 생태계의 의견을 기다리고 있습니다. |
A/B 테스팅 지원 | PA API A/B 테스트 지원을 요청합니다. | 11월 WICG 회의에서 이 요청에 대해 논의했으며 여기에서 추가적인 의견을 기다리고 있습니다. |
광고 크기 | Protected Audience 입찰 크기는 누가 선택하나요? | 이 질문에 대한 답변은 이 FAQ에서 확인할 수 있습니다. |
API 개선 | /bidding-signals/v1/getvalues 경로를 허용하도록 키-값 서비스 구성 요청입니다. | 이 pull 요청에 지원 경로 프리픽스를 추가했습니다. |
API 사용량 | 게시자가 광고주 기반에 있어야 하는 경우 게시자가 코드로 IG를 생성하려면 어떻게 해야 광고주가 입찰할 수 있나요? | 답변은 Protected Audience 입찰에 참여하고자 하며 이러한 잠재고객이 외부 소스에서 유입될 수 있는 방법을 구축하는 DSP 또는 SSP와 같은 일부 광고 기술 파트너로부터 얻어야 합니다. 이 내용은 이 GitHub 문제에서 더 자세히 다루었습니다. |
API 개선 | 'Positive Interest Groups(긍정적 관심분야 그룹)'의 광고에 제외 IG를 연결할 수 있는 기능 요청 | Google은 이 요청을 고려하고 있으며 여기에서 이를 지원하는 방법과 관련된 잠재적인 제안을 공유했습니다. |
샤드 수 | 메타데이터의 '샤드_번호 지원' 전달에 대한 지원을 요청합니다. | 이 의견에 따라 샤드_번호에 대한 지원을 추가했습니다. |
API 사용량 | K/V 서버의 키 오버헤드 추정 요청입니다. | Google에서는 의견을 전달했으며 여기에서 추가적인 의견을 보내 주시기 바랍니다. |
k-익명성 | K-익명성 카운터 세부사항에 관한 설명 및 개선 요청 | K-익명성 카운터 세부사항에 관한 명확한 설명은 여기를 참고하세요. |
디버깅 | forDebugOnly에 대해 최근에 제안된 변경사항에 따라 PA API 디버깅 기능 개선을 요청합니다. | 이 사이트에서 요청에 대해 논의하는 중이며 여기에서 추가 의견을 제공해 주시기 바랍니다. |
광고 크기 | 추가 BTS 신호로 광고 슬롯 크기를 요청합니다. | Google은 이 요청을 지원하기 위한 제안서를 공유했으며 여기에서 추가 의견을 기다리고 있습니다. |
API 안전성 | 출처를 기준으로 'runAdAuction()' 사용을 제한할 수 있나요? | 여기에서 자세한 답변을 공유해 드렸습니다. |
IG 수명 | IG의 전체 기간을 30일에서 90일로 연장해 달라는 요청입니다. | Google은 요청을 고려하고 있으며 여기에서 추가 의견을 기다리고 있습니다. |
API 사용량 | 헤더 입찰 및 게시자의 광고 서버 호출과 동시에 Protected Audience 입찰을 실행할 수 있나요? | 이 요청에 대해 논의 중입니다. 여기에서 추가 의견을 제공해 주시기 바랍니다. |
디버깅 | DevTools와 통신하는 Chrome PA API 디버깅 확장 프로그램에 관한 더 나은 지원을 요청합니다. | Google에서는 더 많은 디버깅 도구를 제공할 수 있도록 지원하고 있으며 여기에서 추가적인 제안을 보내 주시기 바랍니다. |
API 사용량 | 구성요소 판매자의 입찰이 베스트셀러에 표시되지 않으면 손실 알림이 트리거되지 않습니다. | 그 이유는 여기에 설명되어 있습니다. |
API 개선 | Protected Audience 입찰 Worklet에서 TextEncoder 지원 요청 | Google은 이 요청을 고려하고 있으며 여기에서 추가 의견을 기다리고 있습니다. |
API 사용량 | 네트워크 호출과 클라이언트의 로직 실행으로 인해 기본 스레드가 차단되고 SEO에 영향을 줄 수 있는 JS 실행 문제가 발생할 수 있습니다. | 이 문제를 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
API 사용량 | DSP가 현재 서버 측 입찰 유입경로를 사용하여 기기 내 입찰에 사용할 perBuyerSignal의 일환으로 광고 후보를 평가하고 전송할 수 있나요? | 이 질문에 대한 논의를 진행 중입니다. 여기에서 추가 의견을 제공해 주시기 바랍니다. |
입찰가 추천 데이터 확장 | 브라우저에서 활성 IG의 고유한 출처 도메인 목록과 함께 브라우저에서 전달한 입찰 기회 데이터를 SSP로 확장하도록 요청합니다. | 이 요청에 대해 논의 중입니다. 여기에서 추가 의견을 제공해 주시기 바랍니다. |
실시간 입찰(ORTB) | 입찰 구성용 새 후크 2개를 요청하고 ORTB에서 입찰 응답 조정을 생성합니다. | 현재 문제를 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
이전 우승 | IG의 이전 승리를 가져와 직렬화 가능한 항목을 출력하는 prevWinsTransformer를 정의하는 IG 요청입니다. | 현재 문제를 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
콘텐츠 유형 | 콘텐츠 유형(예: JSON에서 CBOR 등으로 진화)을 위한 전략 | 현재 문제를 검토 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
Protected Audience API의 사전 입찰 | Protected Audience 입찰을 위한 엔드 투 엔드 흐름을 실행하기 위해 사전 입찰을 사용하는 샘플 게시자 페이지를 요청합니다. | YouTube에서는 이 요청을 고려하고 있으며 이를 우선시해야 하는 이유에 대한 생태계의 추가적인 의견을 기다리고 있습니다. 생태계의 다른 참여자가 시연할 수 있는 샘플 게시자 페이지를 제작하는 생태계 참여자도 있었습니다. |
보호된 입찰 서비스
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
신뢰할 수 있는 실행 환경 (TEE) | 퍼블릭 클라우드에서 온프레미스 광고 기술 데이터 센터와 달리 신뢰할 수 있는 실행 환경을 실행하는 데 비용이 더 많이 드나요? | 현재 TEE 보안 모델은 퍼블릭 클라우드 구현 관행을 활용할 수 있습니다. 특히, 현재의 하드웨어 기반 TEE는 모든 물리적 공격을 방어하지 못합니다. 기존의 지원되는 퍼블릭 클라우드 제공업체인 AWS 및 GCP에서는 직원을 비롯한 물리적 액세스 위험에 대한 완화 방법을 설계 및 구현했습니다. 온프레미스 지원에 관한 자세한 내용은 아래 를 참고하세요. 광고 기술에서는 클라우드 서비스를 실행하는 비용이 온프레미스 광고 기술 데이터 센터보다 비용이 많이 든다고 언급했습니다. Google은 이러한 진술을 평가할 수는 없지만 비용에 관한 추가 의견을 언제든지 환영하며 TEE 지원을 확대하기 위한 옵션을 계속 평가하고 있습니다. |
(이전 분기에 보고됨) 온프레미스 TEE |
TEE 제공업체가 되기 위한 요구사항은 무엇인가요? | Google의 대응은 이전 분기와 비슷합니다. "보안 관점에서 허용 가능한 배포를 고려하는 등 퍼블릭 클라우드 기반 솔루션 이외의 옵션에 대한 지원을 계속 모색하고 있지만 온프레미스 TEE를 지원할 현재 계획은 없습니다. 이 단계에서는 개인 정보 보호 샌드박스의 보안 요구사항과 온프레미스 배포로 인해 발생하는 중대한 과제를 고려할 때 클라우드 기반 배포를 지속적으로 확장하고 개선하는 것이 생태계에 가장 이득이라고 생각합니다. 그러나 개인 정보 보호 및 보안 제약을 감안할 때 이러한 요구사항이 필요하고 실행 가능한 이유에 대한 추가 의견을 환영합니다." |
키-값 서버의 제한사항 | 서버별 입찰당 키 한도 | 이 문제를 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
K-anon 제한사항 | 향후 K/V 키에 K-익명성이 적용되지 않음에 대한 확인 | 향후 K/V 서버를 TEE로 이동하는 것을 목표로 하고 있으므로 현재 K/V 서버 요청의 키에 k-anon을 적용할 계획은 없습니다. |
K/V 서비스 구축 | Google에 K/V 서비스에 사용할 수 있는 사전 빌드된 아티팩트가 있나요? | 현재 Protected Audience 키/값 서버를 위해 사전 빌드된 아티팩트는 없지만 생태계에서 해당 아티팩트에 대한 수요가 많을 경우 제공할 수 있습니다. |
B&A에서 EgId 지원 | 입찰 및 입찰 코드에서 실험 그룹 ID 필드를 지원하고 BuyerFrontEnd에서 키 값 서비스를 요청합니다. | B&A는 현재 experimentGroupId를 지원하지 않지만 베타 2 (현재 2024년 2월로 예정됨)로 출시하는 것을 목표로 합니다. 추가 정보는 여기에 공유했습니다. |
API 사용량 | HTTP의 요청 병합은 경로 내 공격자로부터 보호하는 데 도움이 될 수 있지만 TEE 운영자는 크기를 학습합니다. | 이 요청에 대해 논의 중입니다. 여기에서 추가 의견을 제공해 주시기 바랍니다. |
문서 개선 | k-v 서버가 어떻게 처리될지 사양은 명확하지 않습니다. | 이 문제를 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
API 사용량 | 'Ad-Auction-Result' 및 adAuctionHeaders의 목적은 무엇인가요? | 여기에서 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다. |
문서 개선 | v2 설계가 FLEDGE.md에 전파되었는지가 명확하지 않습니다. | FLEDGE.md는 Chrome이 BYOS-KV에 요청을 전송하는 방식을 설명합니다. v2 프로토콜 설계는 TEE-KV로만 제한되며 현재 Chrome에서 지원되지 않습니다. |
디지털 광고 측정
Attribution Reporting (및 기타 API)
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
교차 환경 측정 | Chrome 모바일에서 서드 파티 PC가 삭제되었지만 Android용 개인 정보 보호 샌드박스는 아직 제공되지 않는 중간 단계에서 Chrome은 교차 환경 측정을 어떻게 지원할 계획인가요? | Android 측면에서는 PSB/ARA 적용 범위를 확대하기 위해 노력하고 있습니다. Attribution Reporting API (ARA)는 Android 13과 14에서 사용할 수 있습니다. 올해 말에 Android 11과 12로 확대할 계획이지만 일정은 변경될 수 있습니다. Android 10 이하로 확장할 수는 없지만, 여전히 Android 10 이하를 실행하는 Android 기기의 비율은 3PCD에서 더 낮고 사용자가 업그레이드함에 따라 시간이 지남에 따라 자연스럽게 감소할 것으로 예상됩니다. 이 요청에 관해 생태계의 추가 의견을 보내주시기 바랍니다. |
필터링 | 광고 소재 검사에서 '전환' 필터링 | Google은 그들의 요청을 더 잘 이해하기 위해 이 이해관계자에게 연락했으며 이 문제에 대한 생태계의 추가 의견을 환영합니다. |
외부 애드 서버 | PA API 및 ARA는 서드 파티 광고 서버 태그와 어떻게 작동하나요? | 오늘날 픽셀이 노출 및 클릭 태그에서 작동하는 방식과 마찬가지로, 광고 서버는 자체적으로 ARA에 대한 소스를 설정하고 등록을 트리거하거나 (Protected Audience 입찰 포함) 리디렉션을 설정하여 ARA에 대한 소스 및 트리거 등록을 전달하고 허용할 수 있습니다. |
DCM | DCM 및 기타 외부 광고 서버에서 Attributionsrc를 지원합니다. | 이는 DCM 관련 문제이며 DCM팀이 이 GitHub 문제에서 해결했습니다. |
계층적 집계 키 | 모든 기여 예산을 이러한 모든 계층적 키로 분할해야 하나요? | 이 이해관계자에 대해 논의하고 답변을 제공했습니다. 계층적 키 구조를 사용할 때 광고 기술은 참여 예산이 노출에 대한 모든 키 출력에서 공유된다는 점을 고려해야 합니다. |
다른 하위 도메인 사용 | 서로 다른 하위 도메인에 등록된 동일한 eTLD+1인 소스 및 트리거와 함께 작동하도록 기여도 보고서를 설정하시겠어요? | 우리는 이 질문에 대해 이해관계자와 논의하고 다음과 같은 솔루션을 제안했습니다. 소스와 트리거에 동일한 보고 출처를 사용하도록 URL 설정을 변경하거나 등록을 수행하기 전에 현재 URL에서 공통 URL로 리디렉션할 수 있습니다. 제안된 솔루션이 사용 사례에 맞지 않는 경우 생태계에 대한 추가적인 의견을 제공할 수 있습니다. |
(이전 분기에도 보고됨) 프로덕션 지원 |
ARA를 사용하는 파트너에게는 어떤 수준의 서비스가 제공되나요? | Google의 대응은 이전 분기와 동일합니다. "Google은 광고 기술이 기술적 문제를 신고하고 이러한 문제를 해결하는 데 필요한 에스컬레이션을 지원할 수 있는 다양한 채널을 제공합니다. 또한 Chrome은 생태계 상태에 영향을 미치는 기술적 문제와 에스컬레이션을 해결하기 위한 프로세스를 추가로 구축하고 확장할 계획입니다. Chrome은 이를 위한 리소스를 확보하기 위해 최선을 다하고 있습니다. 의견과 에스컬레이션을 위한 공개 및 비공개 포럼에 관한 자세한 내용은 개발자 게시물을 참고하세요. |
(이전 분기에도 보고됨) 타임라인 |
Google은 CMA 정량적 테스트를 시작할 때 '2단계 유연한 이벤트 수준 전체'를 준비할 예정인가요? | 2단계 전체 탄력 이벤트 수준은 2024년 1분기에 Chrome에서 제공될 예정입니다. 여기에서 상태를 추적할 수 있습니다. |
(이전 분기에도 보고됨) 전환 유입경로 |
전환에 사용된 여러 도메인을 보고합니다. | 이 사용 사례는 여러 대상을 추가했기 때문에 가능합니다. 추가 의견을 보내주세요. |
보고 테스트 라벨 | 보고 기능을 사용하면 테스터가 사용자 (Chrome 브라우저)가 어떤 그룹 (모드 A/B)에 속해 있는지 보고할 수 있나요? | ARA에서 Chrome 테스트 라벨을 캡처하기 위한 테스트 가이드를 게시하는 중입니다. |
문서 | Attribution-Reporting- Register-Source 문서에 따르면 만료는 가장 가까운 날짜로 반올림됩니다. 어떻게 반올림되나요? | 가장 가까운 날로 반올림하면 1.5일이 2일로 반올림됩니다. |
다른 하위 도메인 사용 | 소스 및 트리거 등록으로 다른 하위 도메인의 Attribution Reporting API 보고서를 수신하도록 요청합니다. | 포함할 수 없습니다. HTTP 리디렉션을 적용할 수 있지만 이를 위한 설정이 없습니다. 이 요청이 유용한 이유에 대한 생태계의 추가 의견을 환영합니다. |
이벤트 수준 보고 지연 | 기여 분석 및 보고 기간이 7일이지만 이벤트 수준의 보고 지연으로 인해 모든 보고서가 생성되는 데 8일 넘게 걸릴 수 있습니다. | Google은 이러한 의견을 확인하며, 특히 고정 이벤트 보고 기간에서 유연한 이벤트 보고 기간으로 전환함에 따라 이벤트 수준 보고의 이러한 지연이 문제가 되는지 여부에 대한 생태계의 추가 의견을 환영합니다. |
전환 트리거 | 첫 번째 event_report_window 종료 시점 (1h)과 만료 시간 (1일) 사이에 발생한 전환 트리거는 보고서를 생성하지 않습니다. | 고정된 이벤트 보고 기간에서 유연한 이벤트 보고 기간으로 이동하는 유연한 이벤트 수준 구성을 도입했습니다. |
소음 | 이벤트 수준 보고서는 GitHub 설명에 설명된 대로 노이즈가 많은 가짜 전환인가요? | 예. 노이즈는 이벤트 수준 보고서에 적용되며, 다른 trigger_data를 포함해 가능한 모든 출력 상태를 나타내거나, 트리거가 실제로 발생했을 때 아무 것도 보고하지 않거나, 이벤트에 대해 여러 허위 보고서를 보고할 수 있습니다. 노이즈 비율은 오픈소스이며 유연한 이벤트 수준 구성을 통해 유연하게 설정할 수 있습니다. |
필터링 | Attribution Reporting API와 함께 필터링을 사용하면 집계 키를 기록하지 않더라도 기여 예산을 계속 사용합니다. | aggregatable_trigger_data는 값 / 키가 아닌 트리거 키 조각 자체에 대해서만 필터링을 지원하므로 의도한 대로 작동합니다. 최상위 필터는 키 자체 필터링을 지원할 수 있지만 이벤트 + 집계별로 공유되므로 여기에는 적용되지 않습니다. 키 필터링이 필요한 경우 여기에서 생태계의 추가적인 의견을 보내주시기 바랍니다. |
저장용량 한도 | 보고 출처도 고려하는 저장용량 한도 도입을 요청합니다. | 이 한도가 1,024개에서 4,096개로 증가하면 M120부터 적용됩니다. 여기에서 생태계의 추가 의견을 보내주세요. |
직접 기여 분석 | 표준 기여 분석 보고 프로세스에서 이 시나리오를 다루지 않으므로 사용자가 게시자를 통하지 않고 광고주를 직접 방문하는 상황에 대한 측정항목을 얻으려면 어떻게 해야 하나요? | ARA는 교차 사이트 정보 (즉, 게시자/광고주 사이트 간 정보 결합)를 복구하는 용도로만 설계되었습니다. 크로스 사이트 정보가 필요하지 않으면 ARA의 도움을 받을 수 없습니다. 이 문제를 논의 중이며 여기에서 추가 의견을 보내주시기 바랍니다. |
보고 시간 | 로컬 머신 시간을 사용하는 대신 타임서버에서 scheduled_report_time의 시간을 가져옵니다. | 현재 시간 서버를 사용할 계획은 없으며, 광고 기술로부터 이에 대한 많은 요구를 듣지 못했습니다. 이 기능이 유용한지에 관한 생태계의 추가 의견을 듣고 싶습니다. |
집계 서비스
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
(이전 분기에도 보고됨) 온프레미스 솔루션 |
집계 서비스를 온프레미스 데이터 센터에 배포할 수 있나요? | Google에서는 클라우드 기반 솔루션 이외의 잠재적인 지원 옵션을 모색하고 있지만, 개인 정보 보호 샌드박스에 대해 시간이 오래 걸리는 평가가 필요한 온프레미스 보안 제한사항을 고려하여 온프레미스 TEE를 지원하는 것은 현재 불가능합니다. 개인 정보 보호 샌드박스 보안 요구사항과 온프레미스 배포로 인해 발생하는 중대한 도전과제를 고려할 때 Google은 클라우드 기반 배포를 지속적으로 확장 및 개선 (예: AWS 외에 GCP 지원)하는 것이 생태계에 가장 유익하다고 생각합니다. 그러나 이러한 요구사항이 필요한 이유에 관한 추가 의견은 여기를 통해 알려주시기 바랍니다. |
엔클레이브 | 엔클레이브가 가동되지 않거나 갑자기 오류가 발생하는 경우 Aggregation Service API에서 어떻게 처리하나요? | 시작 시 인클레이브가 실패하면 재시도를 사용하고 인스턴스가 비정상으로 간주되는 경우 자동 확장을 사용하여 새 인스턴스를 가져옵니다. 광고 기술은 로그를 사용하여 오류를 조사할 수도 있습니다. AWS에서 엔클레이브 오류를 디버그하기 위해 광고 기술은 AWS Console Manager에 로그인하여 EC2 인스턴스의 상태를 확인할 수 있습니다. 광고 기술은 Nitro Enclave 호스트 인스턴스에 로그인하여 nitro-cli 도구로 엔클레이브 상태를 확인할 수 있습니다. 오류/장애가 있는 경우 AWS 명령줄 인터페이스를 사용하여 로그를 확인하고 자세히 조사할 수 있습니다. GCP에서 인클레이브 오류를 디버그하기 위해 광고 기술은 Cloud Console을 통해 인스턴스의 상태를 확인할 수 있습니다. list-errors-command를 사용하여 오류를 확인할 수도 있습니다. |
다른 하위 도메인 사용 | 개발 및 프로덕션 환경에서 여러 집계 서비스 인스턴스를 사용하기 위해 여러 (하위) 도메인 등록 요청입니다. | 사이트 등록이 출시되었으므로 광고 기술이 하나의 AWS 계정 또는 GCP 프로젝트에 동일한 사이트의 여러 하위 도메인을 등록할 수 있습니다. 여러 AWS 계정 또는 GCP 프로젝트에 동일한 도메인을 등록할 수도 있습니다. 생태계의 의견을 기다립니다. |
개인 정보 보호 예산 | 개인 정보 보호 예산 소진 관련 문제를 더 효과적으로 디버그하는 방법 | 현재 Google은 소진된 예산에 대한 자세한 정보를 제공하는 솔루션을 찾고 있으며, 광고 기술에서 이러한 오류를 최소화하기 위해 사용할 수 있는 전략을 간략하게 설명하는 문서도 개선하고 있습니다. 제안사항이 있으면 집계 서비스 GitHub 페이지가 업데이트됩니다. |
입실론 값 | epsilon 값 증가 요청입니다. | 집계 서비스의 epsilon 값은 3PCD 중에 다양한 매개변수에 대한 실험과 피드백을 용이하게 하기 위해 최대 64로 유지됩니다. epsilon 범위 값이 업데이트되기 전에 생태계에 사전 공지할 예정입니다. |
바이너리 | 집계 서비스 출시를 위해 보다 완전한 바이너리 세트를 게시합니다. | Google에서는 이 요청을 검토 중이며 추가적인 의견을 보내주시기 바랍니다. |
API 사용량 | 코디네이터 서비스 약관에 따라 코디네이터와 데이터를 공유합니다. | Google에서는 이 문제를 명확히 확인하고자 하며 추가적인 의견을 보내주시기 바랍니다. |
비공개 집계 API
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
디버깅 | 모드 B 테스트 중 디버깅을 위한 추가 옵션을 사용 설정합니다. | 이 GitHub 문제에서 공유했듯이, 앞으로 모드 B에서 디버그 모드를 허용할 예정입니다. 이 자격 요건은 1월 31일부터 모드 B 트래픽의 50% 에서 M121 베타에서 변경됩니다. 안정화 버전으로 업그레이드하기 전에 공지할 예정입니다. |
은밀한 추적 제한
사용자 에이전트 축소/사용자 에이전트 클라이언트 힌트
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
ChromeOS | Chrome OS의 비트율에 대한 사용자 에이전트 클라이언트 힌트를 지원합니다. | 여기에서 이 요청에 대한 답변을 공유했습니다. |
IP 보호 (이전 명칭: Gnatcatcher)
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
악용 수준 | Google에서 IP 보호 기능을 통해 사용자의 인터넷 사용 기록을 볼 수 있습니다. | IP 보호는 두 개의 프록시 (하나는 Google에서, 다른 회사에서 하나씩)를 통해 트래픽을 터널링합니다. 이렇게 하면 Google에서 인터넷 사용 기록을 볼 수 없습니다. 모든 트래픽은 Chrome과 프록시 간에 암호화되므로 Google 프록시에는 탐색 중인 웹사이트에 대한 정보가 없습니다. 또한 시스템은 블라인드 인증 토큰을 사용하여 프록시에서의 사용자 식별자 액세스를 최소화합니다. Google 프록시는 특정 IP의 알 수 없는 클라이언트가 프록시 시스템을 사용하고 있는 것만 표시됩니다. 방문한 웹사이트나 로드된 광고에 관한 정보가 없습니다. |
헤드리스 모드 지원 | 플러그인과 헤드리스 모드를 사용하는 봇은 어떻게 관리되나요? | IP 보호의 남용을 완화하는 것이 팀의 최우선 과제입니다. YouTube는 이러한 시나리오 (다른 많은 잠재적 위협 포함)를 신중하게 고려했으며 악용 또는 사기가 성공할 가능성을 줄이기 위한 옵션을 제공하기 위해 노력하고 있습니다. 현재로서는 자세한 내용을 알려드릴 수 없지만 조만간 제공해 드릴 수 있도록 최선을 다하겠습니다. |
기존 프록시 | IP 보호는 Chrome의 기존 프록시 설정과 어떻게 작동하나요? | 기존 프록시 구성은 계속 지원됩니다. 사용자는 전과 같이 자체 커스텀 프록시를 구성할 수 있습니다. |
악용 사례 신고 | 악용사례 신고는 어떻게 처리되나요? | 가까운 시일 내에 자세한 내용을 알려드릴 예정이지만 조직 및 사용자가 악용 사례 신고 및 증거를 공유할 수 있는 메커니즘을 갖출 예정입니다. |
규정 | IP 보호는 현지 법률 및 규정을 어떻게 준수하나요? | Google은 현지 법률 및 규정을 준수하기 위해 최선을 다하고 있으며, 이러한 국가 수준의 차단을 회피하는 행위는 허용되지 않을 수 있습니다. 이 기능은 우회를 위한 기능이 아닙니다. |
기능 제한 | IP 보호가 우리 사이버 대응을 차단합니까? | Google은 IP 주소를 기반으로 웹에서 사용자가 추적되지 않도록 보호하는 동시에 악용 방지를 위한 IP 주소 사용을 비롯한 서버의 정상적인 운영 중단을 최소화하는 것 사이에서 균형을 유지하기 위해 노력하고 있습니다. 현재로서는 자세한 내용을 알려드릴 수 없지만 조만간 제공해 드릴 수 있도록 최선을 다하겠습니다. |
타임라인 | 2024년 말까지 시행될 경우 대비하기가 거의 불가능합니다. | Chrome은 처음에 특정 지역의 사용자를 위한 선택 설정으로 IP 보호를 출시할 예정입니다. 이를 통해 일부 회사가 IP 주소에 의존하는 방식에 큰 변화가 될 수 있음을 이해하고 생태계의 조정에 따른 중단을 최소화하려고 합니다. 2025년 이후에 IP 보호가 기본값으로 전환됩니다. |
API 사용량 | 사용자가 Chrome을 처음 열 때 IP 보호를 전환할 수 있는 선택권이 제공되나요? | Google은 사용자가 IP 보호의 사용 여부를 선택할 수 있도록 할 계획입니다. 이 옵션을 사용자에게 표시하는 메커니즘은 아직 개발 중입니다. |
API 사용량 | 로깅되는 데이터의 양과 해당 데이터는 보관되는 기간 | 향후 더 자세한 내용을 공유할 예정이나 최소한의 데이터만 기록할 계획입니다. |
부정적인 의견 | 사용자는 VPN을 사용하려는 경우 사용할 수 있습니다. PS API는 필요하지 않습니다. | IP 보호의 목표는 크로스 사이트 추적을 위한 IP 주소 사용을 방지하는 것이며 VPN 서비스는 아닙니다. |
API 안전성 | 퍼스트 파티가 IP 주소에 액세스하고 헤더의 매개변수를 통해 정보를 전달하지 못하게 하려면 어떻게 해야 하나요? | 처음에는 타사에 집중하고 있는데, 그 효과가 가장 큰 타사입니다. Google은 생태계를 계속 모니터링하여 대규모 우회를 방지하기 위해 접근 방식을 개선해야 하는지 판단할 것입니다. |
API 사용량 | API 사용에 관해 제대로 이해한 경우 확인이 필요합니다. | IP 보호는 목록 기반 접근 방식을 사용하여 프록시를 통과하는 타사 트래픽을 식별합니다. 목록에 있지만 퍼스트 파티 컨텍스트에서 액세스하는 출처는 이러한 연결에 대해 이 서비스를 통해 프록시되지 않습니다. 예를 들어 분석 회사가 도메인 목록에 있고 사용자가 사이트로 직접 이동하는 경우 해당 사이트는 프록시 처리된 IP 주소 대신 사용자의 IP 주소를 계속 관찰할 수 있습니다. 하지만 목록에 있는 도메인이 서드 파티 컨텍스트에서 네트워크를 요청하는 경우 연결이 프록시되고 사용자의 원래 IP 주소가 사이트에 표시되지 않습니다. Google의 궁극적인 목표는 웹에서 사용자의 크로스 사이트 추적을 방지하는 것입니다. 우선 초점을 맞출 서드 파티 도메인에 대한 자세한 정보를 공유하기 전에 몇 가지 세부정보를 검토하고 있습니다. |
VPN | Google의 제안이 다른 VPN 제공업체에는 불리할 수 있다는 우려가 있음 | IP 보호의 목표는 크로스 사이트 추적을 위한 IP 주소 사용을 방지하는 것이며 VPN 서비스는 아닙니다. |
타임라인 | IP 보호 타임라인이란 무엇인가요? | 처음에는 IP 보호가 선택되지만, 이를 통해 사용자가 개인 정보 보호와 관련된 결정을 제어할 수 있으며 Google에서 소량의 행동을 모니터링할 수 있습니다. IP 보호는 단계적으로 출시되며 2025년 이후에 기본값으로 전환됩니다. 다른 개인 정보 보호 제안과 마찬가지로 Google은 진행 과정에서 배움을 얻고자 하며 지역적 고려사항이 있을 수 있음을 인지하고 있습니다. Google에서는 목록 기반 접근 방식을 사용하고 있으며, 서드 파티 컨텍스트에서 목록에 있는 도메인에만 영향을 미칩니다. Google은 이러한 제안이 합법적인 사용 사례에 원치 않는 중단을 초래할 수 있음을 인지하고 있으므로 사용자를 추적하는 것으로 간주되는 스크립트 및 도메인에만 집중하고 있습니다. |
기능 제한 | 사용자의 IP 주소를 더 이상 WHOIS에서 조회할 수 없습니다. | Google의 입장은 IP 주소가 안정적인 식별자이며, 사용자의 개인 정보 보호에 영향을 미칠 수 있습니다. 여기에는 ASN과 같은 관련 메타데이터의 사용이 포함됩니다. Google은 IP 보호를 통해 개인 정보 보호와 웹에서 유용한 사용자 환경 지원(예: IP 위치정보에 대한 접근 방식) 사이에서 적절한 균형을 유지하기 위해 노력하고 있습니다. 이 메타데이터가 사용 사례에 충분하지 않은 경우, 더 자세히 논의할 수 있습니다. |
HTTP 리퍼러 | 원래 HTTP 리퍼러는 유지되나요? | 여기에서 논의된 바와 같이 IP 보호의 일환으로 리퍼러 헤더를 변경할 계획은 없습니다. |
오픈소스 | IP 보호 소스 코드는 오픈소스인가요? | 여기에 있는 대부분의 소프트웨어는 Chromium 및 Envoy 프록시 프로젝트의 일환으로 오픈소스로 제공되지만 일부 구성요소는 여기에 설명된 대로 비공개 소스입니다. |
이탈 추적 감소
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
스토리지 삭제 | 이탈 추적 완화 (BTM)를 사용하면 공유 저장소와 기여도 보고 저장소가 삭제되나요? | BTM에서 개인 정보 보호 샌드박스 API 스토리지 (ARA, PA API, 공유 스토리지, 비공개 집계, Topics)를 삭제할 의도가 없었습니다. BTM은 서드 파티 맥락에서 액세스하는 경우 개인 정보 보호 위험이 있는 스토리지 유형만 삭제해야 합니다. 버그 수정이 진행 중입니다. |
API 사용량 | BTM이 활성화되는 Chrome 버전은 무엇인가요? 10초 후의 리디렉션/이탈 추적은 BTM에서 이탈 추적으로 간주되나요? | M116에서 BTM은 3PC를 차단한 모든 사용자에게 출시되었습니다. 현재 10초 후 리디렉션되면 이탈로 간주되지 않습니다. |
로그인 사용 사례 | 추적과 같은 동작에 대한 제한 없이 여러 도메인에서 로그인 상태를 자동으로 동기화/유지하나요? | 여기에서 이 요청에 대해 논의하고 있으며 생태계의 추가 의견을 기다리고 있습니다. |
사용자 경험 | 현재 BTM은 복잡한 사용자 경험을 초래합니다. | 이 문제를 논의 중이며 이에 대한 의견을 여기에서 공유해 드립니다. |
저장소 액세스 API | Chromium의 BTM은 Storage Access API (SAA)에서 받은 3PC 보조금을 인정합니다. | Google은 TPAC 2023에서 생태계 참여자들과 이 문제를 논의했으며 여기에서 추가 의견을 기다리고 있습니다. |
광고 보고에 미치는 영향 | 이탈 추적 감소로 인해 생태계의 소규모 기업은 ARA와 같은 다른 개인 정보 보호 샌드박스 API를 사용하여 광고 사용 사례를 수행할 수 있습니다. | 이탈 추적 감소는 3PCD의 우회를 방지하기 위한 것입니다. ARA는 3PCD 이후 기업에서 사용할 수 있는 대체 측정 솔루션 중 하나이지만 기업에서 이를 사용할 필요는 없습니다. |
개인 정보 보호 예산
이번 분기에 제공된 의견이 없습니다.
크로스 사이트 개인 정보 보호 경계 강화
관련 웹사이트 세트 (이전의 퍼스트 파티 세트)
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
(이전 분기에도 보고됨) 관련 웹사이트 세트 (RWS) 도메인 한도 |
연결된 도메인 수 확장 요청입니다. | 현재로서는 숫자 제한이 늘어나지 않을 것으로 예상됩니다. 이 제한은 사용자 개인 정보 보호 고려사항, W3C 생태계 이해관계자의 피드백, 다른 브라우저의 유사한 구현 사례를 고려하여 설정되었습니다. 자세한 내용은 블로그 게시물 (1, 2)을 참고하세요. 숫자 제한을 초과하여 교차 사이트 쿠키 액세스가 필요한 사용 사례를 검토하고 ID 사용 사례, 인증된 삽입, 광고 사용 사례에 대한 안내를 활용하는 것이 좋습니다. |
쿠키 액세스 범위 | RWS의 모든 도메인에 모든 도메인의 모든 쿠키를 읽고 쓸 수 있는 액세스 권한이 부여된다는 우려가 있습니다. | RWS에 속해도 구성원이 서로의 쿠키에 액세스할 수 없게 됩니다. 대신 Storage Access API 호출 후 다른 동일한 RWS 사이트에 삽입된 경우 구성원이 자신의 쿠키에 액세스할 수 있습니다. |
(이전 분기에도 보고됨) RWS + CHIPS 통합 |
A/B 테스트와 같은 사용 사례를 지원하기 위한 RWS + CHIPS 통합 요청 | Google에서는 이 기능에 대한 사용 사례와 요청을 계속 여기에서 요청합니다. 현재, 브라우저 간 상호 운용성 위험과 비교해 이 기능의 필요성을 검토하고 있습니다. |
API 사용량 | 사용자가 Chrome 설정에서 로컬로 사이트를 직접 삭제하면 어떻게 되나요? | 현재는 사용자가 그룹에서 사이트를 직접 삭제할 수 있는 방법이 없습니다. 대신 사용자는 새로운 추적 보호 설정 패널에서 '서드 파티 쿠키 차단' 또는 '모든 서드 파티 쿠키 차단' 아래의 전환 버튼을 사용하여 '관련 사이트' 기능을 사용 중지할 수 있습니다. |
도메인 간 통신 | RWS에서 도메인 간 통신을 허용하나요? | Google에서는 현재 Storage Access API를 통해 이러한 통신을 가능하게 할 일부 유형의 파티션이 없는 스토리지 (localStorage 및 Broadcast Channel 포함)에 대한 액세스를 확대하기 위해 오리진 트라이얼을 진행하고 있습니다. 이 기능은 Storage Access API의 지원되는 모든 구성, 동일한 RWS, RWS가 아닌 사이트에서도 사용할 수 있습니다. 이 블로그 게시물에 추가 정보가 있습니다. |
requestStorageAccessFor | document.requestStorageAccessFor(origin)이 원본의 크로스 사이트 쿠키로 확인되는 프로미스를 반환할 수 있나요? | 포함할 수 없습니다. 호출이 최상위 출처 (인수로 전달된 출처와 다름)에서 발생하므로 이렇게 하면 동일한 출처 정책을 위반하게 됩니다. |
Fenced Frames API
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
(이전 분기에도 보고됨) 네이티브 광고 |
네이티브 광고에서 펜스된 프레임이 지원됩니다. | 개인 정보 보호 기능을 더욱 강화하기 위해 향후 일부 개인 정보 보호 샌드박스 기술이 필요하다고 이전에 공유했습니다. 예를 들어 Protected Audience의 경우 2026년 이전에 광고 렌더링에 분리 프레임을 사용해야 하며 이벤트 수준 보고에서 전환해야 합니다. 각 향후 요건에 대해 '최대한 빨리' 날짜를 제시해 드렸으므로 업계에서는 API가 어떻게 발전할 것인지 명확히 밝힐 수 있습니다. 시간이 더 확보되어 더 광범위한 중요한 사용 사례를 위한 지원을 설계하고 구현하는 데 업계와 계속 협력할 수 있습니다. 예를 들어 Protected Audience API를 통해 동영상 및 네이티브 광고에 대한 지원을 유지하기 위해 2026년 이후 요구사항에 앞서 Fenced Frames를 개선할 예정입니다. Google의 약속에 따라 CMA는 이러한 변경사항에 관해 자문을 구하고, 요구사항을 '최대한 빨리' 구현하기 전에 생태계의 의견을 지속적으로 수렴할 예정입니다. |
플랫폼 간 크기 차이 | 펜스된 프레임에 표시되는 콘텐츠 크기가 데스크톱과 스마트폰 간에 다르게 보인다는 신고가 접수되었습니다. | Google에서 문제를 조사 중이며 여기를 통해 추가 의견을 보내주시기 바랍니다. |
adComponent 렌더링 | 펜스된 프레임에서 adComponents를 렌더링하는 방법에 대한 샘플 코드를 제공하시겠습니까? | Fenced 프레임 내에서 navgator.adAuctionComponents(numComponents)를 사용하여 여러 조각으로 구성된 광고를 표시하는 방법에 대한 문서를 제공하고자 합니다. |
API 개선 | FencedFrames에 더 많은 신호를 제공합니다 (예: 브랜드 안전성 개선). | 제안이 있다면 언제든지 여기를 통해 추가 의견을 보내주시기 바랍니다. |
공유 저장소 API
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
악용 방지 / 사기 방지 사용 사례 | 사기 또는 이상 감지를 위해 공유 스토리지를 사용할 가능성 | 여기에서 가능성에 대해 논의했으며 추가 의견을 보내주시기 바랍니다. |
게재빈도 설정 | PA API 외부에서 크로스 사이트 최대 게재빈도를 설정하는 방법을 제공합니다. | PA API 외부의 크로스 사이트 최대 게재빈도 설정이 유용한 사용 사례라는 의견을 제공해 주셔서 감사합니다. 현재로서는 개인 정보 보호 샌드박스가 현재의 3PCD용 API 세트에 중점을 두고 있습니다. 하지만 여기에서 이 사용 사례에 관한 생태계의 추가 의견을 기다리고 있습니다. |
CHIP
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
팝업/리디렉션 | CHIP은 팝업 및 리디렉션과 관련된 내장된 인증 사용 사례를 어떻게 지원하나요? | 서드 파티 쿠키 단계적 폐지가 로그인 워크플로에 미치는 영향을 확인하는 방법에 관한 몇 가지 안내를 공유해 드렸으며 여기에서 추가 의견을 보내 주시기 바랍니다. |
파티션 한도 | 파티션당 전체 사이트당 한도를 1KiB로 줄입니다. | Google은 이 요청을 고려하고 있으며 여기에서 추가 의견을 기다리고 있습니다. Google에서는 3PCD를 계속 출시하고 개발자가 CHIP를 채택하고 의견을 제공하면서 의견을 지속적으로 모니터링할 예정입니다. |
쿠키 이전 | 진행 중인 쿠키/세션을 중단하지 않으면서 쿠키를 파티셔닝하도록 웹 앱을 마이그레이션하는 권장 프로세스는 무엇인가요? | Google은 여기의 답변에서 잠재적인 이전 계획을 제안했지만, 개발자가 자신의 구성에 더 적합한 대체 솔루션을 만들 수 있었습니다. |
API 사용량 | 사용자가 Ad Privacy API 설정을 선택하지 않으면 파티션을 나눈 저장용량에 대한 액세스가 사용 중지되나요? | 파티션 스토리지와 파티션을 나눈 쿠키 (CHIP)는 크로스 사이트 정보 전송을 사용 설정하지 않으므로 사용자가 Ad Privacy API 설정을 선택하지 않은 경우에도 사용 설정됩니다. 일반적으로 정보의 교차 사이트 전송에는 제한, 확인 또는 사용자 선택이 적용되지만 현재 CHIPS에는 적용되지 않습니다. |
API 사용량 | 브라우저가 단지 파티션을 '알게' 나누지 않고 결국에는 파티션으로 나누지 않은 쿠키를 차단하는 이유는 무엇인가요? | 여기에 설명된 것처럼 단기 및 중기적으로는 불가능합니다. |
FedCM
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
API 사용량 | 개발 환경 내 eTLD+1에서 'well-known file'을 제공할 수 없습니다. | 여기에 설명된 대로 잘 알려진 파일을 가져오지 않도록 Chrome Canary가 업데이트되었습니다. |
API 사용량 | 서드 파티 로그인 권한을 요청하거나 FedCM을 사용하기 위해 정의된 특정 사용자 상호작용 요구사항이 있나요? | 여기에서 설명한 대로 특정한 사용자 상호작용 요구사항은 없습니다. |
API 안전성 | 클라이언트가 FedCM을 시작할 수 있지만 기본적으로 토큰이 IdP에서 RP의 백엔드 시스템으로 전송되도록 허용하는 흐름을 마련할 계획이 있나요? | 여기에서 논의 중이며 추가 의견을 기다리고 있습니다. |
선택 | IDP가 RP의 클라이언트 ID 수신을 선택하도록 허용합니다. 그러면 사용자가 IDP를 신뢰할 수 있는지 여부를 결정할 수 있습니다. | 이 요청에 대해 논의 중입니다. 여기에서 추가 의견을 제공해 주시기 바랍니다. |
API 사용량 | FedCM에 관한 추가 문서 요청 | Google은 이러한 의견을 인지하고 있으며 API를 지속적으로 개발하면서 문서를 지속적으로 개선해 나갈 것입니다. |
스팸 및 사기 방지
Private State Token API 및 기타 API
의견 테마 | 요약 | Chrome 응답 |
---|---|---|
문서 | 테스트 지원을 위해 비공개 상태 토큰에 관한 자세한 개발자 가이드 요청 | 2023년 4분기에 비공개 상태 토큰에 관한 개발자 가이드를 게시했습니다. |
연령/성별 인증 | 3PCD 이후 잠재고객의 '연령 및 성별' 인증을 수행하기가 어렵습니다. | 비공개 상태 토큰은 현재 연령 및 성별 확인용으로 설계되지 않았습니다. Google은 사용 사례를 더 잘 이해하고 현재 그 방식이 어떻게 실현되고 있는지 파악하고자 하며 추가 의견을 기다리고 있습니다. |