Whitepaper de segurança e privacidade (visão geral)Apêndice
Apêndice: Índice de IDs de afirmação (fonte única de verdade)
Este apêndice é a fonte única de verdade para todos os IDs de afirmação do whitepaper. Cada afirmação tem um identificador e uma âncora exclusivos e estáveis, e é apresentada em uma única linha com uma Declaração e uma Evidência. A evidência remete apenas a referências oficiais verificáveis de forma repetível (âncoras de capítulo ou pontos de entrada de relatórios de status/de terceiros) e não remete a capturas de tela nem a conteúdo re-hospedado.
Regras de manutenção
- MUST: os IDs de afirmação são exclusivos e estáveis; uma vez publicados, nunca são reutilizados.
- MUST: A evidência de cada afirmação deve ser verificável de forma repetível (âncoras de capítulo ou pontos de entrada oficiais de terceiros).
- MUST: As declarações devem afirmar apenas o que a evidência sustenta; evite a linguagem de “segurança absoluta”.
- SHOULD: quando alterações na implementação ou na política afetarem uma afirmação, registre-as no changelog e vincule os IDs de afirmação impactados.
Capítulos 1–4 (Escopo, Modelo de Ameaça, Arquitetura, AuthZ)
SCOPE-01
Declaração: O documento define claramente os riscos dentro e fora do escopo e os limites de segurança do sistema. Evidência:1.3， 1.4
THREAT-01
Declaração: O modelo de ameaça cobre ataques de rede, downloads não autorizados, tentativas de leitura de armazenamento/servidor e invasores do lado do navegador. Evidência:2.2
BOUNDARY-01
Declaração: Os limites de confiança separam claramente as responsabilidades entre cliente, servidor, armazenamento de objetos e ambiente externo; o servidor NÃO DEVE obter CEK. Evidência:2.4
FAILCLOSE-01
Declaração: Em caso de falha de autenticação ou contexto inconsistente, o sistema deve falhar no fechamento (fail closed) e não gerar texto simples parcial. Evidência:2.5
ARCH-01
Declaração: Os objetos de dados principais são claramente separados: pedaços criptografados, manifestos e dados de auditoria são isolados uns dos outros. Evidência:3.2
FLOW-UP-01
Declaração: O fluxo de upload inclui a criação de um transferId e a emissão de tokens de acesso de curta duração (tokens de sessão baseados em consulta/lookup) com escopo rigoroso e controles de expiração. Evidência:3.3
FLOW-DL-01
Declaração: Os downloads leem o fragmento da URL para obter a CEK; as leituras de manifesto e de chunk usam tokens com escopos diferentes; falhas de autenticação falham no fechamento (fail closed). Evidência:3.4， 2.5
AUTH-TOKEN-01
Declaração: Tokens de acesso de curta duração são tokens de sessão do lado do servidor (baseados em consulta/lookup) que expiram e são usados para controle de acesso a texto cifrado e manifestos. Evidência:4.2
AUTH-SCOPE-01
Declaração: Os tokens são separados por escopos como read_manifest/read_chunk/upload_chunk e são estritamente validados. Evidência:4.3， 4.4， 3.4
AUTH-PAID-01
Declaração: Os usuários pagos fazem login por meio de um link mágico único e obtêm um token de longa duração mantido pelo cliente para ações de gerenciamento do lado do remetente. Evidência:4.1， 3.5
REVOKE-01
Declaração: O remetente pode revogar o acesso: excluir uma transferência ou remover arquivos torna os downloads inválidos antecipadamente e nega o acesso subsequente. Evidência:4.5
AUDIT-01
Declaração: Dados de auditoria, como contagem de downloads e progresso, são visíveis apenas para o remetente e não para o destinatário. Evidência:4.6， 3.5
LOG-01
Declaração: Os logs/telemetria do cliente e do servidor não incluem CEK, fragmentos de URL ou qualquer material de chave derivável. Evidência:4.7， 10.2
Capítulo 5 (Criptografia e gerenciamento de chaves)
CRYPTO-ZK-01
Declaração: CEK é gerado apenas no navegador e distribuído por meio do fragmento de URL; o servidor nunca gera um link de download completo contendo CEK. Evidência:5.3.1， 5.3.2
CRYPTO-ZK-02
Declaração: O servidor não recebe, não armazena nem registra a CEK; o armazenamento de objetos armazena apenas pedaços criptografados. Evidência:5.0， 5.5.1
CRYPTO-E2EE-01
Declaração: Os pedaços usam AES-128-GCM; a falha de autenticação deve falhar no fechamento (fail closed) e não gerar texto simples parcial. Evidência:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Declaração: chunkSize é fixado em 16 MB (16777216). Evidência:5.4.1， 5.8.1
CRYPTO-NONCE-01
Declaração: IV é derivado como noncePrefix(8B)||uint32_be(chunkIndex) e não deve ser repetido no mesmo CEK. Evidência:5.4.3， 5.8.1
CRYPTO-AAD-01
Declaração: AAD está vinculado a transferId + fileId + chunkIndex e codificado via EncodeAAD_v1. Evidência:5.4.4
CRYPTO-CLIENT-01
Declaração: As páginas de download/descriptografia não carregam scripts de terceiros; os logs/telemetria do cliente não incluem fragmentos ou material de chave. Evidência:5.6， 10.2
CRYPTO-TLS-01
Declaração: O HTTPS é imposto em todo o site; a configuração de TLS pode ser verificada por meio de relatórios públicos de terceiros. Evidência:5.1.2， /status#tls-configuration
Capítulos 6–7 (Ciclo de vida de dados/Defesa contra abuso)
LIFECYCLE-01
Declaração: A expiração e a exclusão iniciada pelo usuário acionam a limpeza; a revogação é suportada para invalidar downloads antecipadamente. Evidência:6.2， 6.3， 4.5
ABUSE-01
Declaração: A defesa contra abuso usa limitação de taxa e controles em níveis, sem romper o limite de conhecimento zero. Evidência:7.2， 7.4
Capítulos 8–9 (Privacidade/Segurança e Isolamento da Web)
PRIVACY-01
Declaração: A definição e os compromissos de conhecimento zero são explícitos: o CEK é gerado e usado apenas no cliente; o servidor não pode recuperar a chave. Evidência:8.1
PRIVACY-02
Declaração: As implicações de privacidade de fragmentos de URL (copiar/colar, vazamento de referenciador, registro em log) são documentadas com mitigações. Evidência:8.2， 10.2
WEB-01
Declaração: As páginas principais impõem limites rígidos de CSP e recursos para reduzir o risco de injeção e clickjacking. Evidência:9.1， 9.3
WEB-HEADERS-01
Declaração: A linha de base dos cabeçalhos de segurança pode ser verificada por meio de relatórios públicos de terceiros. Evidência:/status#security-headers
WEB-OBS-01
Declaração: O site pode ser verificado por meio de verificações públicas de práticas recomendadas de terceiros. Evidência:/status#http-observatory
Capítulos 10–12 (Registro e IR/Divulgação de Vulnerabilidade/Evidência)
OBS-01
Declaração: A observabilidade segue um princípio mínimo, cobrindo apenas necessidades operacionais/de segurança e utilizando estratégias de agregação/amostragem. Evidência:10.1
IR-01
Declaração: É definido um processo de resposta a incidentes de segurança (gravidade, contenção, postmortem, remediação e aviso público). Evidência:10.4
VDP-01
Declaração: Existe um processo de divulgação de vulnerabilidades que prioriza questões que podem afetar o limite de conhecimento zero. Evidência:11.2
EV-01
Declaração: A página de status agrega pontos de entrada de evidências de terceiros; a evidência remete a fontes oficiais e esclarece os limites de aplicabilidade. Evidência:12.2， 12.6