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

Okay, thanks for clarifying. I was aware of the risks at the user end, your post just got me worried there were risks at the NNS website / Internet Identity end that I was unaware of that were similar to the risks involved with browser wallets like Metamask.

Hi @bjoern,

Thank you for your answer.

Does this mean that we can hope hold our NFT through the Ledger Hardwallet soon ? If yes, it is marvelous, and what would the timeline be (approximatively of course) ?

I also don’t understand why we still don’t have the signing of cbor messages with ledger available. we should be able to interact with certain sites with our ledger.

Among the authentication types of Internet Identity, Security key is the most secure because it never passes through the browser or memory, and biometric authentication is equally secure because it is stored in the hardware chip (TPM) in the PC. However, the seed phrase is less secure because it is temporarily stored in memory when it is generated and then deleted.

Security key >= biometric >> seed phrase

Seed phrase with low security is problematic, so security key is recommended, is that correct?

Even so, it is more secure than browser-based wallets like Metamask and Plug. Because,

  • Seed phrase is a one-time use of memory (and then deleted), while browser-based wallets are stored in memory for each signature to tx.

  • Browser-based wallets do not store the private key in the TPM like biometric authentication, but rather store it encrypted in the local storage of the browser, which is less secure ( I could be wrong).

However, the most secure one is a hardware wallet like Security key, which does not pass the private key through browser or memory, and verifies and displays the tx on the hardware, so we are considering to develop it so that we can use it. Is that correct?

hardware wallet(ongoing) > Security key >= biometric > seed phrase >> browser-based wallets


Depends on the application for II because of the ephemeral private key stored in local storage. This is even worse than MetaMask. That key can do anything that the II can do, so your WebAuthN device isn’t providing any security after you’ve logged in.

What would be amazing is if we could require additional verification from a WebAuthN device for certain actions.

1 Like

II never stores key material in local storage. That’s why you have to re-authenticate on every login.


It’s probably realistic to build this functionality in the Ledger application in a few months. The additional implementation effort is moderate, but such an update will have to go through a security review with Ledger, which will usually take a while.

Regarding the concerns with threshold ECDSA signing: We are following three different paths toward improving the security over time:

  1. Diversifying the set of node providers (NPs). If you have been following NNS proposals recently, you must have seen several proposals registering new NPs. So the IC is getting more diversity in its nodes, which will allow the NNS to improve the diversity of nodes in the subnets that host the threshold keys, and also grow that subnet over time. As with anything organic, that just needs a bit of time to grow.
  2. Supporting trusted execution environments (TEEs). We are building support for AMD’s SEV-SNP in the node deployments, which provide some additional security against potentially malicious NPs. This work is in progress, and will play well with the new “Gen 2” node architecture that the new NPs are rolling out.
  3. Threshold trade-off: We can parameterize the protocol to achieve better security (meaning: improved resilience in terms of number of NPs that have to collude to create a signature) at the cost of weaker liveness (less misbehaving NPs could stop the subnet from issuing signatures). This is a protocol-level improvement that is orthogonal to the above two.

I don’t think that this is fair, on multiple levels. First, there is (and has always been) ongoing work toward improving the security of ICP, in several components and aspects. We have made significant improvements since launch, and we will continue doing so. This work often receives less publicity, of course, since in many cases it is just invisible to users.

Second, you seem to imply that deploying on the IC was generally less secure than on “competing systems.” The statement is vague and thus hard to respond to, but I would guess that such comparisons are generally hard because they tend to compare apples with oranges. Anyway, I’d be interested to know what you had in mind.

Third, it would be infeasible (and not helpful either) to now stop all the work we are doing and focus on a single aspect, like security. Are there security aspects we have to work on? Absolutely! But so are aspects of scalability (e.g., number of neurons in the governance canister, number of canisters on a subnet, size of the state a subnet can handle), developer experience, and so forth.


The ephemeral keys must be stored somewhere accessible to the domain (accessible to its JS) so that signing can occur, I don’t understand this.

