$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂
He estado guardando las recompensas de mi campaña de Polygon durante los últimos 6 meses, esperando ese buen impulso. 😭
Al principio pensé que conectar una wallet a un dApp era básicamente un solo permiso.
El usuario se conecta, la aplicación ve la cuenta y cada acción posterior fluye a través de esa relación.
Cuanto más investigaba la nueva Wallet @Dusk , más parecía que conectar es solo el comienzo del modelo de permisos.
A través de $DUSK Connect, un dApp puede solicitar acceso al perfil, firmas, transacciones, llamadas a contratos o una dirección de recepción protegida.
Pero pedir una acción no le da a la aplicación las claves del usuario.
Las claves se quedan locales. Dusk dice que las builds de extensiones las protegen usando PBKDF2 y AES-GCM, mientras que las builds nativas usan Stronghold con Argon2. La wallet también incluye bloqueo automático, retroceso tras fallos de desbloqueo y permisos acotados a cada origen que solicita. #dusk
Eso cambió cómo pienso sobre el acceso a dApps.
Un sitio conectado puede permitirse que solicite una acción sin ganar la autoridad de ejecutarla en silencio.
La wallet sigue siendo el límite de aprobación.
Lo que me llamó la atención no fue solo el almacenamiento local de claves.
Es cuánto depende ahora la seguridad de lo que la pantalla de aprobación comunica.
Una clave privada puede permanecer protegida mientras el usuario aún aprueba una llamada a contrato engañosa, un mensaje ilegible o una solicitud de cuenta inesperada. Los permisos por origen restringen qué sitio recibe acceso, pero no pueden demostrar que cada solicitud de ese sitio sea segura.
El repositorio de la wallet separa aprobaciones para transacciones, mensajes legibles y opacos, firmado de autenticación, llamadas a contratos y direcciones protegidas.
Pero Dusk Connect y la nueva Wallet se introdujeron para vista previa para desarrolladores, así que esta experiencia de permisos todavía tiene que demostrar su validez en dApps reales y con comportamientos reales de usuarios.
¿Mantener las claves locales y los permisos por origen crea el límite de seguridad adecuado, o hará más falta la claridad de cada pantalla de aprobación que el estándar de conexión que haya debajo?
He estado guardando las recompensas de mi campaña de Polygon durante los últimos 6 meses, esperando ese buen impulso. 😭
Al principio pensé que conectar una wallet a un dApp era básicamente un solo permiso.
El usuario se conecta, la aplicación ve la cuenta y cada acción posterior fluye a través de esa relación.
Cuanto más investigaba la nueva Wallet @Dusk , más parecía que conectar es solo el comienzo del modelo de permisos.
A través de $DUSK Connect, un dApp puede solicitar acceso al perfil, firmas, transacciones, llamadas a contratos o una dirección de recepción protegida.
Pero pedir una acción no le da a la aplicación las claves del usuario.
Las claves se quedan locales. Dusk dice que las builds de extensiones las protegen usando PBKDF2 y AES-GCM, mientras que las builds nativas usan Stronghold con Argon2. La wallet también incluye bloqueo automático, retroceso tras fallos de desbloqueo y permisos acotados a cada origen que solicita. #dusk
Eso cambió cómo pienso sobre el acceso a dApps.
Un sitio conectado puede permitirse que solicite una acción sin ganar la autoridad de ejecutarla en silencio.
La wallet sigue siendo el límite de aprobación.
Lo que me llamó la atención no fue solo el almacenamiento local de claves.
Es cuánto depende ahora la seguridad de lo que la pantalla de aprobación comunica.
Una clave privada puede permanecer protegida mientras el usuario aún aprueba una llamada a contrato engañosa, un mensaje ilegible o una solicitud de cuenta inesperada. Los permisos por origen restringen qué sitio recibe acceso, pero no pueden demostrar que cada solicitud de ese sitio sea segura.
El repositorio de la wallet separa aprobaciones para transacciones, mensajes legibles y opacos, firmado de autenticación, llamadas a contratos y direcciones protegidas.
Pero Dusk Connect y la nueva Wallet se introdujeron para vista previa para desarrolladores, así que esta experiencia de permisos todavía tiene que demostrar su validez en dApps reales y con comportamientos reales de usuarios.
¿Mantener las claves locales y los permisos por origen crea el límite de seguridad adecuado, o hará más falta la claridad de cada pantalla de aprobación que el estándar de conexión que haya debajo?
🔐 Local key storage
🌐 Per-site permissions
👀 Clear approval screens
🧠 User judgment
8 hora(s) restante(s)