Quería saber a qué acceso real le da un dApp cuando pulsa “Connect Wallet”, así que probé el flujo en Dario y Pieswap en la red de prueba de Dusk. En ambos casos, la primera conexión solo devolvió el ID de perfil y la cuenta pública. El popup era explícito: “El sitio solo podrá usar la cuenta pública del perfil seleccionado”. Solo cuando pedí la dirección de recepción en modo protegido apareció un segundo paso de consentimiento, y solo entonces la respuesta incluyó shieldedAddress. El popup también cambió, nombrando la “dirección de recepción protegida compartible”. Ambas integraciones mostraron la misma secuencia.
Aquí está el giro: yo estaba tratando “Connect Wallet” como si fuera un único evento de permiso. No lo es. La prueba controlada separó el acceso a la cuenta pública de compartir la dirección de recepción protegida en el momento del consentimiento.
Esa separación coloca parte del límite de divulgación mínima en el flujo de consentimiento de la wallet, no totalmente en manos del usuario para gestionarlo. En ambas pruebas, hacer clic en “Connect” por sí solo nunca concedió el alcance de la dirección protegida; un dApp tuvo que atravesar un paso de consentimiento separado para obtenerlo.
También cometí un error al investigar. Pensé que la cadena de cuenta de 132 caracteres podría insinuar acceso protegido. No es así. Ambos dApps devolvieron el mismo formato de cuenta en la base, mientras que shieldedAddress se mantuvo ausente hasta la solicitud explícita.
Sigue habiendo una pregunta sin resolver. Una sesión anterior en mainnet de Dario se comportó de manera diferente, pero no la he reproducido bajo las mismas condiciones controladas, así que no lo estoy llamando una fuga. Solo puedo decir que el límite de permiso de “solo público” se mantuvo en las dos integraciones de testnet que comprobé, no que esté garantizado en cada entorno.
“Una conexión de wallet debería exponer el alcance que aprobaste, no dejarte inferirlo”.
Lo siguiente que me gustaría ver: la misma prueba controlada en mainnet con la misma versión de wallet, permisos limpios y una instrumentación idéntica, para ver si el límite se mantiene a través de los entornos.
#dusk $DUSK @Dusk
Aquí está el giro: yo estaba tratando “Connect Wallet” como si fuera un único evento de permiso. No lo es. La prueba controlada separó el acceso a la cuenta pública de compartir la dirección de recepción protegida en el momento del consentimiento.
Esa separación coloca parte del límite de divulgación mínima en el flujo de consentimiento de la wallet, no totalmente en manos del usuario para gestionarlo. En ambas pruebas, hacer clic en “Connect” por sí solo nunca concedió el alcance de la dirección protegida; un dApp tuvo que atravesar un paso de consentimiento separado para obtenerlo.
También cometí un error al investigar. Pensé que la cadena de cuenta de 132 caracteres podría insinuar acceso protegido. No es así. Ambos dApps devolvieron el mismo formato de cuenta en la base, mientras que shieldedAddress se mantuvo ausente hasta la solicitud explícita.
Sigue habiendo una pregunta sin resolver. Una sesión anterior en mainnet de Dario se comportó de manera diferente, pero no la he reproducido bajo las mismas condiciones controladas, así que no lo estoy llamando una fuga. Solo puedo decir que el límite de permiso de “solo público” se mantuvo en las dos integraciones de testnet que comprobé, no que esté garantizado en cada entorno.
“Una conexión de wallet debería exponer el alcance que aprobaste, no dejarte inferirlo”.
Lo siguiente que me gustaría ver: la misma prueba controlada en mainnet con la misma versión de wallet, permisos limpios y una instrumentación idéntica, para ver si el límite se mantiene a través de los entornos.
#dusk $DUSK @Dusk
