Saya ingin tahu apa sebenarnya yang diberikan akses dApp oleh "Connect Wallet", jadi saya menguji alur sesungguhnya di Dario dan Pieswap pada Dusk testnet. Di keduanya, koneksi pertama hanya mengembalikan profile ID dan akun publik. Pop-up-nya jelas: "Situs hanya akan dapat menggunakan akun publik dari profil yang dipilih." Baru ketika saya meminta alamat penerimaan (receive) yang disamarkan (shielded), muncul langkah persetujuan kedua, dan barulah responsnya menyertakan shieldedAddress. Pop-up juga berubah, menyebut "alamat penerimaan shielded yang dapat dibagikan". Kedua integrasi menampilkan urutan yang sama.
Inilah pembalikannya: saya menganggap "Connect Wallet" sebagai satu peristiwa izin. Itu tidak. Pengujian terkontrol memisahkan akses akun publik dari pembagian alamat penerimaan shielded pada titik persetujuan.
Pemisahan itu menempatkan sebagian dari batas minimum-disclosure ke dalam alur persetujuan dompet, bukan sepenuhnya pada pengguna untuk mengelola. Pada kedua pengujian, mengklik "Connect" saja tidak pernah memberikan cakupan alamat yang disamarkan; sebuah dApp harus melewati langkah persetujuan terpisah untuk mendapatkannya.
Saya juga mendapat satu hal yang salah saat menyelidiki. Saya mengira string akun 132 karakter mungkin mengisyaratkan akses yang disamarkan. Tidak. Kedua dApp mengembalikan format akun yang sama pada kondisi dasar, sementara shieldedAddress tetap tidak ada sampai permintaan eksplisit.
Masih ada satu pertanyaan yang belum terjawab. Sesi mainnet Dario sebelumnya berperilaku berbeda, tapi saya belum mereproduksinya di bawah kondisi terkontrol yang sama, jadi saya tidak menyebutnya sebagai kebocoran. Yang bisa saya katakan adalah batas izin hanya-publik bertahan di kedua integrasi testnet yang saya periksa, bukan bahwa itu pasti berlaku di setiap lingkungan.
"Koneksi dompet harus menampilkan cakupan yang Anda setujui, bukan membuat Anda menebaknya."
Yang ingin saya lihat berikutnya: uji terkontrol yang sama di mainnet dengan versi dompet yang sama, izin yang bersih, dan instrumentasi yang identik, untuk melihat apakah batas tersebut bertahan lintas lingkungan.
#dusk $DUSK @Dusk
Inilah pembalikannya: saya menganggap "Connect Wallet" sebagai satu peristiwa izin. Itu tidak. Pengujian terkontrol memisahkan akses akun publik dari pembagian alamat penerimaan shielded pada titik persetujuan.
Pemisahan itu menempatkan sebagian dari batas minimum-disclosure ke dalam alur persetujuan dompet, bukan sepenuhnya pada pengguna untuk mengelola. Pada kedua pengujian, mengklik "Connect" saja tidak pernah memberikan cakupan alamat yang disamarkan; sebuah dApp harus melewati langkah persetujuan terpisah untuk mendapatkannya.
Saya juga mendapat satu hal yang salah saat menyelidiki. Saya mengira string akun 132 karakter mungkin mengisyaratkan akses yang disamarkan. Tidak. Kedua dApp mengembalikan format akun yang sama pada kondisi dasar, sementara shieldedAddress tetap tidak ada sampai permintaan eksplisit.
Masih ada satu pertanyaan yang belum terjawab. Sesi mainnet Dario sebelumnya berperilaku berbeda, tapi saya belum mereproduksinya di bawah kondisi terkontrol yang sama, jadi saya tidak menyebutnya sebagai kebocoran. Yang bisa saya katakan adalah batas izin hanya-publik bertahan di kedua integrasi testnet yang saya periksa, bukan bahwa itu pasti berlaku di setiap lingkungan.
"Koneksi dompet harus menampilkan cakupan yang Anda setujui, bukan membuat Anda menebaknya."
Yang ingin saya lihat berikutnya: uji terkontrol yang sama di mainnet dengan versi dompet yang sama, izin yang bersih, dan instrumentasi yang identik, untuk melihat apakah batas tersebut bertahan lintas lingkungan.
#dusk $DUSK @Dusk
