개인 정보 보호 샌드박스 제안 및 Chrome의 응답에 관해 받은 생태계의 의견을 요약한 2022년 3분기 분기별 보고서입니다.
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, Fledge, 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 응답 |
| (2분기에도 보고됨)
다양한 유형의 이해관계자를 위한 유용성 |
개인 정보 보호 샌드박스 기술이 대규모 개발자를 선호하며 틈새 (작은) 사이트가 일반 (대형) 사이트보다 더 많은 기여를 한다는 우려가 있습니다. | 3분기 업데이트:
Google은 Google의 비즈니스를 자체적으로 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안서를 설계하고 구현하고, 디지털 광고 및 게시자 및 광고주의 규모에 관계없이 경쟁에 미치는 영향을 고려하기 위해 CMA에 최선을 다하고 있습니다. Google은 이러한 약속을 준수하기 위해 CMA와 계속해서 긴밀히 협력하고 있습니다. 개인 정보 보호 샌드박스 테스트가 진행됨에 따라 평가할 주요 질문 중 하나는 다양한 유형의 이해관계자에게 새로운 기술이 어떤 성능을 발휘하는지입니다. 의견은 이러한 점에서 매우 중요하며, 특히 기술 설계를 더욱 개선하는 데 도움이 될 수 있는 구체적이고 실행 가능한 의견입니다. Google은 CMA와 협력하여 정량적 테스트에 대한 접근 방식을 개발해 왔으며, 시장 참여자에게 더 많은 정보를 제공하고 제안된 접근 방식에 대해 의견을 제시할 수 있는 기회를 제공하기 위해 CMA가 실험 설계에 관한 메모를 게시하는 것을 지지합니다. |
| (2분기에도 보고됨)
문서 요청 |
테스트, 분석, 구현 관리 방법을 자세히 설명하는 추가 리소스 요청 | 3분기 업데이트:
이번에 발표된 자료가 도움이 되었다는 점을 높이 사며, 개발자가 새로운 기술이 어떻게 도움이 될지 계속 이해할 수 있도록 앞으로 몇 주에서 몇 달에 걸쳐 더 많은 자료를 제공하기 위해 최선을 다하겠습니다. 또한 권장사항과 데모를 공유할 수 있는 공개 개발자 상담 시간 세션을 열고 제품 및 엔지니어링 책임자들과의 Q&A 세션도 마련해 실시간 토론/질문을 진행하기도 했습니다. |
| 교차 브라우저 지원 | 개인 정보 보호 샌드박스 API를 채택하는 다른 브라우저 공급업체 | Apple, Mozilla, Microsoft와 같은 다른 브라우저 공급업체도 개인 정보 보호 원칙과 브라우저 기반 접근 방식을 논의하는 공개 포럼에 적극적으로 참여하고 있습니다. 최근의 W3C 연례 TPAC 회의, 그리고 융합의 조짐이 보이는 지속적인 W3C PATCG 포럼과 같은 포럼에서 공동 토론이 활발히 진행되고 있습니다. |
| 플랫폼 차이 | 전환에 필요한 리소스를 줄일 수 있도록 웹과 Android에서 기능 세트를 최대한 정렬하도록 요청합니다. | Google은 업계 전반에 혼란과 단편화가 발생하지 않도록 Chrome과 Android 전반에서 접근 방식을 조정하기 위해 최선을 다하고 있습니다. 이러한 접근 방식의 차이는 주로 개발자가 이미 고려하고 있는 웹 플랫폼과 모바일 앱 플랫폼 간의 필요한 기술적 차이로 인한 것입니다. |
| 개인 정보 보호 샌드박스 API를 테스트하는 리소스 | 충분히 할당하기 어려움
개인 정보 보호 샌드박스 API를 테스트할 수 있는 리소스를 확보했습니다. |
Google에서는 복잡성을 줄이고 API 채택을 지원하기 위해 테스터에게 제공되는 문서와 지원을 지속적으로 개선하고 있습니다. 이러한 노력의 일환으로 API별 메일링 리스트, 개방된 업무 시간, developers.chrome.com에서 지속적으로 업데이트되는 업데이트 등이 있습니다. |
| 샌드박스 API 거부 신호 | 광고 기술과 웹사이트에서 사용할 수 있는 '사용자가 샌드박스 API를 선택 해제했습니다' 신호를 제공하기 위한 요청입니다. | 이전에는 웹사이트가 사용자의 설정을 변경하도록 하여 '서드 파티 쿠키 사용 중지'와 같은 사용자 선택에 반응하는 경우가 많이 있습니다. 이러한 경우 사용자가 설정을 변경하지 않으면 웹사이트 액세스를 차단하는 경우가 있습니다. 거부 신호는 디지털 지문 수집을 위한 추가 신호로 사용될 수도 있습니다. 현재로서는 Google에서 거부 신호를 제공하지 않을 것입니다. |
| (2분기에도 보고됨)
더욱 명확한 타임라인 |
보다 명확하고 자세한 게시 일정 | 3분기 업데이트:
아래의 의견 반영에 따른 변경사항 섹션에서 설명한 바와 같이, Google에서는 7월에 개인 정보 보호 샌드박스 타임라인을 업데이트하여 예비 테스트 및 의견을 위한 시간을 더 제공하고, 서드 파티 쿠키가 지원 중단되기 전에 개인 정보 보호 샌드박스 API가 완전히 출시된 후 테스트할 시간을 더 확보했습니다. |
| (2분기에도 보고됨)
서드 파티 쿠키 지원 중단 일정 |
서드 파티 쿠키 지원 중단에 대한 추가 지연을 방지하기 위한 요청 | 3분기 업데이트:
지난 7월, Chrome은 기술의 복잡성과 생태계에 갖는 중요성을 감안하여 책임감 있게 행동하겠다는 Google의 노력을 반영하기 위해 서드 파티 쿠키 지원 중단에 관한 업데이트된 일정을 발표했습니다. 이러한 변경 이전에 규제 기관 및 업계의 의견이 반영되었으며, Google은 계속해서 모든 이해관계자와 긴밀하게 협력하고 있습니다. |
| 퍼스트 파티 쿠키 | 퍼스트 파티 쿠키에 대한 제한도 제안되나요? 만약 그렇다면 장기적인 안정성, 향후의 예측 불가능한 브라우저 변경 위험에 대한 우려로 인해 지금은 엔지니어링 작업도 낭비되었습니다. | 당사는 어떠한 퍼스트 파티 쿠키 제한사항도 고려하지 않았습니다. 개인 정보 보호 샌드박스는 서드 파티 쿠키 지원 중단에 중점을 둡니다. |
관련성 높은 콘텐츠 및 광고 표시
주제
| 의견 테마 | 요약 | Chrome 응답 |
| (2분기에도 보고됨)
다양한 유형의 이해관계자를 위한 유용성 |
트래픽 수준이나 콘텐츠의 전문성에 따라 사이트의 유용성에 대한 우려가 제기되었습니다. | 3분기 업데이트:
API의 유용성은 테스트를 통해 살펴봅니다. 약정 제17.c.ii항에 따라 Google은 이러한 테스트 결과를 CMA와 공유합니다. Chrome에서는 테스트 결과에 따라 분류 및 기타 매개변수가 변경될 것으로 예상합니다. 분류 또는 매개변수의 발전에 이전 버전과 호환되지 않는 변경사항이 필요하지 않을 수도 있습니다. 또한 서드 파티 쿠키 지원 중단 후에도 Chrome은 의견이 Topics API 발전에 계속해서 영향을 미칠 것으로 기대합니다. |
| 개인 정보 보호/정책 | 발신자별 주제 필터링 요구사항 삭제 요청입니다. | 개인 정보 보호 KOF, 개인 정보 보호 옹호자, 보안 전문가, 디지털 권리 그룹 등 생태계의 다른 주체들의 의견을 바탕으로 Chrome은 정보 액세스 권한이 있는 사람만 정보에 액세스할 수 있도록 이 설계를 선택했습니다. 그 이유에는 점진적인 교차 측 데이터 유출 제한, 투명성 및 설명 가능성 보장, 구현 및 설명이 간단한 접근 방식 채택, 디지털 지문 수집의 위험 제한 등이 포함되나 이에 국한되지 않았습니다. Topics를 받는 게시자와 서드 파티는 사이트에서 당사자와 공유할 정보를 직접 결정할 수 있습니다. 서드 파티가 이러한 정보를 공유하는 경우 Chrome은 사용자에게 이러한 정보를 투명하게 공개하고 제어 기능을 제공할 것을 적극 권장합니다. |
| 잘못 분류된 사이트 | 사이트의 주제가 잘못 분류되어 광고 타겟팅이 부정확할 수 있습니다. | 사이트는 사람이 선별한 재정의 목록(가장 인기 있는 사이트 포함)과 기기 내 ML 모델을 조합하여 분류됩니다. Chrome은 Topics 분류에 기여하는 사이트 옵션을 계속 평가합니다. 모든 유용성 개선은 개인 정보 보호 및 악용 위험과 비교되어야 합니다. 예를 들어 다음과 같은 위험이 있습니다.
누구나 chrome://topics-internals 또는 이 Colab을 통해 제공되는 도구로 이러한 구성요소를 검사할 수 있습니다. 테스트를 통해 분류가 지속적으로 개선될 것으로 예상되므로 카테고리 분류가 잘못되었을 수 있는 사이트에 대한 의견을 보내주시기 바랍니다. |
| 액세스 요구사항 | 액세스를 위해 페이지의 DOM 항목 페이지에 스크립트 또는 iframe을 적용하는 최신 Topics 요구사항으로 인해 광고 생태계의 플레이어에서 원치 않는 동작이 발생할 수 있습니다. | GitHub 설명 변경사항을 병합했습니다. HTTP 헤더에서 Topics를 지원하려고 합니다. |
| 주제 분류가 충분히 세분화되지 않음 | 현재의 주제 분류는 범위가 너무 넓어 지역별 주제와 같은 보다 세부적인 주제가 포함되지 않습니다. | 분류 체계를 개선하기 위해 지속적인 노력을 기울이고 있으며, 생태계 테스트와 의견 수렴을 통해 분류 체계도 발전할 것으로 예상됩니다.
Google에서는 생태계에 가장 유용한 분류 체계에 대한 의견을 적극적으로 받고 있습니다. 주제 수를 확장할지 아니면 더 세분화된 주제를 포함할지 평가할 때는 1) 잠재적 개인 정보 보호 영향 (예: 주제가 많을수록 디지털 지문 수집 위험이 발생할 수 있음) 및 2) 이전에 관찰된 주제를 검색하는 기능 (예: 주제가 많을수록 광고 기술이 과거에 선택한 주제를 인식할 가능성이 낮아질 수 있음) 등의 몇 가지 고려사항이 있습니다. 두 번째로 Google은 유용성과 개인 정보 보호를 모두 달성한다는 목표하에, 기존 필터링 요구사항 내에서 호출자가 이전에 관찰한 주제를 검색하는 능력을 극대화하는 방법을 모색하고 있습니다. |
| 주제 한도 | 웹사이트당 주제 3개는 광고주가 광고를 게재하기에 정보가 너무 적습니다. | 생태계의 의견, 특히 오리진 트라이얼의 테스트 결과는 API의 발전에 계속해서 영향을 미칠 것입니다. Topics는 방문자에게 적합한 광고를 찾는 데 도움이 되도록 문맥과 같은 다른 신호를 보완해준다는 점에 주목할 필요가 있습니다. 광고주는 주제 이외에 더 많은 정보를 활용할 수 있습니다. |
| (2분기에도 보고됨)
사용자 제어 및 안전 |
특정 주제는 민감한 집단의 프록시일 수 있으며 사용자는 부정적인 결과를 방지하기 위해 더 많은 제어 기능을 필요로 합니다. | 3분기 업데이트:
주제는 사용자 제어 및 투명성을 위한 중요한 진전을 나타냅니다. 사용자는 주제를 선택 해제하고, 자신에게 할당된 주제를 검토하고, 주제를 삭제하고, 특정 페이지에서 주제와 상호작용하는 회사를 파악할 수 있습니다. 또한 사용자는 주제가 파생된 방문 기록을 삭제하여 Topics를 지울 수도 있습니다. 이 컨트롤은 현재 기기 수준의 Chrome 브라우저에 구현되어 있습니다. Google은 개발자가 제안하는 것과 같은 고급 사용자 제어 기능에 관해 계속 논의하는 것을 환영하지만, 제기된 문제를 해결하기 위해 새로 추가된 기능을 적절히 보정하고 부분적인 변경을 하지 않도록 해야 합니다. |
| 검색엔진 최적화에 미치는 영향 | 게시자가 Topics를 더 잘 반영하기 위해 웹사이트의 호스트 이름을 조정하면 검색엔진 최적화에 부정적인 영향을 미칠 수 있습니다. | Google은 Topics를 위해서만 호스트 이름을 변경하지 말 것을 권장합니다. 사실 사이트가 이러한 방식으로 할당된 주제에 영향을 미칠 수도 있습니다. 그러나 이렇게 할 경우 게시자가 얻을 수 있는 이점은 극히 명확하지 않으며, 사이트에서 분류 모델을 '조작'하려고 하면 전체 생태계에서 Topics의 가치가 약화될 수 있습니다. 주제 할당도 고정된 것이 아닙니다. 테스트와 의견을 통해 분류 체계가 계속 발전할 것으로 예상됩니다. 이 테스트와 관련하여 잘못 분류되었을 수 있는 사이트의 예를 포함하여 의견을 보내 주시기 바랍니다. |
| 사기 및 악용 | 구매 측이 표시되는 주제가 브라우저에서 실제로 생성된 것인지 확인할 방법을 마련해야 합니다. | Google은 광고 기술 구매자가 프로그래매틱 광고 입찰에서 판매자가 전달한 주제를 확인할 수 있는 메커니즘을 지원하라는 제안을 환영합니다. 여기에서 활발한 토론에 생태계가 기여하도록 권장합니다. 현재는 우선순위가 높은 다른 개선사항에 집중하고 있지만, 향후 디자인에 중요한 개선사항이 될 수 있다는 점을 잘 알고 있습니다. |
| 사기 및 악용 | 퍼스트 파티 세트에 적용되는 것과 동일한 유형의 공개 게시 및 검토를 통해 Topics 데이터의 적법한 사용자인 당사자를 공개적으로 검토할 수 있습니다. | Google은 이러한 제안에 감사드리며, 공적 책무가 개인 정보 보호 샌드박스의 목표를 달성하는 데 중요한 도구라는 데 동의합니다. 누구나 사이트를 방문하고 JavaScript API에 대한 도메인의 호출을 관찰할 수 있으므로 Topics API 호출은 기본적으로 공개됩니다. 따라서 개인과 조직은 관련 활동을 확인하고 어떤 사이트에서 Topics를 어떻게 사용하고 있는지 평가할 수 있습니다. Google은 이 방법이 Topics API 자체의 기능 중에서 사이트의 '적법성'을 평가하는 것보다 낫다고 생각합니다. |
| 퍼스트 파티 신호에 미치는 영향 | 주제 신호는 매우 중요할 수 있으므로 그 결과 다른 퍼스트 파티 관심 기반 신호의 가치를 낮출 수 있습니다. | Google은 관심 기반 광고가 웹의 중요한 사용 사례라고 생각하며, Topics는 이러한 사용 사례를 지원하도록 설계되었습니다. 위에서 설명한 것처럼 다른 생태계 이해관계자는 Topics가 가치를 제공하기에 충분히 유용하지 않을 수 있다는 우려를 표했습니다. 어떤 경우든 분류를 개선하기 위해 지속적인 노력을 기울이고 있으며, 생태계 테스트와 의견 제공을 통해 분류 체계도 발전해 나갈 것으로 예상됩니다. |
FLEDGE
| 의견 테마 | 요약 | Chrome 응답 |
| FLEDGE 입찰 | SSP는 FLEDGE 입찰에 입찰하기 위해 Google Ads에 전송된 데이터의 형식을 지정하는 방법 | 테스트에 참여하는 기업은 테스트 계획에 관한 문서를 게시하고 필요한 경우 협력하는 것이 좋습니다.
Google은 CMA와 협력하여 정량적 테스트에 대한 접근 방식을 개발해 왔으며, CMA가 실험 설계에 관한 메모를 게시하여 시험 진행을 계획하고 있는 시장 참가자에게 자세한 정보와 제안된 접근 방식에 관해 의견을 말할 기회를 제공하는 데 도움을 주고 있습니다. Ad Manager팀에서는 Ad Manager를 광고 서버로 사용하는 게시자와 함께 FLEDGE를 테스트하는 데 관심이 있는 판매자를 위한 문서를 여기에 게시했습니다. 여기에서 추가적인 기술 세부정보를 확인하세요. |
| 중첩된 펜스된 프레임의 FLEDGE | 펜스된 프레임은 덜 제한적인 테스트를 허용하며 정의되지 않은 향후에는 더 많이 제한합니다. 이처럼 알려지지 않은 이 타임라인은 광고 생태계에 당면한 과제를 안겨줍니다. | 기업은 현재 Fenced Frames로 FLEDGE를 테스트할 수 있습니다. 더 쉬운 온보딩 옵션을 제공하기 위해 기업은 먼저 FLEDGE를 구현할 수 있습니다. FLEDGE를 구현한 후에는 FLEDGE 설계로 펜스된 프레임을 테스트할 수 있습니다. |
| 데이터 처리 정책 | 관심분야 그룹 / FLEDGE에 대한 데이터 처리 정책은 무엇인가요? | FLEDGE 설계에서는 관심분야 그룹에 저장된 모든 데이터 또는 어떤 관심분야 그룹에 속한 사람인지에 관한 모든 데이터가 기기에 유지됩니다. 이 데이터는 Google 서버로 전송되지 않습니다.
FLEDGE에 적용할 Chrome의 일부 개인 정보 보호 기능에는 Google에서 운영하는 k-익명성 서버와의 상호작용이 포함됩니다. 이러한 상호작용은 사용자에 관한 정보 공유를 방지하고 신뢰할 수 있는 실행 환경 (TEE)에서 실행되어 광고 생태계 전반의 정보 패리티를 보장하기 위해 세심하게 설계되어 있습니다. \ Google은 Google의 비즈니스를 자체적으로 우선하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안서를 설계하고 구현하고, 디지털 광고의 경쟁과 게시자 및 광고주에게 미치는 영향을 고려하기 위해 CMA에 최선을 다하고 있습니다. Google은 이러한 약속을 준수하기 위해 CMA와 계속해서 긴밀히 협력하고 있습니다. |
| 연령 정책 | Chrome은 FLEDGE에서 생성된 잠재고객이 연령 제한을 준수하도록 어떻게 보장하나요? | 게시자와 광고주는 FLEDGE를 사용하여 생성하는 잠재고객이 관련 법규를 준수하는지 여부를 평가할 수 있습니다. 사용자 보호를 강화하기 위해 테스트 기간 중에도 계정과 연결된 연령이 만 18세 미만인 경우 Chrome에 로그인한 모든 사용자에게 개인 정보 보호 샌드박스 API가 활성화되지 않습니다. 로그아웃한 사용자의 경우 Chrome은 브라우저에서 사용자 연령을 추론할 수 있는 프로필 신호를 수집하지 않습니다. |
| FLEDGE 키/값 서비스 | 키 수 및 업데이트 빈도와 같이 FLEDGE 키/값 서비스에서 허용하는 항목을 더 명확하게 설명합니다. | FLEDGE를 사용하는 회사는 RAM에 들어갈 수 있는 만큼의 키를 보유할 수 있습니다. 자세한 내용은 여기에서 설명 자료를 참조하세요.
Google은 데이터를 더 빠르게 수정할 수 있는 방법을 모색하고 있으며, 요구사항에 대한 제안을 환영합니다. |
| 테스트 | Google Ads에서 FLEDGE를 테스트하기 어려움 | 오리진 트라이얼에 가장 효과적으로 참여하고 테스트하는 방법은 Google Ads 온보딩 문서를 참조하세요. |
| 입찰 서비스 API | 입찰 서비스 API에 대한 Google의 방향은 무엇인가요? 기기 입찰에서 Chrome 브라우저 FLEDGE보다 높거나 낮은 우선순위로 지정되나요? | Google은 현재의 FLEDGE 기기 내 입찰 설계를 준수하기 위해 최선을 다하고 있습니다. 기기의 컴퓨팅 성능 또는 네트워크 속도가 제한될 수 있는 일부 사용 사례를 지원하기 위해 가능한 솔루션을 모색하기 위해 입찰 서비스를 제안했습니다. |
| 종합 보고 | generateBid에 사용할 수 있는 모든 신호를 기반으로 하는 종합 보고서 지원을 요청합니다. | 곧 이 내용을 공개적으로 공유할 계획입니다. |
| 문맥 광고 | FLEDGE를 사용하여 문맥 광고 게재 | Google은 이 옵션을 고려했으며 이 토론에서 설명한 이유로 인해 현재는 문맥 광고에 FLEDGE를 사용하지 않는 것이 좋습니다. |
| 실제 환경에서 테스트하기 | 실제 테스트를 위해 FLEDGE를 서드 파티 쿠키에서 격리하는 방법에 관한 안내 | Google은 테스트 집단을 제공하는 방법을 연구하고 있습니다.
Google은 CMA와 협력하여 정량적 테스트에 대한 접근 방식을 개발했으며, 시장 참여자에게 더 많은 정보를 제공하고 제안된 접근 방식에 대해 의견을 제시할 수 있는 기회를 제공하기 위해 CMA가 실험 설계에 관한 메모를 게시하도록 지원합니다. |
| FLEDGE 및 Attribution Reporting API 테스트 | FLEDGE로 Attribution Reporting API를 구현하는 가장 좋은 방법은 무엇인가요? FLEDGE와 기여 분석을 분리하거나 함께 테스트하는 것이 좋은가요? | 최종적으로 FLEDGE와 Attribution Reporting API 모두를 통합 솔루션으로 테스트할 수 있도록 지원할 예정이지만, 개발자는 먼저 Attribution Reporting API를 독립적으로 테스트한 다음 통합이 완료되면 FLEDGE를 사용하는 것이 좋습니다. |
| 입찰가 표시 | 입찰가 난독화 요청입니다. | `generateBid()` 또는 `scoreAd()` 내에 중단점을 설정하여 DevTools에서 입찰가에 액세스할 수 있습니다. Chrome팀은 FLEDGE에 관한 이 의견에서 제기된 좁은 공격 벡터를 고려했습니다. 하지만 Chrome의 보안 및 개인 정보 보호 모델은 사용자가 자신의 기기에서 정보를 가지고 원하는 모든 작업을 할 것이라고 생각하므로 입찰 데이터를 요청에 따라 숨길 방법이 없습니다. |
| 문서 요청 | 실시간 생태계에서 테스트하기 위한 문서와 예 | 이번에 발표된 자료가 도움이 되었다는 점을 높이 사며, 개발자가 새로운 기술이 어떻게 도움이 될지 계속 이해할 수 있도록 앞으로 몇 주에서 몇 달에 걸쳐 더 많은 자료를 제공하기 위해 최선을 다하겠습니다.
또한 외부 개발자 상담 시간을 열어 제품 및 엔지니어링 팀장들과 권장사항과 데모를 공유하고 실시간 토론/질문을 진행하기도 했습니다. |
| Private Aggregation API | Private Aggregation API에 대한 추가 정보가 요청되나요? | 공개 설명에는 현재 공유 가능한 최신 정보가 포함되어 있습니다. 이 API가 개발되고 사용 사례가 정의되면 더 많은 문서가 제공됩니다. |
| 데이터 지연 시간 | FLEDGE 키/값 서버 데이터 검색은 실시간으로 진행되나요? | 공개된 GitHub 문제에 설명된 대로 쿼리를 위해 서버에서 업데이트된 데이터를 반환하기까지 몇 시간이 아닌 몇 분 정도의 비활성 상태가 발생할 수 있습니다. 개발자 의견도 환영합니다. |
| 입찰 서비스 | 입찰 및 입찰 (B&A) 서비스를 사용하는 경우 입찰가가 사용자에게 표시되지 않나요? | B&A 서버 측 접근 방식의 경우, 개별 입찰가는 사용자에게 표시되지 않습니다. 입찰 요청이 SSP 입찰 서비스에서 DSP 입찰 서비스로 직접 전송되었고 따라서 브라우저에서 더 이상 사용할 수 없기 때문입니다.
하지만 낙찰가는 브라우저에 계속 표시됩니다 (입찰가 난독화 요청과 관련하여 위에서 자세히 설명). |
| 입찰 서비스 | 입찰 서비스와 경매 서비스의 부하를 분산하는 방법 | 현재 부하 분산에 대한 지침은 없지만 성능 및 개인 정보 보호 측면에서 모두 중요한 관심사입니다. 향후 자세한 내용을 제공해 드리겠습니다. |
| FLEDGE 한도 | JoinAdInterestGroup 기간 한도를 30일에서 90일로 상향 조정하도록 요청합니다. | 30일의 데이터 보관 기간은 Attribution Reporting의 30일 제한, Topics의 3주간 전환 확인과 같은 다른 개인 정보 보호 샌드박스 광고 API와 일치합니다. 이 기간은 광고 기술의 요구사항과 사용자의 개인 정보 보호 기대치를 모두 충족합니다.
그러나 여기에서 문제에 대해 계속 논의하므로 추가 의견을 보내주시기 바랍니다. |
| FLEDGE의 공유 저장소 | FLEDGE에서 Shared Storage API를 사용할 수 있나요? | Google은 향후 FLEDGE에서 Shared Storage API를 지원할 예정이며, 예정된 오리진 트라이얼에서 이 API를 사용할 수 있도록 노력하고 있습니다. |
| 클릭을 통한 게재빈도 관리 | FLEDGE에서 클릭수 (낙찰이 아님)별로 최대 게재빈도를 설정할 수 있나요? | FLEDGE는 Fenced Frame이 navgator.leaveAdInterestGroup()을 매개변수 없이 호출하여 광고를 표시한 관심분야 그룹에서 나갈 수 있다고 지정합니다. 이 호출은 클릭이 수신된 처음 관심분야 그룹에서 나갈 수 있도록 지정합니다. 이는 향후 입찰을 방지하기 위해 최대 게재빈도 설정의 한 형태입니다. 현재 이 방법은 클릭이 두 번 이상 발생한 후에는 한도를 설정할 수 없습니다. |
| 중첩된 Fenced 프레임의 FLEDGE | 클릭이 중첩된 분리 프레임에서 발생하면 분리 프레임 광고 보고서를 통해 클릭수를 보고할 수 없습니다. | 여기에 문제 해결을 위한 제안서를 게시했습니다. |
| 측정 | FLEDGE 입찰에서 입찰자의 지연 시간 데이터를 수집하는 방법에 대한 안내가 필요합니다. | 실적 측정 문서를 곧 게시할 수 있습니다. |
| 보고서 | FLEDGE 보고는 어떻게 처리되나요? | 낙찰, 입찰 결과, 이벤트 등의 클릭수에 대한 FLEDGE 보고는 reportResult()와 같은 FLEDGE API를 통해 사용할 수 있습니다. 광고 전환을 사용한 보고에 대해서는 Attribution Reporting API와의 통합이 FLEDGE와 별개이지만 가능한 접근 방식에 대해 생태계와 진행 중인 논의가 있습니다.
Private Aggregation API는 격리된 실행 환경 내에서 입찰 결과를 보고하는 데도 사용할 수 있습니다. 여기에서 설명을 참고하세요. |
| 관심분야 그룹 규모 | 광고 기술이 관심분야 그룹의 규모 (즉, 그룹의 사용자 수)를 확인할 수 있는 방법이 있나요? | 관심분야 그룹 멤버십은 브라우저에 의해 사용자 기기에 저장되며 브라우저 공급업체 및 다른 누구와도 공유되지 않습니다.
그러나 관심분야 그룹 소유자는 이론적으로 navgator.joininterestgroup(...)에 대한 모든 호출을 추적할 수 있습니다. 사용자가 언제든지 그룹을 탈퇴할 수 있으므로 이 호출을 추적한다고 해서 IG의 정확한 크기가 보장되지는 않지만, 소유자에게 상한선과 근사치를 제공합니다. |
| 성능 | 입찰 JS/WebAssembly 코드는 모든 입찰에서 컴파일되나요? | 입찰 JS/WebAssembly 코드는 매 입찰마다 한 번씩 컴파일됩니다. |
| 성능 | BidDurationMsec의 범위는 무엇인가요? | BidDurationMsec에는 컴파일 스크립트 시간이 포함됩니다. 다운로드 시간, 컴파일 시간, 네트워크 시간, 키-값 서버에서 가져온 시간 또는 JS 컴파일 이전의 모든 항목은 포함되지 않습니다. |
| 맞춤설정 | adComponent를 사용자에게 맞춤설정하도록 업데이트할 수 있나요? | joinInterestGroup을 호출하거나 Chrome에서 DailyUpdateURL을 호출할 때 호출자가 관심분야 그룹을 업데이트할 때 adComponent를 업데이트할 수 있습니다. 이렇게 하면 호출자는 현재 사이트의 사용자 정보를 기반으로 또는 k-익명 정보를 기반으로 adComponent를 각각 업데이트할 수 있습니다. 여기에서 제품 수준 turtledove의 원래 제안서를 확인할 수 있습니다. 여기에는 추천 사용 사례의 핵심 측정항목에 대한 RTB House의 분석이 포함되어 있습니다. |
| 관심분야 그룹 | 관심분야 그룹 소유자가 특정 사용자를 조건부로 삭제할 수 있나요? | 관심분야 그룹 멤버십은 사용자의 브라우저에만 저장되며 사용자 측에서만 삭제할 수 있습니다 (예: 사이트 데이터 삭제).
하지만 사용자가 관심분야 그룹 소유자가 관리하는 페이지로 돌아가는 경우 관심분야 그룹 소유자가 navgator.leaveAdInterestGroup()을 조건부 로직을 호출할 수 있습니다. |
| 성능 | generateBid의 실적은 어떻게 측정하나요? | 컴파일 및 실행 시간은 입찰DurationMsec로 측정할 수 있습니다. 다운로드 시간은 chrome://net-export로 측정할 수 있습니다. 최신 버전의 Chrome에서는 컴파일 및 실행 시간이 DevTools Performance 탭에 표시됩니다. |
| 관심분야 그룹 업데이트 빈도 | 브라우저에서 관심분야 그룹을 업데이트하는 빈도는 어떻게 되나요? | 최근 24시간 동안 업데이트되지 않은 관심분야 그룹의 경우 Chrome은 navgator.updateAdInterestGroups()가 호출되거나 입찰에 참여할 기회가 있을 때 관심분야 그룹을 업데이트하려고 시도합니다. 자세한 내용은 여기의 설명을 참고하세요. |
| 집계 서비스 제공업체 | 다른 클라우드 제공업체는 언제 집계 서비스에서 지원되나요? | 현재 특정 시간에 대한 업데이트가 없지만 업데이트되면 더 많은 소식을 공유할 예정입니다. 현재로서는 AWS만 집계 서비스의 보안 요구사항을 충족합니다. |
| FLEDGE 테스트 타임라인 | FLEDGE는 BYOS에서 얼마나 오래 테스트되나요? BYOS 모델에서 TEE 기반 모델로 전환할 수 있는 시간이 충분할까요? | 생태계에서 충분한 테스트를 진행할 수 있도록 서드 파티 쿠키 지원 중단 시점까지는 TEE 사용을 요구하지 않을 것으로 예상됩니다. 전환이 이루어지기 전에 개발자가 테스트와 채택을 시작할 수 있도록 실질적인 공지를 제공할 예정입니다. 현재로서는 추가 업데이트가 없지만 업데이트되면 더 많은 소식을 전해 드리겠습니다. 여기에서 최신 정보를 확인하세요. |
| 데이터 크기 한도 | 입찰 함수에서 wasm의 데이터 크기 한도는 얼마인가요? | 여기에 설명된 대로 관심분야 그룹 업데이트로 인해 50kb를 초과하는 관심분야 그룹이 될 수는 없지만, wasm의 데이터 크기 제한이 아직 정의되어 있지 않으므로 이 주제에 관해 의견을 제공해 주시면 감사하겠습니다. |
| 입찰 신호 | 입찰 신호의 표준화된 데이터 구조가 있나요? | 아직 정의되지 않았지만 피드백을 기다리고 있습니다. |
| 광고 기술 서버 쿼리 | K/V 서버에서 광고 기술 서버 데이터를 실시간으로 쿼리할 수 있나요? | 아니요. K/V 서버는 사용자 데이터 유출을 방지하기 위해 '네트워크, 디스크 액세스, 타이머 또는 로깅 없음'을 시행하는 신뢰 모델에서 실행됩니다. 자세한 내용은 여기에서 신뢰 모델 설명을 참고하세요. |
| adComponent 업데이트 빈도 | 현재는 사용자의 방문 기록을 통해 adComponents 필드 (현재 IG 설정에만 해당)를 업데이트할 수 없습니다. | 개인 정보 보호 샌드박스는 크로스 사이트 추적 없이 웹 생태계의 요구사항을 지원하는 것을 목표로 합니다. 즉, 방문 기록에 대한 액세스를 방지하는 것입니다. Topics와 같은 대안을 사용하는 것이 좋습니다. |
| 입찰 결과 | 광고 기술이 입찰 낙찰률을 알 수 있는 방법이 있나요? | 입찰 결과는 판매자와 낙찰된 구매자가 각각 제공한 입찰 코드에서 reportResult() 및 reportWin() 함수를 호출하여 보고되므로, 각각 입찰 결과에 대한 로깅 및 보고를 실행할 수 있습니다. |
| (2분기에도 보고됨)
제외 관심분야 그룹 타겟팅 지원 |
제외 관심분야 그룹 타겟팅을 지원하는 API: 사용자가 관심분야 그룹에 속하지 않는 경우에만 광고를 표시합니다. | 3분기 업데이트:
새로운 제안서 를 공유하였으며 의견을 기다리고 있습니다. |
디지털 광고 측정
Attribution Reporting (및 기타 API)
| 의견 테마 | 요약 | Chrome 응답 |
| OT 요구사항 | OT 중에만 또는 OT 기간에만 권한 정책 제한을 삭제합니다. | 테스트 중에 권한 정책에 대해 공지된 변경사항을 확인하시기 바랍니다. 이번 변경으로 해결된 근본적인 이해관계자의 우려는 DSP가 더 많은 수의 교차 출처 iframe에서 API를 테스트할 수 있도록 하는 것입니다. 원래 DSP는 게시자/SSP와 협력하여 교차 출처 iframe에서 API를 테스트하기 위해 올바른 권한 정책이 설정되었는지 확인해야 했지만, 이번 변경을 통해 DSP는 기본적으로 API를 호출할 수 있게 되며 오리진 트라이얼 동안 필요에 따라 SSP/게시자가 API를 사용 중지할 수 있습니다. |
| 소음 | 노이즈 수준이 너무 높아 보고의 유용성에 영향을 미치고 있다는 피드백 | 노이즈에 관한 의견을 보내주시면 특정 노이즈 관련 매개변수를 설정하는 방법을 결정할 때 사용됩니다. 또한 테스터에게 도움이 되는 리소스, 도구, 기타 문서를 추가로 게시할 계획입니다. |
| 교차 도메인 전환 | 교차 도메인(예: 2개 이상의 도착 페이지) 전환을 추적하는 방법 | Google은 현재 이 질문에 대한 의견을 논의하고 있으며 의견을 구하고 있습니다. |
| 디버깅 요구사항 | 개발자가 요약 보고서를 배포 / 테스트할 때 개발자가 잔여 개인 정보 보호 예산을 확인할 수 있도록 허용하시겠습니까? | 이 기능 요청은 여기에서 추적할 수 있습니다. |
| API 사용 정책 | 디지털 지문 수집과 같은 제한사항에 따라 특정 API를 사용할 수 있는 사용자 관련 정책을 제안하는 의견 | 이는 매우 흥미로운 아이디어이며, Google은 다른 브라우저 제공업체 및 더 광범위한 웹 생태계와도 적극적으로 협력하고 싶습니다. |
| 전환 보고서의 만료 설정 | 24시간 미만의 보고서 필터 / 만료를 지원하도록 요청합니다. | 시간 수준 만료는 광고 기술에서 사용자가 광고주 사이트를 방문하는 시간을 정확히 알 수 있게 하므로 개인 정보 보호 문제의 원인이 됩니다. 일 수준의 만료를 사용하면 사용자가 사이트를 방문한 시간을 결정하지 않고 광고 기술에서 무효 노출을 필터링할 수 있습니다. |
| OT 토큰 만료 | 운영 오버헤드 감소를 위해 기존 OT 토큰의 유효성 연장 요청 | Google은 토큰 갱신이 필요하다는 점을 인지하고 있으며, 개발자가 보다 쉽게 토큰을 처리하고 추가 알림을 제공할 수 있도록 노력하고 있습니다. |
| 지역별 지원 | 집계 서비스는 현재 일부 리전을 지원하지 않습니다. | 이는 현재 베타의 제한사항입니다. 테스트가 진행됨에 따라 더 많은 지역을 지원할 예정이지만 아직 명확한 일정은 정해지지 않았습니다. |
| 이벤트 수준 보고 지연 | 특정 사용 사례의 경우 이벤트 수준 보고에서 2~30일의 지연이 너무 길 수도 있습니다. | Google은 광고 기술에서 만료를 통해 이벤트 수준 보고서가 전송되는 시기를 제어할 수 있도록 여기에서 제안서를 공유했습니다. 기본값은 30일이지만 이보다 짧게 설정할 수도 있습니다. |
| (2분기에도 보고됨)
멀티 터치 기여 분석 |
멀티 터치 기여 분석(예: 교차 기기 또는 교차 앱)을 허용합니다. | 3분기 업데이트:
현재의 멀티 터치 기여 분석 방식은 여러 웹사이트에서 발생하는 사용자 노출 (및 ID)을 확정적으로 연결해야 합니다. 따라서 현재 형식의 이 기능은 크로스 사이트 추적 없이 주요 광고 사용 사례를 지원하는 것을 목표로 하는 개인 정보 보호 샌드박스의 목표에 부합하지 않습니다. |
| FLEDGE 및 Attribution Reporting 통합 타임라인 | FLEDGE 및 Attribution Reporting API 통합 타임라인은 어떻게 되나요? | 현재로서는 알려드릴 소식이 없지만 구체적인 일정이 잡히면 추가 정보를 공개할 예정입니다. |
| 여러 트리거 유형 | 트리거 등록의 유연성을 높여달라고 요청합니다. | Google에서는 광고 기술이 이벤트 수준 보고서와 집계 가능한 보고서를 더 유연하게 제어할 수 있도록 집계 API를 위한 중복 삭제 시스템을 제안했습니다. |
| 측정 | 인벤토리의 실적이 좋은지 여부에 대한 측정 데이터를 수신하기 위한 요청입니다. | 의견을 보내주셔서 감사합니다. 이 요청의 사용 사례를 더욱 명확하게 밝히고자 합니다. |
| 전환 만료 | 소스 태그뿐만 아니라 트리거 태그에 대한 전환 만료를 지원하도록 요청합니다. | 의견을 보내주셔서 감사합니다. 이 요청의 사용 사례를 더욱 명확하게 밝히고자 합니다. |
| 일괄 보고 | 일괄 보고의 추가 측정 요청입니다. | Google에서는 집계 서비스에 미치는 영향에 대해 계속 고민하면서 의견을 보내 주셔서 감사합니다. 애드테크에서 보고서 일괄 처리와 예상 실행 빈도에 대해 어떻게 생각하고 있으며, 한 해 동안 일괄 처리 전략이 어떻게 바뀌는지에 대한 의견을 듣고 싶습니다. |
| Epsilon | epsilon 값은 언제 결정되나요? | Google은 생태계 테스터들과 적극적으로 협력하여 epsilon 값을 확정하고 GA에서 이 값을 구현하는 방법을 확정하고 있습니다. 이 값은 가치 결정으로 이어진 논의와 함께 공개적으로 표시됩니다. 의견이 있는 경우 이 GH 문제를 통해 게시해 주세요. |
비밀 추적 제한
사용자 에이전트 축소
| 의견 테마 | 요약 | Chrome 응답 |
| 배포 종속 항목 | 구조화된 사용자 에이전트 (SUA) 배포 종속 항목 해결 | Google은 버전 101 이상에서 Chrome 사용자 100% 에게 마이너 버전 축소라고도 하는 '4단계'를 출시했습니다. 여기에서 업데이트를 확인하세요. |
| 테스트 | Meta에서 사용자 에이전트 축소 오리진 트라이얼 연장 요청 | Google은 오리진 트라이얼을 연장하고 대규모 사이트를 수용할 수 있도록 트래픽 제한을 삭제할 수 있는 권한을 획득했습니다. 완화된 트래픽 제한은 규모에 관계없이 모든 사이트에 적용됩니다. |
사용자 에이전트 클라이언트 힌트
| 의견 테마 | 요약 | Chrome 응답 |
| (2분기에도 보고됨)
사기 / 악용 방지 우려사항 |
UA-CH를 통해 손실될 수 있는 특정 기능: 클릭 리디렉션 추적기 및 허위 클릭 | 3분기 업데이트:
Google은 사기 방지 파이프라인에 부정적인 영향을 미치지 않는다는 내용의 긍정적인 피드백을 받았습니다 (결과는 여기 및 여기 참고). 팀은 사기 방지 및 측정 이해관계자와 함께 이러한 잠재적 문제를 계속 조사하고 있습니다. |
| 권한 정책 | 권한 정책이 캐시되나요? | 권한 정책은 이 GitHub 문제에 설명된 대로 캐시되지 않습니다. |
Gnatcatcher (작업 진행 중)
| 의견 테마 | 요약 | Chrome 응답 |
| 위치정보 사용 사례 | Gnatcatcher는 향후 위치정보에 기반한 콘텐츠 맞춤설정과 같은 적법한 위치정보 사용 사례가 작동하지 않도록 할 수 있습니다. | Google은 Chrome이 합법적인 IP 주소 사용 사례를 계속 지원하기 위해 이해관계자와 협력하고 있습니다. |
크로스 사이트 개인 정보 보호 경계 강화
퍼스트 파티 세트
| 의견 테마 | 요약 | Chrome 응답 |
| 정책 | FPS가 예상하는 사이트 수에는 3개가 있지만 GDPR은 세트의 사이트 수에 제한을 두지 않는다는 점을 근거로 FPS가 '관련 데이터 보호법'과 관련된 CMA의 약속 조항과 일치하지 않는다는 우려 | Google은 Google의 자체 비즈니스를 자체적으로 선호하여 경쟁을 왜곡하지 않는 방식으로 개인 정보 보호 샌드박스 제안서를 설계 및 구현하고, 디지털 광고, 게시자, 광고주의 경쟁에 미치는 영향뿐 아니라 개인 정보 보호 결과 및 '관련 데이터 보호법'에 규정된 데이터 보호 원칙 준수에 미치는 영향을 고려하기 위해 CMA를 위해 노력해 왔습니다. 명시된 우려사항은 GDPR과의 비호환성을 공개하지 않습니다. Google은 이러한 약속을 준수하기 위해 CMA와 계속해서 긴밀히 협력하고 있습니다. 자세한 내용은 아래의 '의견에 따른 변경사항' 섹션을 참고하세요. |
| 문서 | 추가 예시를 요청하고 기존 설명 문구를 업데이트합니다. | 설명의 예는 검토 중이며 필요에 따라 명시되거나 삭제됩니다. |
| 환경설정 공유 | 같은 파티 집단에서 선호도를 정하기 위한 제안입니다. | Google은 의견을 기다리고 있으며 여기에서 아이디어에 대해 활발하게 토론하고 있습니다. |
| 정책 시행 | 투명한 시정 조치 절차는 악의적인 행위자가 악용할 위험이 있습니다. | 의견을 보내주셔서 감사합니다. GitHub (이 문제에서 제기된 요점을 고려하고 이 문제에서 제기된 제안사항을 고려하고 있음) 및 기타 포럼에서 이 위험을 평가하고 잠재적인 완화 조치를 파악하기 위해 이해관계자와 적극적으로 대화하고 있습니다. |
| 공동 소유권 | 공동 소유권에 대한 컴퓨터가 읽을 수 있는 선언에 대한 제안입니다. | Google에서는 제안서에 대한 의견을 보내주시기 바랍니다. |
| 하위 도메인 소유권 | 서로 다른 데이터 컨트롤러, 다른 개인정보처리방침을 사용하거나 다른 법인에서 운영하는 여러 하위 도메인이 동일한 퍼스트 파티 세트에 포함되어야 하나요? | Google은 의견에 따라 일반적인 eTLD 사용 사례를 삭제할 계획입니다. |
| 악용 완화 | 악용 완화 조치에 대한 자세한 내용 요청입니다. | 절차 관리는 현재 고려 중이며 자세한 내용은 앞으로 몇 달 안에 공유될 예정입니다. |
| 잠재적 공격 벡터 | 쉽게 찾을 수 있는 페이지에 대한 사기성 관련 세트를 사용하여 기만적인 방식으로 독립적인 페이지로 트래픽을 유도할 수 있습니다. | Google에서는 대중의 의견을 적극적으로 수집하고 이 문제를 해결할 방법을 모색하고 있습니다. |
| 검증 설정 | 동의를 받은 일반 정책을 통해 세트를 검증합니다. | 웹 표준 커뮤니티와 광범위한 생태계의 다양한 구성원들이 실현할 수 없다고 지적했습니다. |
| 도메인 한도 | 연결된 도메인 수 확장 요청입니다. | Google은 FPS의 도메인 제한에 대해 활발하게 논의 중이며, 사용 사례에 필요한 관련 도메인 수에 대한 커뮤니티의 의견을 더 받고자 합니다. |
| 하위 집합 서비스 상호작용 | 서비스 및 관련 하위 집합 상호작용 관련 우려사항 | 피드백을 제공해 주셔서 감사드리며 향후 사양에서 이를 보다 명확히 할 수 있도록 노력하겠습니다. |
| (2분기에도 보고됨)
개인 정보 보호 개선 |
동일한 집합에 있는 사이트가 너무 많으면 서드 파티 쿠키와 유사한 결과가 발생할 수 있습니다. | 3분기 업데이트:
최신 제안에서는 '연결된' 하위 집합 (ccTLD 및 서비스 도메인은 포함하지 않음)에 대해 도메인을 3개로 제한하도록 제안합니다. Chrome은 이 제한이 적절한지 판단하기 위해 생태계와 활발하게 협력하고 있습니다. |
| (2분기에도 보고됨)
일반적인 개인정보처리방침 요구사항 |
모든 제품, 그리고 동일한 집합에 속해야 하는 관할권에서 공통의 개인정보처리방침을 유지하는 것은 불가능합니다. | 3분기 업데이트:
공통 개인정보처리방침이 더 이상 동일한 집합에 속하지 않아도 됩니다. |
Fenced Frames API
| 의견 테마 | 요약 | Chrome 응답 |
| iframe의 속성 대신 새 요소가 필요한 이유는 무엇인가요? | 기존 iFrame 제안이 아닌 Frenced Frame 제안에 관한 질문입니다. | Google은 여러분의 의견을 환영하며 여기에서 논의한 바와 같이 현재 상태를 수렴하는 방법에 대한 아이디어를 기다리고 있습니다. |
| 분리 프레임의 교차 관찰자 | 펜스된 프레임 내 정보의 조회가능성에 관한 질문 | 이 내용은 이 문서와 GitHub에서 현재 활발하게 논의되고 있는 주제입니다. Google에서는 파트너가 지원 방법을 더 잘 이해할 수 있도록 사용 사례를 공유해 주시기 바랍니다. |
| 동영상 및 네이티브 인벤토리 지원 | 펜스된 프레임은 동영상 및 네이티브 인벤토리를 지원하나요? | 동영상 재생 기능 측면에서 펜스된 프레임은 iframe과 다르지 않으므로 공개 문서에 명시적으로 언급되어 있지 않습니다. 동영상 광고에 문제가 있는 경우 의견을 제출해 주시면 더 자세히 조사하는 데 도움이 됩니다. |
| 웹 번들 | 향후 Fenced Frame x FLEDGE에서 웹 번들을 통한 광고 게재 / 렌더링이 필수가 될 예정인가요? | 장기적인 목표는 웹 번들을 지원하여 분리 프레임에서 광고 콘텐츠를 렌더링하는 것입니다. 그러나 현재 FLEDGE 구현은 이를 지원하지 않으며 렌더링 URL에서 가져온 HTML 리소스를 렌더링해야 합니다. |
| 애셋 크기 | 적절한 크기의 광고 소재로 응답할 수 있도록 draw_url에 슬롯 높이 및 너비 매크로를 지원하도록 요청합니다. | 이 문제는 여기에서 활발하게 논의되고 있습니다. |
Shared Storage API
| 의견 테마 | 요약 | Chrome 응답 |
| FLEDGE 통합 | Shared Storage와 FLEDGE는 어떻게 통합되나요? | Google은 현재 이 목표를 추구하지는 않지만, 개인 정보 보호 기능의 보존을 보장할 수 있는지만 확인하고자 합니다. 이해관계자는 Shared Storage GitHub 저장소 또는 FLEDGE github 저장소에서 이 제안서가 지원할 수 있는 잠재적 사용 사례에 관한 제안을 제출하는 것이 좋습니다. . |
| 데이터 보관 | 공유 저장소를 비우면 유틸리티가 줄어듭니다. 보관 기간을 연장하거나 개별 키/값을 삭제할 수 있는 기능이 대안으로 간주되었나요? | Google은 항상 사용자 개인 정보 보호와 유용성의 균형을 이루기 위해 노력하고 있습니다. Google은 조정에 대한 의견을 기다리고 있습니다. 파트너가 공유 스토리지를 테스트할 때 추가 의견 및 세부정보를 제공해 주시기 바랍니다. |
| 부정적 신호 | 공유 저장소 제안에 대해 Mozilla의 부정적인 신호입니다. | 제안을 신중히 검토해 주신 Mozilla님께 감사드립니다. 조만간 답변을 받으실 수 있도록 노력하겠습니다. |
칩
| 의견 테마 | 요약 | Chrome 응답 |
| 파티션을 나눈 요구사항 | 퍼스트 파티 쿠키의 '파티션을 나눈' 속성에 관한 명시적인 동작 요구사항을 추가합니다. | PrivacyCG 통화에서 이 문제에 대해 논의한 바 있으며, 메모와 함께 GitHub 문제 에 대해 후속 조치를 취했습니다. Google은 브라우저, 개발자, 개인 정보 보호 커뮤니티와 계속 협력하여 특정 동작을 조율하고 이를 명시하고 있습니다. |
| 인증된 삽입 | 파티션 나누기가 인증된 삽입에 영향을 미치므로 CHIPS는 현재 SSO 로그인 흐름에 영향을 미칠 수 있습니다. | Google은 인증된 삽입 사용 사례를 알고 있으며 솔루션을 모색하기 위해 노력하고 있습니다. |
| 쿠키 파티션 제한 | 현재 쿠키 한도인 10개로는 특정 사용 사례에 충분하지 않을 수 있습니다. | 쿠키 수의 제한이 12KB 메모리 한도로 변경됩니다. 이를 통해 성능과 브라우저 메모리 사용량에 부정적인 영향을 주지 않으면서도 쿠키 한도에 대한 우려를 해소할 수 있습니다. |
| 오리진 트라이얼 타임라인 | 호스트 이름 제한 요구사항 삭제에 따라 OT 확장 | Google에서는 생태계의 의견을 반영하여 오리진 트라이얼 기한을 연장했습니다. |
| Chrome의 테스트 제한사항 | Chrome의 현재 제한사항으로 인해 Firefox에서 CHIPS를 테스트할 수 있습니다. | Firefox의 구현은 거의 다르고 Chrome의 쿠키 제한이 더 낮으며 CHIPS는 선택 메커니즘이지만 Firefox는 기본적으로 파티션이 나눠집니다. |
| (2분기에도 보고됨)
인증된 삽입 |
CHIPS로 로그온 상태가 보존되나요? | 3분기 업데이트:
로그인한 상태는 현재 유지되지 않지만 CHIPS의 의도된 사용 사례는 아닙니다. Google은 인증된 삽입 사용 사례를 알고 있으며 솔루션을 모색하기 위해 노력하고 있습니다. |
FedCM
| 의견 테마 | 요약 | Chrome 응답 |
| (2분기에도 보고됨)
잠재적 공격 벡터 |
링크 장식 및 타이밍 공격을 통한 잠재적 공격 벡터 | 3분기 업데이트:
Google은 타이밍 공격 문제를 해결하는 방법에 대한 공통된 이해를 위해 Mozilla와 협력해 왔습니다. 자세한 내용은 여기에서 확인하세요. Google은 현재 이 아키텍처 변경사항의 프로토타입을 제작하고 있으며 앞으로 몇 분기에 걸쳐 실험을 진행할 예정입니다. |
| ID 공급업체 | 계정 선택기: 단일 ID 공급업체 여러 ID 공급업체 허용 요청입니다. | Google은 여러 ID 공급업체를 허용하는 방법을 찾기 위해 브라우저 공급업체 및 FedID CG와 협력해 왔으며 시도해 볼 만한 공식을 찾았습니다. 제안서에 대한 설명은 여기에서 확인할 수 있으며 앞으로 몇 분기 내에 프로토타입을 개발하고 실험을 진행할 예정입니다. |
| 제휴 관련 알려진 문제 | 서드 파티 쿠키 지원 중단으로 인해 제휴에서 문제가 발생할 수 있는 사례를 열거하기 위한 요청입니다. | FedID CG에는 여기와 여기에서 페더레이션이 중단되는 방식을 나열하는 작업 항목이 있습니다. 또한 여기에서 장애를 Web Platform API에 매핑하는 의사 결정 매트릭스를 구축하고 있습니다. |
| nonce 매개변수 | Nounce 매개변수가 로그인 흐름에 영향을 미칠 수 있나요? | 이는 크로스 사이트 추적으로 간주될 수 있지만 아직 의견을 수집하고 이러한 사례를 처리하는 방법을 분석 중입니다. |
| 사용자 동의 | 각 출처에 대해 서로 다른 신뢰 당사자 (RP) 및 사용자 동의 연결 | 이 사양은 동일한 도메인 내의 출처가 쿠키를 공유하는 방식을 제어할 수 없습니다. 사양은 IDP 출처에서 RP 출처로의 idtoken을 허용하지만 사용자의 로그인 상태를 해당 단일 출처로 잠긴 쿠키에 저장해야 하는지 또는 동일한 도메인 내의 출처와 공유된 쿠키에 저장해야 하는지는 RP가 선택합니다. |
| IDP 계정
이동성 |
IDP가 두 IDP 간에 이전할 때 원하는 경우 IDP를 이전할 수 있는 사용자 옵션입니다. | 이는 사용자가 FedCM API를 통해서가 아니라 선택한 새로운 IDP의 가입 페이지에서 직접 해야 하는 작업인 것 같습니다. |
| 계정 삭제 | IDP를 통한 계정 삭제에 대한 IDP 해지 계정. | 이 기능 요청은 현재 입력 및 조사 중입니다. |
| UI 소유권 주장 | 브라우저별 인터페이스 측면에 관한 주장 | 이 문제를 해결하려면 pull 요청을 참조하세요. |
| IDP 추천 확인 | IDP가 RP의 리퍼러를 확인합니다. | 사양에 필수 IDP 리퍼러 확인을 추가했습니다. pull 요청을 참조하세요. |
| 로그인 흐름 | RP 환경설정에 따라 로그인 흐름의 맞춤설정 요청입니다. | Google은 이 아이디어를 환영하며 적극적으로 논의하고 있습니다. |
스팸 및 사기 퇴치
Trust Tokens API
| 의견 테마 | 요약 | Chrome 응답 |
| 사기 및 악용 | 봇이 발급기관을 속여 토큰을 제공하도록 유도하지 않았는지, 봇이 실제 사용자에게 발급된 토큰을 탈취하지 않았는지, 봇이 악의적인 토큰을 발급하지 못하도록 하는 도구는 무엇인가요? | 봇이 발급기관으로부터 토큰을 받을 수도 있지만, 악의적인 행위자가 이러한 토큰을 우회하려고 시도하므로 발급기관이 토큰 발급 빈도와 토큰을 발급하고 발급 로직을 업데이트하는 강력한 방법을 제한하는 것이 좋습니다. 토큰 발급에 있어 견고한 로직이 없는 발급기관은 생태계에서 더 견고한 발급기관에 따라 웹사이트의 우선순위가 떨어질 수 있습니다. |
| 사기 및 악용 | 신뢰 토큰 사용자가 특정 법인의 신뢰 토큰만 수락하도록 지정할 수 있는 방법이 있나요? | 예, 가능합니다. 설명의 신뢰 토큰 사용 섹션에서 작동 방식을 설명합니다. |
| 사기 및 악용 | 신뢰 토큰 발급기관에서 사용자 목록을 정의하고 다른 사람은 토큰을 사용하지 못하도록 할 수 있는 방법이 있나요? | 현재는 없지만 팀에서 이 사용 사례를 조사하고 있습니다. |
| 타임라인 | Trust Token API는 언제 정식 버전으로 제공되나요? | 구체적인 일정이 확정되는 대로 추가 정보를 공개할 예정입니다. |
| (2분기에도 보고됨)
유지보수 오버헤드 |
프로토콜 버전이 얼마나 오래 지원되는지 명확하지 않습니다. | 3분기 업데이트:
버전 간의 원활한 전환을 위해 API에서 여러 개의 동시 버전을 지원하는 추가 지원이 추가되고 있지만 지원 / 지원 중단 기간은 아직 정해져 있습니다. |