Riscos imediatos da fraude no iOS 14 e na SKAdNetwork

Em meio à confusão e às incertezas sobre a SKAdNetwork, uma questão ainda não foi respondida – existe o risco da fraude de atribuição com o novo protocolo de atribuição da Apple?

A Apple introduziu diversos mecanismos antifraude que têm como objetivo impedir diferentes tipos de manipulações de atribuição. Todas as transações que correspondem a um evento da SKAdNetwork são assinadas de maneira criptografada e verificadas pela Apple para comprovar que o postback está ligado a um evento de conversão reconhecido pela Apple.

O postback inclui um ID exclusivo de transação (um identificador único para uma transação, como uma compra ou um re-download) para a detecção de repetições de eventos de conversão válidos.

Os mecanismos acima têm o intuito de validar a autenticidade do postback, mas não validam a autenticidade da interação do usuário (impressão ou clique).

Esses mecanismos podem ser contornados? E os fraudadores conseguem encontrar formas criativas de contornar essas limitações sem serem notados?

Para responder a essas perguntas, vamos analisar os possíveis cenários de fraude de atribuição na SKAdNetwork:

1. Manipulação de um postback antes que ele chegue ao anunciante.
   A assinatura e o ID de transação mencionados acima têm como objetivo evitar casos como esse. No entanto, tanto a assinatura como o ID de transação podem ser falsificados.
   Exemplo: O valor de conversão não é parte da assinatura, e o ID de transação pode ser usado mais de uma vez (na esperança de que quem o recebe não armazene todo o histórico de IDs de transação para sempre).
   A única solução real para isso é o envio do postback para o seu verdadeiro proprietário – o anunciante.
2. Manipulação da Apple a partir de uma atribuição errada a nível do dispositivo.
   Os exemplos que vamos citar abaixo tratam de casos como esse.

Podemos afirmar que o protocolo de atribuição da SKAdNetwork oferece dados limitados tanto para mensuração como para otimização, ou seja, apenas o aplicativo de origem e o ID da campanha.

Os indicativos de tempo de interação do dispositivo também não estão disponíveis. Esses indicativos são essenciais para a mensuração de intervalos de tempo entre os principais eventos – principalmente o tempo de clique e o tempo de instalação. Sem esse indicativos, tendências normais de comportamento do usuário (que são muito difíceis de serem emuladas em escala por bots) não podem ser definidas – o que elimina os indicativos de comportamento anormal.

Mas, ao tentar identificar possíveis falhas que podem ser exploradas pela fraude, abordamos o problema a partir de outra perspectiva.

Imitar um possível comportamento fraudulento pode nos ajudar a descobrir o caminho de manipulação do fraudador e, em troca, nos permite analisar e identificar potenciais fraquezas enquanto tentamos proteger nossos anunciantes dessas fraudes.

Criação de instalações falsas

Qualquer um que tenha um ou mais dispositivos pode clicar, baixar, engajar com aplicativos e reiniciar seu ID de dispositivo para fazer com que pareça um dispositivo diferente. Isso é, em resumo, uma device farm. Assim que uma solução VPN é introduzida, o endereço de IP do fraudador também pode ser alterado ou ocultado.

Isso pode ser feito na SKAdNetwork?

A resposta curta é: sim.

A SKAdNetwork pode ter eliminado o uso do IDFA, mas o ID de conta de um usuário da Apple ainda é utilizado para fins de mensuração.

Reiniciar o ID de conta da Apple é algo que pode ser feito programaticamente através de diversas ferramentas e serviços, assim, a criação de inúmeros usuários falsos a partir de um único dispositivo é algo muito possível.

Além disso, ao usar um dispositivo desbloqueado, você também elimina a necessidade de usar um aplicativo de publisher, pois pode gerar cliques falsos sem ele.

O protocolo SK registra todos os cliques em um banco de dados interno do dispositivo. Com o conhecimento técnico certo, pode-se facilmente criar um ambiente semelhante a um aplicativo falso que se conecta ao servidor da ad network para obter sua assinatura exclusiva e detalhes de campanha.

Esse ambiente de aplicativo falso pode inserir os detalhes de clique na base de dados do SK – fazendo com que o iOS pense que o clique foi feito em um aplicativo real.

Dispositivos desbloqueados também oferecem aos fraudadores a capacidade de controlar programaticamente o timer do SK através desse ambiente de aplicativo falso, o que significa que os postbacks podem ser enviados dentro de 20 ou 30 segundos, e não dentro da janela esperada de 24 horas.

