Encriptação Móvel para Transferência de Ficheiros: Partilha Segura em Movimento
Garanta que as transferências de ficheiros móveis são encriptadas ponto-a-ponto. Como a encriptação baseada no browser funciona em iOS e Android para partilha segura em qualquer lugar.
A encriptação de ficheiros em dispositivos móveis corre no Safari no iOS e no Chrome/Firefox no Android usando a Web Crypto API — a mesma chamada crypto.subtle.encrypt que funciona no computador. Ficheiros selecionados da biblioteca de Fotos ou da aplicação Ficheiros são encriptados com AES-256-GCM antes de qualquer byte sair do telemóvel. O trabalho pesado é a derivação de chave PBKDF2, que num iPhone 14 Pro completa 600 000 iterações em cerca de 350 ms. Para um .mov de 500 MB de uma viagem recente, o verdadeiro obstáculo é a largura de banda de envio, não a encriptação. Os serviços de transferência orientados para mobile não precisam de aplicações nativas — o browser tem tudo o que é necessário.
Porque o browser supera as aplicações nativas em mobile
As aplicações nativas iOS e Android para transferência de ficheiros (Dropbox, a aplicação WeTransfer anterior a 2023) pedem permissões alargadas, ficam em memória após o uso e exibem anúncios. Um fluxo de trabalho baseado no browser não exige instalação, corre uma vez e encerra quando o separador fecha. Mais importante: a rejeição da App Store da Apple de aplicações verdadeiramente de conhecimento zero (o caso da Cryptee em 2021 está documentado) torna a entrega pelo browser a única forma de garantir que a lógica de encriptação não é substituída silenciosamente por uma atualização da loja. O mesmo bundle JavaScript corre em todo o lado, verificável contra hashes SHA-384.
A Web Crypto API no iOS e Android
O Safari 17 no iOS 17+ suporta crypto.subtle integralmente: deriveKey, encrypt, decrypt, sign, verify. O Chrome no Android suporta-a desde a versão 37 (2014). Ambas as implementações delegam para primitivas nativas do SO — CommonCrypto no iOS, BoringSSL no Android — pelo que a criptografia é acelerada por hardware nas instruções AES do ARM. Um bloco de 5 MB encripta em cerca de 15 ms num Pixel 8. A API não expõe material de chave bruto ao JavaScript (os objetos CryptoKey são handles opacos), o que ajuda contra extensões maliciosas, embora os browsers móveis tenham muito menos dessas.
Gerir ficheiros grandes sem esgotar a memória
O Safari móvel limita o heap JavaScript a cerca de 2 GB em iPhones com 6 GB de RAM, menos em dispositivos mais antigos. Um padrão ingénuo de "ler ficheiro para ArrayBuffer, encriptar, enviar" falha em qualquer coisa acima de 1 GB. O streaming é obrigatório. Use File.slice() para ler blocos de 5 MB, encripte cada um com uma sub-chave derivada via HKDF, e faça o upload via fetch() com um corpo ReadableStream. O upload progressivo mantém o pico de memória abaixo de 50 MB mesmo para vídeos de 10 GB. O Chrome no Android suporta pedidos fetch com streaming desde a versão 105; o Safari adicionou suporte completo na versão 17.4.
Considerações de bateria e temperatura
AES-256-GCM é barato em hardware — as Cryptography Extensions do ARMv8 fazem-no correr quase à velocidade da DRAM. A encriptação de 1 GB num iPhone 14 Pro consome cerca de 2% de bateria, maioritariamente o rádio para upload, não o CPU. Onde os utilizadores sentem calor é no PBKDF2 a iterações elevadas; 1,2 milhões de iterações (recomendação OWASP de 2024) demoram 700 ms e fazem o A17 pico de temperatura para 90°C brevemente. Definir iterações em 600 000 equilibra segurança e temperatura. Argon2id com m=32MB é mais suave em cargas de trabalho prolongadas porque a dureza de memória é mais lenta mas menos densa em energia.
Rede celular, Wi-Fi e fiabilidade do upload
Os uploads móveis falham. Um túnel de metro, um elevador, uma mudança de Wi-Fi para LTE — qualquer um destes mata um fetch() ingénuo. Uma transferência móvel robusta usa uploads retomáveis com reconhecimento ao nível do bloco, protocolos como tus.io (especificação tus 1.0, amplamente suportada) ou uploads multipart do S3. Cada bloco de 5 MB carrega de forma independente; uma falha reenvía apenas esse bloco. O cliente guarda o estado dos blocos no IndexedDB para que uma recarga do separador do browser ou uma evicção de separador iOS não reinicie todo o trabalho. O SwissTransfer e o HexaTransfer implementam uploads retomáveis; o fluxo web móvel do WeTransfer não o faz, o que é a razão pela qual uploads de 2 GB sobre LTE falham frequentemente.
Entrada de teclado e o problema de UX da palavra-passe
Digitar uma palavra-passe forte de 16 caracteres num teclado de telemóvel é frustrante. Ofereça alternativas: ler um código QR contendo a palavra-passe do ecrã do remetente, colar a partir do gestor de palavras-passe nativo (o iOS preenche a partir do Keychain via equivalentes de .well-known/apple-app-site-association para web) ou usar uma passkey registada durante uma transferência anterior. Para casos pontuais, use a Web Share Target API para permitir que uma aplicação companheira (Signal, por exemplo) injete a palavra-passe sem o utilizador redigitar.
Acessibilidade e ecrãs pequenos
Um iPhone SE de 4,7 polegadas não comporta um interface de arrastar e largar estilo desktop. Os interfaces de encriptação móvel devem respeitar o viewport: seletor de ficheiros em ecrã completo, barras de progresso visíveis acima do teclado virtual, etiquetas VoiceOver em todos os botões (role="progressbar" com aria-valuenow para acessibilidade) e um alvo de toque mínimo de 44x44px conforme as HIG da Apple. Não esconda controlos por detrás de estados de hover — não existe hover no toque. Teste com o Modo de Baixa Energia do iOS, que limita temporizadores em segundo plano e quebra atualizações de progresso baseadas em polling.
Peculiaridades do Safari iOS que quebram uploads
O Safari no iOS tem algumas armadilhas. Os eventos de progresso de upload da Fetch API não disparam de forma fiável antes do iOS 16.4. A File System Access API não é suportada, pelo que não pode transmitir ficheiros grandes do armazenamento local como o Chrome faz. O Safari expulsa agressivamente separadores inativos sob pressão de memória, o que mata uploads em curso. Mitigações: use XMLHttpRequest com eventos de progresso como alternativa (ainda funciona bem), mantenha o separador em primeiro plano durante o upload e avise o utilizador para não bloquear o ecrã em ficheiros grandes. O ecrã ligado drena a bateria mas evita a expulsão do separador.
Fragmentação de dispositivos Android
O Android abrange desde o Pixel 8 Pro a dispositivos Moto de entrada de gama a correr Android Go. A Web Crypto funciona em todos eles, mas o desempenho varia muito — um MT6762 a 2 GHz demora 1,8 segundos para 600 000 iterações PBKDF2 onde um telemóvel de classe Apple M3 demora 200 ms. Detete o dispositivo via Device Memory API e Hardware Concurrency, adapte as contagens de iterações em conformidade (descendo para 300 000 em dispositivos Go) e avise os utilizadores em ligações apenas por dados celulares que uploads acima de 1 GB podem ser pouco fiáveis. A vantagem: a transferência encriptada funciona na maioria dos telemóveis do mundo sem exigir um topo de gama.
Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo