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