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