Eu queria saber o que, de fato, o “Connect Wallet” concede acesso a uma dApp, então testei o fluxo real no Dario e no Pieswap na testnet do Dusk. Em ambos, a primeira conexão retornou apenas o ID do perfil e a conta pública. O popup era explícito: “O site só poderá usar a conta pública do perfil selecionado.” Só quando pedi o endereço de recebimento protegido é que apareceu um segundo passo de consentimento, e somente então a resposta incluiu shieldedAddress. O popup também mudou, nomeando o “endereço de recebimento protegido compartilhável.” As duas integrações mostraram a mesma sequência.
Aqui vai a virada: eu estava tratando “Connect Wallet” como um único evento de permissão. Não é. O teste controlado separou o acesso à conta pública do compartilhamento do endereço de recebimento protegido no momento do consentimento.
Essa separação coloca parte do limite de divulgação mínima no fluxo de consentimento da carteira, não totalmente sob responsabilidade do usuário. Nos dois testes, clicar em “Connect” sozinho nunca concedeu o escopo do endereço protegido; a dApp precisava atravessar uma etapa de consentimento separada para obtê-lo.
Eu também entendi uma coisa errada ao investigar. Achei que a string de conta com 132 caracteres poderia indicar acesso protegido. Não indica. Ambas as dApps retornaram o mesmo formato de conta na base, enquanto shieldedAddress ficou ausente até o pedido explícito.
Ainda há uma pergunta sem resposta. Uma sessão anterior no mainnet do Dario se comportou de forma diferente, mas eu não consegui reproduzir isso nas mesmas condições controladas, então não estou chamando de vazamento. Posso apenas dizer que o limite de permissão somente público se manteve nas duas integrações de testnet que verifiquei, não que esteja garantido em todos os ambientes.
“Uma conexão de carteira deve expor o escopo que você aprovou, não te deixar inferir.”
O que eu gostaria de ver a seguir: o mesmo teste controlado no mainnet com a mesma versão da carteira, permissões limpas e instrumentação idêntica, para verificar se o limite se mantém entre ambientes.
#dusk $DUSK @Dusk
Aqui vai a virada: eu estava tratando “Connect Wallet” como um único evento de permissão. Não é. O teste controlado separou o acesso à conta pública do compartilhamento do endereço de recebimento protegido no momento do consentimento.
Essa separação coloca parte do limite de divulgação mínima no fluxo de consentimento da carteira, não totalmente sob responsabilidade do usuário. Nos dois testes, clicar em “Connect” sozinho nunca concedeu o escopo do endereço protegido; a dApp precisava atravessar uma etapa de consentimento separada para obtê-lo.
Eu também entendi uma coisa errada ao investigar. Achei que a string de conta com 132 caracteres poderia indicar acesso protegido. Não indica. Ambas as dApps retornaram o mesmo formato de conta na base, enquanto shieldedAddress ficou ausente até o pedido explícito.
Ainda há uma pergunta sem resposta. Uma sessão anterior no mainnet do Dario se comportou de forma diferente, mas eu não consegui reproduzir isso nas mesmas condições controladas, então não estou chamando de vazamento. Posso apenas dizer que o limite de permissão somente público se manteve nas duas integrações de testnet que verifiquei, não que esteja garantido em todos os ambientes.
“Uma conexão de carteira deve expor o escopo que você aprovou, não te deixar inferir.”
O que eu gostaria de ver a seguir: o mesmo teste controlado no mainnet com a mesma versão da carteira, permissões limpas e instrumentação idêntica, para verificar se o limite se mantém entre ambientes.
#dusk $DUSK @Dusk
