구글 개인정보 보호 설정 업데이트 방법

2월 초기 발표 이후 Android 생태계 전반의 파트너로부터 의견을 받았습니다. 의견을 보내주셔서 감사합니다. 계속해서 의견 및 질문을 보내주시기 바랍니다.

이번 진행 상황 업데이트에서는 설계 제안의 새로운 개발 및 업데이트의 요약, 접수된 주요 질문과 의견, 개발자 프리뷰 출시의 업데이트를 공유합니다.

최종 업데이트: 2022년 9월 9일

신규 출시

개발자 프리뷰 5 출시

이 최신 출시 버전은 향후 개인 정보 보호 샌드박스 베타 출시의 기반이 되는 주요 버전입니다. 이 출시 버전에는 추가 기능, 데이터 유효성 검사 개선사항, Android의 FLEDGE, Topics, 기여도 보고서, SDK 런타임의 API 서명 변경사항이 포함되어 있습니다.

Google은 향후 몇 달 동안 새로운 기능이 출시됨에 따라 개발자 프리뷰 리소스를 지속적으로 업데이트할 예정입니다. 의견이나 질문을 공유해 주시기 바랍니다. 또한 이번 이니셔티브에 관한 업데이트를 받기 위해 가입하시는 것을 권장합니다.

개발자 프리뷰 출시 일정 업데이트

모든 날짜와 세부정보는 변경될 수 있습니다.

각 개발자 프리뷰에는 각 출시에서 제공되는 기능과 제공되지 않는 기능을 설명하는 자세한 출시 노트와 가이드가 함께 제공됩니다.

현재 사용 가능

• 개발자 프리뷰 5 - SDK 런타임, Topics, FLEDGE 및 Attribution Reporting API 등 관련 API를 사용하여 통합을 설계할 수 있는 기능을 포함합니다.

2022년 9월 이후:

• 모든 API 및 SDK 런타임의 개발자 프리뷰 정기 업데이트

2022년 말

• 소비자 휴대기기용 Android의 개인 정보 보호 샌드박스 베타 1 출시

알림: 지난 2월 Android의 개인 정보 보호 샌드박스를 발표했을 때 이 새로운 샌드박스를 설계, 빌드, 테스트하는 동안 Google에서는 기존 광고 플랫폼 기능을 최소 2년 동안 지원할 예정이며, 향후 변경에 앞서 충분한 공지를 제공할 계획이라고 강조했습니다.

설계 제안 업데이트

이 섹션에서는 설계 제안의 몇 가지 구체적인 업데이트를 설명합니다.

Reflection API

Google은 초기 SDK 런타임 설계 제안에서 SDK 개발자가 다른 SDK에 의한 조작을 방지하는 것을 돕는다는 목표로 Reflection API와 Invoke API에 대한 액세스를 금지하려는 제안에 관한 의견을 요청했습니다.

Google은 영향을 받는 사용 사례에 관한 소중한 의견을 받았으며, 유틸리티 및 위험에 관한 세부 조사를 한 후 SDK 런타임 내에서 Reflection API와 Invoke API를 사용할 수 있도록 허용할 예정이며 그에 따라 설계 제안을 업데이트했습니다.

그러나 다른 런타임 지원 SDK에서는 SDK가 Reflection API 또는 Invoke API를 사용할 수 없습니다. 대신 SDK 런타임의 SDK 간 통신을 위해 SDK 검색을 위한 별도의 API를 설계하고 있으며, 향후 업데이트에서 자세히 설명하겠습니다.

Google은 다른 SDK에 의한 변조 위험을 줄이기 위해 지속적으로 노력하고 있으며, 이에 따라 SDK 런타임 시 JNI 코드 사용을 금지하도록 여전히 제안하고 다른 API 사용도 적극적으로 고려하고 있습니다. 향후 업데이트에서는 금지된 API에 관한 전체 제안을 공유할 예정입니다.

Attribution Reporting API

• 보내주신 의견을 바탕으로 여러 관련 당사자가 조회, 클릭, 전환 이벤트를 등록할 수 있는 방법을 보여주는 예를 추가했습니다. 새로운 향후 고려사항 및 미해결 질문을 추가했으며 의견을 기다리고 있습니다.

Topics API

• Topics API는 지난 3 에포크(예: 지난 3주 동안)마다 하나씩 주제가 최대 3개인 목록을 반환합니다 반환된 주제가 사용자의 관심분야를 반영하고 반환된 주제 중 일부 또는 전부가 광고 개인 최적화에 사용될 수 있음을 명확히 하기 위해 Topics API 기술 제안을 업데이트했습니다.

추가로 받은 질문 및 의견 요약

이 섹션에서는 Google에서 받은 몇 가지 질문과 의견을 답변과 함께 제공합니다.

일반적인 질문

최종 설계는 아직 개발 중이지만 베타 기간에는 기기 설정에서 다음과 같은 목적으로 사용자 컨트롤을 제공하고자 합니다.

1. 개인 정보 보호 샌드박스 솔루션 종료 또는 다시 참여
2. Topics API에서 추론된 특정 주제 삭제

모든 개인 정보 보호 샌드박스 솔루션은 Android 오픈소스 프로젝트(AOSP)의 일부이므로 원하는 경우 다른 앱 스토어에서 채택할 수 있습니다. 사용하고 있는 앱 스토어에 문의하여 계획을 더 자세히 알아보세요.

SDK 런타임

현재 설계 중입니다. 고려 중인 한 가지 방식은 SDK 개발자가 SDK 런타임을 지원하는 앱 스토어를 통해 배포하기로 선택한 SDK의 major.minor.patch 버전을 지정하는 것입니다.

