Чтобы обеспечить конфиденциальность и безопасность данных, служба агрегации использует платформу, поддерживающую дифференциальную конфиденциальность (DP) . Инструменты и механизмы предназначены для количественной оценки и ограничения объема информации, раскрываемой отдельным пользователем. Давайте обсудим некоторые из этих мер защиты конфиденциальности.
Добавлен шум в сводные отчеты.
Когда рекламные технологии группируют агрегированные отчеты, служба агрегирования создает сводный отчет. Сводный отчет представляет собой совокупность всех вкладов всех предопределенных ключей домена с добавленным статистическим шумом.
Шум, добавляемый в отчеты, не зависит от количества агрегированных отчетов, значений отдельных отчетов или агрегированных значений отчетов.
Шум извлекается из дискретной версии распределения Лапласа, масштабированной до бюджета вклада (чувствительность L1 ), который применяется клиентом в зависимости от соответствующего API измерения и параметра конфиденциальности epsilon . Подробнее о шуме читайте.
Ограничение вклада
В зависимости от используемых клиентских API для измерения ( API Attribution Reporting или Private Aggregation API ), количество вкладов, передаваемых в вызове, привязано к определенному ограничению вклада, чтобы контролировать чувствительность сводного отчета.
Чтобы узнать больше о бюджетах взносов для каждого API, вы можете найти их в следующих разделах каждого API:
Правило «Нет дубликатов»
Правило гласит, что агрегированный отчет, уникально идентифицируемый report_id , может появляться только один раз в одном пакете. Если агрегируемый отчет появляется более одного раза в пакете, первый отчет будет включен в агрегирование, а последующие отчеты с тем же report_id будут отброшены. Пакет завершится успешно.
Правило также гласит, что один и тот же отчет не может появляться более чем в одном пакете. Если отчет уже был включен в предыдущий успешный пакет, этот же отчет не может быть включен в последний пакет. Последняя партия закончится неудачей.
Без этих правил злоумышленники могут получить представление о содержимом определенного пакета, манипулируя содержимым пакетов путем включения дублирующихся копий отчета в один или несколько пакетов.
Другая концепция, которую представляет Служба агрегирования, — это непересекающиеся пакеты. Это означает, что в двух или более пакетах не должно быть отчетов с общим идентификатором .
Общий идентификатор — это комбинация данных, собранных из shared_info агрегируемого отчета. Пример shared_info можно увидеть ниже. Мы можем видеть API, version , attribution_destination (для отчетов об атрибуции), reporting_origin , scheduled_report_time и source_registration_time (для отчетов об атрибуции). Все эти поля, за исключением report_id вносят вклад в общий идентификатор.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Поскольку source_registration_time усекается до дня, а scheduled_report_time усекается до часа, будут отчеты, которые будут использовать один и тот же общий идентификатор.
Посмотрите, как два отчета могут использовать один и тот же общий идентификатор. У нас есть следующий пример полей общей информации из Report1 и Report2 .
Оба отчета имеют одинаковый API, версию, attribution_destination , reporting_origin и source_registration_time . Поскольку report_id не является частью общего идентификатора, мы можем игнорировать эту разницу. Единственное другое отличие — это scheduled_report_time . Если мы посмотрим на это дальше, scheduled_report_time для Report1 — February 19, 2024 9:08:10 PM , а для Report2 — February 19, 2024 9:55:10 PM . Поскольку scheduled_report_time усекается до часа, мы видим, что в обоих отчетах в качестве scheduled_report_time указано February 19, 2024 9 PM . А поскольку все поля одинаковы, мы можем подтвердить, что оба отчета имеют один и тот же общий идентификатор.
Соблюдайте scheduled_report_time .
| Пожаловаться1 Общая информация | Общая информация Report2 |
|---|---|
| "shared_info": { | "shared_info": { |
| «API»: «отчетность по атрибуции», | «API»: «отчетность по атрибуции», |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "версия": "0.1" | "версия": "0.1" |
| } | } |
Теперь, когда подтверждено, что оба отчета имеют один и тот же общий идентификатор, оба отчета необходимо будет включить в один и тот же пакет.
Если Report1 будет объединен в ранее успешный пакет, а Report2 будет обработан в последующем пакете, пакет с Report2 завершится сбоем с ошибкой PRIVACY_BUDGET_EXHAUSTED . В этом случае удалите отчеты с общим идентификатором, которые были успешно объединены в предыдущие пакеты, и повторите попытку.
Чтобы узнать больше о пакетной обработке, посетите руководство по стратегии пакетной обработки .
Предварительное объявление ключей агрегации
При отправке пакета в службу агрегации необходимо включить как агрегируемые отчеты, полученные от источника отчетов, так и выходной файл домена. Выходной домен содержит ключи или сегменты, которые будут получены из агрегированных отчетов.
С точки зрения конфиденциальности ко всем ключам, заранее объявленным в выходном домене, будет добавлен шум, даже если ни один реальный отчет не соответствует конкретному ключу. Указание выходного домена защищает от атаки, при которой наличие ключа в выходных данных раскрывает что-то об отдельном пользователе/событии. Например, если вы показали кампанию только одному пользователю, получение ключа в выходных данных (даже с шумом) покажет, что этот пользователь позже совершил конверсию. Указав этот домен заранее, мы можем быть уверены, что он ничего не расскажет о вкладе пользователей.
Ключи или сегменты — это 128-битные ключи, объявленные рекламной технологией либо в API отчетов об атрибуции , либо в API частного агрегирования. Рекламные специалисты могут использовать эти ключи для кодирования измерений, которые они хотят отслеживать.
Только заранее объявленные ключи будут учитываться для агрегирования и включаться в сводный отчет. К агрегированным значениям сегментов в сводном отчете будет добавлен статистический шум, который будет отражен в созданном сводном отчете.
По сути, если ключ агрегирования включен в выходной файл домена и при этом не находится ни в одном пакетном отчете, даже если агрегированное значение равно нулю, окончательный сводный отчет, скорее всего, будет ненулевым из-за добавленного шума для сохранения конфиденциальности. .
Обратите внимание, что на момент написания этой статьи рассматривается функция, называемая обнаружением ключей . Обнаружение ключей позволит рекламным технологиям обрабатывать агрегируемые файлы без необходимости предварительно объявленных ключей, но для сохранения конфиденциальности в ранее заявленном сценарии будет выполнен дополнительный пороговый шаг.
,Чтобы обеспечить конфиденциальность и безопасность данных, служба агрегации использует платформу, поддерживающую дифференциальную конфиденциальность (DP) . Инструменты и механизмы предназначены для количественной оценки и ограничения объема информации, раскрываемой отдельным пользователем. Давайте обсудим некоторые из этих мер защиты конфиденциальности.
Добавлен шум в сводные отчеты.
Когда рекламные технологии группируют агрегированные отчеты, служба агрегирования создает сводный отчет. Сводный отчет представляет собой совокупность всех вкладов всех предопределенных ключей домена с добавленным статистическим шумом.
Шум, добавляемый в отчеты, не зависит от количества агрегированных отчетов, значений отдельных отчетов или агрегированных значений отчетов.
Шум извлекается из дискретной версии распределения Лапласа, масштабированной до бюджета вклада (чувствительность L1 ), который применяется клиентом в зависимости от соответствующего API измерения и параметра конфиденциальности epsilon . Подробнее о шуме читайте.
Ограничение вклада
В зависимости от используемых клиентских API для измерения ( API Attribution Reporting или Private Aggregation API ), количество вкладов, передаваемых в вызове, привязано к определенному ограничению вклада, чтобы контролировать чувствительность сводного отчета.
Чтобы узнать больше о бюджетах взносов для каждого API, вы можете найти их в следующих разделах каждого API:
Правило «Нет дубликатов»
Правило гласит, что агрегированный отчет, уникально идентифицируемый report_id , может появляться только один раз в одном пакете. Если агрегируемый отчет появляется более одного раза в пакете, первый отчет будет включен в агрегирование, а последующие отчеты с тем же report_id будут отброшены. Пакет завершится успешно.
Правило также гласит, что один и тот же отчет не может появляться более чем в одном пакете. Если отчет уже был включен в предыдущий успешный пакет, этот же отчет не может быть включен в последний пакет. Последняя партия закончится неудачей.
Без этих правил злоумышленники могут получить представление о содержимом определенного пакета, манипулируя содержимым пакетов путем включения дублирующихся копий отчета в один или несколько пакетов.
Другая концепция, которую представляет Служба агрегирования, — это непересекающиеся пакеты. Это означает, что в двух или более пакетах не должно быть отчетов с общим идентификатором .
Общий идентификатор — это комбинация данных, собранных из shared_info агрегируемого отчета. Пример shared_info можно увидеть ниже. Мы можем видеть API, version , attribution_destination (для отчетов об атрибуции), reporting_origin , scheduled_report_time и source_registration_time (для отчетов об атрибуции). Все эти поля, за исключением report_id вносят вклад в общий идентификатор.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Поскольку source_registration_time усекается до дня, а scheduled_report_time усекается до часа, будут отчеты, которые будут использовать один и тот же общий идентификатор.
Посмотрите, как два отчета могут использовать один и тот же общий идентификатор. У нас есть следующий пример полей общей информации из Report1 и Report2 .
Оба отчета имеют одинаковый API, версию, attribution_destination , reporting_origin и source_registration_time . Поскольку report_id не является частью общего идентификатора, мы можем игнорировать эту разницу. Единственное другое отличие — это scheduled_report_time . Если мы посмотрим на это дальше, scheduled_report_time для Report1 — February 19, 2024 9:08:10 PM , а для Report2 — February 19, 2024 9:55:10 PM . Поскольку scheduled_report_time усекается до часа, мы видим, что в обоих отчетах в качестве scheduled_report_time указано February 19, 2024 9 PM . А поскольку все поля одинаковы, мы можем подтвердить, что оба отчета имеют один и тот же общий идентификатор.
Соблюдайте scheduled_report_time .
| Пожаловаться1 Общая информация | Общая информация Report2 |
|---|---|
| "shared_info": { | "shared_info": { |
| «API»: «отчетность по атрибуции», | «API»: «отчетность по атрибуции», |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "версия": "0.1" | "версия": "0.1" |
| } | } |
Теперь, когда подтверждено, что оба отчета имеют один и тот же общий идентификатор, оба отчета необходимо будет включить в один и тот же пакет.
Если Report1 будет объединен в ранее успешный пакет, а Report2 будет обработан в последующем пакете, пакет с Report2 завершится сбоем с ошибкой PRIVACY_BUDGET_EXHAUSTED . В этом случае удалите отчеты с общим идентификатором, которые были успешно объединены в предыдущие пакеты, и повторите попытку.
Чтобы узнать больше о пакетной обработке, посетите руководство по стратегии пакетной обработки .
Предварительное объявление ключей агрегации
При отправке пакета в службу агрегации необходимо включить как агрегируемые отчеты, полученные от источника отчетов, так и выходной файл домена. Выходной домен содержит ключи или сегменты, которые будут получены из агрегированных отчетов.
С точки зрения конфиденциальности ко всем ключам, заранее объявленным в выходном домене, будет добавлен шум, даже если ни один реальный отчет не соответствует конкретному ключу. Указание выходного домена защищает от атаки, при которой наличие ключа в выходных данных раскрывает что-то об отдельном пользователе/событии. Например, если вы показали кампанию только одному пользователю, получение ключа в выходных данных (даже с шумом) покажет, что этот пользователь позже совершил конверсию. Указав этот домен заранее, мы можем быть уверены, что он ничего не расскажет о вкладе пользователей.
Ключи или сегменты — это 128-битные ключи, объявленные рекламной технологией либо в API отчетов об атрибуции , либо в API частного агрегирования. Рекламные специалисты могут использовать эти ключи для кодирования измерений, которые они хотят отслеживать.
Только заранее объявленные ключи будут учитываться для агрегирования и включаться в сводный отчет. К агрегированным значениям сегментов в сводном отчете будет добавлен статистический шум, который будет отражен в созданном сводном отчете.
По сути, если ключ агрегирования включен в выходной файл домена и при этом не находится ни в одном пакетном отчете, даже если агрегированное значение равно нулю, окончательный сводный отчет, скорее всего, будет ненулевым из-за добавленного шума для сохранения конфиденциальности. .
Обратите внимание, что на момент написания этой статьи рассматривается функция, называемая обнаружением ключей . Обнаружение ключей позволит рекламным технологиям обрабатывать агрегируемые файлы без необходимости предварительно объявленных ключей, но для сохранения конфиденциальности в ранее заявленном сценарии будет выполнен дополнительный пороговый шаг.
,Чтобы обеспечить конфиденциальность и безопасность данных, служба агрегации использует платформу, поддерживающую дифференциальную конфиденциальность (DP) . Инструменты и механизмы предназначены для количественной оценки и ограничения объема информации, раскрываемой отдельным пользователем. Давайте обсудим некоторые из этих мер защиты конфиденциальности.
Добавлен шум в сводные отчеты.
Когда рекламные технологии группируют агрегированные отчеты, служба агрегирования создает сводный отчет. Сводный отчет представляет собой совокупность всех вкладов всех предопределенных ключей домена с добавленным статистическим шумом.
Шум, добавляемый в отчеты, не зависит от количества агрегированных отчетов, значений отдельных отчетов или агрегированных значений отчетов.
Шум извлекается из дискретной версии распределения Лапласа, масштабированной до бюджета вклада (чувствительность L1 ), который применяется клиентом в зависимости от соответствующего API измерения и параметра конфиденциальности epsilon . Подробнее о шуме читайте.
Ограничение вклада
В зависимости от используемых клиентских API для измерения ( API Attribution Reporting или Private Aggregation API ), количество вкладов, передаваемых в вызове, привязано к определенному ограничению вклада, чтобы контролировать чувствительность сводного отчета.
Чтобы узнать больше о бюджетах взносов для каждого API, вы можете найти их в следующих разделах каждого API:
Правило «Нет дубликатов»
Правило гласит, что агрегированный отчет, уникально идентифицируемый report_id , может появляться только один раз в одном пакете. Если агрегируемый отчет появляется более одного раза в пакете, первый отчет будет включен в агрегирование, а последующие отчеты с тем же report_id будут отброшены. Пакет завершится успешно.
Правило также гласит, что один и тот же отчет не может появляться более чем в одном пакете. Если отчет уже был включен в предыдущий успешный пакет, этот же отчет не может быть включен в последний пакет. Последняя партия закончится неудачей.
Без этих правил злоумышленники могут получить представление о содержимом определенного пакета, манипулируя содержимым пакетов путем включения дублирующихся копий отчета в один или несколько пакетов.
Другая концепция, которую представляет Служба агрегирования, — это непересекающиеся пакеты. Это означает, что в двух или более пакетах не должно быть отчетов с общим идентификатором .
Общий идентификатор — это комбинация данных, собранных из shared_info агрегируемого отчета. Пример shared_info можно увидеть ниже. Мы можем видеть API, version , attribution_destination (для отчетов об атрибуции), reporting_origin , scheduled_report_time и source_registration_time (для отчетов об атрибуции). Все эти поля, за исключением report_id вносят вклад в общий идентификатор.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Поскольку source_registration_time усекается до дня, а scheduled_report_time усекается до часа, будут отчеты, которые будут использовать один и тот же общий идентификатор.
Посмотрите, как два отчета могут использовать один и тот же общий идентификатор. У нас есть следующий пример полей общей информации из Report1 и Report2 .
Оба отчета имеют одинаковый API, версию, attribution_destination , reporting_origin и source_registration_time . Поскольку report_id не является частью общего идентификатора, мы можем игнорировать эту разницу. Единственное другое отличие — это scheduled_report_time . Если мы посмотрим на это дальше, scheduled_report_time для Report1 — February 19, 2024 9:08:10 PM , а для Report2 — February 19, 2024 9:55:10 PM . Поскольку scheduled_report_time усекается до часа, мы видим, что в обоих отчетах в качестве scheduled_report_time указано February 19, 2024 9 PM . А поскольку все поля одинаковы, мы можем подтвердить, что оба отчета имеют один и тот же общий идентификатор.
Соблюдайте scheduled_report_time .
| Пожаловаться1 Общая информация | Общая информация Report2 |
|---|---|
| "shared_info": { | "shared_info": { |
| «API»: «отчетность по атрибуции», | «API»: «отчетность по атрибуции», |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "версия": "0.1" | "версия": "0.1" |
| } | } |
Теперь, когда подтверждено, что оба отчета имеют один и тот же общий идентификатор, оба отчета необходимо будет включить в один и тот же пакет.
Если Report1 будет объединен в ранее успешный пакет, а Report2 будет обработан в последующем пакете, пакет с Report2 завершится сбоем с ошибкой PRIVACY_BUDGET_EXHAUSTED . В этом случае удалите отчеты с общим идентификатором, которые были успешно объединены в предыдущие пакеты, и повторите попытку.
Чтобы узнать больше о пакетной обработке, посетите руководство по стратегии пакетной обработки .
Предварительное объявление ключей агрегации
При отправке пакета в службу агрегации необходимо включить как агрегируемые отчеты, полученные от источника отчетов, так и выходной файл домена. Выходной домен содержит ключи или сегменты, которые будут получены из агрегированных отчетов.
С точки зрения конфиденциальности ко всем ключам, заранее объявленным в выходном домене, будет добавлен шум, даже если ни один реальный отчет не соответствует конкретному ключу. Указание выходного домена защищает от атаки, при которой наличие ключа в выходных данных раскрывает что-то об отдельном пользователе/событии. Например, если вы показали кампанию только одному пользователю, получение ключа в выходных данных (даже с шумом) покажет, что этот пользователь позже совершил конверсию. Указав этот домен заранее, мы можем быть уверены, что он ничего не расскажет о вкладе пользователей.
Ключи или сегменты — это 128-битные ключи, объявленные рекламной технологией либо в API отчетов об атрибуции , либо в API частного агрегирования. Рекламные специалисты могут использовать эти ключи для кодирования измерений, которые они хотят отслеживать.
Только заранее объявленные ключи будут учитываться для агрегирования и включаться в сводный отчет. К агрегированным значениям сегментов в сводном отчете будет добавлен статистический шум, который будет отражен в созданном сводном отчете.
По сути, если ключ агрегирования включен в выходной файл домена и при этом не находится ни в одном пакетном отчете, даже если агрегированное значение равно нулю, окончательный сводный отчет, скорее всего, будет ненулевым из-за добавленного шума для сохранения конфиденциальности. .
Обратите внимание, что на момент написания этой статьи рассматривается функция, называемая обнаружением ключей . Обнаружение ключей позволит рекламным технологиям обрабатывать агрегируемые файлы без необходимости предварительно объявленных ключей, но для сохранения конфиденциальности в ранее заявленном сценарии будет выполнен дополнительный пороговый шаг.