Мне хотелось понять, какой именно доступ dApp получает от «Connect Wallet», поэтому я проверил реальный сценарий на Dario и Pieswap в Dusk testnet. В обоих случаях при первом подключении возвращались только profile ID и общедоступный аккаунт. Всплывающее окно было прямым: «Сайт сможет использовать только публичный аккаунт выбранного профиля». Только когда я запросил защищённый адрес получения (shielded receive address), появлялся второй шаг согласия, и только тогда в ответе появлялся shieldedAddress. Также изменялось само всплывающее окно — в нём упоминался «подлежащий распространению защищённый адрес получения». Обе интеграции показали одну и ту же последовательность.
Перевёрнутый вывод: я воспринимал «Connect Wallet» как одно событие предоставления разрешения. Это не так. В контролируемом тесте доступ к публичному аккаунту был отделён от передачи защищённого адреса получения именно в момент согласия.
Это разделение переносит часть границы минимального раскрытия в сам сценарий согласия кошелька, а не полностью оставляет её пользователю на управление. В обоих тестах нажатие «Connect» само по себе никогда не выдавало область (scope) защищённого адреса; dApp должен был пройти отдельный шаг согласия, чтобы получить её.
Я ещё один момент неправильно понял при исследовании. Я думал, что строка аккаунта длиной 132 символа может намекать на защищённый доступ. Нет. Оба dApp возвращали одинаковый формат аккаунта на базовом уровне, при этом shieldedAddress оставался отсутствующим, пока не был сделан явный запрос.
Остался один вопрос без ответа. Ранее сессия на Dario mainnet вела себя иначе, но я не смог воспроизвести это при тех же контролируемых условиях, так что я не называю это утечкой. Я могу лишь сказать, что граница разрешения «только публичное» сохранялась в двух проверенных интеграциях на testnet, но не утверждать, что она гарантирована для любой среды.
«Подключение кошелька должно показывать область, которую вы одобрили, а не заставлять вас догадываться».
Что я бы хотел увидеть дальше: тот же контролируемый тест на mainnet с той же версией кошелька, чистыми разрешениями и идентичной инструментализацией, чтобы выяснить, сохраняется ли эта граница в разных средах.
#dusk $DUSK @Dusk
Перевёрнутый вывод: я воспринимал «Connect Wallet» как одно событие предоставления разрешения. Это не так. В контролируемом тесте доступ к публичному аккаунту был отделён от передачи защищённого адреса получения именно в момент согласия.
Это разделение переносит часть границы минимального раскрытия в сам сценарий согласия кошелька, а не полностью оставляет её пользователю на управление. В обоих тестах нажатие «Connect» само по себе никогда не выдавало область (scope) защищённого адреса; dApp должен был пройти отдельный шаг согласия, чтобы получить её.
Я ещё один момент неправильно понял при исследовании. Я думал, что строка аккаунта длиной 132 символа может намекать на защищённый доступ. Нет. Оба dApp возвращали одинаковый формат аккаунта на базовом уровне, при этом shieldedAddress оставался отсутствующим, пока не был сделан явный запрос.
Остался один вопрос без ответа. Ранее сессия на Dario mainnet вела себя иначе, но я не смог воспроизвести это при тех же контролируемых условиях, так что я не называю это утечкой. Я могу лишь сказать, что граница разрешения «только публичное» сохранялась в двух проверенных интеграциях на testnet, но не утверждать, что она гарантирована для любой среды.
«Подключение кошелька должно показывать область, которую вы одобрили, а не заставлять вас догадываться».
Что я бы хотел увидеть дальше: тот же контролируемый тест на mainnet с той же версией кошелька, чистыми разрешениями и идентичной инструментализацией, чтобы выяснить, сохраняется ли эта граница в разных средах.
#dusk $DUSK @Dusk
