L’erreur la plus dangereuse d’un portefeuille axé sur la confidentialité, c’est de comprendre « capable de masquer » comme « qu’il suffit de ne pas regarder trop souvent ». En lisant ensemble, dans la page de Dusk Wallet, la ligne « public and shielded DUSK » et l’avertissement de sécurité selon lequel « chaque connexion, signature et transaction doit être approuvée », j’ai compris que le produit sépare deux choses qu’on confond souvent : l’affichage des actifs peut être segmenté, mais la responsabilité des autorisations ne peut pas l’être.
L’extension officielle d’auto-hébergement pour <0-9]{11} /> (@Dusk ) gère en même temps les requêtes liées à DUSK public et à DUSK shielded, et elle les présente aussi aux applications compatibles sous forme de demandes de connexion, de transaction et de signature. La difficulté ne vient pas du fait que l’interface comporte davantage d’états d’actifs, mais du fait que l’utilisateur peut facilement confondre « personne ne voit le solde » avec « cette autorisation-ci n’a pas beaucoup d’importance ». La confidentialité on-chain répond à ce que les observateurs peuvent voir ; la fenêtre de signature répond, elle, à ce qu’une application précise est sur le point de te faire faire.
Ce mauvais scénario n’est pas si loin. Une application d’imitation fait passer sa demande pour une simple connexion ; pour protéger son solde, l’utilisateur choisit un actif shielded, mais dans la fenêtre pop-up, il zappe les détails de connexion ou de signature. Les mécanismes de confidentialité ne permettent pas à eux seuls de juger à qui l’autorisation est accordée ; la première frontière à être franchie est souvent celle de l’action. Le coût de vérification retombe sur l’utilisateur en auto-hébergement, tandis que l’équipe du portefeuille doit, elle, rendre chaque requête impossible à interpréter à tort, même par inadvertance.
Je ne considère pas cela comme un problème de quantité de fonctionnalités du portefeuille. Si $DUSK veut intégrer la confidentialité à des opérations financières du quotidien, il faut plutôt que chaque demande affiche clairement l’identité du site, les comptes affectés et les conséquences des actions. #dusk
L’extension officielle d’auto-hébergement pour <0-9]{11} /> (@Dusk ) gère en même temps les requêtes liées à DUSK public et à DUSK shielded, et elle les présente aussi aux applications compatibles sous forme de demandes de connexion, de transaction et de signature. La difficulté ne vient pas du fait que l’interface comporte davantage d’états d’actifs, mais du fait que l’utilisateur peut facilement confondre « personne ne voit le solde » avec « cette autorisation-ci n’a pas beaucoup d’importance ». La confidentialité on-chain répond à ce que les observateurs peuvent voir ; la fenêtre de signature répond, elle, à ce qu’une application précise est sur le point de te faire faire.
Ce mauvais scénario n’est pas si loin. Une application d’imitation fait passer sa demande pour une simple connexion ; pour protéger son solde, l’utilisateur choisit un actif shielded, mais dans la fenêtre pop-up, il zappe les détails de connexion ou de signature. Les mécanismes de confidentialité ne permettent pas à eux seuls de juger à qui l’autorisation est accordée ; la première frontière à être franchie est souvent celle de l’action. Le coût de vérification retombe sur l’utilisateur en auto-hébergement, tandis que l’équipe du portefeuille doit, elle, rendre chaque requête impossible à interpréter à tort, même par inadvertance.
Je ne considère pas cela comme un problème de quantité de fonctionnalités du portefeuille. Si $DUSK veut intégrer la confidentialité à des opérations financières du quotidien, il faut plutôt que chaque demande affiche clairement l’identité du site, les comptes affectés et les conséquences des actions. #dusk