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

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.

Let’s have a closer look at the details.

  • The use of The decision to serve Internet Identity under 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 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 is controlled much stricter than under, the domain is much less likely to suffer from such an incident.
  • Different ways of blocking 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 or, 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 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 any longer. It seems unlikely that the latter would apply to
  • 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 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.