#dusk $DUSK @Dusk
Saya menelusuri kembali catatan keamanan dompet Dusk dan changelog v0.3.0 dengan satu asumsi sederhana: keamanan dompet berarti melindungi frasa seed dan menetapkan kata sandi yang kuat.
Desain ekstensi ini lebih bersifat operasional. Mnemonic (frasa mnemonik)-nya dienkripsi saat disimpan menggunakan PBKDF2 dan AES-GCM-256, tetapi mnemonic yang sudah terbuka masih berada di memori JavaScript dan tidak bisa dijamin akan di-nol-kan (zeroized). Auto-lock dijalankan oleh alarm browser; v0.3.0 memperbaiki stempel waktu aktivitas yang sebelumnya tetap bertahan saat restart worker latar belakang dan mempertahankan peristiwa status terkunci untuk dApps yang terhubung. Provider juga memeriksa panjang memo dan menolak memo pada panggilan kontrak karena payload bisa berupa memo atau panggilan, bukan keduanya. Catatan vault versi lama yang tidak didukung dibersihkan dan mengharuskan pengimporan ulang mnemonic, bukan diterima secara diam-diam.
Itu membuat saya melihatnya dengan cara berbeda.
Interpretasi saya: privasi bisa gagal di batas sesi dan local-state meskipun kriptografi transaksi yang dilindungi (shielded) sudah kuat.
Ketidakpastian saya ada pada trade-off pemulihan. Apakah penolakan format vault lama benar-benar melindungi pengguna dari catatan yang dimanipulasi atau lemah, atau justru menciptakan risiko operasional baru ketika pengguna tidak bisa menemukan seed? Dan apakah auto-lock yang sering akan memperkuat penggunaan nyata, atau justru melatih orang untuk menyetujui prompt tanpa membaca?
Saya ingin mengamatinya dalam praktik.
Saya menelusuri kembali catatan keamanan dompet Dusk dan changelog v0.3.0 dengan satu asumsi sederhana: keamanan dompet berarti melindungi frasa seed dan menetapkan kata sandi yang kuat.
Desain ekstensi ini lebih bersifat operasional. Mnemonic (frasa mnemonik)-nya dienkripsi saat disimpan menggunakan PBKDF2 dan AES-GCM-256, tetapi mnemonic yang sudah terbuka masih berada di memori JavaScript dan tidak bisa dijamin akan di-nol-kan (zeroized). Auto-lock dijalankan oleh alarm browser; v0.3.0 memperbaiki stempel waktu aktivitas yang sebelumnya tetap bertahan saat restart worker latar belakang dan mempertahankan peristiwa status terkunci untuk dApps yang terhubung. Provider juga memeriksa panjang memo dan menolak memo pada panggilan kontrak karena payload bisa berupa memo atau panggilan, bukan keduanya. Catatan vault versi lama yang tidak didukung dibersihkan dan mengharuskan pengimporan ulang mnemonic, bukan diterima secara diam-diam.
Itu membuat saya melihatnya dengan cara berbeda.
Interpretasi saya: privasi bisa gagal di batas sesi dan local-state meskipun kriptografi transaksi yang dilindungi (shielded) sudah kuat.
Ketidakpastian saya ada pada trade-off pemulihan. Apakah penolakan format vault lama benar-benar melindungi pengguna dari catatan yang dimanipulasi atau lemah, atau justru menciptakan risiko operasional baru ketika pengguna tidak bisa menemukan seed? Dan apakah auto-lock yang sering akan memperkuat penggunaan nyata, atau justru melatih orang untuk menyetujui prompt tanpa membaca?
Saya ingin mengamatinya dalam praktik.
