Para manter a privacidade e a segurança dos dados, o serviço de agregação usa uma estrutura compatível com a privacidade diferencial (PD). Ferramentas e mecanismos são projetados para quantificar e limitar a quantidade de informações reveladas por um usuário individual. Vamos discutir algumas dessas proteções de privacidade.
Ruído adicionado aos relatórios de resumo
Quando as adtechs agrupam relatórios agregáveis, o serviço de agregação cria um relatório de resumo. O relatório de resumo é um agregado de todas as contribuições de todas as chaves de domínio predefinidas com ruído estatístico adicionado.
O ruído adicionado aos relatórios não depende do número de relatórios agregados, dos valores de relatórios individuais ou dos valores de relatórios agregados.
O ruído é extraído de uma versão discreta da distribuição de Laplace dimensionada para o orçamento de contribuição (sensibilidade L1) que é aplicado pelo cliente dependente da API de medição correspondente e do parâmetro de privacidade epsilon. Leia mais sobre ruído.
Limite de contribuição
Dependendo das APIs do cliente de medição (API Attribution Reporting ou API Private Aggregation) usadas, o número de contribuições transmitidas em uma chamada é vinculado a um limite de limite de contribuição específico para controlar a sensibilidade do relatório resumido.
Para entender melhor os orçamentos de contribuição por API, consulte as seções a seguir de cada API:
Regra "Nenhuma cópia"
A regra determina que um relatório agregável, identificado exclusivamente por report_id, só pode aparecer uma vez em um único lote. Se um relatório agregável aparecer mais de uma vez por lote, o primeiro será incluído na agregação, e os relatórios subsequentes com o mesmo report_id serão descartados. O lote será concluído.
A regra também determina que o mesmo relatório não pode aparecer em mais de um lote. Se um relatório já tiver sido agrupado em um lote anterior, ele não poderá ser incluído em um lote posterior. O lote mais recente vai terminar com uma falha.
Sem essas regras, os invasores podem ter insights sobre o conteúdo de um lote específico manipulando o conteúdo dos lotes, incluindo cópias duplicadas de um relatório em um único lote ou vários lotes.
Outro conceito que o serviço de agregação introduz é o de lotes separados. Isso significa que dois ou mais lotes não podem ter relatórios com o mesmo ID compartilhado.
O ID compartilhado é uma combinação de dados coletados no campo shared_info de um relatório agregável. Confira um exemplo de campo shared_info abaixo. Podemos ver a API, version, attribution_destination (para o Relatório de atribuição), reporting_origin, scheduled_report_time e source_registration_time (para o Relatório de atribuição). Todos esses campos, exceto report_id, contribuem para o ID compartilhado.
"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"
}
Como source_registration_time é truncado por dia e scheduled_report_time é truncado por hora, haverá relatórios que vão compartilhar o mesmo ID compartilhado.
Veja como dois relatórios podem compartilhar o mesmo ID compartilhado. Confira o exemplo a seguir de campos de informações compartilhadas dos relatórios Relatório1 e Relatório2.
Ambos os relatórios têm a mesma API, versão, attribution_destination, reporting_origin e source_registration_time. Como report_id não faz parte do ID compartilhado, podemos ignorar essa diferença. A única outra diferença é o scheduled_report_time. Analisando mais a fundo, o scheduled_report_time do Relatório1 é February 19, 2024 9:08:10 PM, e o do Relatório2 é February 19, 2024 9:55:10 PM. Como scheduled_report_time está truncado com a hora, podemos ver que ambos os relatórios têm February 19, 2024 9 PM como scheduled_report_time. Como todos os campos são iguais, podemos confirmar que os dois relatórios têm o mesmo ID compartilhado.
Observe o scheduled_report_time.
| Informações compartilhadas do Report1 | Report2 Informações compartilhadas |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "attribution-reporting", | "API": "attribution-reporting", |
| "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_register_time": "0", | "source_register_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
Agora que está confirmado que os dois relatórios têm o mesmo ID compartilhado, ambos precisarão ser incluídos no mesmo lote.
Se o Relatório1 for agrupado em um lote anterior e o Relatório2 for processado em um lote subsequente, o lote com o Relatório2 vai falhar com um erro PRIVACY_BUDGET_EXHAUSTED. Se isso acontecer, remova os relatórios com o ID compartilhado que foram agrupados em lotes anteriores e tente de novo.
Para saber mais sobre lotes, acesse o guia de estratégia de lotes.
Declarar chaves de agregação previamente
Ao enviar um lote para o serviço de agregação, é necessário incluir os relatórios agregáveis recebidos da origem de relatórios e o arquivo de domínio de saída. O domínio de saída contém as chaves ou os buckets que serão recuperados dos relatórios agregáveis.
Do ponto de vista da privacidade, o ruído será adicionado a todas as chaves pré-declaradas no domínio de saída, mesmo quando nenhum relatório real corresponder a uma chave específica. A especificação do domínio de saída protege contra um ataque em que a presença de uma chave na saída revela algo sobre um único usuário / evento. Por exemplo, se você exibiu uma campanha para apenas um usuário, receber uma chave na saída (mesmo com ruído) revela que esse usuário fez uma conversão mais tarde. Ao especificar esse domínio com antecedência, podemos ter certeza de que ele não revela nada sobre as contribuições do usuário.
As chaves ou os buckets são chaves de 128 bits declaradas pela adtech na API Attribution Reporting ou na API Private Aggregation. As adtechs podem usar essas chaves para codificar as dimensões que querem acompanhar.
Somente as chaves predeclaradas serão consideradas para agregação e incluídas no relatório de resumo. Os valores agregados dos buckets no relatório de resumo vão ter ruído estatístico adicionado, que será refletido no relatório de resumo criado.
Essencialmente, se uma chave de agregação for incluída no arquivo do domínio de saída e não localizada em nenhum relatório em lote, mesmo que o valor agregado seja zero, o relatório de resumo final provavelmente será diferente de zero por causa do ruído adicionado para preservar a privacidade.
No momento em que este artigo foi escrito, um recurso chamado key-discovery estava sendo considerado. A descoberta de chaves vai permitir que a adtech processe arquivos agregáveis sem o requisito de chaves pré-declaradas. No entanto, para preservar a privacidade no cenário informado anteriormente, outra etapa de limite vai ser realizada.