Як дізнатися, що збирають ваші SDK

Кожна вимога магазинів щодо даних зводиться до одного списку, і майже ніхто його не записує. Ваша політика конфіденційності, ваша форма Data safety і ваші відповіді в App Privacy — це три подання того самого списку, тож скласти його один раз і як слід — це і є вся робота.

Обидва магазини прямо кажуть, що поведінка SDK вважається вашою. Google Play зазначає, що збір даних “includes data collected and handled through any third-party libraries or SDKs used in their apps” (охоплює дані, які збирають і обробляють будь-які сторонні бібліотеки чи SDK, що використовуються в їхніх застосунках). Apple просить вас указати дані, які “you or your third-party partners collect” (збираєте ви або ваші сторонні партнери).

Крок 1 — знайдіть кожен SDK

Читайте файли, не покладайтеся на пам’ять:

Платформа	Файли
Android	build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (дозволи, метадані)
iOS	Podfile, Package.swift, *.pbxproj, Info.plist (рядки опису використання), *.entitlements
Flutter	pubspec.yaml
React Native / Expo	package.json, app.json

Враховуйте й транзитивні залежності, яких ви не обирали: SDK, що підтягує рекламну бібліотеку, збирає те, що збирає ця бібліотека.

Крок 2 — прочитайте розкриття від самого постачальника

Більшість серйозних постачальників публікують сторінку, де точно сказано, що надсилає їхній SDK, бо їхнім клієнтам це потрібно для тих самих форм. Саме ця сторінка — не допис у блозі, не відповідь на форумі — ваше джерело.

Firebase — розібраний приклад, бо Google публікує розбивку за продуктами, зіставлену з категоріями App Privacy від Apple:

Продукт Firebase	Що він збирає, згідно з документацією Google
Analytics	App instance ID, властивості користувача, події, IP-адреса
Crashlytics	Трасування стека та стан застосунку в момент збою, інформація про пристрій і ОС, а також будь-які власні ключі, журнали та ідентифікатори користувачів, які додаєте ви
Cloud Messaging	Push-токен, пов’язаний з ідентифікатором встановлення застосунку; модель пристрою, мова, часовий пояс, версія ОС, ідентифікатор і версія застосунку
Authentication	Ідентифікатори, які він генерує, а також адреси електронної пошти, номери телефонів і відображувані імена від постачальників входу, які ви вмикаєте
Performance Monitoring	Показники продуктивності, як-от час запуску та мережеві затримки, інформація про пристрій і ОС, IP-адреса для географічної сегментації
Remote Config	Код країни та мови, часовий пояс, версія ОС, ідентифікатори застосунку та bundle

Якщо ви користуєтеся Crashlytics, прочитайте цю таблицю двічі: останній стовпець частково залежить від вас. Власні ключі та ідентифікатори користувачів, які ви додаєте до звітів про збої, — це дані, які ви вирішили надсилати, і вони мають бути у вашій політиці вашими власними словами.

Інші постачальники з опублікованими розкриттями, до яких варто звертатися напряму: рекламні мережі (AdMob, AppLovin, Unity, ironSource), інструменти атрибуції (AppsFlyer, Adjust), звіти про помилки (Sentry, Bugsnag), покупки (RevenueCat, Adapty) і постачальники автентифікації.

Крок 3 — коли постачальник нічого не публікує

Таке трапляється, особливо з меншими бібліотеками. Тоді:

• Прочитайте мережевий трафік. Пропустіть застосунок через проксі й подивіться, що надсилає SDK. Це єдиний метод, з яким не посперечаєшся, і він вирішує питання за пів дня.
• Прочитайте вихідний код, якщо він відкритий.
• Запитайте постачальника письмово і збережіть відповідь.
• Подумайте про те, щоб його прибрати. Залежність, щодо поводження з даними якої ніхто не хоче нічого заявити, — це ризик, який ви несете заради чужої зручності.

Крок 4 — перетворіть список на три документи

Один список, три подання, у такому порядку:

1. Політика конфіденційності — категорії, цілі, названі сторонні сервіси, строки зберігання, контакти.
2. Форма Data safety у Play Console — ті самі факти у вигляді прапорців.
3. App Privacy в App Store Connect — знову ті самі факти, у категоріях Apple.

Заповнюйте їх зі списку, ніколи не один з одного. Коли два з них розходяться, магазин вірить SDK: Google Play зазначає, що “when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action” (коли Google дізнається про розбіжність між поведінкою вашого застосунку та вашою декларацією, ми можемо вжити відповідних заходів, зокрема примусових).

Як підтримувати актуальність

Подія, яка робить недійсними всі три, завжди одна й та сама: змінилася залежність. Додайте один рядок до свого чекліста релізу — чи змінилася в цьому релізі якась залежність? якщо так, перевірте політику й обидві форми ще раз, — бо обидва магазини вимагають, щоб вони залишалися точними, а не лише були точними на момент запуску.

Що тут робить AppFoyer

Саме цей метод автоматизує наш агент. Спрямуйте агента для програмування на репозиторій, і він прочитає ці файли залежностей, зіставить знайдене з картою відомих SDK і складе чернетку політики конфіденційності з назвами знайдених сторонніх сервісів, — указуючи файл і рядок, звідки взято кожен факт, щоб ви могли його перевірити, а не просто вірити. Без агента ті самі питання ставить коротка форма.

Результат — чернетка, яку ви переглядаєте. Він не бачить бібліотеки, якої не розпізнає, і ніколи нічого не публікує без вашого натискання.

Офіційні джерела

• Конфіденційність і безпека у Firebase та Збір даних для App Store — Google. Таблицю вище взято з цих сторінок; авторитетне джерело — вони, а не ця сторінка.
• Надання інформації для розділу Data safety в Google Play — Довідка Google Play Console
• Відомості про конфіденційність застосунку в App Store — Apple