As far as I know, Dfinity operates all boundary nodes and there is no clarity on when this will change. How does the whack-a-mole method work in this reality? Can’t the US just tell Dfinity to remove access through all boundary nodes and if Dfinity fails to comply, come after Dfinity itself?
1 Like
-
how can we contact the canister if its not served by any boundary node?
-
If the canister is still reachable, wouldn’t authorities reauest a takedown to the node provider running it?
1 Like
the BN API’s are distinct from the http handling logic. The http handling logic will remove .ic0.app, but requests to /api/v2/<canisterid> are unaffected by takedown requests.
The Node provider doesn’t have the authority or the ability to take down a canister, or to opt out of hosting any particular canister at this point.
@tsetse This work is underway - we’ve been migrating bare metal boundary nodes to a VM-based model, and monitoring for stability. The goal is to decentralize the operation of boundary nodes soon, but I won’t do something irresponsible like promising a date
8 Likes
Forgive me if this has been brought up in the thread.
I have an interesting thought experiment that may help to poke holes in some moral/legal/logical arguments about censorship.
What would we do if there were a dangerous canister causing serious harm to the IC itself? Let’s say this canister was extremely well-funded and very effective at causing havoc in various ways.
Would we censor it?
I’m aware, but I doubt similar technicalities would be enough for authorities. Also in case a canister were blacklisted by all boundary nodes, would only incoming http request be blocked? Would the canister still be able to perform http requests?
How would this canister harm the IC? By exposing node providers to legal issues or by abusing some vulnerability?
1 Like
Any of those things, or dos attacks of some kind
Of course, I’d vote to take it down because I care my interest, the long term success of ic.
However I don’t think anybody would be able to permanently block a service, technically always can be redeployed. For example if I sell weapons I can advertise the url in a closed group but if the url leaks I start using my predeployed secondary url. Another identity, obfuscated wasm and mutated interface.
The key is the anonimity. Until people behind the service not taken down by the police they will run the service. But hey, it’s same with aws except to use aws for illegal things you have to anonimize yourself somehow.
So I agree to emphasize the difference between dfinity, ic and dapps.
2 Likes
I would propose it and vote for it. Democracy is above anarchy
3 Likes
If the canister negatively impacts the network by dos attacks or abusing some exploits then it should be removed, if it causes legal issues then it’s a case to case basis: CP? remove it, Tornado cash like situation? That is a protocol shortcoming and I’d vote against the canister removal. That’s the way I see it.
2 Likes
So you see canister censorship as desirable in some circumstances? I know there are some that seem to believe that no censorship should be possible.
Society is based on the principle:
- Everything that is not forbidden is allowed.
The ban on censorship is too big a ban.
It is necessary to start with small prohibitions. Then combine them into larger ones.
While I understand that sentiment I don’t think it’s achievable on the IC considering the compromises Dfinity made for scalability’s sake and while I can see the appeal of an immutable and completely uncensorable ledger it could facilitate some use undesirable cases.
The problem with having the possibility to censor is it could become a slippery slope, everyone has a different morality compass, some stakers are OG cypherpunks, others only care about their financial investment, in order to make things as clear as possible for dApp devs looking to build on the IC we should do 2 things:
-
Make sure the protocol is as shielded as possible from outside influences, e.g authorities threatening node providers
-
Figure out guidelines for what is and isn’t allowed on the IC, so devs don’t get ugly surprises.
Personally speaking I’d only ban canisters which intentionally attack the network with exploits and canisters hosting content usually found on the Deep Web, e.g CP, guns, drugs, etc…, the reason being both are immediately recognizable once spotted and undermining to society.
6 Likes
Your second item @Zane is relatively easy to do and urgent. NNS needs some sort of constitution asap.
If there are guidelines or a constitution, the IC becomes liable for content on the chain. A blockchain should never have content-related policies. The best path is the exact opposite, to have a completely hands-off approach to dapps and whatever is on them. Because the IC differs from other chains in its ability to host content easily, achieving separation is difficult, but the need for separation is more urgent for exactly that reason.
What you listed is:
- Defensiveness
- Law
The executive branch must be added to this list. For example, the NNS will block the canister and in an hour the same new one will appear, how to stop it?
I think with the current decentralization of IC nodes (a significant percentage of nodes are located in US), it is difficult for Spinner to avoid not being controlled by the US government
Only when there are enough nodes and nodes are entered without permission, the risk of being regulated is greatly reduced
4 Likes