AdGuard всегда пристально следит за новостями отрасли, которые затрагивают вопросы конфиденциальности. Недавно Google представил Privacy Sandbox, который во многом определит будущее конфиденциальности на устройствах Android. И мы, безусловно, должны это прокомментировать. В этой статье Андрей Мешков, CTO и соучредитель AdGuard, даёт краткий обзор ситуации. А позже выйдет большой исследовательский материал по данной теме. Следите за нашим блогом и социальными сетями, чтобы не пропустить её выход.

Google представил Privacy Sandbox — новый пакет технологий, внедрение которого в теории должно сделать устройства Android лучше с точки зрения конфиденциальности. В то же время Google дал понять, что хочет оставить рекламодателям как можно больше возможностей. Соблюсти такой баланс очень сложно. Удалось ли им угодить всем сторонам?

Privacy Sandbox включает в себя несколько отдельных технологий. Вы можете самостоятельно изучить этот вопрос, но я постараюсь описать здесь ключевые моменты каждой из новых инициатив.

SDK Runtime

SDK Runtime (Software Development Kit, набор средств разработки ПО) создаёт специальную среду для запуска SDK сторонних разработчиков. Это чрезвычайно полезная технология.

Как это работало раньше

Раньше этот момент никак не регулировался: разработчики вставляли сторонние библиотеки в свои приложения (например, Facebook и Google), и эти библиотеки наследовали все разрешения, которые были предоставлены самому приложению. Например, если у приложения был доступ к местоположению устройства, он появлялся и у библиотеки. Излишне говорить, что поставщики библиотек без стеснения злоупотребляли этой схемой, собирая всевозможные данные. И это была не единственная неприятность: в случае возникновения проблем с библиотекой приложение тоже могло пострадать ([1], [2]).

На этой диаграмме изображена работа приложения до внедрения SDK Runtime. Здесь мы видим, что код вызова SDK, а также SDK, которые получают вызовы от этого кода, находятся внутри процесса приложения.

Что предлагает Google

С введением SDK Runtime сторонние библиотеки будут работать в отдельной виртуальной «песочнице» (отсюда и название пакета технологий Privacy Sandbox). Её работу можно будет контролировать и регулировать. Разработчик сможет управлять правами доступа для каждой библиотеки, в том числе ограничивать их.

На этой диаграмме показано, что активный процесс взаимодействует только с интерфейсами SDK, в то время как сами SDK библиотек работают внутри выделенного процесса SDK Runtime.

Поскольку все эти библиотеки будут работать в «песочнице», отделённой от остальных процессов приложения, приложение не прекратит работу, даже если с одной из них что-то пойдёт не так.

И последнее, но не менее важное: сторонние библиотеки будут распространяться через специальный магазин, который предположительно будет иметь свои собственные правила проверки.

Подробнее об SDK Runtime:
https://developer.android.com/design-for-safety/ads/sdk-runtime

Topics

Это та же технология, которую Google собирается внедрить в Chrome. Основная идея Topics заключается в том, что устройство само будет отслеживать, какими приложениями пользуется его владелец. На основе этих данных оно будет рассчитывать пять тем, которые больше всего интересовали пользователя на этой неделе, и так каждую неделю.

Приложения смогут получить доступ к некоторым из этих данных, причём разные приложения будут получать разные данные. По мнению Google, это позволит свести к минимуму риск использования Topics для создания «цифрового отпечатка» устройства пользователя.

Но давайте рассмотрим ситуацию на примере:

1. У вас на телефоне установлено несколько приложений, которыми вы регулярно пользуетесь: Facebook, WhatsApp, Instagram и т.д.
2. Каждое из них получает некоторую часть ваших тем за неделю.
3. Приложения собирают эту информацию и используют её для пополнения вашего онлайн-профиля.
4. Каждую неделю ваш профиль растёт и пополняется данными.

Мне неясно, почему Google решил, что делиться моими интересами без моего согласия — это нормально. Не заблуждайтесь, техногиганты, такие как Facebook/Meta, не будут использовать эту информацию единожды и выбрасывать из памяти. Они будут агрегировать её, объединять с другими данными и так далее.

И это ещё не всё. Многие приложения используют SDK, разработанные узким кругом компаний (вы угадали, Meta — одна из них). Эти компании будут получать потоки информации о вас от десятков различных приложений и запросто смогут составить ваш максимально подробный профиль, содержащий все мыслимые данные.

Читайте больше о Topics для Android:
https://developer.android.com/design-for-safety/ads/topics

FLEDGE на Android

FLEDGE — это механизм, предназначенный для локального использования на устройстве. Скоро вы увидите, что с точки зрения безопасности данных он выгодно отличается от существующих альтернатив.

Как это работало раньше

В настоящее время ретаргетинг рекламы основывается главным образом на списках «аудиторий», которые загружают те, кто размещает рекламу. Списки часто состоят из идентификаторов пользователей, а иногда и прямо из электронных адресов. Это даёт рекламщикам возможность показывать людям из списка те объявления, которые они считают для них релевантными.

Что предлагает Google

Когда FLEDGE вступит в полную силу, приложения будут сами создавать такие списки с помощью специального API (т.е. интерфейса прикладного программирования). Ключевое отличие в том, что эти списки будут храниться локально на устройстве. Рекламные сети будут знать названия этих списков, и они будут размещать объявления, предназначенные для конкретных списков. Реклама для показа пользователю будет выбираться только на устройстве, на основе списков (хранящихся на том же устройстве) и рекламы, загруженной рекламными сетями.

Подробнее о FLEDGE:
https://developer.android.com/design-for-safety/ads/fledge

Attribution Reporting

Это технология учёта кликов и измерения конверсии. Рекламодатели хотят знать, как работают их объявления, и Google предлагает выполнять все измерения прямо на устройстве. SDK рекламных сетей смогут запрашивать агрегированный отчёт, но он будет предоставляться с определённой задержкой. Задержка очень важна, так как она значительно усложняет потенциальные попытки идентифицировать пользователя. И весь механизм щедро сдобрен шифрованием и дополнительными проверками.

Общая схема работы API Attribution Reporting выглядит довольно сложной. Чтобы лучше понять эту тему, откройте ссылку, которую мы разместили ниже.

Читать подробнее об отчётах:
https://developer.android.com/design-for-safety/ads/attribution

Выводы

В целом, все эти инициативы, кроме Topics, улучшают конфиденциальность пользователей в контексте рынка рекламы. Но с одним очень важным условием — должны использоваться ТОЛЬКО эти механизмы.

Что касается Topics, то эта инициатива отражает совершенно понятное желание сохранить возможность использовать информацию об интересах пользователей в целях таргетинга. Но эта технология ещё больше увеличивает объём этой информации, вместо того чтобы уменьшать его.

Но даже от хорошего остаётся горькое послевкусие: де-факто Google станет единственным лицом, контролирующим рекламу, которую пользователи видят на своих устройствах Android. Отчасти это было верно и раньше, но только в рамках собственной рекламной сети Google. Теперь они намерены напрямую влиять и на все остальные рекламные сети, а мы знаем, что монополии крайне редко сулят потребителю выгоду. Мы вроде бы знаем, что будет происходить на наших смартфонах сейчас, но нет никакой гарантии, что так будет и дальше.

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