Privacidade por arquitetura, não por promessa

O modelo da promessa

A maioria dos produtos "privacidade em primeiro lugar" se organiza em torno de uma promessa: coletamos seus dados, mas prometemos cuidá-los. Às vezes a promessa é sincera. Às vezes sobrevive a uma troca de CEO. Às vezes não sobrevive a uma intimação. A promessa, por construção, dura apenas o que dura a empresa que a fez.

O modelo da arquitetura

Outro caminho: construir o produto de modo a tornar a promessa fisicamente desnecessária. Sem contas. Sem telemetria. Sem sincronização em nuvem. Revogue a permissão de rede e o app continua funcionando. A propriedade de privacidade não é afirmada por uma página de políticas — é imposta pela ausência de código capaz de violá-la.

Na prática significa:

• Zero SDK de analytics. Sem Mixpanel, sem Amplitude, sem pipeline de eventos caseiro. O número de usuários nos é desconhecido, e esse é o ponto.
• Zero configuração remota. No nosso modelo de ameaça, feature flag é backdoor. Todo binário que entregamos se comporta igual no dia 1 e no dia 300.
• Zero uploads em background. Logs são locais, opt-in, e só aparecem quando o usuário os cola num e-mail de suporte.
• Zero domínios de terceiros. As únicas chamadas de rede que um app Flux faz são as mediadas pelo SO (atualizações da App Store, push do sistema) — nunca as nossas.

O que custa

• Não dá para A/B testar no sentido convencional. Apoiamo-nos em pequenos estudos internos e em escutar o e-mail de suporte.
• Não dá para corrigir bugs olhando seus dados. Apoiamo-nos em repros locais.
• Recursos têm de funcionar de primeira. Não existe "ajustamos depois pelo painel".

O que compra

• Uma afirmação de privacidade que um regulador verifica com tcpdump.
• Uma base de usuários que não precisa confiar em nós — pode verificar.
• Um produto que envelhece bem, porque não depende de uma relação de cobrança para continuar funcionando daqui a cinco anos.

O modelo da promessa escala a empresa. O modelo da arquitetura escala a confiança. Escolhemos o segundo.