DNS as Censor (variation on Boundary Nodes as Censors)

Roadmap
1

This proposal can be thought of as a variation of this idea: Boundary Nodes as Censors

This proposal may be technically difficult or impractical to achieve, but if implementation is possible then I think it may be better than the Boundary Nodes as Censors proposal, all things considered.

The Boundary Nodes as Censors proposal leaves a bit to be desired. For example, boundary nodes lose plausible deniability, automatic scaling, fault-tolerance, and other benefits that being a more integrated part of the IC protocols might provide. Though allowing anyone to run a boundary node will lead to more decentralization than otherwise, boundary nodes will not be “maximally” decentralized.

The idea of DNS as Censor it to force censorship of content on the IC into the Domain Name System, maintaining plausible deniability for the rest of the system. DNS being one of the outermost protocols which provide access to blockchain applications, and considering its centralized and compliant nature, it is a natural place for censorship to occur. This would free up everything beneath DNS on the IC (e.g. boundary nodes and replica nodes and the protocols that control them) to be as decentralized and censorship-resistant as possible.

For this to work, all access to canisters would be forced through registered domain names. Anyone would be able to register a domain name that connects to any canister. If that’s not appropriate, perhaps we could build into canisters a way to authorize only certain domain names. I’m not sure we’ve figured out an elegant way to allow custom domains to map to canister ids, but I imagine DNS records would work here, such as a TXT record. Boundary nodes would forward on all traffic from properly configured domain names.

This proposal builds on the assumption that most legal complaints would first go to the registrant of the lowest subdomain, and then work up the domain hierarchy. For example, if illegal.piracy.org were hosting infringing content belonging to Innocent NFT Artists LLC, then the legal complaints would first be served to the registrant of .illegal.piracy.org, and if corrective action weren’t taken then to .piracy.org, and if necessary finally to .org.

This would place legal accountability on the domain name registrant, and allow the already-operating DNS to maintain legal compliance as it’s been doing for years. DNS becomes the interface between the centralized and decentralized worlds. And we might even be able to improve that interface as the Internet Computer gains more DNS capabilities (DNS server as canister, x.509 certificates, stuff like that).

Like I said, the technical implementation of this could be tricky (DNS records/SSL certificates/etc), but this solution feels cleaner than the Boundary Nodes as Censors proposal. We force domain name registrants to be accountable for access to canisters, and leave boundary and replica node operators out of murky waters as far as possible.

Considering the increased complexity of this solution, I think we should still move forward with Boundary Nodes as Censors. It will be much easier to open source and allow individual entities to run boundary node instances than it will be to create a maximally decentralized boundary node system. There’s also a lot about DNS and the IC that hasn’t been figured out yet.

Boundary Nodes as Censors can be a stepping stone towards this proposal.

11 Likes
2

I love the idea of passing the responsibility of site content to site owners. Seems like the best way to stay neutral as the NNS while still being responsive to laws of the modern world. The original Nintendo take-down order was served to the host of ic0.app, so let’s make it so take down notices aren’t served to us, they are served to the domain name. We need custom domain names anyway!

4 Likes
3

The original Nintendo take-down order was served to the host of ic0.app

Wait, was this confirmed by the recipient of the DMCA takedown? I thought Nintendo just found a node provider on https://dashboard.internetcomputer.org/.

4

All boundary nodes seems to be with Dfinity Foundation for now as per this post. Boundary Nodes as Censors - #77 by Alixthe

1 Like
5

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).

6

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.

7

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
8

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
9

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

1 Like
10

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
11

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.

12

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

13

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.

14

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

15

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
16

Hmmm. Who would be those entities with such power?

17

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.

18

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.

19

Post must be at least 20 characters

1 Like
20

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