Ich wollte wissen, worauf ein dApp mit „Connect Wallet“ tatsächlich Zugriff erhält, also habe ich den echten Ablauf bei Dario und Pieswap im Dusk-Testnet getestet. In beiden Fällen lieferte die erste Verbindung nur die Profil-ID und das öffentliche Konto zurück. Das Popup war eindeutig: „Die Website kann nur das öffentliche Konto des ausgewählten Profils verwenden.“ Erst als ich die „geschützte Empfangsadresse“ angefordert habe, erschien ein zweiter Zustimmungs-Schritt, und erst dann enthielt die Antwort shieldedAddress. Auch das Popup änderte sich und nannte die „freigabefähige geschützte Empfangsadresse“. Beide Integrationen zeigten dieselbe Abfolge.
Hier die Kehrseite: Ich habe „Connect Wallet“ als ein einzelnes Berechtigungsereignis betrachtet. Das ist es nicht. Der kontrollierte Test trennte den Zugriff auf das öffentliche Konto vom Teilen der geschützten Empfangsadresse genau an dem Punkt, an dem die Zustimmung erteilt wurde.
Diese Trennung legt einen Teil der Mindest-Offenlegungsgrenze in den Zustimmungsablauf der Wallet, nicht vollständig in die Hand des Nutzers. In beiden Tests gewährte ein Klick auf „Connect“ allein niemals den Scope für die geschützte Adresse; eine dApp musste einen separaten Zustimmungs-Schritt durchlaufen, um ihn zu erhalten.
Außerdem habe ich bei der Untersuchung eine Sache falsch eingeschätzt. Ich dachte, die 132-Zeichen lange Kontostring könnte auf geschützten Zugriff hindeuten. Das tut sie nicht. Beide dApps lieferten im Ausgangszustand dasselbe Kontofomat zurück, während shieldedAddress erst dann fehlte, bis die explizite Anfrage erfolgte.
Es gibt noch eine offene Frage. Eine frühere Dario-Mainnet-Session verhielt sich anders, aber ich habe das nicht unter denselben kontrollierten Bedingungen reproduziert, also bezeichne ich es nicht als Leck. Ich kann nur sagen, dass die Grenze „nur öffentlich“ in den beiden von mir geprüften Testnet-Integrationen eingehalten wurde, nicht, dass dies in jeder Umgebung garantiert ist.
„Eine Wallet-Verbindung sollte den von dir genehmigten Scope offenlegen, statt dich dazu zu zwingen, ihn abzuleiten.“
Was ich als Nächstes sehen würde: derselbe kontrollierte Test im Mainnet mit derselben Wallet-Version, sauberen Berechtigungen und identischer Instrumentierung, um zu prüfen, ob die Grenze über Umgebungen hinweg stabil bleibt.
#dusk $DUSK @Dusk
Hier die Kehrseite: Ich habe „Connect Wallet“ als ein einzelnes Berechtigungsereignis betrachtet. Das ist es nicht. Der kontrollierte Test trennte den Zugriff auf das öffentliche Konto vom Teilen der geschützten Empfangsadresse genau an dem Punkt, an dem die Zustimmung erteilt wurde.
Diese Trennung legt einen Teil der Mindest-Offenlegungsgrenze in den Zustimmungsablauf der Wallet, nicht vollständig in die Hand des Nutzers. In beiden Tests gewährte ein Klick auf „Connect“ allein niemals den Scope für die geschützte Adresse; eine dApp musste einen separaten Zustimmungs-Schritt durchlaufen, um ihn zu erhalten.
Außerdem habe ich bei der Untersuchung eine Sache falsch eingeschätzt. Ich dachte, die 132-Zeichen lange Kontostring könnte auf geschützten Zugriff hindeuten. Das tut sie nicht. Beide dApps lieferten im Ausgangszustand dasselbe Kontofomat zurück, während shieldedAddress erst dann fehlte, bis die explizite Anfrage erfolgte.
Es gibt noch eine offene Frage. Eine frühere Dario-Mainnet-Session verhielt sich anders, aber ich habe das nicht unter denselben kontrollierten Bedingungen reproduziert, also bezeichne ich es nicht als Leck. Ich kann nur sagen, dass die Grenze „nur öffentlich“ in den beiden von mir geprüften Testnet-Integrationen eingehalten wurde, nicht, dass dies in jeder Umgebung garantiert ist.
„Eine Wallet-Verbindung sollte den von dir genehmigten Scope offenlegen, statt dich dazu zu zwingen, ihn abzuleiten.“
Was ich als Nächstes sehen würde: derselbe kontrollierte Test im Mainnet mit derselben Wallet-Version, sauberen Berechtigungen und identischer Instrumentierung, um zu prüfen, ob die Grenze über Umgebungen hinweg stabil bleibt.
#dusk $DUSK @Dusk
