Tôi muốn biết “Connect Wallet” thực sự cấp cho dApp quyền truy cập vào những gì, nên tôi đã thử quy trình thực tế trên Dario và Pieswap ở Dusk testnet. Ở cả hai trường hợp, lần kết nối đầu tiên chỉ trả về profile ID và tài khoản public. Cửa sổ bật lên ghi rõ: “Trang web chỉ có thể sử dụng tài khoản public của profile đã chọn.” Chỉ khi tôi yêu cầu địa chỉ nhận (receive) được che chắn (shielded) thì mới xuất hiện bước đồng ý (consent) thứ hai, và chỉ khi đó phản hồi mới bao gồm shieldedAddress. Cửa sổ bật lên cũng thay đổi, đặt tên cho “địa chỉ nhận được che chắn có thể chia sẻ (shareable shielded receive address)”. Cả hai tích hợp đều hiển thị cùng một chuỗi.
Đây là điểm lật ngược: Tôi đang coi “Connect Wallet” như một sự kiện cấp quyền duy nhất. Không phải vậy. Thử nghiệm kiểm soát của tôi đã tách việc truy cập tài khoản public khỏi việc chia sẻ địa chỉ nhận được che chắn tại thời điểm xin đồng ý.
Sự tách bạch này đưa một phần ranh giới “tiết lộ tối thiểu” vào trong luồng đồng ý của ví, chứ không phải hoàn toàn để người dùng tự quản lý. Trong cả hai bài thử nghiệm, việc bấm “Connect” đơn thuần không bao giờ cấp phạm vi địa chỉ được che chắn; dApp phải đi qua một bước đồng ý riêng để có được nó.
Tôi cũng hiểu sai một điều khi đang điều tra. Tôi nghĩ chuỗi tài khoản dài 132 ký tự có thể gợi ý khả năng truy cập được che chắn. Không phải. Cả hai dApp đều trả về cùng định dạng tài khoản ở trạng thái nền (baseline), trong khi shieldedAddress vẫn vắng mặt cho đến khi có yêu cầu rõ ràng.
Vẫn còn một câu hỏi chưa được giải quyết. Một phiên làm việc trên Dario mainnet trước đó hoạt động khác đi, nhưng tôi chưa thể tái tạo lại nó trong cùng các điều kiện kiểm soát, nên tôi không gọi đó là rò rỉ (leak). Tôi chỉ có thể nói rằng ranh giới quyền chỉ public đã được giữ vững qua hai tích hợp testnet mà tôi kiểm tra, chứ không khẳng định là nó chắc chắn đúng với mọi môi trường.
“Việc kết nối ví phải hiển thị phạm vi mà bạn đã phê duyệt, không nên khiến bạn phải suy đoán.”
Điều tôi muốn xem tiếp theo: cùng thử nghiệm kiểm soát trên mainnet với cùng phiên bản ví, quyền được dọn sạch (clean permissions) và công cụ đo lường (instrumentation) giống hệt, để xem liệu ranh giới này có được duy trì xuyên suốt các môi trường hay không.
#dusk $DUSK @Dusk
Đây là điểm lật ngược: Tôi đang coi “Connect Wallet” như một sự kiện cấp quyền duy nhất. Không phải vậy. Thử nghiệm kiểm soát của tôi đã tách việc truy cập tài khoản public khỏi việc chia sẻ địa chỉ nhận được che chắn tại thời điểm xin đồng ý.
Sự tách bạch này đưa một phần ranh giới “tiết lộ tối thiểu” vào trong luồng đồng ý của ví, chứ không phải hoàn toàn để người dùng tự quản lý. Trong cả hai bài thử nghiệm, việc bấm “Connect” đơn thuần không bao giờ cấp phạm vi địa chỉ được che chắn; dApp phải đi qua một bước đồng ý riêng để có được nó.
Tôi cũng hiểu sai một điều khi đang điều tra. Tôi nghĩ chuỗi tài khoản dài 132 ký tự có thể gợi ý khả năng truy cập được che chắn. Không phải. Cả hai dApp đều trả về cùng định dạng tài khoản ở trạng thái nền (baseline), trong khi shieldedAddress vẫn vắng mặt cho đến khi có yêu cầu rõ ràng.
Vẫn còn một câu hỏi chưa được giải quyết. Một phiên làm việc trên Dario mainnet trước đó hoạt động khác đi, nhưng tôi chưa thể tái tạo lại nó trong cùng các điều kiện kiểm soát, nên tôi không gọi đó là rò rỉ (leak). Tôi chỉ có thể nói rằng ranh giới quyền chỉ public đã được giữ vững qua hai tích hợp testnet mà tôi kiểm tra, chứ không khẳng định là nó chắc chắn đúng với mọi môi trường.
“Việc kết nối ví phải hiển thị phạm vi mà bạn đã phê duyệt, không nên khiến bạn phải suy đoán.”
Điều tôi muốn xem tiếp theo: cùng thử nghiệm kiểm soát trên mainnet với cùng phiên bản ví, quyền được dọn sạch (clean permissions) và công cụ đo lường (instrumentation) giống hệt, để xem liệu ranh giới này có được duy trì xuyên suốt các môi trường hay không.
#dusk $DUSK @Dusk
