$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂
Ich habe meine Polygon-Kampagnenbelohnungen die letzten 6 Monate gehalten und auf genau diesen einen guten Pump gewartet. 😭
Ursprünglich dachte ich, eine Wallet mit einem dApp zu verbinden sei im Grunde nur eine einzige Berechtigung.
Der Nutzer verbindet, die Anwendung sieht das Konto, und jede spätere Aktion läuft über diese Beziehung.
je mehr ich in die neue @Dusk Wallet geschaut habe, desto mehr wirkte es so, als sei das Verbinden nur der Anfang des Berechtigungsmodells.
Über $DUSK Connect kann ein dApp Profilzugriff, Signaturen, Transaktionen, Contract Calls oder eine geschützte Empfangsadresse anfordern.
Aber das Anfordern einer Aktion gibt der Anwendung nicht die Schlüssel des Nutzers.
Die Schlüssel bleiben lokal. Dusk sagt, dass Erweiterungs-Builds sie mit PBKDF2 und AES-GCM schützen, während native Builds Stronghold mit Argon2 verwenden. Die Wallet enthält außerdem Auto-Lock, ein Backoff bei fehlgeschlagenem Unlock und Berechtigungen, die auf jede anfordernde Origin zugeschnitten sind. #dusk
Das hat meine Sicht auf den dApp-Zugriff verändert.
Eine verbundene Seite kann so zugelassen werden, dass sie eine Aktion anfordern darf, ohne die Autorität zu erhalten, sie still und heimlich auszuführen.
Die Wallet bleibt die Genehmigungsgrenze.
Was meine Aufmerksamkeit nicht nur auf die lokale Schlüsselspeicherung gelenkt hat.
Sondern darauf, wie stark die Sicherheit jetzt davon abhängt, was der Genehmigungsbildschirm kommuniziert.
Ein privater Schlüssel kann geschützt bleiben, während der Nutzer trotzdem eine irreführende Contract-Call-Anfrage genehmigt, eine unlesbare Nachricht oder eine unerwartete Kontoanfrage. Per-Origin-Berechtigungen beschränken, welche Seite Zugriff erhält, aber sie können nicht beweisen, dass jede Anfrage von dieser Seite sicher ist.
Das Wallet-Repository trennt Genehmigungen für Transaktionen, lesbare und undurchsichtige Nachrichten, Authentifizierungs-Signings, Contract Calls und geschützte Adressen.
Aber Dusk Connect und die neue Wallet wurden für die Entwicklervorschau eingeführt, daher muss diese Berechtigungserfahrung sich noch über echten dApps und echtes Nutzerverhalten hinweg bewähren.
Schafft das Vorhalten der Schlüssel lokal und die Berechtigungen pro Origin die richtige Sicherheitsgrenze, oder wird eher die Klarheit jedes einzelnen Genehmigungsbildschirms entscheidend sein als der darunterliegende Verbindungsstandard??
Ich habe meine Polygon-Kampagnenbelohnungen die letzten 6 Monate gehalten und auf genau diesen einen guten Pump gewartet. 😭
Ursprünglich dachte ich, eine Wallet mit einem dApp zu verbinden sei im Grunde nur eine einzige Berechtigung.
Der Nutzer verbindet, die Anwendung sieht das Konto, und jede spätere Aktion läuft über diese Beziehung.
je mehr ich in die neue @Dusk Wallet geschaut habe, desto mehr wirkte es so, als sei das Verbinden nur der Anfang des Berechtigungsmodells.
Über $DUSK Connect kann ein dApp Profilzugriff, Signaturen, Transaktionen, Contract Calls oder eine geschützte Empfangsadresse anfordern.
Aber das Anfordern einer Aktion gibt der Anwendung nicht die Schlüssel des Nutzers.
Die Schlüssel bleiben lokal. Dusk sagt, dass Erweiterungs-Builds sie mit PBKDF2 und AES-GCM schützen, während native Builds Stronghold mit Argon2 verwenden. Die Wallet enthält außerdem Auto-Lock, ein Backoff bei fehlgeschlagenem Unlock und Berechtigungen, die auf jede anfordernde Origin zugeschnitten sind. #dusk
Das hat meine Sicht auf den dApp-Zugriff verändert.
Eine verbundene Seite kann so zugelassen werden, dass sie eine Aktion anfordern darf, ohne die Autorität zu erhalten, sie still und heimlich auszuführen.
Die Wallet bleibt die Genehmigungsgrenze.
Was meine Aufmerksamkeit nicht nur auf die lokale Schlüsselspeicherung gelenkt hat.
Sondern darauf, wie stark die Sicherheit jetzt davon abhängt, was der Genehmigungsbildschirm kommuniziert.
Ein privater Schlüssel kann geschützt bleiben, während der Nutzer trotzdem eine irreführende Contract-Call-Anfrage genehmigt, eine unlesbare Nachricht oder eine unerwartete Kontoanfrage. Per-Origin-Berechtigungen beschränken, welche Seite Zugriff erhält, aber sie können nicht beweisen, dass jede Anfrage von dieser Seite sicher ist.
Das Wallet-Repository trennt Genehmigungen für Transaktionen, lesbare und undurchsichtige Nachrichten, Authentifizierungs-Signings, Contract Calls und geschützte Adressen.
Aber Dusk Connect und die neue Wallet wurden für die Entwicklervorschau eingeführt, daher muss diese Berechtigungserfahrung sich noch über echten dApps und echtes Nutzerverhalten hinweg bewähren.
Schafft das Vorhalten der Schlüssel lokal und die Berechtigungen pro Origin die richtige Sicherheitsgrenze, oder wird eher die Klarheit jedes einzelnen Genehmigungsbildschirms entscheidend sein als der darunterliegende Verbindungsstandard??
🔐 Local key storage
🌐 Per-site permissions
👀 Clear approval screens
🧠 User judgment
8 Stunde(n) übrig
