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:
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.
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 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?
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.
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
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.
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âŚ
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
@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.
/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!
But really, what is the proposed solution for this??
