DNS as Censor (variation on Boundary Nodes as Censors)

My understanding is that the takedown order was given to a node provider, not a boundary node.

The owner of the ic0.app domain is DFINITY, not the node provider (I think).

Would be good to get a lawyers option on this. It would basically act as a shield to the nodes. However, I don’t know if the nodes are still responsible since the node will be accessible via the origin URL. I like the badlands idea that Dominic had. Now more than even I think that should be a completely different NNS. That network will get all the bad shit and will act as a shield, there might even be many copies of it. At this point once the tech is there it will move to the network of less resistance which will be badlands. It is in the name.

The reason I ask is that even if we decentralize the boundary nodes and/or DNS servers, what if Nintendo doesn’t care and still chooses to send the DMCA takedown to the IC node provider?

Even the threat of which may scare the node provider (or the data center in which they operate) to shut down the node machines.

1 Like

So, no support for decentralized DNS alternatives like ENS?

AFAIK boundary nodes could still be on the hook. Imagine a domain in a TLD outside the reach of DMCA that points to a boundary node IP address in the US. The copyright holders lawyers would probably send a notice to the owner of that IP address.

2 Likes

Can we make each user run a boundary node to interact with DAPP in the IC subnet?

1 Like

This has already been addressed, please read this
There are two relevant types of node in this issue:

  • Storage Node (SN)
  • Boundary Node (BN)

The short term solution is to decentralize BN so that BN operators become legally autonomous, they decide how to respond to the law depending on the content they decide to forward, as other web3 protocols successfully do right now (IPFS, Filecoin, Arweave).
After that SN operators would become unliable by to be discussed technical solutions (node reshuffling, secure enclaves), read here.

I would like to hear what dfinity’s thoughts are about this.

2 Likes

If this proposal were implemented as I envision, there would be no special origin URL. All URL access to canisters would be through domains registered and run by entities outside of the protocol. DFINITY could decide to keep running ic0.app and provide the canister subdomain system that we have now, but they would be subject (as they already are) to legal requests to block/take down content.

That’s why we implement plausible deniability for boundary and replica node operators.

Yes, tightly integrating the IC with DNS to the exclusion of all other protocols for accessing canisters might be a major problem with this proposal.

That might be what the Boundary Nodes as Censors proposal would allow, eventually.

It was served to a boundary node provider. If DFINITY owns all the boundary nodes as mentioned above, then maybe it was issued to DFINITY…but I’m almost 100% sure it was a boundary node and not a standard node provider.

2 Likes

Hmmm. Who would be those entities with such power?

I’m pretty sure it’s a node provider.

This is from @alexa.smith’s original post:

DFINITY Foundation was contacted on December 6, 2021 by a node provider who received a notice of infringement of copyrighted materials from Nintendo Co., Ltd.

The phrase “node provider” is only ever used for parties that run IC node machines, not boundary nodes. Besides, it wouldn’t make sense for DFINITY to be contacted by a boundary node, since it runs all of the boundary nodes.

I’m no expert on DMCA takedowns, but after doing a bit of googling it seems that the standard method for figuring out who to issue a DMCA takedown notice is to run whois on the domain name, which returns information about the domain name’s registrant. You can then look up the “designated agent” of that registrant, who you can then send the takedown notice.

This is the whois for ic0.app: Whois Lookup Captcha

DFINITY apparently registered this domain on Google Domains, so Google would be considered a “service provider” in the context of DMCA. They are probably the ones who typically handle takedown notices, I think.


What I don’t understand is why Nintendo decided to issue the DMCA takedown notice to a node provider, instead of going the standard route of issuing it to Google. The boundary nodes aren’t even in the picture here, since if Google takes down the ic0.app domain (or a specific subdomain), then no request would even get routed to a boundary node IP address to begin with.

Something doesn’t make sense… they went through more effort for a less effective method. Taking down a node provider wouldn’t even remove the content on other nodes in the subnet. But taking down the ic0.app domain would effectively remove the content globally, i.e. users would no longer be able to easily access it.

Post must be at least 20 characters

1 Like

I see…

At this point, I’m confused about the facts of what even happened. I’ve seen people from DFINITY say that the takedown was sent to a node provider and others say it was sent to a boundary node operator. There’s a big difference between the two…

2 Likes

FYI, this cleared up my confusion: Nintendo Incident: Feedback Summary and Open Questions

It really was a boundary node.

A1. Further there are only 6 boundary nodes (https://dashboard.internetcomputer.org/).

A2. Additionally the claim as made by others in this forum is that there is anecdotal evidence that ALL boundary nodes are currently provided by dfinity… ( unless there is a affirmative rejection of this claim).

Adding A1 & A2 an astute observer would infer that that the DCMA notice was actually served to Dfinity. Please feel free to correct this inference.

2 Likes

I assume this wouldn’t affect canister calls addressing a principal using dfx or smth?

1 Like

It would, all calls to canisters would be forced to use DNS. dfx would need to use an endpoint with a DNS domain name.