SDK iOS: Otimizando para ITP do Safari e Prevenção de Rastreamento (PT-BR)

Adote o Contexto PrimárioO ITP do Safari restringe severamente os cookies de terceiros. Projete seu SDK iOS para operar em um contexto primário sempre que possível, aproveitando soluções server-side ou integração direta.

Priorize Identificadores que Preservam a PrivacidadeAbandone os identificadores persistentes e cross-site. Concentre-se em identificadores efêmeros ou consentidos pelo usuário, respeitando as configurações de privacidade do usuário e a estrutura de Transparência de Rastreamento de Apps da Apple.

Implemente Fallbacks RobustosAntecipe que alguns pontos de dados ou mecanismos de rastreamento podem ser bloqueados. Construa seu SDK com degradação graciosa e estratégias de fallback para manter a funcionalidade principal mesmo quando o ITP estiver ativo.

Mantenha-se Atualizado com as Políticas da AppleO ITP e as políticas de privacidade são dinâmicos. Revise regularmente a documentação do desenvolvedor da Apple e as atualizações de privacidade para garantir que seu SDK permaneça compatível e eficaz.

A Prevenção Inteligente de Rastreamento (ITP) do Safari remodelou fundamentalmente o cenário do rastreamento web, particularmente para desenvolvedores que dependem de cookies de terceiros e identificadores persistentes. Para SDKs iOS, isso apresenta um conjunto único de desafios, especialmente ao integrar com web views ou lidar com comunicação cross-domain. O compromisso contínuo da Apple com a privacidade do usuário, reforçado por recursos como a Transparência de Rastreamento de Apps (ATT) e políticas mais rigorosas sobre coleta de dados, significa que os desenvolvedores de SDKs devem adaptar proativamente suas estratégias para garantir funcionalidade, manter a integridade dos dados e respeitar o consentimento do usuário.

Esta postagem de blog explora as complexidades do ITP e mecanismos de privacidade semelhantes no Safari para iOS, oferecendo insights acionáveis e exemplos práticos para otimizar seu SDK. Nosso objetivo é ajudá-lo a construir SDKs resilientes e que preservam a privacidade, que não apenas funcionam de forma confiável, mas também promovem a confiança do usuário em um mundo digital cada vez mais consciente da privacidade.

Entendendo o ITP do Safari e seu Impacto nos SDKs iOS

A Prevenção Inteligente de Rastreamento (ITP) é um conjunto de tecnologias de aprimoramento da privacidade incorporadas ao Safari (e WebKit). Sua função principal é limitar o rastreamento cross-site, restringindo o uso de cookies e outras formas de dados de sites por terceiros. Ao longo dos anos, o ITP evoluiu através de várias iterações, cada uma introduzindo controles mais rigorosos:

• Bloqueio de Cookies de Terceiros: O aspecto mais significativo. O ITP particiona ou bloqueia agressivamente cookies de terceiros, tornando difícil para anunciantes e provedores de análise rastrear usuários em diferentes sites.
• Storage Access API: Introduzida como uma forma de preservar a privacidade para que o conteúdo incorporado solicite acesso ao seu armazenamento primário quando um usuário interage com ele.
• Proteções de Decoração de Links: O ITP também pode remover parâmetros de rastreamento de URLs para evitar o rastreamento através da decoração de links.
• Política de Referrer: O Safari frequentemente envia uma política de referrer mais restritiva (por exemplo, strict-origin-when-cross-origin), limitando a quantidade de informações passadas para sites de terceiros.
• Prevenção de Rastreamento de Bounce Efêmero: Identifica e mitiga técnicas onde os rastreadores redirecionam os usuários através de seu site para definir cookies primários.

Para SDKs iOS, especialmente aqueles que interagem com conteúdo web (por exemplo, navegadores in-app, fluxos de autenticação, gateways de pagamento ou análises incorporadas), o impacto do ITP pode ser profundo. Se seu SDK depende da definição ou leitura de cookies de um domínio de terceiros dentro de um WKWebView, ou se espera que certas informações de referrer sejam passadas, o ITP pode quebrar esses mecanismos, levando a:

• Processos de autenticação ou pagamento falhos.
• Atribuição imprecisa ou dados analíticos incorretos.
• Experiências de usuário quebradas devido à falta de estado ou informações de sessão.

Estratégias para o Desenvolvimento de SDKs iOS à Prova de ITP

A adaptação ao ITP exige uma mudança de mentalidade, do rastreamento tradicional para o tratamento de dados centrado na privacidade. Aqui estão as principais estratégias:

1. Priorize o Contexto Primário e Soluções Server-Side

A maneira mais eficaz de contornar as restrições do ITP em cookies de terceiros é operar dentro de um contexto primário. Isso significa que o domínio que define o cookie ou acessa o armazenamento é o mesmo domínio que o usuário está visitando atualmente.

Exemplo Prático: Rastreamento Server-Side para Análises

Em vez de depender de um script de análise de terceiros incorporado em seu WKWebView que tenta definir seus próprios cookies, considere uma abordagem server-side:

1. SDK Coleta Dados: Seu aplicativo iOS (ou o conteúdo web dentro do seu WKWebView) coleta dados de interação do usuário relevantes (por exemplo, produto visualizado, botão clicado).
2. Envie Dados para seu Backend: Esses dados são enviados diretamente para o seu próprio servidor backend.
3. Backend Encaminha para o Provedor de Análises: Seu backend então encaminha esses dados para a API do seu provedor de análises. Como essa comunicação ocorre de servidor para servidor, ela ignora as restrições do ITP em cookies client-side.

Essa abordagem oferece controle total sobre os dados, garante que sejam enviados de forma confiável e não está sujeita à prevenção de rastreamento do lado do navegador.

