#dusk $DUSK @Dusk
Voltei às anotações de segurança da carteira da Dusk e ao changelog da v0.3.0 com uma suposição simples: segurança da carteira significava proteger a frase-semente e definir uma senha forte.
O design da extensão é mais operacional. O mnemonic é criptografado em repouso com PBKDF2 e AES-GCM-256, mas um mnemonic desbloqueado ainda fica na memória do JavaScript e não há como garantir que seja zerado. O auto-bloqueio é acionado por alarmes do navegador; a v0.3.0 corrigiu o timestamp de atividade que sobrevivia a reinícios do worker em segundo plano e preservou eventos de estado bloqueado para dApps conectados. O provider também verifica o tamanho do memo e rejeita memos em chamadas de contrato porque a carga pode ser um memo ou uma chamada, não ambas. Registros antigos de vault não suportados são limpos e exigem reimportação do mnemonic em vez de serem aceitos silenciosamente.
Isso me fez olhar para isso de forma diferente.
Minha interpretação: a privacidade pode falhar na fronteira de sessão e de estado local mesmo quando a criptografia de transação protegida (shielded) está correta.
Minha incerteza é a compensação na recuperação. Rejeitar um formato antigo do vault protege os usuários contra registros adulterados ou fracos, ou cria um novo risco operacional quando o usuário não consegue encontrar a seed? E auto-bloqueios frequentes fortalecem o uso real, ou treinam as pessoas a aprovar prompts sem ler?
Quero observar isso na prática.
Voltei às anotações de segurança da carteira da Dusk e ao changelog da v0.3.0 com uma suposição simples: segurança da carteira significava proteger a frase-semente e definir uma senha forte.
O design da extensão é mais operacional. O mnemonic é criptografado em repouso com PBKDF2 e AES-GCM-256, mas um mnemonic desbloqueado ainda fica na memória do JavaScript e não há como garantir que seja zerado. O auto-bloqueio é acionado por alarmes do navegador; a v0.3.0 corrigiu o timestamp de atividade que sobrevivia a reinícios do worker em segundo plano e preservou eventos de estado bloqueado para dApps conectados. O provider também verifica o tamanho do memo e rejeita memos em chamadas de contrato porque a carga pode ser um memo ou uma chamada, não ambas. Registros antigos de vault não suportados são limpos e exigem reimportação do mnemonic em vez de serem aceitos silenciosamente.
Isso me fez olhar para isso de forma diferente.
Minha interpretação: a privacidade pode falhar na fronteira de sessão e de estado local mesmo quando a criptografia de transação protegida (shielded) está correta.
Minha incerteza é a compensação na recuperação. Rejeitar um formato antigo do vault protege os usuários contra registros adulterados ou fracos, ou cria um novo risco operacional quando o usuário não consegue encontrar a seed? E auto-bloqueios frequentes fortalecem o uso real, ou treinam as pessoas a aprovar prompts sem ler?
Quero observar isso na prática.
