I am Bugs from the Sonic team.
I have a suggestion based on the feedback from the customer support team.
We found that a lot of new users are coming to IC and start buying assets in IC. A lot of these newcomers are using Sonic to trade tokens. However, they’re encountering confusion with the NNS wallet subaccount generation for each domain.
Is there a specific reason behind implementing this feature aside from privacy concerns?
Could we explore alternative options, such as providing the choice to use the same wallet address with a switch (allowing users to toggle the privacy mode on or off)?
Want to know your thoughts on this and would be great to know the possibility of updating this feature in NNS.
Thanks in advance.
The main reason of the subaccount structure is not privacy, it’s security. And it derives, in a pretty direct sense, from the browser security model.
Browsers implement access control by origin, where an origin is the triplet of domain, protocol, and port. Generally, code from some origin can access everything that is associated with that origin, but nothing from other origins. The principals derived from II take the same route, deriving a principal per origin (as specified by the URL used in the derivation). So dapps from different origin are isolated.
If two dapps were to use the same principal, they would have the same privileges on any canister on the IC. This may sometimes simplify things, but sharing principals also creates a major risk: Any dapp the user were to authenticate with has control over all the user’s assets!
The strategy that II uses is of course quite conservative: everything that is not the same is fully isolated. The underlying model would allow for more flexible use; for example one could allow users to explicitly manage several “security domains,” akin to the functionality in MetaMask or Plug. This is possible, it’s mostly a question of whether it can be made usable in a secure way. The identity and authentication working group is also working on several standards that improve support for “wallet” functionality, encouraging a model where the wallet exists outside of each particular frontend dapp. I think the latter model may actually be more promising.
Thankyou @bjoern for the explanation.