Important Community Update on ic0.app domain being flagged by an anti-spam blocklist

[bjoern]

@lastmjs

I thinks it’s important to reflect on the design of II. It seems almost unbelievable to me that the design allows a user to possibly lose their II if a domain name disappears.

The web authentication standard specifies that the credentials are bound to the origin, meaning (amongst others) the domain name. So as long as we are in the realm of web authentication (which allows us to combine a pretty good level of security with a pretty good level of usability), there is not much we can fundamentally do about this. That doesn’t mean that things did not go wrong or we shouldn’t change things, it just limits our options.

I think this should be scrutinized and mitigated somehow, quite unnerving. A self-sovereign identity should not be inextricably linked to a centralized naming service.

Let’s have a closer look at the details.

• The use of ic0.app: The decision to serve Internet Identity under identity.ic0.app was, in retrospect, wrong. I don’t think there’s much more to say about this now, other than that we already had planned migrating to identity.internetcomputer.org before this incident; the incident simply began before we had the nice UI flow prepared. This work will continue, and we will migrate to the new domain regardless. As the content under internetcomputer.org is controlled much stricter than under ic0.app, the domain is much less likely to suffer from such an incident.
• Different ways of blocking ic0.app: There are different possible levels of impact for the domain name, and the one we saw is actually the most benign. It is relatively easy to circumvent on the client side with a moderate level of tech savviness (use a different DNS resolver like 8.8.8.8 or 1.1.1.1, use a VPN). A worse level would be Google (the owner of .app) completely blocking the domain. In that case, users would have to change domain resolution (e.g. edit /etc/hosts, or set the DNS resolver to one that DFINITY or the community could provide, which would still resolve ic0.app) and accept a certificate that is not issued by a generally trusted CA, as Let’s Encrypt, now any other CA, would not extend our certificates for ic0.app any longer. It seems unlikely that the latter would apply to internetcomputer.org.
• Recovery phrases: As you pointed out in a different message, recovery phrases as implemented in Internet Identity today have serious security drawbacks. In contrast to the web authentication keys, they are not held on a specific secure chip but simply in browser memory, which makes them more prone to attacks.

So where does that leave us and where should we go? In principle I see three avenues:

1. Make the use of web authentication more reliable: This is the path we are already taking with identity.internetcomputer.org. Additional steps could be extending the IC to act as a DNS resolver or providing web extensions for browsers.
2. Provide additional recovery options – recovery phrases have security drawbacks and recovery devices still suffer from the domain name problem. Tech-savvy users can already use dfx or ic-repl to effectively register an additional “device,” possibly even with a key stored on an air-gapped device. We could have a phone app that works in exactly the same way as the recovery phrase, but without the use of browsers?
3. Remind everyone to use hardware wallets for managing (at least larger amounts of) tokens and neurons. Internet Identity is great for authenticating toward dapps, but it still fundamentally relies on the security of the browser (which is the still piece of software most likely to be affected by zero days), and so fundamentally that isn’t a good way of managing things of significant value.