Обзор службы агрегации

Разверните эту службу и управляйте ею для создания сводных отчетов для API отчетов об атрибуции или API частного агрегирования.

Разверните службу агрегирования и управляйте ею для обработки агрегированных отчетов из API отчетов об атрибуции или API частного агрегирования для создания сводного отчета .

Статус реализации

В пояснении изложены ключевые термины , полезные для понимания Службы агрегирования.

Доступность

建议 状态
Attribution Reporting API 和 Private Aggregation API 为 Amazon Web Services (AWS) 提供的汇总服务支持
说明
可用
Attribution Reporting API 和 Private Aggregation API 为 Google Cloud 提供的汇总服务支持
说明
推出 Beta 版
注册汇总服务网站以及将网站映射到云账号(AWS 或 GCP)
GitHub 上的常见问题解答
可用
汇总服务的 epsilon 值将保持在 64 这一范围内,以便于针对不同参数进行实验和提供反馈。
提交 ARA epsilon 反馈
提交 PAA epsilon 反馈
可用。在 epsilon 范围值更新之前,我们会提前向生态系统发出通知。
针对汇总服务查询更灵活的贡献过滤
说明
预计 2024 年第 2 季度
灾难恢复后的预算恢复流程(错误、配置错误等)
GitHub 问题
预计 2024 年第 2 季度
Accenture 是 AWS 的协调员之一
开发者博客
可用
担任 Google Cloud 协调员之一的独立方
开发者博客
预计 2024 年第 3 季度

Безопасная обработка данных

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

Код TEE — единственное место в Службе агрегирования, имеющее доступ к необработанным отчетам. Этот код будет проверяться исследователями безопасности, защитниками конфиденциальности и специалистами по рекламе. Чтобы подтвердить, что TEE использует именно утвержденное программное обеспечение и что данные остаются в безопасности, координатор проводит аттестацию.

Агрегированные отчеты собираются, группируются и отправляются в TEE для преобразования в окончательный сводный отчет.
Агрегированные отчеты собираются, группируются и отправляются в службу агрегирования, работающую на TEE. Среда службы агрегации принадлежит и управляется той же стороной, которая собирает данные.

Координатор аттестации ТЭЭ

Координатор – лицо, отвечающее за ключевое управление и учет сводных отчетов.

У координатора есть несколько обязанностей:

  • Ведите список разрешенных бинарных изображений. Эти изображения представляют собой криптографические хэши сборок программного обеспечения Службы агрегирования, которые Google периодически выпускает. Это будет воспроизводимо, чтобы любая сторона могла убедиться, что образы идентичны сборкам Службы агрегации.
  • Используйте систему управления ключами. Ключи шифрования необходимы Chrome на устройстве пользователя для шифрования сводных отчетов. Ключи расшифровки необходимы для подтверждения соответствия кода службы агрегации двоичным изображениям.
  • Отслеживайте агрегированные отчеты, чтобы предотвратить повторное использование при агрегировании сводных отчетов, поскольку повторное использование может раскрыть личную информацию (PII).

Правило «Нет дубликатов»

Чтобы получить представление о содержимом конкретного сводного отчета, злоумышленник может сделать несколько копий отчета и включить эти копии в один или несколько пакетов. По этой причине Служба агрегации применяет правило «нет дубликатов»:

  • В пакете . Агрегированный отчет может появиться в пакете только один раз.
  • По пакетам . Агрегированные отчеты не могут появляться более чем в одном пакете или входить в более чем один сводный отчет.

Для этого браузер присваивает каждому агрегированному отчету общий идентификатор. Браузер генерирует общий идентификатор на основе нескольких точек данных, включая: версию API, источник отчетов, целевой сайт, время регистрации источника и запланированное время отчета. Эти данные поступают из shared_info в отчете.

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

При выполнении отладки правило «без дубликатов» не применяется к пакетам. Другими словами, отчеты из предыдущих пакетов могут появиться в ходе отладки. Однако правило по-прежнему применяется внутри пакета. Это позволяет вам экспериментировать с сервисом и различными стратегиями пакетной обработки, не ограничивая будущую обработку в производственной среде.

Шум и масштабирование

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

Хотя вы не можете напрямую контролировать способы добавления шума, вы можете влиять на влияние шума на данные измерений.

Шум является постоянным, независимо от совокупного значения.

Значение шума случайным образом извлекается из распределения вероятностей Лапласа , и распределение одинаковое независимо от объема данных, собранных в агрегированных отчетах. Чем больше данных вы соберете, тем меньшее влияние шум окажет на результаты сводного отчета. Вы можете умножить данные агрегированного отчета на коэффициент масштабирования, чтобы уменьшить влияние шума.

Чтобы понять, как добавляется шум, ваши элементы управления и влияние на ваши отчеты, обратитесь к разделам «Бюджет вклада» и «Масштабирование до бюджета вклада» в разделе «Работа с шумом» .

Создание сводных отчетов

Создание сводного отчета зависит от использования вами API. Узнайте больше о создании сводных отчетов для API частного агрегирования и API отчетов по атрибуции .

Тестирование службы агрегации

Мы рекомендуем прочитать соответствующее руководство для каждого тестируемого API:

Чтобы протестировать сервис агрегации на AWS, ознакомьтесь с этими инструкциями .

Также доступен локальный инструмент тестирования для обработки агрегированных отчетов для отчетов по атрибуции и API частного агрегирования.

Платформа нагрузочного тестирования служб агрегации предоставляет предлагаемую среду тестирования.

Привлекайте и делитесь отзывами

Служба агрегации — это ключевой элемент API-интерфейсов измерения Privacy Sandbox. Как и другие API Privacy Sandbox, это документировано и публично обсуждается на GitHub.