개인 정보 보호 샌드박스 제안 및 Chrome의 대응에 대해 받은 생태계 의견을 요약한 2023년 1분기 분기 보고서입니다.
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 응답 |
|---|---|---|
| 테스트 및 무료 체험 | 테스트가 시작될 때까지 개인 정보 보호 샌드박스 API가 완료되지 않은 경우 CMA의 평가에 정보를 제공하기 위한 테스트의 관련성 | 개인 정보 보호 샌드박스 API의 개발이 빠르게 진행되고 있습니다.
이 기능은 이미 Origin 무료 체험판에서 테스트용으로 제공되고 있으며 올여름에는 모든 트래픽에 정식 버전으로 제공될 예정입니다. 또한 2026년 이전에는 영향을 받지 않는 특정 기능 (예: FLEDGE 이벤트 수준 보고, iframe을 사용한 FLEDGE 렌더링)의 타임라인을 명확히 했습니다. 생태계는 API를 테스트하고 서드 파티 쿠키가 지원 중단된 후 테스터가 기대하는 기능을 기반으로 CMA에 의견을 제공하는 것이 좋습니다. 이를 통해 서드 파티 쿠키 지원 중단의 예상되는 영향을 평가하는 데 도움이 될 수 있습니다. |
| 사용자 제어 | 개인 정보 보호 샌드박스 API의 사용자 제어 관련 생태계 가이드 | Google은 사용자가 제어하는 생태계에서 사용할 수 있는 항목에 관한 법적 조언을 제공할 수 없습니다. 동시에 Chrome은 개인 정보 보호 샌드박스 기술을 개선하기 위한 지속적인 노력의 일환으로 업데이트된 개인 정보 보호 샌드박스 ('광고 개인 정보 보호 강화') 사용자 설정을 소수의 사용자에게 표시하는 실험을 진행하고 있습니다. 이번 업데이트에는 더 명확하고 유용한 표현과 레이아웃이 포함되어 있습니다. Chrome에서 이러한 개선사항을 평가하고 더 많은 사용자층으로 확대할지 결정한 후에는 생태계와 더 많은 정보를 공유할 수 있습니다. |
| 데이터 유출 | 브라우저가 손상된 경우 Google 및 기타 당사자에게 퍼스트 파티 데이터가 유출될 위험 | Google의 FLEDGE 설명에 따르면 한 광고 기술의 데이터는 동일한 광고 기술 (워크렛 또는 신뢰할 수 있는 서버)과만 공유되거나 해당 광고 기술에서 명시적으로 공유하는 경우에만 공유됩니다 (예: 구매자가 판매자에게 표시하려는 광고 URL을 보여주는 경우). 유일한 예외는 전 세계 중앙 집중식 서버에서 k-익명성 검사를 수행해야 한다는 점입니다. Google은 이 분야에 상당한 리소스를 계속 투입하고 있습니다. Google의 개인 정보 보호에 대한 자세한 내용은 K-익명성 설명을 참고하세요. 이 외에도 Google은 k-익명성 서버 설계 시 사용되는 광고 기술 보호 기능이 작동하는 방식에 관한 자세한 정보를 제공할 수 있습니다. |
| 추가 토론 포럼 | 기술 이외의 생태계 참여자가 의견을 공유할 수 있는 포럼을 W3C에 추가로 요청 | 개인 정보 보호 샌드박스 의견 양식은 기술적 의견과 비기술적 의견, 일반적인 의견과 구체적인 의견 모두에 적합합니다. 웹 광고 개선 비즈니스 그룹은 주간 통화 및 GitHub 저장소를 통한 토론을 위한 포럼입니다. 개인 정보 보호 샌드박스 의견 페이지에서는 의견을 제공하고 토론에 참여하기 위한 다른 메커니즘을 설명합니다. 또한 Chrome은 질문과 콘텐츠 공유를 용이하게 하기 위해 공개적인 상담 시간과 같은 이벤트를 계속해서 개최하고 있습니다. 또한 Chrome은 지난 분기에 12개가 넘는 업계 이벤트를 주최하거나 참석했습니다. |
| 타임라인 설명 | 2023년 3분기 정식 버전 출시의 정확한 날짜에 관한 설명 | PrivacySandbox.com에 게시된 타임라인에 따라 Chrome 버전 115 출시와 함께 정식 버전이 출시될 예정입니다. |
| reCAPTCHA | reCATPCHA의 스팸 감지 사용 사례에 대한 Sandbox API의 영향 | Google은 개인 정보 보호 샌드박스 제안이 웹 안전이나 사기에 큰 영향을 미치지 않도록 하기 위해 reCAPTCHA로부터 주기적으로 의견을 수렴합니다. 서드 파티 쿠키 지원 중단에 대비하고 조정하기 위한 자체 계획을 수립하고 있으므로 이 질문은 해당 팀에 문의하는 것이 가장 좋습니다. |
| Chrome 확장 프로그램 | 은밀한 추적 방지 (ACT) 조치와 같은 개인 정보 보호 샌드박스 기술이 Chrome 확장 프로그램에 적용되나요? | ACT가 Chrome 확장 프로그램에 적용될 수 있는지에 대한 발표는 아직 없습니다. 하지만 기술이 사용자에 대한 정보를 은밀하게 수집하는 경우 Google의 개인 정보 보호 원칙에 부합하지 않습니다. |
관련성 높은 콘텐츠 및 광고 표시
주제
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| TAG 디자인 검토 | TAG에서 주제의 초기 설계 검토를 발표했습니다. | Google은 Topics에 대한 노력을 계속하고 있으며 최신 업데이트 페이지 및 이 문제에서 Google의 노력에 대한 업데이트를 공유했습니다. YouTube는 TAG 검토에 대해 포인트별로 답변하고 전반적인 비전을 공유했습니다. Topics API는 2023년 동안 광고 생태계에서 테스트해야 하는 API 모음의 일부로 유지됩니다. Google은 테스트 의견과 구현자 경험이 이 분야에서 크로스브라우저 표준 작업을 향한 향후 노력에 중요한 기여를 할 수 있기를 바랍니다. Google은 Topics API가 교차 브라우저 호환성을 갖춘 합의된 표준이 될 수 있는 전환을 원활하게 하는 방법에 관해 생태계와 계속 협력할 예정입니다. |
| 주제 접근 방식 | Chrome의 Topics API 개발에 대한 개방형 접근 방식 지원 | Google은 이러한 의견을 소중하게 생각하며 업계 그룹과 지속적으로 협력하여 전체 생태계에 가치를 제공하는 Topics API를 개발할 수 있기를 기대합니다. |
| (2022년 3분기에도 신고됨) 주제 분류가 충분히 세분화되지 않음 |
광범위한 주제 분류에는 지역별 주제를 비롯한 더 세분화된 주제가 포함되지 않습니다. | 1분기 업데이트: 분류 개선은 지속적으로 진행 중이며 2분기에 Topics API의 업데이트된 분류를 발표할 예정입니다. 이 새로운 분류를 만들기 위해 Google은 생태계 전반의 기업과 긴밀히 협력했습니다. YouTube는 생태계에 가장 유용한 분류에 관한 의견을 적극적으로 수렴하고 있습니다. 주제 수를 늘릴지 또는 더 세분화된 주제를 포함할지 평가할 때는 1) 잠재적인 개인 정보 보호 관련 문제 (주제가 많을수록 지문 식별 위험이 발생할 수 있음)와 2) 이전에 관찰된 주제를 검색할 수 있는 기능 (예: 주제가 많을수록 광고 기술에서 이전에 선택한 주제를 보았을 가능성이 줄어듦)을 고려해야 합니다. |
| (2022년 4분기에도 보고됨) 퍼스트 파티 신호에 미치는 영향 |
주제 신호는 매우 가치가 높을 수 있으며, 그 결과 다른 퍼스트 파티 관심분야 기반 신호의 가치가 떨어질 수 있습니다. | Google은 관심 기반 광고가 웹의 중요한 사용 사례라고 생각하며 Topics는 이러한 사용 사례를 지원하도록 설계되었습니다. 일부 대규모 게시자는 Topics가 퍼스트 파티 데이터 전략에 부정적인 영향을 미칠 것으로 우려하고 있습니다. 주제가 게시자에게 미치는 영향을 파악할 수 있는 생태계 테스트를 기대하고 있습니다. |
| 광고와 관련 없는 주제 사용 사례 | 관심분야 기반 광고를 표시하는 목적이 아닌 용도로 Topics 사용 | Topics는 자유롭고 개방된 웹의 중요한 사용 사례라고 생각되는 관심 기반 광고 사용 사례를 해결하도록 설계되었습니다. 현재 다른 사용 사례에 관한 의견을 수렴하고 평가하고 있습니다. |
| 기본 선택 상태 | 주제 동의 기본값에 대한 지역별 법률 영향 | Google은 법적 의견에 대해 언급할 수 없습니다. |
| (2022년 3분기에도 신고됨) 잘못 분류된 사이트 |
특정 사이트의 주제가 잘못 분류된 경우 타겟팅하는 광고 | 1분기 업데이트: 2분기에 Topics API의 업데이트된 분류기를 발표할 예정이며, 이를 통해 생태계와 소통할 수 있기를 기대합니다. 현재 의견에 따라 사이트는 가장 인기 있는 사이트가 포함된 사람이 선별한 재정의 목록과 기기 내 ML 모델을 조합하여 분류됩니다. Chrome은 사이트가 주제 분류에 참여할 수 있는 옵션을 계속 평가하고 있습니다. 유용성 개선은 개인 정보 보호 및 악용 위험과 비교하여 평가해야 합니다. 예를 들어 사이트에서 다양한 (잠재적으로 민감한) 의미를 주제에 암호화하는 방법으로 자체 라벨을 사용하는 경우, 금전적 이익을 위해 주제를 허위로 진술하는 사이트, 다른 사용자에게 주제의 유용성을 떨어뜨리기 위해 주제를 공격하는 사이트 (예: 의미 없는 노이즈로 사용자의 주제를 스팸함) 등이 위험에 해당합니다. 누구나 chrome://topics-internals 또는 이 colab을 통해 도구를 사용하여 이러한 구성요소를 검사할 수 있습니다. 테스트를 통해 시간이 지남에 따라 분류가 개선될 것으로 예상되며, 잘못 분류될 수 있는 사이트의 예시를 의견으로 보내주세요. |
| 주제 분류 기준 | 디버깅 목적으로 호출자에게 'No Topics'가 반환될 때 이유를 보여주는 추가 정보를 반환하도록 요청 | Google은 Topics API를 시스템에 통합하는 데 있어 디버깅 도구가 개발자에게 유용하다는 점을 잘 알고 있습니다. 하지만 추가 정보 (예: 반환된 주제가 없는 이유)를 노출하면 의도치 않게 당사자가 의도한 것 이상으로 추가 세부정보 (예: 사용자가 시크릿 모드에 있거나 API를 사용 중지한 경우 등)를 파악할 수 있는 정보를 공유하여 사용자 개인 정보 보호를 침해할 수 있습니다. 현재로서는 추가 디버깅 도구를 제공할 계획은 없지만 유용한 도구에 관한 의견은 언제든지 보내주세요. |
| 개인 정보 검색 (PIR) | Topics API에서 개인 정보 검색을 채택하도록 요청 | 이전에 PIR 사용을 조사했으며 여기에서 절충점을 공유했습니다. |
| 입찰 스트림 | 주제는 입찰 스트림에서 판매자 정의 잠재고객과 구별되게 표시되나요? | Topics API는 Chrome에서 개발한 개인 정보 보호 샌드박스 제안으로, IAB Tech Lab의 판매자 정의 잠재고객 제안과는 다릅니다. 이 두 가지는 입찰 스트림 내에서 명확하게 표현되어야 합니다. OpenRTB 입찰 요청에서 주제가 표현되는 방식을 알아보세요. |
Protected Audience API (이전의 FLEDGE)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| FLEDGE 기능 사용 가능 여부 | 펜스 프레임 시행, K-익명성 등의 FLEDGE 기능 테스트 및 구현 일정에 관한 설명 | 다양한 범위의 FLEDGE 기능과 지원 시기에 관한 상태를 공유했습니다. FLEDGE를 지속적으로 개발하는 과정에서 발표에 대한 추가 의견을 보내주세요. |
| 제품 렌더링 제한사항 | FLEDGE 펜싱된 프레임의 여러 부분으로 구성된 광고 제한 완화 요청 | 2월에 발표한 바와 같이 펜스 프레임 사용은 2026년까지 선택사항으로 유지되며 iframe 동작은 urn-iframes에서 지원됩니다. 이 주제에 관해 추가로 논의할 수 있습니다. |
| 확장성 문제 | 사용량이 증가함에 따른 FLEDGE 성능 | YouTube는 조치 가능한 해결책을 제안할 수 있도록 의견을 적극적으로 검토하고 더 많은 맥락을 파악하고 있습니다. 첫 번째 단계는 의견을 두 가지 카테고리로 구분하는 것이었습니다.
|
| (2022년 3분기에도 신고됨) 입찰 로직의 공개 상태 |
DSP 입찰 로직이 JavaScript에 노출될 수 있다는 우려 | 1분기 업데이트: 적대 행위자가 탐색 (강제 브라우징) 방식으로 서버에서 데이터를 요청하는 기능을 제한하는 제안서를 공유했으며 생태계 참여자는 제안서에 대한 의견이나 지원을 공유해 주시기 바랍니다. |
| 테스트 어려움 | 소규모 DSP가 FLEDGE를 적절하게 테스트하고 광고주가 대규모 DSP에서만 테스트하는 데 관심을 가질 위험을 완화할 수 있는 기능 | Google은 소규모 DSP와 협력하기 위해 최선을 다하고 있으며 FLEDGE가 정식 버전으로 전환됨에 따라 모든 규모의 DSP 및 광고주 간에 확대된 테스트를 적극 권장합니다. Google은 생태계의 다른 업체와 FLEDGE를 테스트하는 데 가장 효과적으로 지원할 수 있는 방법을 모색하고 있으며, 광고주가 소규모 DSP를 사용해 테스트하도록 유도하기 위한 아이디어와 업계의 노력을 환영합니다. |
| 동적 리마케팅 | 서드 파티 쿠키 지원 중단 후에도 FLEDGE를 통해 동적 리마케팅을 계속할 수 있나요? | Google은 이 질문에 대한 답변을 고려하고 있으며 생태계 참여자가 동적 리마케팅을 사용할 계획에 관한 추가 통계를 공유해 주시기 바랍니다. |
| 사기/악용 | 생태계는 위험을 줄이고 악의적인 행위자나 구매자가 원하는 잠재고객으로 포지셔닝하는 것을 막으려면 어떻게 해야 하나요? | Google은 사기 및 악용에 대해 생태계 참여자와 더 많은 협력을 기대하며 이 분야에 관한 추가 의견을 기다립니다. |
| 사용자 환경설정 | 사용자 환경설정을 저장하고 광고 선택에 사용하는 프로세스 | 특정 광고의 경우 관련 광고 기술이 표시되는 광고 소재 또는 광고 소재가 선택되는 방식을 제어할 수 있는 최적의 위치에 있습니다. |
| 정량적 테스트 제안서 | 정량적 테스트를 공정하게 진행하려면 서드 파티 쿠키가 없는 트래픽에서 테스트를 진행해야 하나요, 아니면 FLEDGE만 사용하는 SSP를 사용해야 하나요? 서드 파티 쿠키의 신호가 혼합되는 것을 방지하려면 어떻게 해야 하나요? | Google은 이러한 의견에 감사드리며, 서드 파티 쿠키 지원 중단 및 개인 정보 보호 샌드박스 제안서 도입이 생태계에 미치는 영향을 신뢰할 수 있는 방식으로 보여주는 실험을 설계하기 위해 CMA와 협력하고 있습니다. CMA의 정량적 테스트 제안에 관한 추가 의견이 있으면 CMA에 직접 공유해 주시기 바랍니다. |
| 더 명확한 문서 | 입찰 구성에 관한 더 명확한 문서 요청 | 앞으로 몇 주 내에 FLEDGE 입찰 보고에 관한 추가 개요가 포함된 블로그 게시물을 공유할 예정입니다. |
| 병렬 처리 | 입찰 서비스 (B&A)에서 병렬화를 지원하나요? | 입찰 서버를 사용하는 광고 기술은 결과를 동시에 게재할 수 있는 여러 서버를 시작할 수 있습니다. |
| 악용 완화 | 비공개 상태 토큰을 사용하는 FLEDGE k-익명성 서버로 사용자 개인 정보를 보호하기에 충분할까요? | k-익명성의 동기는 마이크로타겟팅보다는 FLEDGE에서 이벤트 수준 보고를 허용하는 중간 단계에서 백스톱을 갖추는 데 더 중점을 둡니다. 추가 의견을 공유했으며 추가 의견을 환영합니다. |
| ES 모듈 충돌 | ES 모듈과 충돌하므로 generateBid를 전역 함수로 삭제해 달라는 요청 |
이 요청을 논의 중이며 추가 의견을 보내주세요. |
| 구성요소 입찰 | 게시자가 입찰 설계를 더 세부적으로 관리할 수 있도록 요청 | 기기 내 Chrome과 마찬가지로 구성요소 입찰을 지원하는 입찰 및 입찰 계획 |
| B&A 타임라인 | B&A 서버 테스트에 관심이 있는 광고 기술의 일정 명확히 | B&A 설명을 업데이트했으며, CMA와 조정된 후 Chrome-B&A 테스트의 여러 단계에 대한 타임라인의 명확한 정의를 포함하도록 타임라인 섹션을 업데이트했습니다. |
| 제한 시간 제어 스킴 | 현재 FLEDGE에서 사용할 수 있는 제한 시간 제어 스킴 개선 | 흥미로운 제안입니다. 이 제안은 검토할 제안서 대기열에 추가되며 진행 상황을 보고해 드리겠습니다. |
| 광고 소재 입찰 스트림 | 광고 소재를 기반으로 낙찰된 입찰가를 검토하고 필터링할 수 있는 기능 | 흥미로운 제안입니다. 이 제안은 검토할 제안서 대기열에 추가되며 진행 상황을 보고해 드리겠습니다. |
reportWin |
reportWin 함수에서 낙찰자가 아닌 다른 관심분야 그룹 소유자의 최고 점수 입찰에 관한 추가 정보를 제공하는 제안 |
흥미로운 제안입니다. 집계 보고서에 신호를 추가하는 방안을 고려하고 있으며 여기에서 추가 의견을 보내주세요. |
| 이벤트 유형 | FLEDGE와 통합할 때 측정 API 전반에서 이벤트 유형 표준화 | 흥미로운 제안입니다. 이 제안은 검토할 제안서 대기열에 추가되며 진행 상황을 보고해 드리겠습니다. FLEDGE 외의 다른 개인 정보 보호 샌드박스 API에 영향을 미치므로 이 분야의 광범위한 노력과 조정해야 합니다. 여기에서 추가 의견을 보내주세요. |
| 이벤트 수준 보고를 위한 장기 솔루션 | 서드 파티 쿠키 지원 중단 후에도 highestScoringOtherBid와 같은 특정 데이터를 사용할 수 있도록 유지하는 데 관심이 있음 |
2월 블로그 게시물에서 공유한 바와 같이 이벤트 수준 입찰 낙찰 보고는 '2026년까지' 지원됩니다. 현재로서는 더 이상 공유드릴 정보가 없지만 서드 파티 쿠키 지원 중단 후에도 특정 데이터를 계속 사용할 수 있어야 하는 이유에 관한 추가 의견을 보내주시면 감사하겠습니다. |
| 관심분야 그룹 한도 | 출처에서 단일 브라우저를 추가할 수 있는 관심분야 그룹의 한도는 어떻게 되나요? | Chrome에서는 소유자당 최대 1,000개의 관심분야 그룹과 최대 1,000명의 관심분야 그룹 소유자를 허용합니다. 이는 일반 운영 중에 충족되어야 하는 것이 아니라 가드레일 역할을 하는 것입니다. |
| 이벤트 수준 신호 | 머신러닝 학습에 사용할 수 있는 generateBid 및 reportWin의 이벤트 수준 신호를 포함하는 제안서 지원 |
브라우저에서 설계한 신호 및 광고 기술에서 정의한 신호에 대한 결정을 공유했으며 추가 의견을 보내주세요. |
| 입찰 스크립트 | 입찰 스크립트의 URL에 사용자 ID를 포함합니다. | FLEDGE에는 광고를 게재하려면 관심분야 그룹 소유자, 입찰 스크립트 URL, 렌더링된 광고 소재의 튜플이 k-익명성이어야 한다는 추가 요구사항이 있으므로 불가능합니다. |
| K-anon 시정 조치 | (componentAd, size) 쌍에 k-익명성이 적용되나요? | 예, 맞습니다. turtledove/issues/312를 참고하세요. |
| 입찰 서비스 요구사항 | B&A 서비스는 기기 내 FLEDGE와 통합하는 참여자와 B&A 서비스와 통합하는 참여자를 어떻게 지원하나요? | 아직 디자인을 마무리하는 단계이며 여기에서 추가 의견을 보내주세요. |
| 조회 후 기여 분석 | 조회 후 기여 분석이 지원되나요? | 현재 조회가능성에 대한 표준 정의는 없으며 광고 소재 자체를 사용하여 조회 이벤트를 표시합니다. turtledove/issues/452를 참고하세요. |
| 유사 타겟팅 | 개인 정보 보호 샌드박스에서 '유사 타겟팅'을 지원할 수 있나요? | 여기에서 사용 사례에 관해 논의하고 있으며 추가 의견을 보내 주세요. |
| 실시간 모니터링 API | 실시간 FLEDGE 모니터링 접근 방식 제안 | Google에서는 제안서를 검토 중이며 여기에서 추가 의견을 보내주세요. |
| FLEDGE 보고 | reportWin 및 reportResult는 오버 보고 또는 언더 보고를 방지하기 위해 무작위 순서로 만들어야 합니다. |
reportResult()의 판매자 신호가 reportWin()에 포함될 수 있도록 reportResult()의 판매자가 먼저 reportWin()를 실행한 후 구매자가 실행해야 합니다. 자세한 내용은 설명을 참고하세요. |
| 맞춤 키-값 (K/V) 서버 | 향후 맞춤 K/V 서버가 지원될 예정인가요? | 여기에서 질문에 대해 논의하고 있으며 추가 의견이 있으면 언제든지 알려주세요. |
| 최상위 입찰 | 최상위 입찰 메커니즘을 실행하려면 광고 서버여야 하나요? | FLEDGE API는 이를 호출해야 하는 당사자를 지정하지 않습니다. FLEDGE 설계에는 이러한 의미의 요구사항이 없습니다. 누구나 FLEDGE 입찰 (복수 판매자 입찰 포함)을 실행할 수 있습니다. 2022년 4분기 보고서에서 언급했듯이 FLEDGE를 사용하면 각 게시자가 최상위 및 구성요소 판매자 선택을 비롯한 입찰 구조를 선택할 수 있습니다. |
| API 범위 | FLEDGE는 퍼스트 파티 데이터를 사용할 계획인가요? | 2023년 2분기에 퍼스트 파티 데이터를 FLEDGE에서 1) 관심분야 그룹 멤버십을 결정하는 로직으로 사용하고 2) 후속 입찰 로직 생성에 사용할 사용자 입찰 신호로 제공하는 데 실제로 사용할 수 있음을 명확히 하는 콘텐츠를 게시할 예정입니다. |
| 교차 도메인 관심분야 그룹 | 교차 도메인 관심분야 그룹을 만들 수 있는 기능 | 관심분야 그룹에 브라우저를 추가할 때 사용 가능한 모든 정보는 잠재고객에게 정보를 제공하는 데 사용할 수 있습니다. 서드 파티 쿠키가 단계적으로 중단되면 관심분야 그룹 생성을 알리는 교차 사이트 데이터의 가용성이 제한됩니다. |
| 클라이언트 측 입찰 로직 | 기존 서버 측 입찰 로직을 클라이언트 측으로 포팅 | YouTube는 포팅 과정에서 어려움을 겪고 있거나 현재 부족한 부분에 대해 자세히 알아보고 추가 의견이나 통계를 기다리고 있습니다. |
| K/V 서버 값 | K/V 서버 값은 문자열 유형이어야 하나요? | 값은 문자열이어야 하지만 JSON 또는 프로토콜 버퍼에 객체를 저장하고 문자열로 직렬화할 수 있습니다. |
| 광고주 차단 목록 | 구매자에게 광고주 차단 목록을 제공하는 데 적합한 신호는 무엇인가요? | 적절한 위치는 auctionSignals 또는 perBuyerSignals입니다. |
| 입찰 단위 | CPI 및 CPM과 같은 다양한 입찰 단위 지원 | 현재 설계에서 이 기능이 필요한 이유를 자세히 알아보고 추가 의견을 받고자 합니다. |
| 입찰 로직 | 브라우저 또는 광고 서버에서 입찰의 낙찰자를 결정하나요? | 모든 낙찰자 선택은 샌드박스 내에서 실행되며 모든 결정은 판매자의 코드에 의해 이루어집니다. 브라우저는 구매자 코드와 판매자 코드가 실행되는 봉인된 비공개 환경을 제공하기만 합니다. |
| Permissions-Policy | 오리진 트라이얼이 종료된 후에도 현재 FLEDGE 권한 정책이 계속 시행되나요? | Origin 체험판의 경우 두 기능의 현재 기본 허용 목록은 일시적이며 변경될 예정입니다. Google에서 시행하기 전에 광고 기술이 변경사항에 대비하는 데 얼마나 걸릴지 알고 싶습니다. |
| 신호 크기 제약조건 | 신뢰할 수 있는 입찰 신호 요청은 동일한 trustedBiddingSignalsUrl를 사용하는 여러 관심분야 그룹에서 병합됩니다. 2MB 크기 제한은 제약 조건입니다. |
이 제약 조건은 기기 내 호출자가 기기의 리소스를 과도하게 사용하지 못하도록 하기 위한 것입니다. B&A 서버의 호출자는 더 완화된 제약 조건이 적용됩니다. |
| 신호 보고 | 관심분야 그룹 소유자 및 computeBid 또는 reportWin / reportResult당 클라이언트 측 오류 수를 검색할 수 있도록 스크립트 오류라는 신호를 추가합니다. |
Google은 이 제안에 대한 잠재적인 개인 정보 보호 문제를 고려하고 있으며 생태계 참여자가 이 기능이 필요한 이유에 관한 추가 통계를 공유해 주시기 바랍니다. |
| K-Anon 창 크기 | K-Anon 기간을 현재 7일 한도에서 늘립니다. | 이 사항은 현재 검토 중이며 생태계의 추가 의견을 기다리고 있습니다. |
| 기기 실적 | 사용자가 많은 관심분야 그룹에 속해 있는 경우 FLEDGE는 기기 성능을 어떻게 처리하나요? | FLEDGE는 SSP와 DSP 전반에서 여러 가지 제한 시간, 우선순위, 제한 옵션을 제공하여 기기가 많은 관심분야 그룹에 속해 있을 때 입찰 참여를 제한하는 이유 중 하나가 기기 성능일 수 있는 상황에서 광고 기술을 세부적으로 제어할 수 있도록 지원합니다. |
| B&A 서비스 테스트 | 디버깅에 사용할 수 있는 로그를 더 많이 확보하기 위해 테스트 단계에서 생태계 플레이어가 자체 서버를 사용하도록 요청 | B&A를 사용하면 사용자가 승인된 클라우드 제공업체의 서버를 실행하고 확장할 수 있습니다. Google은 사용자 개인 정보를 보호하기 위해 신뢰할 수 있는 실행 환경 (TEE) 내에서 실행되도록 시행하고 있습니다. 곧 B&A TEE 디버깅에 관한 설명을 제공하고 이를 지원하는 기능을 개발할 예정입니다. 이 주제에 관한 추가 의견을 모집하고 있습니다. |
| 규제 기관 요건 | FLEDGE는 현지 규제 요구사항 준수를 지원하기 위해 여러 국가의 클라우드 제공업체와 협력하나요? | 다른 클라우드 제공업체에 대한 제안은 언제든지 환영하지만 현재는 서드 파티 쿠키 지원 중단이 시행될 때 최소한 GCP와 AWS를 지원할 계획입니다. 자세한 내용은 이 설명을 참고하세요. |
디지털 광고 측정
Attribution Reporting (및 기타 API)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 노이즈 영향 데이터 분석 | 노이즈의 영향에 대한 데이터 분석을 수행하는 방법에 관한 안내 | 노이즈 및 노이즈가 광고 기술 데이터에 미치는 영향을 변경하는 데 사용할 수 있는 노이즈 및 설계 결정에 관한 추가 문서를 공유했습니다. 자세한 가이드도 확인할 수 있습니다. |
| Null 보고 | null 보고서 구현에 관한 명확성 | 현재 null 보고서 구현을 위한 제안서를 작성 중이며 곧 자세한 내용을 공유해 드리겠습니다. null 보고서를 구현하면 개인 정보를 침해하지 않고도 보고서 지연을 줄일 수 있습니다. |
| 소음 수준 | 기여 분석 기간 길이에 따라 노이즈 수준 조정 | Google은 이 제안을 환영하며 사양에 추가하는 방안을 모색하고 있습니다. 여기에서 추가 의견을 보내주세요. |
| 트리거 데이터 크기 | 트리거 데이터 크기가 3비트로 제한되는 이유는 무엇인가요? | 크기는 3비트 및 8개의 고유한 값으로 제한되어 사용자에 관한 교차 사이트/문맥 정보의 양이 제한됩니다. 생태계 참여자는 이벤트 수준 보고의 현재 매개변수가 적절한지 여부에 관한 의견을 제출할 수 있습니다. |
| 이벤트 수준 보고 트리거 | 중복 삭제 키 내에서 우선순위 지정 허용 | YouTube는 이 문제에 대한 해결책을 모색하고 있으며 추가 의견을 기다리고 있습니다. |
| 디버깅 지원 | 서드 파티 쿠키 지원 중단 후 디버깅 관련 명확성 | Google은 서드 파티 쿠키 지원 중단 후 디버깅을 지원하고자 하며 다양한 옵션을 고려하고 있습니다. 추가 의견과 아이디어를 기다리고 있습니다. |
| 클릭 후 전환 대안 | 클릭 후 전환의 대안과 관련된 추가 안내 요청 | 생태계는 Attribution Reporting API를 관련 전환 측정 사용 사례를 위한 지속적인 비공개 측정 시스템으로 사용하는 것이 좋습니다. 다른 대안도 있으며 광고 기술 제공업체는 원하는 개인 정보 보호 및 유용성 요구사항에 따라 적절한 솔루션을 결정해야 합니다. |
| 결제 사용 사례 | 기여 분석에서 전환 기반 결제 사용 사례를 지원하는 정도 명확히 | Google은 결제에 대한 Attribution Reporting API의 범위를 명확히 하는 공개 게시물을 준비하고 있습니다. Attribution Reporting API는 처음에는 CPA 결제를 직접 지원하는 방식으로 범위가 지정되지 않았습니다. 대다수의 광고 기술에서 사용하는 결제 구조인 CPC 및 CPM 결제를 지원합니다. 향후 생태계 관련 의견이 추가되면 지원될 수 있습니다. |
| 사용 사례 지원 | 측정 API 사용 사례 문서 | Google은 모든 개인 정보 보호 샌드박스 보고 도구의 문서를 명확히 하는 작업을 진행하고 있습니다. |
| 클릭 품질 | 광고의 의도적 클릭과 의도하지 않은 클릭을 구분하는 신호 추가 요청 | YouTube에서 요청을 논의 중이며 추가 의견을 기다리고 있습니다. |
| 측정 솔루션 | 여러 DSP에서 측정 솔루션 지원 | Attribution Reporting API는 측정 제공업체가 여러 DSP 간에 중복을 제거하는 데 사용할 수 있습니다. 또한 attributionsrc의 URL 목록 지원을 제안하고 있습니다. 이를 통해 DSP가 측정 서비스 제공업체 Attribution Reporting API 요청을 더 쉽게 지원할 수 있습니다. 위 제안에 관한 추가 의견이 있으면 보내주세요. |
| 이벤트 수준 보고 | 보고서가 직접 전송되기까지의 일수를 요청합니다. | 이 요청은 현재 사용 가능한 정보를 사용하여 광고 기술에서 이미 계산할 수 있습니다. 이 요청과 관련하여 다른 생태계 의견은 접수되지 않았지만 의견이 있으시면 언제든지 보내주세요. |
source_registration_time |
이벤트 수준 기여 분석 보고서에 source_registration_time를 추가합니다. |
YouTube는 이 요청을 검토 중이며 생태계 참여자가 이 기능을 유용하게 생각하는지에 관한 추가 의견을 기다리고 있습니다. |
| 시크릿 모드 | 사용자가 시크릿 모드일 때 측정 솔루션을 사용할 수 있나요? | 아니요. 사용자가 시크릿 모드일 때는 측정 솔루션을 사용할 수 없습니다. 시크릿 모드에서는 기본적으로 서드 파티 쿠키가 사용 중지되어 있습니다. |
| 데이터 클린룸 | Measurement API는 데이터 클린룸과 호환되나요? | 일반적인 데이터 클린룸은 여러 소스의 개별 식별자 데이터를 데이터베이스에 업로드하여 기본 데이터 병합을 기반으로 분석을 실행하는 환경입니다. 개인 정보 보호 샌드박스 API의 두 가지 측정 프레임워크는 이벤트 수준 보고서와 요약 보고서입니다. 이벤트 수준 보고서에는 데이터 클린룸에서 사용할 수 있는 광고 기술 제공 이벤트 ID가 포함되어 있지만 연결된 전환 측정 정보는 제한적이고 노이즈가 많습니다. 암호화된 집계 가능한 보고서는 클린룸에서 직접 사용할 수 없지만 집계 서비스에서 제공하는 요약 결과는 분석에 사용할 입력 또는 보충 정보로 사용할 수 있습니다. |
Aggregation Service
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| (2022년 4분기에도 신고됨) 보고 지연 |
예상되는 보고 지연은 얼마나 되나요? | 2023년 1분기 업데이트: 파트너 의견을 바탕으로 지연을 줄이고 지연의 영향을 완화하기 위한 제안을 공유했습니다. 두 제안서 모두 WICG 통화 중에 광고 기술에서 지원했습니다. |
| 중복 없음 규칙 | 공유 ID가 동일한 집계 가능한 보고서가 이미 처리된 경우 '지연된 집계 가능 보고서'를 어떻게 처리하나요? | 집계 가능한 보고서의 공유 정보에 추가 보고서 지연을 추가하고 집계 서비스의 공유 ID 정의에 관한 지연 손실이 집계 API에 미치는 영향을 부분적으로 해결하기 위한 제안서를 공유했습니다. 제안에 대한 의견이 있으시면 알려주세요. |
| 데이터 처리 | 개인 정보 보호 예산을 사용하여 개인 정보 차등 보호를 준수하면서 여러 번의 데이터 패스를 지원하도록 사용 설정해 달라는 요청 | 이 사용 사례를 지원하기 위해 개인 정보 보호 예산을 사용하는 더 유연한 방법을 사용할 가능성을 논의하고 있으며 추가 의견을 기다립니다. |
| (2022년 2분기에도 신고됨) 검색어 인체공학 | 키 집계 쿼리 사용 설정 | 2023년 1분기 업데이트: 기능 요청은 아직 검토 중이지만 현재로서는 공유해 드릴 제안이 없습니다. |
| Origin 트라이얼 제한사항 | 현재 원본 체험판에 적용되지 않는 '중복 없음 규칙'과 같은 집계 서비스의 범위를 명확히 합니다. | 오리진 트라이얼과 GA에서 제공되는 기능을 명확히 설명하기 위해 문서를 업데이트하는 방안을 모색하고 있습니다. |
Private Aggregation API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 비공개 집계 참여 예산 | L1 참여 예산이 너무 제한적입니다. | Private Aggregation API를 호출할 때마다 기여라고 합니다. 사용자 개인 정보를 보호하기 위해 개인으로부터 수집할 수 있는 참여 횟수는 제한됩니다. 모든 집계 키에서 집계 가능한 모든 값을 합산하면 합계가 기여도 예산보다 작아야 합니다. 현재 설계에서는 지난 24시간 동안 특정 보고 출처의 기여도를 누적 기간으로 제한합니다. 이는 의견에 언급된 L1 참여 예산입니다. 개발자는 예상 볼륨에 따라 기여하는 값을 조정하는 것이 좋습니다 (단순히 값 1을 사용하는 것이 아님). 따라서 예산이 소진되지 않도록 더 일반적인 이벤트에는 더 작은 값을 사용하는 것이 좋습니다. 현재 숫자 경계와 범위 모두에 관한 비공개 집계 API의 참여 예산에 관한 의견을 수렴하고 있습니다. 범위를 출처별에서 사이트별로 변경하고 기존 경계를 더 큰 일일 경계가 있는 10분 범위로 이동하는 방안을 고려하고 있습니다. |
은밀한 추적 제한
User-Agent Reduction/User-Agent Client-Hints
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| UA-R 채택 | 영국의 상위 10,000개 사이트 중 프로그래매틱 광고를 사용하는 사이트의 1% 만 HTTP 클라이언트 힌트를 전송하고 있습니다. 이전하지 않은 DSP는 사기 방지 기능에 영향을 줄 수 있습니다. | 동일한 데이터 세트에서 분석을 실행한 결과, HTML <meta> 태그와 JavaScript API를 사용하여 UA-CH 사용량을 고려하면 UA-CH를 사용하는 사이트 수가 의견에 제공된 1% 보다 훨씬 많습니다. 이를 토대로 생태계 의견을 비롯한 기타 사실을 고려하여 게시된 타임라인에 따라 UA 감소 6단계를 점진적으로 출시하고 CMA에 계속해서 정보를 제공할 계획입니다. 사이트는 전환에 대비할 수 있도록 거의 2년의 준비 기간을 보냈으며, 준비가 되지 않았다고 생각하는 사이트는 지원 중단 체험판을 계속 사용할 수 있습니다. |
| 추가 폼 팩터에 관한 힌트 | UA-CH에 TV, VR과 같은 추가 폼 팩터를 제공해 달라고 요청 | Google은 이 제안을 환영하며 설계에 통합하는 방안을 모색하고 있습니다. 추가 의견을 보내주세요. |
| 자동 테스트 | UAR 6단계가 출시되기 전에 헤드리스 Chrome에서 UA-CH 버그를 해결해 달라는 요청 | 해당 버그가 수정되었습니다. |
| iOS의 UA-CH 지원 | 광고 사용 사례에 세부적인 UA 정보를 사용하는 사이트에서 iOS의 Chrome은 지원되지 않는다고 명시합니다. | Safari가 아닌 iOS 브라우저(iOS용 Chrome 포함)의 경우 네트워크 스택을 제어하므로 사용 설정하기 전에 WebKit 프로젝트에서 UA-CH 지원을 추가해야 합니다. |
IP 보호 (이전 명칭: Gnatcatcher)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| (4분기에 보고됨) 위치정보 사용 사례 | IP 보호로 인해 향후 위치정보 기반 콘텐츠 맞춤설정과 같은 합법적인 위치정보 사용 사례가 작동하지 않을 수 있습니다. | 2022년 4분기와 동일한 답변을 제공하고 있습니다. "Google은 Chrome에서 IP 주소의 적법한 사용 사례를 계속 지원할 수 있도록 이해관계자와 협력하고 있습니다. IP 위치정보 세분성에 관한 생태계 의견을 모집하고 있습니다." |
| 규정 준수 | 인구가 100만 명 미만인 지역의 경우 현재 IP 보호의 기준점인 100만 명이 적용되면 웹사이트에서 규정 준수를 위해 IP 주소를 사용할 수 없게 됩니다. | Google은 Chrome에서 IP 주소의 합법적인 사용 사례를 계속 지원할 수 있도록 이해관계자와 협력하고 있습니다. Google은 IP 보호 관련 규정 준수에 관한 생태계 의견을 모으고 있습니다. |
| 악용 완화 | 당사자는 마스킹되지 않은 IP 주소를 다른 사용자와 공유하여 IP 보호를 우회할 수 있습니다. | Google은 현재 IP 보호 제안이 기술적으로 당사자가 마스킹되지 않은 IP 주소를 다른 사용자와 공유하는 것을 막지 못할 수 있다는 위험을 인식하고 있습니다. Google은 이러한 악용 위험을 방지하기 위한 완화 조치를 모색하고 있습니다. 제안서를 반복할 때 더 많은 의견과 논의를 보내주세요. 특히 당사자가 마스킹되지 않은 IP 주소를 다른 당사자와 공유해야 한다고 생각하는 사용 사례를 알고 싶습니다. |
| 네트워크 차단 | 당사자는 IP 보호 프록시를 사용하여 네트워크 차단을 우회할 수 있습니다. | 차단을 실행하는 항목은 이 시나리오에 대해 IP 보호를 사용 중지해야 합니다. 문제에 응답했으며 추가 의견을 보내주세요. |
| IP 보호 제안서의 영향을 받는 IP 주소 차단 목록 | 많은 광고 기술 회사는 TAG 데이터 센터 IP 목록과 같은 IP 주소의 기본 차단 목록을 활용하여 사기 가능성이 높거나 최소한 수익을 창출할 수 없는 광고 인벤토리에 입찰하지 않습니다. 광고 기술이 추적 광고주이기도 하며 IP 보호 제안서에 적용될 수 있는 경우 해당 회사는 광고 인벤토리를 구매하기 전에 광고에 대한 기본적인 확인을 수행할 수 없게 될 수 있습니다. | 잠재적 문제 및 해결책에 관한 IP 보호 제안서에 대한 더 많은 의견과 토론을 보내주세요. 한 가지 방법은 이전에 신고된 IP 주소에서 발생한 클라이언트를 프록시하지 않도록 이와 유사한 목록을 IP 보호에 적용하는 것입니다. |
크로스 사이트 개인 정보 보호 경계선 강화
퍼스트 파티 세트
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| (4분기에도 신고됨) 도메인 한도 | 연결된 도메인 수 확대 요청 | 2022년 4분기와 동일한 답변을 제공합니다. "WICG 회의에서 Chrome은 사용자의 개인 정보 보호 이익도 고려하는 사용 가능한 솔루션을 제공하기 위해 노력하고 있다고 명확히 밝혔습니다. 이러한 맥락에서 Google은 사용자 개인 정보를 계속 보호하면서 이러한 사용 사례를 해결할 방법을 고려할 수 있도록 도메인 제한의 영향을 받을 수 있는 특정 사용 사례에 관한 커뮤니티의 의견을 보내주실 것을 요청합니다." |
| 대체 FPS 제출 | FPS용 전 세계 목록을 제출하는 대체 방법에 관한 제안 | 현재 Chrome에서 퍼스트 파티 세트 (FPS)를 출시할 준비를 하고 있으며 세트 제출을 수락하는 중앙 집중식 GitHub 저장소를 설정했습니다. FPS가 서드 파티 쿠키 지원 중단에 대비하여 기존 웹 플랫폼 솔루션의 공백을 메울 수 있기를 바라므로 사이트 작성자가 FPS를 활용하는 방법을 알아볼 수 있을 것으로 기대합니다. 시간이 지남에 따라 세트 목록이 늘어나고 생태계가 서드 파티 쿠키가 사라진 세상에 적응함에 따라 제안된 것과 같은 대체 분산형 스키마를 고려할 수 있을 만큼 프로세스를 성숙시킬 수도 있습니다. 현재 절차를 통해 설정된 전체 기간을 도입할 예정이며, 이를 통해 시간이 지남에 따라 접수 절차를 개선할 수 있을 것으로 기대됩니다. 제출 절차가 완성되면 이 아이디어를 다시 검토할 수 있습니다. |
| 저장소 검토 | 악용을 방지하기 위해 FPS 제출 저장소에 대한 커뮤니티 검토를 시행합니다. 악의적인 행위자는 버너 출처를 사용하여 세트를 제안하는 프로세스를 쉽게 과도하게 처리할 수 있으며, 엄청난 양의 요청은 실제 세트 제안 작업에 영향을 줄 수 있습니다. | YouTube는 기술적 유효성 검사를 활용하여 최대한 객관적인 검토를 진행하고 있습니다. 이는 제출 절차에 가장 확장 가능한 접근 방식이라고 생각합니다. 이 목표에 따라 스팸 / 버너 제출에 강한 프로세스를 만드는 것도 목표로 하고 있습니다. |
| 연결된 하위 집합 | FPS가 연결된 하위 집합을 통해 서드 파티 공급업체/SaaS 흐름 사용 사례를 지원할 수 있나요? | 서드 파티 공급업체 / SaaS 흐름은 현재 퍼스트 파티 세트의 범위 내에서 고려되는 사용 사례가 아닙니다. 이러한 사용 사례에 교차 사이트 쿠키가 사용되는 방식에 관한 추가 의견을 보내주세요. |
| FPS + CHIPS 통합 | A/B 테스트와 같은 사용 사례를 지원하기 위한 FPS + CHIPS 통합 요청 | 이 사용 사례에 대해 논의 중이며 WICG 회의에서 추가로 논의하는 것도 고려하고 있습니다. 여기에서 추가 의견을 보내주세요. |
| GDPR | GDPR 개념에 따라 모델링할 새로운 FPS 하위 집합에 관한 제안 | Google은 이 제안을 내부적으로 논의하고 Google의 개인 정보 보호 목표와 접수된 다른 의견과 비교하여 검토했습니다. 현재 이 제안을 추진하지 않는 이유를 설명하는 답변을 제공했습니다. |
| 메모리 | FPS 목록이 통합될 때 예상되는 브라우저 메모리 크기 변경사항 | 브라우저가 이러한 종류의 목록을 최소한의 메모리 영향을 미치도록 저장한 선례가 있습니다(예: 연결 해제 추적 보호 목록). 퍼스트 파티 집합 목록은 로컬에서 각 Chrome 클라이언트에 복사되지만 Google은 파일 크기를 계속 모니터링하고 메모리 사용량을 최적화할 수 있다고 확신합니다. |
Fenced Frames API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 분리 프레임 제한사항 | Fenced Frames의 제한사항에 관한 명확성 | 3월에 기능에 관한 정보를 제공하는 울타리 프레임에 관한 설명을 업데이트했으며 추가 의견을 보내주세요. |
| 액세스 정보 펼치기 | 인접 프레임 주변 정보에 대한 액세스 권한 확장 요청 | Google은 생태계에서 이 요구사항이 필요한 이유를 자세히 파악하고자 하며 추가 의견을 기다리고 있습니다. |
| 분리 프레임 및 iframe | 펜싱된 프레임과 iframe 간의 기능 패리티에 관한 질문 | 사용 가능한 모든 개인 정보 보호 샌드박스 API 및 보고서는 iframe과 FencedFrames에서 동일한 방식으로 사용할 수 있습니다. |
| 분리 프레임 크기 조정 | 프레임 크기 변경을 제한하면 특정 사용 사례에 영향을 미칩니다. | Google은 이 제한사항의 영향을 받는 사용 사례 유형에 대해 자세히 알아보고 추가 의견을 받고자 합니다. |
Shared Storage API
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 서드 파티 워크렛 | 서드 파티가 출처별로 파티션된 공유 저장소에 쓸 수 있나요? 아니면 서드 파티 측정을 위해 다른 워크렛을 호출하나요? | 코드가 실행되는 브라우징 컨텍스트의 출처에 따라 데이터가 작성되는 공유 저장소가 결정됩니다. 서드 파티 코드가 페이지에 추가되면 서드 파티 코드는 자체 브라우징 컨텍스트가 있는 iframe으로 삽입될 수 있으므로 서드 파티 코드가 자체 출처에 쓸 수 있습니다. 서드 파티 코드는 iframe 대신 스크립트로 삽입할 수도 있으며, 이 경우 브라우징 컨텍스트가 전환되지 않으며 서드 파티는 삽입자의 공유 저장소에 쓸 수 있습니다. 공유 저장소의 소유자만 공유 저장소에서 읽을 수 있습니다. |
| 중복 삭제 | Chrome 생태계 외부의 상호작용에는 중복 삭제가 불가능합니다. | 공유 저장소는 Chrome 내에서 Chrome 브라우저 기반 고유 도달범위 출력을 제공하기 위한 것입니다. Google은 광고 기술과 협력하여 이러한 출력을 광범위한 도달범위 모델의 일부로 사용하는 방법을 알아보고자 합니다. Google은 출력 자체가 상호작용의 일부만 설명할 수 있다는 점을 잘 알고 있으며, 광고 기술과 협력하여 추가로 모델링 방법론을 탐색하고 이를 위에 적용하는 데 관심이 있습니다. |
| 전환 확인 기간 | 시간 경과에 따른 전환 변화를 확인하기 위해 전환율에 대한 전환 확인 기간을 요청합니다. | 이는 공유 저장소를 사용하여 클라이언트 측에서 다양한 전환 경로를 처리하여 구현할 수 있으며, 이는 안전한 파티션되지 않은 브라우저 저장소를 통한 고급 분석에 추가적인 유연성을 제공합니다. |
| 상품 만료 기간 | 만료 기간을 90일로 연장해 달라고 요청 | 데이터 보관 정책은 2022년 11월에 업데이트되었으며, 각 키는 마지막 쓰기 후 30일이 지나면 삭제된다고 명시되어 있습니다. 새로운 정책이 생태계에 적합한지 파악하기 위한 추가 의견을 보내주세요. |
| 광고 소재 순환게재 | 광고 소재 순환 사용 사례는 입찰 후 실제 액션을 반영하지 않습니다. | 광고 소재 순환 문서의 정확성에 관한 구매 측 광고 기술 회사의 의견을 더 많이 듣고자 합니다. |
CHIPs
이번 분기에 받은 의견이 없습니다.
FedCM
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| ID 어설션 엔드포인트 | ID 어설션 엔드포인트에 대한 임의의 요청을 명시적으로 허용합니다. | Google은 이 풀 리퀘스트에 대해 Mozilla와 협력하여 웹사이트가 사용자에게 불편을 주지 않으면서 크로스 오리진 사용자 인증 정보 요청을 자동으로 실행할 수 있는 기능을 제한하고 있으며, 다른 의견도 계속 검토하고 해결할 예정입니다. |
| ID 자동 입력 | FedCM을 사용하여 FedCM 목록의 ID 공급자로 로그인 양식을 미리 채울 수 있나요? | 이 사용 사례의 문제는 사용자와 상호작용하지 않은 사이트에서 사용자가 사용한 마지막 IDP를 쿼리할 수 있으므로 정보가 유출될 수 있다는 점입니다. YouTube는 이 문제를 논의하고 있으며 추가 의견을 기다리고 있습니다. |
| 문맥에 따른 계정 선택 | 계정 선택 UI에 문맥 신호를 추가하기 위한 제안 | YouTube는 이 제안을 검토 중이며 추가 논의를 환영합니다. |
스팸 및 사기 퇴치
Private State Tokens API (및 기타 API)
| 의견 테마 | 요약 | Chrome 응답 |
|---|---|---|
| 기능 수집 설문조사 | 1분기 초, 다양한 사기 방지 사용 사례에 필요한 기능에 관한 설문조사 결과를 수집하고 이를 공개적으로 공유했습니다 (회의록, 결과). | Google은 사기 방지 기능을 위한 목적 지향적인 개인 정보 보호 API에 관한 새로운 제안과 프로토타입을 개발할 때 이 의견을 반영할 계획입니다. Google은 사용자 개인 정보를 보호하면서 웹에 기능을 도입하기 위해 구축할 수 있는 기존 기술이 있고 충분한 요구가 있는 개발에 우선순위를 둘 것으로 예상됩니다. 예를 들어 기기 및 부팅 무결성이 높은 순위에 올랐으며 많은 플랫폼에 기기 무결성 평가를 안전하게 공유하는 기존 API가 있으므로 커뮤니티 그룹 내에서 탐색을 추구하기에 좋은 후보입니다. |
| PST 발송 인텐트 의견 | 출시 의도의 일환으로 이전 버전의 개인 정보 보호 패스를 사용하고 있으므로 진행에 관해 우려사항이 접수되었습니다. 또한 특정 섹션에서 사양이 명확하지 않으며 브라우저 호환성을 용이하게 하기 위해 개선해야 한다는 의견도 접수되었습니다. | GA로 출시하기 전에 제안된 사양 변경사항과 몇 가지 API 변경사항을 구현할 계획입니다. 의견은 1분기 말에 접수되었으므로 구체적인 세부정보와 출시 계획 업데이트 (이 의견 보고서 게시 시점 기준 진행 중)를 포함하여 github 문제에 대해 후속 조치를 취하고 있습니다. API의 대규모 변경사항은 고려할 수 있지만, 가장 좋은 방법은 정식 버전 출시를 진행하고 더 많은 개발자의 의견을 직접 수렴하는 것입니다. 이 논의를 계속하고 브라우저 표준화를 추구할 수 있기를 바랍니다. 새로운 표준이 등장하면 Google은 해당 표준으로 신중하게 전환할 계획을 수립하고 채택하는 것을 고려할 것입니다. |