$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂
Tenho guardado as recompensas da minha campanha de Polygon pelos últimos 6 meses, esperando aquela boa alta. 😭
Achei inicialmente que conectar uma carteira a um dApp era basicamente uma única permissão.
O usuário conecta, a aplicação vê a conta e todas as ações posteriores fluem dessa relação.
Quanto mais eu olhava para a nova @Dusk Wallet, mais parecia que conectar é só o começo do modelo de permissões.
Através do $DUSK Connect, um dApp pode solicitar acesso ao perfil, assinaturas, transações, chamadas de contrato ou um endereço de recebimento protegido.
Mas solicitar uma ação não dá à aplicação as chaves do usuário.
As chaves ficam locais. O Dusk diz que builds de extensão as protegem usando PBKDF2 e AES-GCM, enquanto builds nativas usam Stronghold com Argon2. A carteira também inclui bloqueio automático, retrocesso em tentativas de desbloqueio falhas e permissões com escopo em cada origem que solicita. #dusk
Isso mudou a forma como eu penso sobre acesso a dApps.
Um site conectado pode ser autorizado a solicitar uma ação sem ganhar a autoridade de executá-la silenciosamente.
A carteira continua sendo o limite de aprovação.
O que chamou minha atenção não foi apenas o armazenamento local de chaves.
É o quanto a segurança agora depende do que a tela de aprovação comunica.
Uma chave privada pode permanecer protegida enquanto o usuário aprova uma chamada de contrato enganosa, uma mensagem não legível ou um pedido de conta inesperado. Permissões por origem restringem qual site recebe acesso, mas não conseguem provar que cada solicitação desse site é segura.
O repositório da carteira separa aprovações para transações, mensagens legíveis e opacas, autenticação por assinatura, chamadas de contrato e endereços protegidos.
Mas o Dusk Connect e a nova Wallet foram apresentados para prévia de desenvolvedor, então essa experiência de permissões ainda precisa se provar em dApps reais e no comportamento real dos usuários.
Manter as chaves locais e as permissões por origem cria o limite de segurança certo, ou a clareza de cada tela de aprovação importa mais do que o padrão de conexão por baixo??
Tenho guardado as recompensas da minha campanha de Polygon pelos últimos 6 meses, esperando aquela boa alta. 😭
Achei inicialmente que conectar uma carteira a um dApp era basicamente uma única permissão.
O usuário conecta, a aplicação vê a conta e todas as ações posteriores fluem dessa relação.
Quanto mais eu olhava para a nova @Dusk Wallet, mais parecia que conectar é só o começo do modelo de permissões.
Através do $DUSK Connect, um dApp pode solicitar acesso ao perfil, assinaturas, transações, chamadas de contrato ou um endereço de recebimento protegido.
Mas solicitar uma ação não dá à aplicação as chaves do usuário.
As chaves ficam locais. O Dusk diz que builds de extensão as protegem usando PBKDF2 e AES-GCM, enquanto builds nativas usam Stronghold com Argon2. A carteira também inclui bloqueio automático, retrocesso em tentativas de desbloqueio falhas e permissões com escopo em cada origem que solicita. #dusk
Isso mudou a forma como eu penso sobre acesso a dApps.
Um site conectado pode ser autorizado a solicitar uma ação sem ganhar a autoridade de executá-la silenciosamente.
A carteira continua sendo o limite de aprovação.
O que chamou minha atenção não foi apenas o armazenamento local de chaves.
É o quanto a segurança agora depende do que a tela de aprovação comunica.
Uma chave privada pode permanecer protegida enquanto o usuário aprova uma chamada de contrato enganosa, uma mensagem não legível ou um pedido de conta inesperado. Permissões por origem restringem qual site recebe acesso, mas não conseguem provar que cada solicitação desse site é segura.
O repositório da carteira separa aprovações para transações, mensagens legíveis e opacas, autenticação por assinatura, chamadas de contrato e endereços protegidos.
Mas o Dusk Connect e a nova Wallet foram apresentados para prévia de desenvolvedor, então essa experiência de permissões ainda precisa se provar em dApps reais e no comportamento real dos usuários.
Manter as chaves locais e as permissões por origem cria o limite de segurança certo, ou a clareza de cada tela de aprovação importa mais do que o padrão de conexão por baixo??
🔐 Local key storage
61%
🌐 Per-site permissions
8%
👀 Clear approval screens
23%
🧠 User judgment
8%
13 Votos • Votação encerrada