개인 정보 보호 샌드박스 제안 및 Chrome의 응답에 관해 받은 생태계의 의견을 요약한 2022년 2분기 분기별 보고서입니다.
CMA에 대한 약속의 일환으로 Google은 개인 정보 보호 샌드박스 제안과 관련된 이해관계자 참여 프로세스에 관한 분기별 보고서를 공개적으로 제공하는 데 동의했습니다 (약정의 문단 12 및 17(c)(ii) 참고). 개인 정보 보호 샌드박스 의견 요약 보고서는 GitHub 문제, privacysandbox.com에서 제공되는 의견 양식, 업계 이해관계자와의 회의, 웹 표준 포럼을 포함하되 이에 국한되지 않는 의견 개요에 나열된 다양한 출처에서 Chrome이 받은 의견을 집계하여 생성됩니다. Chrome은 생태계의 의견을 환영하며 설계 결정에 반영할 방법을 적극적으로 모색하고 있습니다.
의견 테마는 API별 보급률에 따라 순위가 매겨집니다. 이렇게 하려면 특정 테마와 관련하여 Chrome팀이 받은 피드백의 양을 집계하고 양에 따라 내림차순으로 정렬합니다. 일반적인 의견 주제는 공개 회의(W3C, PatCG, IETF), 직접적인 의견, GitHub 및 Google의 내부 팀과 공개 양식을 통해 표시되는 자주 묻는 질문(FAQ)의 토론 주제를 검토하여 파악했습니다.
구체적으로는 웹 표준 기구 회의를 위한 회의록을 검토했으며, 직접적인 의견을 위해 Google의 1:1 이해관계자 회의 기록, 개별 엔지니어가 받은 이메일, API 메일링 리스트, 공개 의견 양식을 고려했습니다. 그런 다음 Google은 이러한 다양한 봉사 활동에 관여한 팀 간에 조율하여 각 API와 관련하여 나타나는 주제의 상대적 보편성을 판단했습니다.
의견에 대한 Chrome의 응답에 관한 설명은 게시된 FAQ, 이해관계자가 제기한 문제에 대한 실제 응답, 이 공개 보고 활동의 목적을 위한 입장을 파악하여 개발되었습니다. 현재 주력하고 있는 개발 및 테스트와 관련하여 Topics, 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 응답 |
| 더욱 명확한 타임라인 | 개인 정보 보호 샌드박스 기술의 보다 명확하고 자세한 출시 일정 | Google은 privacysandbox.com에 배포 일정에 관한 현재 계획을 제시하고 매달 업데이트합니다. 여기에는 Chrome과 웹 개발자 모두를 위한 개발 시간과 새로운 기술을 테스트하고 채택하는 데 필요한 시간과 관련해 더 광범위한 생태계로부터 받은 피드백이 고려됩니다. 각 기술은 테스트부터 출시 (출시)까지 여러 단계를 거치며 각 단계의 타이밍은 이전 단계에서 학습한 내용을 바탕으로 결정됩니다. 현재 확정된 출시는 없지만, privacysandbox.com에서 공개 일정을 업데이트할 예정입니다. |
| 다양한 유형의 이해관계자를 위한 유용성 | 개인 정보 보호 샌드박스 기술이 대규모 개발자를 선호하며 틈새 (작은) 사이트가 일반 (대형) 사이트보다 더 많은 기여를 한다는 우려가 있습니다. | 일부 개발자가 개인 정보 보호 샌드박스 기술의 영향에 대해 우려하고 있다는 점을 잘 알고 있습니다. Google은 Google 자체 비즈니스를 선호하여 경쟁을 왜곡하는 방식으로 개인 정보 보호 샌드박스 제안서를 설계하거나 구현하지 않으며, 디지털 광고와 게시자 및 광고주에 대한 경쟁에 미치는 영향, 개인 정보 보호 결과 및 사용자 경험에 미치는 영향을 고려하기 위해 CMA에 최선을 다했습니다. Google은 이러한 약속을 준수하기 위해 CMA와 계속해서 긴밀히 협력하고 있습니다.
개인 정보 보호 샌드박스 테스트가 진행됨에 따라 평가할 주요 질문 중 하나는 다양한 유형의 이해관계자에게 새로운 기술이 어떤 성능을 발휘하는지입니다. 의견은 이러한 점에서 매우 중요하며, 특히 기술 설계를 더욱 개선하는 데 도움이 될 수 있는 구체적이고 실행 가능한 의견입니다. |
| 서드 파티 쿠키 지원 중단 일정 | 서드 파티 쿠키 지원 중단에 대한 추가 지연을 방지하기 위한 요청 | 일부 이해관계자들은 Chrome이 지체 없이 서드 파티 쿠키 지원 중단을 진행하기를 바라고 있으며, 개인 정보 보호 샌드박스 기술을 테스트하고 채택하는 데 더 많은 시간이 필요하다고 생각하는 이해관계자들도 있었습니다. Google은 이러한 기술의 복잡성과 문제 해결 생태계의 중요성을 감안하여 책임감 있게 기술을 발전시키기 위해 최선을 다하고 있습니다. 이 프로세스에는 업계 및 규제 기관의 의견이 매우 중요했습니다. |
| 서드 파티 쿠키 지원 중단 일정 | 서드 파티 쿠키 지원 중단을 연기하고 API를 테스트할 시간을 더 많이 제공해 달라는 요청 | 일부 이해관계자들은 Chrome이 지체 없이 서드 파티 쿠키 지원 중단을 진행하기를 바라고 있으며, 개인 정보 보호 샌드박스 기술을 테스트하고 채택하는 데 더 많은 시간이 필요하다고 생각하는 이해관계자들도 있었습니다. Google은 이러한 기술의 복잡성과 문제 해결 생태계의 중요성을 감안하여 책임감 있게 기술을 발전시키기 위해 최선을 다하고 있습니다. 이 프로세스에는 업계 및 규제 기관의 의견이 매우 중요했습니다. |
| 문서 요청 | 테스트, 분석, 구현 관리 방법이 자세히 설명된 추가 리소스 요청입니다. | 개발자들이 현재의 자료를 유용하게 활용할 수 있도록 도와드리고 있으며, 앞으로 몇 주에서 몇 개월에 걸쳐 개발자 업무 시간 및 기술 문서를 비롯한 더 많은 자료를 제공하여 개발자들이 새로운 기술이 어떻게 도움이 될 수 있는지 지속적으로 이해할 수 있도록 최선을 다하겠습니다.
또한 공개 외부 개발자 Office Hours 세션을 개최하여 권장사항 및 데모를 공유하고 제품 및 엔지니어링 책임자들과 Q&A 세션을 공유하며 실시간 토론/질문을 진행하기도 했습니다. |
| 업계 전문 지식 | 표준 기관과 협력하는 Chrome팀은 개인 정보 보호와 유용성의 적절한 균형을 유지하는 데 필요한 광고 생태계에 관한 전문성이 부족합니다. | Google에 막중한 책임감을 느끼고 있으며 이를 위해서는 구체적인 의견이 필요합니다. 또한 Google은 개인 정보 보호와 효과 모두를 중요하고 필요한 설계 기준으로 간주합니다. 웹용 개인 정보 보호 샌드박스를 연구하는 팀 전체가 광고 생태계에서 일한 총 기간은 수백 년에 달합니다. |
관련성 높은 콘텐츠 및 광고 표시
주제
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 다양한 유형의 이해관계자를 위한 유용성 | 사이트의 트래픽 수준이나 콘텐츠의 전문성에 따라 사이트에서 창출되는 가치와 그 가치의 분포에 대한 우려가 제기되었습니다. | API의 유용성은 테스트를 통해 살펴봅니다. Chrome에서는 테스트 결과에 따라 분류 및 기타 매개변수가 변경될 것으로 예상합니다. 분류 또는 매개변수의 발전에 이전 버전과 호환되지 않는 변경사항이 필요하지 않을 수도 있습니다. 또한 서드 파티 쿠키 지원 중단 후에도 Chrome은 의견이 Topics API 발전에 계속해서 영향을 미칠 것으로 기대합니다. |
| 분류 | 업계 이해관계자는 분류에 영향을 미치는 데 있어 의견을 제시하고자 합니다. | Chrome은 분류에 대한 입력에 계속 열려 있습니다. Chrome은 분류 수정을 위한 거버넌스 모델에 대한 의견과 장기적으로 분류 체계를 개발하고 유지하는 데 다른 산업 단체가 어떻게 보다 적극적인 역할을 할 수 있는지에 대한 논의에 관심이 많습니다. |
| 방문 기록이 충분하지 않음 | 사용자의 방문 기록이 충분하지 않아 최근 한 주간의 주제 5개를 생성할 수 없는 경우 발신자가 지난 몇 주 동안 본 주제를 표시하기 위한 제안 | 현재 설계에서는 무작위로 선택됩니다. 이전 주제와의 상관관계를 조사하고 이를 통합할 가능성이 있는지 여부를 알아볼 예정이지만, 이러한 상관관계로 인해 개인 정보 보호에 관한 불리한 고려사항이 발생할 수 있습니다. |
| 게시자를 대신하여 주제 호출 | 서드 파티 서비스 제공업체가 Topics를 게시자와 공유할 수 있나요? | 예. 이는 Topics가 사용되는 방식입니다. |
| 잠재적 공격 벡터 | 노이즈가 많은 주제 식별 | Chrome은 생태계 내 많은 사용자의 의견을 바탕으로 주제를 필터링하고 노이즈를 도입했습니다. 이러한 결정은 개인 정보 보호를 염두에 두고 내려진 것입니다. 그렇게 하지 않았다면 이러한 정보에 액세스할 수 없었을 정보로 액세스를 제한하고 사용자에게 그럴듯한 부인 가능성을 도입하기 위해서입니다. 이러한 결정에는 여기에 설명된 공격 벡터와 같은 단점이 있다는 점을 잘 알고 있습니다. 그러나 개인 정보 보호와 관련된 이점이 잠재적 위험보다 크다고 판단됩니다. 이 결정에 대한 공개 토론을 환영합니다. |
| 오리진 트라이얼 자격요건 | 사용자가 오리진 트라이얼 이용 요건을 충족하는지 감지할 수 있는 방법이 있나요? | 사용자가 유효한 체험판 토큰을 제공하는 웹페이지를 방문했고 사용자의 브라우저가 트라이얼이 사용 설정된 그룹에 포함되어 있더라도 브라우저 설정 또는 기타 요인으로 인해 오리진 트라이얼 기능을 사용하지 못할 수 있습니다.
따라서 항상 오리진 트라이얼 기능을 사용하기 전에 기능 감지를 사용하여 오리진 트라이얼 기능을 사용할 수 있는지 확인해야 합니다. |
| 성능에 미치는 영향 | Topics 관련 오버헤드 및 지연 시간 문제 | Google에서는 비용이 많이 들고 느린 x-origin iframe을 방지하는 접근 방식과 주제를 가져오더라도 탐색 상태가 변경되지 않도록 제안이 Topics API를 풀기 위한 의견을 요청하고 있습니다. |
| Split Topics API 기능 | API의 세 가지 측면에 대해 더 많은 제어 기능 제공 | Google은 사용 사례를 잘 알고 있으며 GitHub 내에서 이를 해결할 수 있는 방법을 제안했습니다. 현재 해당 기능의 빌드 여부에 대한 생태계의 추가 의견을 기다리고 있습니다. 진행 중인 토론은 여기에서 확인하세요. |
| 분류 기준 타임라인 및 문서 | 개발자가 분류 기준에 관한 추가 정보를 요청했습니다. | 여기에서 분류 기준에 관한 자세한 정보를 공개했습니다.
여기에서 확인할 수 있습니다. |
| 사용자 제어 및 안전 | 특정 주제는 민감한 집단의 프록시일 수 있으며 사용자는 부정적인 결과를 방지하기 위해 더 많은 제어 기능을 필요로 합니다. | 주제는 사용자 제어 및 투명성을 위한 중요한 진전을 나타냅니다. 사용자는 주제를 선택 해제하고, 자신에게 할당된 주제를 검토하고, 주제를 삭제하고, 특정 페이지에서 주제와 상호작용하는 회사를 파악할 수 있습니다. 또한 사용자는 방문 기록을 삭제하여 Topics에 영향을 미칠 수도 있습니다. Google은 개발자가 제안하는 고급 사용자 제어와 같은 고급 사용자 제어 기능에 관해 계속 논의하는 것을 환영하지만, 이 버그에서 제기된 우려사항에 관해서는 실제로 위험이 제거되도록 해야 합니다. 예를 들어, 탐색 기록에서 주제를 생성한 웹사이트가 사용자를 완전히 보호하지 않는 등의 방식으로 '외국어 연구'를 삭제하는 것만으로는 사용자를 완전히 보호할 수 없습니다. |
| prebid.js가 포함된 사이트에서 주제 사용하기 | prebid.js가 포함된 웹사이트에서 Topics API를 사용할 수 있나요? | 간단히 말하면 '예'입니다. 자세한 내용은 여기에 게시되어 있습니다. |
| 추천 위젯에서 Topics API 사용 | 추천 위젯 (예: Outbrain)에서 Topics API를 사용할 수 있나요? | Google에서는 API가 호출된 후 검색된 Topics의 사용 사례를 제한하지 않습니다 (각 개발자의 데이터 정책에 따라 달라짐). |
| 개인 정보 보호 / 정책 | 일부 제3자가 전화를 건 사람과 주제를 공유하는 경우 발신자별로 응답을 필터링하는 목적과 관련된 질문 | Chrome은 생태계에 있는 많은 사용자의 의견을 바탕으로 이러한 정보에 액세스할 수 없었을 사람들로 정보 액세스를 제한하기 위해 이러한 설계를 선택했습니다. 물론 Topics를 받는 게시자와 서드 파티는 사이트에서 당사자와 어떤 정보를 공유할지 직접 결정할 수 있습니다. 이러한 방식으로 공유하는 경우 Chrome은 사용자에게 공유에 대해 투명하게 알리고 제어 기능을 제공할 것을 적극 권장합니다. |
| 노이즈 신호 | 임의의 5% 확률로 무작위 주제를 전송하면 과도한 노이즈 / 거짓 신호가 생성될 수 있습니다. | 노이즈는 사용자 개인 정보를 보호하는 중요한 방법이며, 테스트를 통해 주제의 노이즈 수준과 유용성을 살펴봅니다. |
FLEDGE
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 조정 테스트 | 성능 및 수익 효과 테스트 | FLEDGE 성능 및 오리진 트라이얼과 정식 버전 기간에 Google이 생태계 테스트를 가장 잘 지원할 수 있는 방법은 공개 WICG 회의에서 적극적으로 논의되고 있습니다. |
| FLEDGE용 신뢰할 수 있는 서버 | 신뢰할 수 있는 서버는 언제 테스트할 수 있나요? | Google은 이러한 의견을 소중히 여기며, FLEDGE에서 신뢰할 수 있는 서버를 사용하기 위해 공유할 수 있는 보다 자세한 계획을 위해 적극적으로 노력하고 있습니다. |
| 프로토콜 표준화 | SSP와 DSP 간에 데이터를 전달하기 위한 공통 프로토콜(예: 관심분야 그룹의 공통 라벨)이 있나요? | Google은 사양의 잠재적 표준화에 대한 DSP, SSP 및 광범위한 광고 생태계의 의견을 환영합니다. 현재 초기 테스트를 위해서는 다양한 접근 방식을 실험하는 테스트 파트너와 직접 협력하는 것이 좋습니다. 또한 Google은 광고 거래 조직이 회원사에 도움이 될 수 있도록 표준화를 만드는 데 개입하도록 권장하고 있으며 앞으로도 계속 협력할 예정입니다. |
| 최대 게재빈도 설정 | 캠페인 및 광고그룹 내에서 사용자당 게재빈도를 관리합니다. | FLEDGE는 기기 내 입찰과 문맥 / 브랜딩 캠페인의 최대 게재빈도 설정도 지원합니다. 또한 공유 스토리지 및 사이트별 한도를 사용하여 최대 게재빈도 설정을 추가로 관리할 수 있습니다. |
| FLEDGE가 성능에 미치는 영향 | FLEDGE 입찰에서 계산 집약적인 입찰자 | Chrome은 사이트 성능에 미칠 수 있는 영향에 관해 개발자와 활발하게 논의 중입니다. Chrome은 테스트 중에 더 많은 것을 배울 수 있는 기회를 환영합니다. |
| 다른 기능으로 FLEDGE 테스트 | Attribution Reporting API와 FLEDGE의 이벤트 수준 보고서는 어떻게 연동되나요? | 이 내용은 최근 WICG/conversion-measurement-api 호출에서 논의되었으며 여기에서 자세한 내용을 확인할 수 있는 링크가 제공됩니다.
분리 프레임 광고 보고의 현재 설계에 따라 분리 프레임 내에서 생성된 ID를 문맥 정보와 연결할 수 있습니다. 따라서 분리 프레임 내에서 생성된 이벤트 수준 보고서는 서버에서 동일한 문맥 정보에 조인할 수 있습니다 (1개가 아닌 2개의 서버 측 조인 사용). |
| 노출수 계산 | 구매자와 판매자 간에 사용되거나 사용할 수 있는 노출수 계산 방법 | FLEDGE API는 이미 입찰 중에 판매자와 구매자 간의 방법에 대한 조정을 지원합니다. 현재 설계가 해당 생태계에 적합하지 않은 이유에 관한 의견 없이 대체 구현에 관한 제안을 받았습니다. |
| 여러 광고 게재하기 | 특정 분리 프레임에서 한 번의 입찰에 여러 광고를 게재할 수 있는지 여부 | 이는 현재 구성요소 광고를 통해 가능합니다 (구성요소 입찰과 혼동해서는 안 됨). 이렇게 하려면 모든 광고가 동일한 관심분야 그룹에 있어야 합니다. |
| '판매자 정의 잠재고객 (SDA)' 사양 및 FLEDGE | FLEDGE는 구매자가 광고 요청 시 SDA의 프로필을 작성하지 못하게 하는 메커니즘이 될 수 있나요? | FLEDGE는 게시자가 이미 방문자의 SDA를 알고 있고 동일한 사이트를 타겟팅하는 경우 관련성이 없는 정보 유출을 방지하도록 설계되었습니다. FLEDGE에 내장된 모든 보호 조치 내에서 SDA에서 구매를 지원하는 것이 중요한 경우, 한 가지 해결책은 SDA 라벨을 기기 내 입찰에 전달하고 구매 측 광고 기술에서 입찰 로직이 '잠재고객 X를 구매하고 싶어요'라는 자체 관심분야 그룹을 만드는 것일 수 있습니다. |
| 미국 달러 외 통화 지원 | 미국 달러 이외의 통화로 FLEDGE 테스트 지원 | Google은 이러한 콜아웃에 감사 드리며, 기능 요청의 백로그에 다른 통화도 지원할 수 있도록 지원을 추가했습니다. 이 기능이 빠른 시일 내에 제공되기를 바랍니다. |
| 제외 관심분야 그룹 타겟팅 지원 | 제외 IG 타겟팅을 지원하는 API: 사용자가 IG에 속하지 않는 경우에만 광고를 표시합니다. | github 문제에서 지원하기 위한 몇 가지 제안된 옵션을 비롯하여 진행 중인 토론입니다. |
| FLEDGE의 여러 SSP | FLEDGE에서 다단계 입찰을 구현할 때 Google을 우대할 위험 | 공정하고 공평한 경쟁의 장을 마련하기 위해 FLEDGE에 여러 SSP에 대한 지원을 추가했습니다. Google은 광고 제품 및 서비스를 자체 추천하여 경쟁을 왜곡하는 방식으로 개인 정보 보호 샌드박스 제안서를 설계, 개발 또는 구현하지 않겠다고 약속했습니다. Google은 이를 중요하게 생각하며 기술의 특정 측면에 대해 이해 관계자가 가질 수 있는 우려사항에 대해 자유롭게 토론할 수 있습니다. Chrome의 구성요소 입찰 메커니즘은 여기에 공개되어 있으니 참고하세요. |
디지털 광고 측정
Attribution Reporting (및 기타 API)
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 멀티 터치 기여 분석 | 멀티 터치 기여 분석에 대한 지원을 요청하는 게시자 | 현재의 멀티 터치 기여 분석 방식은 여러 웹사이트에서 발생하는 사용자 노출 (및 ID)을 확정적으로 연결해야 합니다. 따라서 현재 형식의 이 기능은 크로스 사이트 추적 없이 주요 광고 사용 사례를 지원하는 것을 목표로 하는 개인 정보 보호 샌드박스의 목표에 부합하지 않습니다. 경우에 따라서는 개별 사용자를 추적하지 않고도 크레딧 할당의 근사치를 얻을 수 있습니다 (예: 가중치가 적용된 무작위 우선순위를 사용). |
| 노이즈 생성 | 보고서 내 노이즈 수준에 관한 질문 | 초기 실험을 통해 개발자는 자체적으로 epsilon 값을 설정하여 노이즈 수준에 따라 보고서가 어떻게 변경되는지 경험할 수 있습니다. 현재 개발자는 epsilon 값을 epsilon=64까지 선택할 수 있습니다. 이는 특히 개발자가 더 쉽게 API를 테스트하고 적절한 epsilon 값에 관한 피드백을 제공할 수 있도록 하기 위한 것입니다.
이러한 의견에 대한 공개 요청도 YouTube에서 진행했습니다. |
| 조정 테스트 | 로컬 테스트 도구를 OT에 사용할 수 있나요? | 예. OT 기간 동안 로컬 테스트 도구를 사용할 수 있습니다. 서드 파티 쿠키를 사용할 수 있는 경우 로컬 테스트 도구를 디버그 보고서와 함께 사용할 수 있습니다. |
| 쿼리 에르고노믹스 | 키 집계 쿼리 사용 설정 | Google은 이를 통해 명백한 개인 정보 보호 비용이 거의 또는 전혀 없이 API 인체공학을 개선할 것으로 보인다는 데 동의합니다. Google은 제안서를 만들어 이를 지원할 가치가 있다는 광범위한 합의가 있는지 살펴볼 예정입니다. |
| 소규모 사이트의 경우 데이터 정확도가 떨어짐 | 사이트 또는 캠페인의 규모가 작을수록 수신 데이터의 정확도가 떨어질 수 있습니다. | Chrome은 노이즈 기반 개인 정보 보호 기능이 작은 데이터 슬라이스에 더 큰 영향을 미친다는 사실을 인식합니다. 그러나 장기간에 걸쳐 집계하는 것과 같은 방법으로 이 문제를 해결할 수 있습니다. 또한 매우 작은 데이터 슬라이스 (예: 한두 개의 구매)에 기반한 결론이 광고주에게 의미가 있는지도 불분명합니다. 오리진 트라이얼 동안 Chrome은 테스터가 이 문제에 관한 보다 구체적인 의견을 제공할 수 있도록 다양한 개인 정보 보호 및 노이즈 매개변수를 실험하는 기능을 활용할 것을 권장합니다. |
비밀 추적 제한
사용자 에이전트 축소
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 봇 보호 | UA-R이 봇 보호에 미치는 영향 | 의견을 보내주셔서 감사합니다. 향후 설계에 반영하기 위해 봇 보호 접근 방식에 관한 정보를 수집하고 있습니다. |
| 배포 종속 항목 | 구조화된 사용자 에이전트 (SUA) 배포 종속 항목 해결 | Google은 버전 101 이상에서 모든 Chrome 사용자를 대상으로 마이너 버전 축소라고도 하는 '4단계'를 출시했습니다. 여기에서 업데이트를 확인하세요. |
사용자 에이전트 클라이언트 힌트
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 지원되는 모든 힌트 열거 | 브라우저에서 지원되는 모든 힌트를 알 수 있는 프로그래매틱 방식을 원하는 경우 | 의견을 보내주셔서 감사합니다. 현재 기능 요청을 평가하는 중입니다. 이것이 일반적인 사용 사례인지 파악하고자 합니다. |
| UA-CH와 User-Agent 헤더의 유연성 | UA-CH는 rfc7231에 정의된 대로 사용자 에이전트 헤더가 제공하는 유연성에 비해 지나치게 규범적입니다. | Chrome은 UA-CH 헤더의 처방적 특성이 최종적인 브라우저 간 상호 운용성과 사용자 개인 정보 보호 기능 (높은 엔트로피 식별자의 임의 추가 방지)이라는 측면에서 UA 문자열의 유연성에 대한 중요한 개선이라고 생각합니다.
다른 사용자도 같은 문제를 공유하고 의견을 제공하고자 하는 경우 이 문제는 미해결 상태로 유지됩니다. |
| UA-CH: 사기 / 악용 방지 우려사항 | UA-CH를 통해 손실될 수 있는 특정 기능: 클릭 리디렉션 추적기 및 허위 클릭 | 팀에서는 사기 방지 및 측정 이해관계자와 함께 이러한 잠재적 문제를 조사하고 있습니다. |
| 성능 | (첫 페이지 로드 시) Critical-CH를 통한 힌트 제공 지연에 대한 우려가 있습니다. | Chrome에서 성능 개선 방법을 모색하고 있습니다. |
Gnatcatcher (작업 진행 중)
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 지연 시간 문제 | 추가 홉을 추가하면 지연 시간에 영향을 줄 수 있음 | Google은 투 홉 프록시를 고려하고 있으며 사용자 개인 정보 보호와 지연 시간 사이에서 적절한 균형을 찾을 방법을 모색하고 있습니다. Google은 피드백을 환영합니다. W3C 포럼에서 자세한 논의를 하고 싶습니다. |
| 사기 및 봇 보호 | 선진국을 비롯한 여러 국가에서 사기 및 봇 보호에 미치는 영향 | Google은 IP 주소 프록시와 같이 의미 있는 방식으로 사용자 개인 정보 보호를 개선할 방법을 모색할 때 안전이 핵심 요구사항입니다. 공신력 있는 회사와 파트너 관계를 맺은 2홉 프록시는 검증 가능한 사용자 개인 정보 보호를 제공합니다. 또한 사용자 신뢰를 전달하는 데 도움이 되는 새로운 신호에 관한 아이디어도 개발하고 있습니다. |
| 현지 개인 정보 보호법 준수 | 국가 수준의 지역 데이터 보고로 인해 보다 세분화된 현지 제도를 준수하기가 어렵습니다. | Google은 제안된 원칙을 공개적으로 게시했습니다. 여기에는 웹사이트가 현지 요구사항을 계속 준수하도록 하기 위한 잠재적 접근 방식이 포함되어 있습니다. |
크로스 사이트 개인 정보 보호 경계 강화
퍼스트 파티 세트
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 다양한 유형의 이해관계자를 위한 유용성 | 소규모 게시자와 대규모 게시자에게 FPS가 미치는 영향 | 개인 정보 보호 샌드박스의 주요 목표는 현재 관행을 크로스 사이트 추적 메커니즘을 사용하지 않는 솔루션으로 대체하여 사용자 개인 정보 보호를 개선하는 것입니다. Google은 이러한 솔루션이 다양한 유형과 규모의 이해관계자에게 최대한 광범위하게 제공되기를 바랍니다. Google은 이러한 솔루션을 개선할 수 있는 방법에 대해 구체적이고 실행 가능한 의견을 기다리고 있으며, 커뮤니티 토론 및 테스트를 통해 지속적으로 발전할 것으로 예상됩니다. |
| 개인 정보 보호 개선 | 동일한 세트에 사이트가 너무 많으면 서드 파티 쿠키와 유사한 결과가 발생할 수 있습니다. | Google은 이러한 의견을 소중히 여기고 어떤 제한이 적절한지 또는 어느 정도로 타당한지 평가하고 있으며, 사용자와 개발자 모두에게 제한에 도달했을 때 알 수 있는 처리나 신호를 제공하기 위해 노력하고 있습니다. 아직 공유할 구체적인 제안서는 없지만 조만간 제공할 수 있기를 바랍니다. |
| FPS 생태계 지원 | 개인 정보 보호 CG 이외의 FPS 개발을 위한 지원 및 우려사항 수집 | Google은 퍼스트 파티 세트 제안을 PrivacyCG에 유지하기를 바라지만, Google은 계속해서 WICG에서 제안을 추진할 수 있기를 기대합니다. 또한 퍼스트 파티 세트와 퍼스트 파티 세트에서 다루려는 사용 사례에 관한 지속적인 논의를 위해 여러 지지 의사를 표명해 주었습니다. Google은 사용자의 개인 정보를 보호하고 존중하는 방식으로 웹이 지속적으로 성장하고 발전할 수 있는 솔루션을 찾기 위해 최선을 다하고 있습니다. |
| 브라우저 상호 운용성 | 다른 브라우저에서 구현 | Google은 개발자 여러분에게 브라우저 상호 운용성의 중요성을 잘 알고 있으며, FPS 표준화를 추구하기 위해 다른 브라우저와 계속해서 협력할 것입니다. |
| 일반적인 개인정보처리방침 요구사항 | 모든 제품, 그리고 동일한 집합에 속해야 하는 관할권에서 공통의 개인정보처리방침을 유지하는 것은 불가능합니다. | Chrome은 아직 정책 요구사항을 정의하는 중이며, 이 의견을 염두에 두겠습니다. |
Fenced Frames API
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 문서 요청 | 샌드박스 처리된 iframe과의 차이점 | 의견과 제안을 보내 주셔서 감사합니다. GitHub에서 이에 대한 논의가 진행되고 있으며, 요청을 최종적으로 확정하고 완벽하게 평가할 수 있기를 바랍니다. 공개 토론은 여기에서 확인할 수 있습니다. |
| 교차 API 기능 | 분리 프레임의 기여도 보고 기본 지원 | Attribution Reporting API가 분리 프레임의 '불투명 광고 모드'에서 기본적으로 사용할 수 있도록 제안에 대한 의견을 요청합니다. 이에 대해 유익하다고 생각할 만한 개발자는 이러한 논의에 참여하도록 권장드립니다. |
Shared Storage API
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 데이터 한도 | 파티션당 저장할 수 있는 데이터 양에 제한이 있나요? | 예, 한도가 있습니다. 자세한 내용은 github 문제를 참고하세요. 스토리지 할당량이 필요합니다. 현재 제안은 항목당 크기 한도가 4KB이고, 키와 값은 각각 1,024자16_t자로 제한되며, 출처당 항목별 한도는 원본의 용량이 가득 찼을 때 추가 항목이 커밋되지 않도록 하는 메커니즘을 통해 10,000개 항목으로 제한됩니다. Google은 여기에 제안된 구체적인 한도에 대한 의견을 적극적으로 받고 있습니다. |
| 사용자 투명성 | 데이터 소스와 데이터 사용량에 대한 사용자 투명성 | Google은 이러한 의견을 소중하게 여기며, 시도해 볼 만한 유망한 접근방식이라고 생각합니다. 특히 사용자에게 충분한 투명성을 제공하는 방식으로 이 작업을 실행할 수 있는지 평가하고 있습니다. |
칩
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 채택 방해 요소 | CHIPS에 호스트 이름 바인딩이 필요한가요? (도메인 없음 요구사항) | 이 요구사항이 더 복잡해지고 CHIPS 채택을 방해하는 역할을 한다는 OT 참가자의 의견을 바탕으로 OT에서 이 요구사항을 삭제할 예정입니다.
표준 도입의 일환으로 여기에서 개인 정보 보호 커뮤니티 그룹에서 이 요구사항을 논의할 예정입니다. |
| CHIPS의 광고 사용 사례 | 단일 사이트에서 Google Ads 사용 사례에 CHIPS를 사용할 수 있나요? | 한 사이트 내에서 사용자를 추적하는 것은 허용되는 사용 사례입니다. 이러한 사용 사례를 강조하기 위해 개발자 도움말을 업데이트했습니다. |
| 인증된 삽입 | CHIPS로 로그온 상태가 보존되나요? | 로그인한 상태는 현재 유지되지 않지만 CHIPS의 의도된 사용 사례는 아닙니다. Google은 인증된 삽입 사용 사례를 알고 있으며 솔루션을 모색하기 위해 노력하고 있습니다. |
| 조정 테스트 | 파티션 나누기를 테스트하는 데 필요한 추가 사용자 작업이 있나요? | OT 토큰이 유효하고 방문한 페이지의 헤더에 있는 경우 사용자의 추가 작업 없이 기능을 사용할 수 있어야 합니다. |
| 브라우저 호환성 | 다른 브라우저에서 파티션을 나눈 쿠키 속성을 어떻게 처리했는지 알아보려는 경우 | Chrome은 여러 브라우저에서 작동하는 디자인 및 구현을 파악하기 위해 W3C와 같은 공개 표준 그룹 내에서 계속 노력하고 있습니다. |
FedCM
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 잠재적 공격 벡터 | 링크 장식 및 타이밍 공격을 통한 잠재적 공격 벡터 | Google에서는 대중의 의견을 적극적으로 수집하고 이 문제를 해결할 방법을 모색하고 있습니다. |
| 여러 IDP를 지원하는 UX | 한 번에 하나의 IDP만 제시할 수 있습니다. | Google은 여러 IDP를 지원하는 것이 중요하며 |
| 표현력 | 브라우저가 제휴 ID 흐름의 일부를 렌더링하기 때문에 IDP가 사용자에게 제시하고자 하는 미묘한 차이를 모두 파악하기란 어렵습니다. | Chrome은 브랜드 맞춤설정 (예: 로고, 색상) 및 문자열 맞춤설정 (예: '로그인'이 아닌 '이 도움말에 액세스')을 포함한 방안을 모색하고 있습니다.
Chrome은 이 같은 장단점을 인식하고 최대한 많은 영역을 커버하고 최대한 표현력을 높일 수 있도록 생태계와 협력할 것입니다. |
| 적용 가능성 및 상호 운용성 | 다른 브라우저에서 FedCM을 채택하거나 구현하지 않을까 우려됩니다. | 또한 Chrome은 FedID Community Group에서 제휴를 위한 공통 솔루션을 찾기 위해 다른 브라우저 공급업체와도 협력하고 있습니다. |
| 가입 절차에서 개인 정보 요구사항을 삭제하도록 제안 | (1) 사용자에게 이메일, 사진, 이름이 개인 정보를 더 안전하게 공유할 수 있다는 알림 없이 사용자가 어떤 IdP를 선택할지 알려주는 UX
(2) Use-cases-sign-up은 사용자 환경 및 IdP의 클레임 선택에 빈약합니다. |
Google은 이러한 동의에 동의하며, 사용자의 개인 정보를 보호하고 친근한 방식으로 사용자의 의견을 반영할 수 있는 방법을 모색하고 있습니다. |
| 사용자와 IdP의 상호작용 | 위험 기준을 초과하는 경우 사용자와 IdP 간의 직접적인 상호작용이 필요함 | Google에서는 이 의견에 대해 적극적으로 조사하고 있습니다. |
네트워크 상태 파티셔닝
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 성능 | 네트워크 상태를 파티셔닝하면 CDN에 대한 리소스 집약적인 연결이 증가할 수 있습니다. | Google은 다양한 가능한 키 지정 체계를 측정하는 것을 포함하여 네트워크 상태 파티셔닝의 성능 특성을 아직 조사하고 있습니다. 성능, 보안, 개인 정보 보호의 절충점 사이에서 아직 결정은 내리지 않았으며 더 많은 데이터를 수집해야 합니다. |
스팸 및 사기 퇴치
Trust Tokens API
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 규제 피드백 | 규제 기관으로부터 장기적 타당성에 대한 명확한 신호 없이 신뢰 토큰에 시간과 리소스를 투자하는 것에 대한 우려 | Google의 목표는 생태계에 적합한 기술을 개발하여 업계와 규제 당국의 의견을 수렴하는 것입니다. Google은 개인 정보 보호 샌드박스를 개발하고 신뢰 토큰을 포함한 제안을 개발자에게 제공할 때 계속해서 전 세계 규제 기관과 상의할 것입니다. 모든 신기술과 마찬가지로 기업은 자체적인 규제 요건 평가에 따라 결정을 내려야 합니다. |
| 출시 시기 | 신뢰 토큰은 언제 정식 버전으로 출시되나요? | Google에서는 privacysandbox.com에서 공개 일정에 따라 현재 예상 게재 시간을 제공하고 있습니다. 정식 버전 제공일에 대한 최종 결정이 내려지는 대로 Chrome의 출시 절차를 통해 공개적으로 게시하고 웹사이트의 일정을 업데이트하겠습니다. |
| 신뢰 토큰과 다른 토큰 | 비공개 액세스 토큰과 같이 표준화 중인 다른 토큰을 고려할 때 신뢰 토큰은 어떤 역할을 하나요? | Google은 표준화를 논의하고 있으며, 각 기술이 감당할 수 있는 다양한 사용 사례를 지원하면서 다른 노력과 최대한 연계하는 것을 목표로 삼고 있습니다. 예를 들어 신뢰 토큰과 비공개 액세스 토큰은 모두 개인 정보 보호 패스 프로토콜을 사용합니다. |
| 데이터 한도 | 페이지당 최대 2개의 발급기관 토큰 사용 가능(최대 2개) | Google은 기업이 토큰 사용에 대한 액세스 권한을 분할함으로써 더 많은 사용자 엔트로피의 위험 없이 토큰을 안전하게 사용할 수 있도록 하는 장기적인 옵션을 찾고 있습니다. |
| 액세스 제한 | 승인된 (그리고 확인된/스푸핑되지 않은 리퍼러) 출처만 토큰의 존재를 확인하고 사용할 수 있어야 합니다. | Google은 누가 토큰을 보고 사용할 수 있는지에 대한 접근 방식을 모색하고 있습니다. |
| 기기 지원 | JavaScript 런타임 종속 항목은 특정 기기에서 사용을 제한합니다. TT 지원을 다른 유형의 기기에서 작동하도록 확장할 수 있나요? | 이는 향후 개발을 위해 고려할 수 있는 사항이며, W3C 포럼에서 개발자로부터 더 많은 의견을 듣고자 합니다. HTTP 헤더로 트리거된 토큰 사용에 대해 논의하기 위한 미해결 문제도 있습니다. |
| 사용 사례 | 신뢰 토큰의 올바른 사용 사례가 명확하지 않습니다. 사용 목적이 명확하지 않습니다. | Google의 목표는 사기 방지 영역에서 혁신을 촉진하고, 각 회사가 신뢰 토큰과 함께 독점 기술을 사용할 수 있음을 이해하는 것입니다. 그렇기 때문에 Google에서는 정해진 용도를 규정하지 않았습니다. 하지만 실험 또는 도입을 고려 중인 파트너를 위한 출발점으로 더 많은 예시를 포함하도록 이 문서를 확장할 예정입니다. |
| 신뢰 토큰 범위 | 이 'trust-token-redemption' 기능 정책을 삭제하면 신뢰 토큰 적용 범위가 크게 늘어납니다. | 이는 OT의 의견을 수집하고 다음 단계를 결정할 때 고려됩니다. |
| 발급기관 신뢰 | 신뢰 토큰을 발행한 웹사이트를 신뢰해야 하는 이유는 무엇인가요? | 발급기관이 되기 위한 가이드라인은 없습니다. 누구나 할 수 있습니다. 게시자는 신뢰할 수 있는 발급기관과만 협력해야 합니다. 또한 광고 생태계의 다른 적법한 행위자가 의심스럽거나 알 수 없는 발급기관과 관련된 트래픽을 제외하거나 구매를 중지할 수도 있습니다. |
| 서드 파티 삽입 서비스 | 서드 파티 삽입 서비스에서 신뢰 토큰을 사용하거나 요청할 수 있나요? | 예. 서드 파티 삽입 서비스에서 신뢰 토큰을 발급하고 사용할 수 있습니다. |
| 발급기관 생태계 | 신뢰 신호를 다른 회사와 공유할 수 있으면 유용성을 높일 수 있습니다. | 신뢰 토큰은 낮은 수준의 기본 토큰으로 설계되었으며, 협력 발급기관/청구자가 신뢰/평판 신호를 공유하는 데 사용할 수 있습니다. |
| 유지보수 오버헤드 | 신뢰 토큰 작업의 기반이 되는 암호화 구현은 Google이 단독 유지관리하는 BoringSSL을 사용합니다. 라이브러리 유지보수는 어떻게 관리되나요? | 신뢰 토큰은 표준화된 암호화 작업 (개인 정보 보호 패스 프로토콜 참고)에 의존하며 이는 다른 라이브러리에서도 구현될 수 있습니다. 개발자는 원하는 라이브러리에서 이러한 작업 지원을 요청/개발/유지하는 것이 좋습니다. |
| 유지보수 오버헤드 | 프로토콜 버전이 얼마나 오래 지원되는지 명확하지 않습니다. | Google은 프로토콜 버전의 예상 지원 기간에 대한 구체적인 정보를 개발하고 문서화하는 방안을 모색하고 있습니다. |
| 발급기관 한도 | 체인의 후반부에 있는 경우 신뢰 토큰을 실행할 기회가 나타나지 않을 수 있습니다. | 점점 더 많은 조직이 신뢰 토큰을 사용하기 시작하면서 이러한 유형의 타이밍 역학이 점점 더 중요해지고 있으며 잠재적 솔루션을 연구하고 있습니다. 앞서 설명한 바와 같이, 우리는 회사들이 더 많은 사용자 엔트로피의 위험을 감수하지 않고 토큰을 안전하게 사용할 수 있도록 하는 장기적인 옵션을 찾고 있습니다. 이를 통해 페이지상의 위치 또는 로드 순서의 중요성이 최소화됩니다. |
인큐베이션 단계의 새로운 사기 방지 솔루션
| 의견 테마
(확진율별 순위) |
질문 및 우려사항 요약 | Chrome 응답 |
| 기기 무결성 증명 신호 | 플랫폼에서 증명되고 웹에 제공되는 기기 무결성 신호 추적에 대한 일반적으로 강력한 지원 | Google은 계속해서 의견을 수렴하고 공개 설계와 반복을 통해 제안을 추진할 예정입니다. |
| 기기 무결성 증명 신호 | 새로운 신호를 통해 얼마나 많은 사용자 엔트로피를 전달할 수 있는지, 특정 사용 사례 (예: 사용자가 은행에 로그인하는 경우)가 더 높은 엔트로피 신호를 정당화할 수 있는지에 대한 질문. | YouTube는 사용자 개인 정보 보호를 위해 최대한 적은 사용자 엔트로피로 가치가 높은 신호를 제공하는 데 주력합니다. |
| 기기 무결성 증명 신호 | 이 신호가 구형 기기 또는 오픈소스/수정된 플랫폼의 액세스를 제한하나요? | 모든 새로운 신호는 범용 액세스를 개발의 핵심 원칙으로 고려해야 합니다. 이러한 질문은 연구가 계속 진행됨에 따라 미리 해결해야 할 중요한 질문입니다. |
| 기기 무결성 증명 신호 | 새로운 신호로 인해 보안 및 사기 방지 기업이 브라우저와 플랫폼에 지나치게 의존하게 된다면 우려가 있었습니다.
|
새로운 신호는 브라우저에서 '신뢰'를 나타내는 것이 아니라 추가 데이터로 봐야 합니다. Google은 보안 기업이 기기 증명을 추가적인 입력으로 사용하여 자체 독점 데이터, 모델, 결정 엔진을 계속 활용할 것으로 기대합니다. 새로운 신호를 통해 생태계 전반의 감지 활동이 개선되고 사기가 더 어려워지기를 바랍니다. |
| 쿠키 사용 기간 신호 | 흥미로운 개념이지만 관련 사용 사례에 대한 더 많은 조사가 필요할 수 있습니다. | 관심이 있는 정도에 따라 Chrome은 이 개념에 관해 추가로 구상하여 향후 생태계 의견을 위한 설명으로 만들 수 있습니다. |
| 사기 방지를 위한 신뢰할 수 있는 서버 | 흥미로운 개념이지만 관련 사용 사례에 대한 더 많은 조사가 필요할 수 있습니다. | 관심이 있는 정도에 따라 Chrome은 이 개념에 관해 추가로 구상하여 향후 생태계 의견을 위한 설명으로 만들 수 있습니다. |