Je voulais savoir à quoi exactement « Connect Wallet » donne accès une dApp, alors j’ai testé le flux réel sur Dario et Pieswap sur le testnet Dusk. Sur les deux, la première connexion n’a renvoyé que l’ID de profil et le compte public. La fenêtre contextuelle était explicite : « Le site ne pourra utiliser que le compte public du profil sélectionné. » Ce n’est que lorsque j’ai demandé l’adresse de réception protégée (« shielded receive address ») qu’une deuxième étape de consentement est apparue, et c’est seulement alors que la réponse a inclus shieldedAddress. La fenêtre contextuelle a aussi changé, en nommant la « shareable shielded receive address ». Les deux intégrations ont montré la même séquence.
Voici le retournement : je traitais « Connect Wallet » comme un seul événement de permission. Ce n’est pas le cas. Le test contrôlé a séparé l’accès au compte public du partage de l’adresse de réception protégée au moment du consentement.
Cette séparation place une partie de la limite de divulgation minimale dans le flux de consentement du portefeuille, et pas entièrement sur l’utilisateur à gérer. Dans les deux tests, cliquer sur « Connect » seul n’a jamais accordé la portée relative à l’adresse protégée ; une dApp a dû franchir une étape de consentement distincte pour l’obtenir.
J’ai aussi commis une erreur en enquêtant. Je pensais que la chaîne de compte de 132 caractères pourrait laisser entendre un accès protégé. Ce n’est pas le cas. Les deux dApps ont renvoyé le même format de compte en situation de base, tandis que shieldedAddress est restée absente jusqu’à la demande explicite.
Il reste une question non résolue. Une session plus ancienne sur le mainnet Dario a eu un comportement différent, mais je ne l’ai pas reproduite dans les mêmes conditions contrôlées ; je n’en parle donc pas comme d’une fuite. Je peux seulement dire que la limite de permission « publique uniquement » a tenu entre les deux intégrations testnet que j’ai vérifiées, et non que cela est garanti dans chaque environnement.
« Une connexion de portefeuille devrait exposer la portée que vous avez approuvée, pas vous laisser l’inférer. »
Ce que je voudrais voir ensuite : le même test contrôlé sur le mainnet, avec la même version du portefeuille, des permissions propres et une instrumentation identique, pour vérifier si la frontière tient selon les environnements.
#dusk $DUSK @Dusk
Voici le retournement : je traitais « Connect Wallet » comme un seul événement de permission. Ce n’est pas le cas. Le test contrôlé a séparé l’accès au compte public du partage de l’adresse de réception protégée au moment du consentement.
Cette séparation place une partie de la limite de divulgation minimale dans le flux de consentement du portefeuille, et pas entièrement sur l’utilisateur à gérer. Dans les deux tests, cliquer sur « Connect » seul n’a jamais accordé la portée relative à l’adresse protégée ; une dApp a dû franchir une étape de consentement distincte pour l’obtenir.
J’ai aussi commis une erreur en enquêtant. Je pensais que la chaîne de compte de 132 caractères pourrait laisser entendre un accès protégé. Ce n’est pas le cas. Les deux dApps ont renvoyé le même format de compte en situation de base, tandis que shieldedAddress est restée absente jusqu’à la demande explicite.
Il reste une question non résolue. Une session plus ancienne sur le mainnet Dario a eu un comportement différent, mais je ne l’ai pas reproduite dans les mêmes conditions contrôlées ; je n’en parle donc pas comme d’une fuite. Je peux seulement dire que la limite de permission « publique uniquement » a tenu entre les deux intégrations testnet que j’ai vérifiées, et non que cela est garanti dans chaque environnement.
« Une connexion de portefeuille devrait exposer la portée que vous avez approuvée, pas vous laisser l’inférer. »
Ce que je voudrais voir ensuite : le même test contrôlé sur le mainnet, avec la même version du portefeuille, des permissions propres et une instrumentation identique, pour vérifier si la frontière tient selon les environnements.
#dusk $DUSK @Dusk