그런 다음 앱 개발자는 앱 매니페스트에서 선언하여 사용하려는 major.minor 버전을 선택할 수 있습니다. 해당 major.minor 버전의 최신 패치 출시는 다음 패치가 출시될 때까지(자동으로 설치됨) 또는 앱 개발자가 다른 major.minor 버전 종속 항목을 지정하여 앱을 다시 빌드할 때까지 설치되어 있습니다.

SDK 런타임의 초기 버전은 광고 게재, 광고 측정, 광고 사기, 악용 감지를 지원하는 SDK를 포함하여 광고 관련 SDK의 사용 사례를 지원하도록 설계되었습니다.

초기에는 광고 관련 SDK에 집중하지만 개인 정보 보호 친화적인 상태를 추구하고 위에 설명된 조건에서 작동할 수 있다고 생각하는, 비 광고 관련 SDK의 개발자는 SDK 런타임에서 실행되는 SDK에 관한 의견을 공유할 수 있습니다.

Google에서는 초기 설계 제안에 있는 권한 외의 특정 액세스 권한이 필요한 광고 관련 사용 사례를 파악하고자 합니다. 영향을 받는 기능에 관한 의견을 공유해 주시기 바랍니다.

여러 앱이 동일한 버전의 개별 런타임 지원 SDK와 통합되면 다운로드 크기와 디스크 공간이 절약됩니다.

AAID에 액세스하는 RE SDK의 기능은 앱과 앱의 매니페스트에 권한을 선언하는 SDK에 따라 다릅니다. 향후 제안서 업데이트에서는 SDK가 권한을 보유한 경우 SDK가 AAID를 가져오는 데 사용할 수 있는 API를 자세히 설명할 예정입니다.

Google에서는 현재 광고 관련 SDK가 액세스할 수 있는 시스템 속성을 통해 진행하고 있으며 이 기능은 향후 설계 제안서 업데이트에서 공유할 예정입니다. 이러한 속성의 사용과 관련된 정책은 게시되지 않았습니다.

앱이나 앱의 SDK는 호스트 앱의 Google Play 개발자 계정과 연결된 앱 세트 ID 값에만 액세스할 수 있습니다. Android의 개인 정보 보호 샌드박스는 사기를 목적으로 하는 교차 게시자 식별자를 제공하지 않습니다. 현재는 개발자가 약간 일관성이 낮은 대안으로 IP 사용을 고려할 수 있습니다.

주제

Android의 FLEDGE

현재 설계 제안은 FLEDGE의 맞춤 잠재고객에 기반한 제외 타겟팅을 지원하지 않습니다.

앱 설치 캠페인의 경우 광고 기술 제공업체에서 이미 설치된 앱을 필터링할 수 있는 광고 필터링 기능을 제공할 예정입니다. 또한 최대 게재빈도 설정 기반의 캠페인 제외 필터링 요구사항이 어떻게 지원될 수 있는지 살펴봅니다. 자세한 내용은 향후 설계 제안 업데이트에서 제공됩니다.

맞춤 잠재고객을 위한 Google의 제안서는 현재 개인 정보 보호를 위한 리마케팅 사용 사례의 구매 측 입찰가 생성을 지원하기 위한 것임을 고려하여 구매 측 사용 사례에 중점을 둡니다.

기여도 보고

현재 설계 및 계획에 따르면 Privacy Sandbox API는 Play 설치 리퍼러에서 제공하는 기능에 영향을 미치지 않습니다.

일부 개발자는 사용자가 특정 클릭 후 이벤트를 완료하면 '보상'을 받을 수 있는 광고 형식을 파악했습니다. 사용자 수준 기여 분석이 없으면 이는 현재 제안에서 어려운 과제입니다.

이 영역은 가능한 솔루션을 결정하기 위해 조사 중입니다. 이 사용 사례 및 있을 수 있는 다른 사용 사례에 관한 추가 의견을 보내 주세요.

오늘날 많은 광고주가 네트워크 전반에서 전환 이벤트의 중복 삭제된 뷰를 가져오는 것이 중요하다고 생각하며 모바일 측정 파트너(MMP)를 사용하는 것이 일반적입니다. 이렇게 하면 새 API로 쉽게 계속할 수 있지만, 개별 기술 플랫폼이나 광고주가 원하는 경우 직접 측정하는 것도 더 쉬워집니다.

리디렉션을 사용한다고 해서 모든 앱에 SDK가 실제로 존재해야 하는 것은 아니지만, 리디렉션 프로세스에 포함되어야 하는 광고 기술 SDK와 관계가 있어야 합니다.

이 접근 방식의 주요 이점은 모든 사용자가 자체 비즈니스 로직에 관한 자체 메타데이터 및 집계 키를 사용할 수 있고 자체 우선순위를 정의할 수 있다는 것입니다.

검증된 설치는 설치 후 전환 기여 분석 로직(선택 사항)에만 사용됩니다. 이러한 검증된 설치는 API를 통해 전송되지 않습니다. API는 등록된 전환을 기반으로 한 보고서만 전송하며 사용자가 이전에 앱을 설치했는지 여부에 관한 신호는 반환하지 않습니다.

현재 API 제안은 InputEvent를 통한 기본 클릭 검증을 지원합니다. Google은 더 강력한 클릭 검증 및 조회 검증 형식을 모색하고 있습니다. 이러한 사용 사례, 특히 생태계에 도움이 되는 조회 정의 유형에 관한 추가 의견을 보내주세요.