2. Aproveite a Storage Access API para Necessidades Cross-Site

Quando você precisa absolutamente de acesso a cookies cross-site dentro de um WKWebView incorporado (por exemplo, para single sign-on com um provedor de identidade), a Storage Access API é o método aprovado e que preserva a privacidade. Esta API permite que o conteúdo de terceiros solicite permissão explícita do usuário para acessar seu armazenamento primário.

Exemplo Prático: SSO Contínuo em WKWebView

Imagine que seu SDK incorpora um WKWebView para um fluxo de autenticação que precisa acessar cookies do seu provedor de identidade (IDP) para conseguir o SSO. Sem a Storage Access API, o Safari bloquearia esses cookies.

Client-side (dentro do seu conteúdo web incorporado):

document.requestStorageAccess().then(function() {
    // Acesso ao armazenamento concedido, agora você pode fazer solicitações que usam cookies
    // por exemplo, carregar o iframe SSO ou fazer uma solicitação XHR para o IDP
}).catch(function() {
    // Acesso ao armazenamento negado ou interação do usuário necessária
    // Lide graciosamente, talvez volte para um login de redirecionamento completo
});

SDK iOS (WKUIDelegate e WKNavigationDelegate):

Você precisará lidar com o prompt do usuário que o Safari apresenta. O método WKUIDelegate webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (ou solicitações de permissão semelhantes) pode ser invocado, mas para acesso ao armazenamento, o prompt geralmente é tratado pelo próprio Safari. Certifique-se de que sua WKWebViewConfiguration esteja configurada corretamente, particularmente websiteDataStore.

3. Adote Identificadores que Preservam a Privacidade e o Consentimento do Usuário

Com a Transparência de Rastreamento de Apps (ATT), a Apple exige o consentimento explícito do usuário para rastreamento em aplicativos e sites de outras empresas. Seu SDK deve respeitar isso. Abandone a dependência de identificadores de dispositivo persistentes para fins de rastreamento sem consentimento.

Exemplo Prático: Lidando com ATT e IDFA

Se seu SDK anteriormente dependia do Identificador para Anunciantes (IDFA) para atribuição ou segmentação:

1. Solicite Autorização ATT: Use AppTrackingTransparency.framework para solicitar autorização do usuário antes de acessar o IDFA.
2. Uso Condicional do IDFA: Somente recupere e use o IDFA se o usuário conceder permissão.
3. Identificadores Alternativos: Se negado, dependa de identificadores efêmeros e específicos do contexto (por exemplo, um ID de sessão) ou IDs não persistentes gerados pelo servidor que não são usados para rastreamento cross-site.

Exemplo em Swift:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // Use IDFA para rastreamento consentido
            case .denied, .notDetermined, .restricted:
                print("Autorização ATT negada ou não determinada.")
                // Conte com outros métodos que preservam a privacidade
            @unknown default:
                break
            }
        }
    } else {
        // Fallback para versões do iOS anteriores ao 14
        // Verifique se o rastreamento está ativado via ASIdentifierManager.shared().isAdvertisingTrackingEnabled
    }
}

Como o Didit Ajuda

Didit, como uma plataforma de identidade completa, alinha-se inerentemente a uma abordagem de privacidade em primeiro lugar, tornando-a robusta contra o ITP e mecanismos de prevenção de rastreamento semelhantes. Nosso foco principal é verificar humanos reais com segurança, não o rastreamento cross-site. A arquitetura do Didit é projetada para lidar com verificação de identidade, biometria, detecção de fraude e autenticação dentro de um sistema único e controlado, minimizando a dependência de cookies de rastreamento de terceiros. Conseguimos isso através de:

• Integração Primária: Os SDKs e APIs do Didit são projetados para integração direta e primária em seu aplicativo, garantindo que os processos de verificação de identidade ocorram dentro do contexto do seu aplicativo, ignorando amplamente as preocupações do ITP relacionadas ao rastreamento cross-site.
• Processamento Server-Side: Muitas das capacidades robustas do Didit, como triagem AML e análise de sinais de fraude, operam de servidor para servidor. Isso significa que o processamento de dados sensíveis e as verificações de identidade acontecem com segurança em nosso backend, eliminando vulnerabilidades de rastreamento client-side.
• Biometria Efêmera: O Didit processa dados biométricos na memória e os exclui, retornando apenas resultados booleanos ao seu aplicativo. Essa abordagem de "privacidade desde a concepção" significa que não armazenamos identificadores biométricos persistentes para rastreamento, alinhando-se perfeitamente com os objetivos do ITP.
• Fluxos de Autenticação Seguros: Nossos métodos de autenticação, incluindo reautenticação biométrica, são construídos para serem seguros e privados, usando mecanismos de desafio-resposta que não dependem de cookies cross-site para gerenciamento de estado.
• Conformidade e Confiança: Sendo SOC 2 Tipo II, ISO 27001 e GDPR compliant, o Didit é construído sobre uma base de privacidade e segurança de dados, o que naturalmente torna nossa plataforma resiliente a mudanças nas tecnologias de prevenção de rastreamento.

Pronto para Começar?

Adaptar seu SDK iOS para o ITP do Safari e o cenário mais amplo de privacidade não é apenas uma questão de conformidade; é sobre construir confiança com seus usuários e garantir a longevidade do seu produto. Ao abraçar contextos primários, aproveitar APIs apropriadas como Storage Access, priorizar o consentimento do usuário e manter-se informado sobre as políticas em evolução da Apple, você pode criar um SDK robusto e que respeita a privacidade.

Explore como a plataforma de identidade first-party do Didit pode simplificar sua conformidade e aprimorar a experiência do usuário. Visite nosso site, confira nossa documentação técnica, ou solicite uma demonstração para ver o Didit em ação.