My understanding is there is a keypair created on every login that can sign for the II. That key is not protected by hardware and is accessible to JS and thus XSS or other similar attacks.

1 Like

I’ve got a page or two of notes on security concerns I’ve come across while building the prototype of Backed USD, but managed to make myself busy again and don’t have time to flesh it out now. I hope to within a week or so.

For now, I’ll just dispel a couple of possible misunderstanding, plus stating that the fact that there is no way to securely connect to a dapp is alone probably enough to concede that the system is not “as secure as competing systems” today.

First, as a relative newcomer I have no idea why the foundation has chosen to do the things it’s done: all I know is you’ve managed to create a groundbreaking system that mostly works. What I mean is only that, as you know, the world doesn’t care about how efficiently we allocate resources or how diligently we work: it only cares about the outcome, the concrete offering. What I mean is I don’t claim there haven’t been security improvements, perhaps massive ones that have required great effort and dexterity. I only claim that if those don’t amount to equal or better than the alternative, we’re in trouble. In particular, I mean no criticism of the foundation or its work (I don’t understand it well enough internally to comment): I only mean that the situation we’re in, the state of the network, is vulnerable to several attacks for a host of reasons, regardless of how much or how little work or improvements or what reasons have led to it.

1, 2, 3 above are important improvements (I understand 3 less well). They help.


Maybe, I don’t know, that’s why I say “perhaps”, and “appears to be”. But also, maybe not, and perhaps the situation is such that really an exclusive focus on security would make sense for a while. It is not at all obvious to me from what I’ve seen.

If all goes well I hope to be back with a more detailed response soon.

That would be very helpful – looking forward to that!

1 Like

There is an ephemeral key that is kept in memory, which is created for each session. I just checked that we are currently using a key that is actually accessible to JS, it seems preferable to use a type of key where at least the private key cannot be extracted from JS. I’ll check with the team when they plan to migrate there. Either way, this is entirely in the origin of II, and we intentionally keep the codebase of II small and simple.


Why is using an air gapped device more secure than a hardware wallet?

Not an expert like Bjoern is but i interpreted his statement that air gapped removes the potential of a bug in the hardware wallet.

Air gap has no internet connection so no potential for bugs (hardware wallets have very limited basic software, but still software) or hardware design flaws to affect you.


Hey - we switched all of our domains to last week because of this warning… we come back after the weekend to find users complaining that domain throws errors on their browsers and the original domain does not… what is going on here?

Which one should be used as of 2-28-2023?

For domain…

Hey apotheosis!

Unfortunately, we discovered that the domain, which we recently introduced as an alternative default domain, has been used for malicious content.

As a result the following providers/products have flagged (only the subdomain raw) on their list as spam/phishing:

  • Google Safebrowsing
  • Netcraft
  • Kaspersky
  • Emisoft

We will work with the providers/products and were already able to remove the entry of Netcraft, Kaspersky and Emisoft.

Update: Sorry mixed the domains in my original post. It’s now updated to

Thanks🙏 switching back to the old one.

Depending on how much effort it is for you to switch and how much you rely on raw URL, I would suggest to not switch back yet, because the same risk also applies to, as we experienced with the Spamhaus listing.
In general its highly recommended to use custom domains to not rely on either of them.

Update: Just double checked your canister id from the screenshot and Kinic is indeed a special use case. So in your case switching definitely makes sense.

1 Like

This will keep happening with every domain. It’s a trivially simple attack vector that is now widely known. I reiterate what I suggested upthread:
“Have a domain reserved for core services and apps. Perhaps an NNS vote could be required to have a site on that core services domain, making it a community whitelisted IC. That way, we avoid having to censor while also sealing off any nonsense that goes on in the wider network from systemically important services. Because making a malicious website or app is extremely easy. Now that this issue is public, people will do it just to sabotage the IC.”

Good news: is not listed on Google Safe Browsing anymore and the red warning should disappear.