Por que offline-first importa para dados sensíveis.

A maioria dos apps que pede dados sensíveis os armazena em seus servidores. against. faz o oposto: seus dados ficam apenas no seu dispositivo. Veja por que isso importa especificamente para o trabalho de recuperação.

O que “cloud-first” geralmente significa

Quando um app armazena seus dados em servidores, está fazendo uma aposta: de que sua infraestrutura é mais confiável, mais disponível e mais segura do que seu celular. Para muitos tipos de dados, essa aposta é razoável. Para dados de recuperação (notas sobre recaídas, padrões de gatilho, entradas de diário), o cálculo é diferente.

Cloud-first significa que várias coisas acontecem automaticamente, muitas vezes sem que você decida:

• Seus dados cruzam uma rede cada vez que você interage com eles.
• Eles ficam em um servidor de propriedade de uma empresa, sujeito às práticas de segurança dessa empresa.
• Eles são potencialmente visíveis para os funcionários, contratados e quaisquer terceiros com quem essa empresa compartilhe.
• Podem ser obtidos por uma intimação judicial ou por um atacante que comprometa o servidor.

Nada disso é necessariamente um resultado. São possibilidades que existem enquanto os dados ficam em algum lugar que você não controla. Para dados rotineiros (uma lista de tarefas, um rastreador de leitura) essas possibilidades são aceitáveis. Para notas sobre sua relação com a pornografia, pode não ser.

O que acontece quando dados sensíveis são centralizados

Os modos de falha para dados sensíveis centralizados são previsíveis e bem documentados. Brechas acontecem. Empresas são adquiridas. Modelos de negócio mudam em direção à publicidade, o que introduz SDKs de rastreamento de terceiros. Regimes legais mudam. Uma startup com boas intenções hoje pode não existir da mesma forma em dois anos.

Há também um problema mais sutil. Quando os dados ficam em um servidor, as pessoas que construíram o app têm a capacidade técnica de lê-los, mesmo que a política de privacidade diga que não. Políticas são promessas. Arquitetura técnica é restrição. Um servidor que armazena suas entradas de diário pode ser lido por alguém com o acesso certo. Um banco de dados no dispositivo que nunca sai do seu celular não pode ser lido remotamente, independentemente do que qualquer um prometa.

Para o trabalho de recuperação especificamente, os riscos são maiores do que para a maioria das categorias de dados pessoais. Essa informação toca relacionamentos, situações legais, emprego e autopercepção. O risco de exposição, mesmo acidental, mesmo por uma empresa bem-intencionada, é real.

Como o offline-first muda o modelo de ameaça

Offline-first significa que os dados nunca saem do seu dispositivo em forma legível. No against., eles não saem do seu dispositivo de forma alguma. Não há sincronização, não há backup para um serviço de nuvem, não há conta que guarde seus registros.

Isso muda o modelo de ameaça de forma significativa:

Brecha no servidor: Não se aplica. Não há servidor com seus dados.

Aquisição ou mudança de empresa: Não se aplica. Os dados não estão nas mãos da empresa.

Intimação ou solicitação legal: Não temos nada a entregar. Não armazenamos dados de conta, porque não há contas.

Acesso de funcionários: Nenhum funcionário pode ler suas notas, porque não as recebemos.

Rastreadores de terceiros: against. não inclui SDKs de publicidade. Não há razão econômica para isso, já que não há dados para vender.

O modelo de ameaça restante é local: alguém com acesso físico ao seu celular desbloqueado, ou um atacante sofisticado que extrai o armazenamento do dispositivo e quebra a criptografia. Essas são ameaças reais para alvos de alto valor. Para o diário de recuperação da maioria das pessoas, não são a preocupação principal.

O que você abre mão ao optar pelo offline-first

Offline-first não é uma atualização gratuita. Vem com tradeoffs reais.

Sem sincronização entre dispositivos. Seus dados ficam em um dispositivo. Se você trocar de celular, precisará exportar e importar manualmente. Se perder o celular sem backup, perderá seu histórico.

Sem recuperação de conta. Não há fluxo de “esqueci a senha”, porque não há conta. Sua chave de criptografia é armazenada no hardware seguro do seu celular. Se você perder isso, perde o acesso aos dados criptografados.

Sem acesso pela web. Você não pode fazer login por um navegador. O app só roda no celular onde os dados ficam.

Esses não são bugs. São a consequência direta do mesmo design que protege seus dados. O app documenta esse tradeoff claramente. É uma escolha que vale a pena fazer para essa categoria de dados, mas é uma escolha, e ela é sua.

Há um ponto mais amplo sobre o que “seguro” significa na prática. Segurança não é um dial único que você vira ao máximo. Cada propriedade de segurança envolve tradeoffs com usabilidade, conveniência e funcionalidade. Offline-first maximiza um conjunto de propriedades (resistência ao acesso remoto, resistência ao tratamento de dados corporativos, resistência a intimações) enquanto aceita limites em outro conjunto. A questão real é se os tradeoffs específicos correspondem aos riscos específicos que você está gerenciando.

Para o rastreamento de recuperação, o argumento é forte. Os dados são pessoais e sensíveis. As pessoas com maior probabilidade de serem prejudicadas pela exposição são as próprias pessoas que geram os dados, não terceiros. Os comportamentos rastreados não exigem coordenação em tempo real com outros usuários. As vantagens da nuvem (acesso de múltiplos dispositivos, compartilhamento, colaboração) não são recursos que você precisa aqui. Os riscos que ela introduz são reais. Offline-first é a escolha certa.

Leitura adicional

• Como funciona a criptografia no against.
• Privacidade não é a mesma coisa que silêncio
• Privacidade e Segurança

Veja também: Privacidade e Segurança.