Como essa manipulação do timer ocorre no dispositivo, no qual não há dados de tempo do dispositivo com o qual trabalhar, o anunciante não consegue dizer se o tempo foi adulterado.

As manipulações acima mostram que device farms podem operar em escala, sem precisar de nenhuma interação humana contínua.

Inundando os portões

O flooding de cliques tem como objetivo “inundar” o anunciante com uma onda de relatórios de cliques falsos, na esperança de que um desses cliques seja de alguma forma associado a uma instalação orgânica (quando um usuário baixa o aplicativo por conta própria, sem interagir com um anúncio) ou a uma instalação não-orgânica (um clique que foi artificialmente inserido após o usuários visualizar um anúncio de outro publisher).

A SKAdNetwork atribui crédito por instalações que ocorreram através da Apple App Store. Quando um usuário visualiza um anúncio no aplicativo de um publisher e clica nele, a página do aplicativo dentro da store aparecerá no aplicativo do publisher.

Essa visualização da página da App Store é registrada como um clique pelo protocolo SK.

Quando o usuário baixa o aplicativo da página da App Store e o inicia, a instalação será atribuída ao aplicativo do publisher.

Como esse fluxo pode ser manipulado?

Nossos testes mostram que os publishers podem simplesmente acionar a página da App Store do anunciante para que ela apareça sem que seja necessário um clique de um usuário no anúncio, criando um relatório de cliques falso.

A página da App Store pode ser repetidamente acionada sem um único clique sobre o anúncio, criando um efeito parecido ao do flooding de cliques. Isso é muito semelhante a manipulações comuns, nas quais as impressões dos anúncios são falsamente relatadas como cliques.

Como isso é afetado pela recente adição de visualização completa da Apple?

Com a mais recente adição de visualização sobre o protocolo SK da Apple, o flooding pode se tornar ainda mais fácil. Teoricamente, um fluxo de cliques pode ser validado pela Apple através da verificação do fluxo completo (clique → App Store → instalação).

No entanto, com a atribuição de visualização, que elimina o clique da equação, essa validação do fluxo não pode ocorrer. Qualquer um pode, teoricamente, reivindicar impressões, na expectativa de que as instalações sejam atribuídas.

Com a SKAdNetwork, publishers podem determinar os tempos de início e fim de uma impressão. Embora a declaração oficial da Apple diga que esse período de tempo deve ser superior a 3 segundos, isso não se aplica de forma alguma. Isso significa que os publishers têm liberdade para gerar relatórios de impressão falsos e um flooding de impressões, aproveitando os fluxos de visualização.

Uma maneira ainda mais simples de tirar proveito da atribuição de visualização é o uso do acesso à base de dados do dispositivo mencionado acima, com a inserção de relatórios de impressão falsos – certificando-se de que o publisher seja sempre o único a oferecer a última impressão.

Isso abre a possibilidade para a criação de flooding de cliques ou flooding de impressões, acionando programaticamente relatórios de cliques ou de impressões.

Embora o pop up da página da App Store busque iniciar uma instalação real do usuário que visualiza a página, todas as outras manipulações buscam apenas roubar o crédito por uma instalação orgânica que não se relaciona a uma exposição a um anúncio ou a uma página de aplicativo.

Nossos testes mostram que até mesmo instalações que ocorrem dentro de 24 horas após o relatório de cliques recebem crédito pela atribuição na SKAdNetwork. Além disso, a documentação oficial da Apple menciona uma janela de lookback de 30 dias, aumentando a probabilidade de tal esquema obter sucesso.

Aplicativos de fontes maliciosas, como descrito acima, ainda podem ser identificados e bloqueados pelo Protect360 (a solução de proteção contra fraudes da AppsFlyer), com o uso de diversos métodos de detecção. O comportamento descrito acima ainda se desviará das tendências de comportamento padrão quando visto a partir de uma escala de base de dados ampla o suficiente, mesmo dentro da natureza agregada da SKAdNetwork.

Estamos apenas começando

Estamos entrando em uma nova era da mensuração de atribuição e, por isso, é muito provável que estejamos apenas olhando para a ponta do iceberg em termos de possíveis manipulações e métodos de fraude.

A AppsFlyer está trabalhando em conjunto com a Apple e o ecossistema como um todo para tratar desses problemas à medida que eles ocorrem, além de trabalhar duro para manter um ambiente livre de fraudes nessa nova era da atribuição.

Como pesquisadores da fraude, é nosso trabalho continuar a analisar mais detalhadamente possíveis áreas de fraqueza e identificar como elas podem ser exploradas, para que possamos continuar a nos adaptar e proteger nossos clientes.

Fique atento para mais novidades.