[FOLLOW UP ON ITEM] New canisters will only be accessible through the icp0.io domain. Existing canisters will be accessible both through ic0.app and icp0.io


TLDR: As of March 20, 2023 April 20, 2023, new canisters will only be accessible through the icp0.io domain. Existing canisters will be accessible both through ic0.app and icp0.io.

1. Summary

In February 2023, Spamhaus temporarily added ic0.app to a blocklist. As a result, an extensive mitigation plan was put in place and communicated to the IC community. While the need for a new default domain is less pressing now that ic0.app is no longer on a blocklist, good reasons remain to introduce a new default domain. In particular, by no longer making new canisters accessible through ic0.app, the ic0.app domain is less likely to end up on a new blocklist. Existing dapps, such as Internet Identity under identity.ic0.app, are thus shielded from the impact of user-generated content.

2. Next Step: On Monday, March 20 , the following will happen:

  • New canisters deployed to the IC will be accessible through the icp0.io domain and not through ic0.app. Developers may additionally configure a custom domain for the dapp.
  • This change will happen via an update to the boundary nodes

3. This will be communicated to developer and wider ICP community in the following places:

  • Developer documentation will reflect this change: Internet Computer Content Validation Bootstrap
  • Announcements via social media
  • Update dfx to use icp0.io instead of ic0.app going forward. This will be part of the 0.13.2 release.

4. What this means for existing smart contracts:

  • This will not affect existing canister smart contracts using the ic0.app domain.
  • New existing canisters can also be accessed via the icp0.io domain

I haven’t been following the follow up chats after the incident. What makes the .io superior to the .app? Or are we just protecting the .app domains during this transition period

It is not necessarily superior. Since there will be many more new canisters than currently exist, the main intent is to limit the reputational impact on .app domain by having new canisters exist in the new domain.

Does that make more sense?


Yep. Thanks for the clarification. Keep up the good work. Can’t wait for the boundary node changes

1 Like

For those who use custom domains, consider the ‘running on-chain’ banners

Accesible via dfinity.org
DFINITY Brand Guide - DFINITY Brand Guide


raw.icp0.io throws security errors on Chrome browsers…
So all new canisters created by our clients that need raw will not be viewable to them without
explicitly closing out a browser ‘red screen of death…’

Don’t fix what is not broken :stuck_out_tongue_winking_eye: But really, what is the proposed solution for this??
Wait until raw.icp0.io is removed from the blocklists and have users just deal with it?

Check out the post here for more details… It seems like it is on a blocklist.

Also what about the host in agent.js files? https://ic0.app will this still work for calling new canisters?

Regarding blocklisting:
I can confirm that raw.icp0.io was listed on Google Safe Browsing, but was removed ~2 weeks ago.

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

But I can also confirm that Google Safe Browsing lists some canisters that are already served via icp0.io. If you check the Safe Browsing entry it states Some pages on this site are unsafe, which means that it shows the warning only for those sites that are listed and not all.

I don’t see any warning, when I browse a canister using raw.icp0.io or icp0.io.

Regarding raw in general:
To my understanding raw works for icp0.io as it works for ic0.app. Maybe @raymondk can comment on that as well.

1 Like

In that thread ‘Google Safebrowsing’ was the only one left. It has been removed from that list since then?

Last time it was users who mentioned it to us. Our team also, did not see any issues until users reported it. I guess we can retry this and see what they say Monday.

If it is confirmed off all lists, hopefully there will no be issues :slight_smile:

1 Like

If you are using the latest version of agent-js, it has been changed to send /api calls to icp-api.io.
see: feat: changes default host and supports icp-api.io (#690) · dfinity/agent-js@6b64030 · GitHub

Also starting v1.5.2 the Service Worker will translate all /api requests to go to icp-api.io
see: SW: Use new api gateway icp-api.io · dfinity/ic@0aee610 · GitHub


Cool. But the old one still works right?

For example, say we have 500 client apps that are in use sometimes but were never intended to be updated.

OpenDNS is blocking it currently:


Thanks for heads up. Letting @jwendling and @raymondk know.

Hey @diegop

  1. Can you ask the team to postpone this until we are off lists?
    Last time I changed it, a few hours later I got bombarded with messages that sites were blocked or no longer working…I can un-revert those changes… but I really do not want to un-un-revert again.

  2. The question above about the /api endpoint. The old endpoint ic0.app will always work right? I do not need to go back and notify 500~ people to update to a new endpoint @raymondk ? New sites can use icp-api.io endpoint, while old sites can keep the old endpoint?

Yes, postponing is very much possible if people need more time. It is good to do it as early as possible, but definitely looking for developer feedback. I think it would be helpful if you share how much more time you think is needed. “once we are off lists” is a bit vague, as I think the domain will be added and removed from lists for a while…

Does that make sense?

1 Like

I had 10 people test and 3 said they saw the blocked list error on Chrome… Someone above also mentioned Cisco blocklist. New domain should === old domain in usability.

I have never saw or was reported to about a browser level error about phishing schemes with the raw.ic0.app domain… If 1/3 users checking out IC sites see this error, it is not good for anyone.

Test, test, test, remove from lists. Do what cryptographers do and make the probability 1/F where F is some very large field :blush:

@jwendling mentioned not seeing any error. My entire team saw no errors last time, but when we pushed to prod a lot of people globally noticed within an hour. This needs to be tested in many locations to make sure that it is very unlikely for users to get blocked.

1 Like

I have escalated your concerns to folks @apotheosis (though I am sure they are reading this thread actively)

1 Like
  • /api calls will continue to work for all canisters on all the domains (ic0.app, icp0.io and icp-api.io)
  • If you are using the default service worker or more recent version of the agents your api calls are already going to icp-api.io

We can postpone for sure but @diegop is right that it is likely that icp0.io will continue going on and off spam lists. I would recommend using the [custom domains] feature (Custom domains | Internet Computer) and making api calls to icp-api.io


The reason for this was an active entry in the Google Safe Browsing list, which is not present anymore.

In general I fully agree on what @raymondk wrote. The problem is that we can’t guarantee that the domain will never end up on another list. We are actively approaching any Vendor that we are aware of and in the last days, we have seen additional entries for Sophos, Heimdal and CyRadar.

ic0.app is not affected by the entries at the moment because the people behind the malicious canisters are already actively using the new domain icp0.io and no longer use ic0.app. Lucky for us! If we don’t migrate to the new domain and leave ic0.app open, there is a persistent threat to ic0.app, which is a bigger risk because it still impacts system services like Internet Identity.

As @raymondk already mentioned, we strongly recommend to use Custom Domains as a shared domain is affected by the usage all canisters and this unfortunately includes those who use it for a malicious purpose.

@BHare1985 Thank you for the notification. We will contact Cisco and hopefully solve the case very soon!

1 Like