Path forward on leveraging boundary nodes for content filtering

Hello community,

In the time since the Nintendo DMCA incident in December, the DFINITY Foundation has been actively reviewing community feedback, engaging in discussions and working sessions with community members, and researching best practices from the broader web3 ecosystem. This exercise has led to the revision of several of DFINITY’s existing roadmap items and the creation of new approaches for handling incidents like this in the future.

The Internet Computer is the first blockchain capable of hosting large amounts of data on the blockchain itself, using the memory of advanced “canister” smart contracts, in a significant leap forward. Another advance is that canister smart contracts can also service HTTP requests, and serve interactive web experiences directly to end-users. Together, this means that multimedia content can now be stored on a blockchain and served directly into web browsers. In the foregoing incident, copyrighted games encoded in WebAssembly were served by smart contracts into web browsers, and Nintendo attempted to take action against the computers they could see serving the content.

The community has discussed at length how such incidents should be handled since several approaches can be taken. A consensus has formed that these issues should be handled by those operating “boundary nodes,” which act as HTTP routers through which the network’s subnet blockchain nodes can be reached. The boundary nodes have several purposes: they are geo-aware and can route incoming requests to the nearest subnet node that hosts the canister involved, they can help load balance query transactions, they can hide the IP addresses of end users from the subnet nodes, they can cache cryptographically verified data in the role of a content distribution network, they can throttle excessive interactions from an outside IP address, and they can help protect subnets from DDoS attacks.

At a high level, the plan is to make boundary node operators responsible for deciding whether to forward requests to specific canister smart contracts. This will enable them to filter access to canisters, for example in response to takedown notices that legally oblige them to stop serving content or face sanctions and fines. Since boundary nodes generally serve specific geographies and jurisdictions, this makes it possible that canisters will be accessible in some places, but not others, depending upon where legal action occurs. Having boundary nodes limit access to canisters, on a case-by-case basis, is seen as superior from a decentralization perspective to having node operators attempting to remove or freeze canisters by submitting proposals to the Network Nervous System (a special DAO that automates the management and governance of the Internet Computer blockchain network by the community).

Each operator of boundary nodes will be responsible for defining their own policy and practices. As a boundary node operator, DFINITY is developing its own policy, which will be made public in the coming days and defines in what circumstances it may decide to refuse to route HTTP requests to a canister on the blockchain. Currently, while subnet blockchain node machines are run by independent node providers from data centers around the world, boundary nodes are run exclusively by the DFINITY Foundation, which has allowed it to help protect the blockchain. This situation will soon change, however.

Essentially, independent parties will be able to operate boundary nodes that run as encrypted virtual machine instances hosted on computers built using AMD’s SEV-SNP (Secure Encrypted Virtualization, with Secure Nested Paging) hardware. The use of SEV-SNP to host boundary nodes has three purposes. Firstly, it will prevent even those that own the hardware, whoever they are, from monitoring the data passing through the nodes. Secondly, it will allow short-lived HTTPS certificate information to be stored, which cannot be seen, before the blockchain gains MPC HTTPS capabilities. Thirdly, it will allow the boundary nodes to create cryptographic attestations that they are running the correct software image, and thus are faithfully implementing the protocol, which they can supply to node machines that are hosting subnet blockchains. Boundary nodes will load configurations that their owners specify externally, including canister smart contracts that should not be routed. It is important to note that this SEV work will also be rolled out to subnet node providers and is currently being discussed in the forum here, with an estimated timeline of end of Q2 2022.

At this time, the only way that a node provider can remove a canister from the network, for example in order to comply with a legal notice, is to submit a proposal to the Network Nervous System (NNS) to remove the canister, which will be executed automatically by the network if it is adopted. If their proposal is rejected, their only remaining option may be to take their equipment offline. Even if their proposal is successful, the proper purpose of this proposal type is actually to provide a last line of defense that allows a malicious canister seriously impacting network performance or security to be dealt with. The goal of allowing boundary nodes to decide not to route HTTP requests to specific canisters is to shift decision making to the individual boundary node providers and have them decide what content they should be serving.

Work on several other enhancements is underway, including canister sandboxing, which will eliminate the need for removing or suspending canisters hosted by the blockchain for security purposes. The timeline for these items is estimated by end of March 2022. As a short-term measure, based on community feedback, the DFINITY Foundation plans to propose an update that would change the voting threshold required for proposals of this type to pass to 80%.

We are very pleased with the path forward described and feel it reflects both the concerns and innovations brought forth by the community. We thank you all again for the productive discussion on this topic over the last month, and we have learned a lot from the community, as always. Please stay tuned for updates related to these workstreams in the coming weeks.

28 Likes

this is amazing news and progress. super glad to see the foundation listening to the community and deciding on a great path forward!

16 Likes

Can’t wait to run my own boundary node.

Although I thought we were months (if not years) away from decentralized boundary nodes. There seems to be a lot of work remaining for that to happen, not the least of which is designing and implementing an economic renumeration scheme to reward boundary nodes.

1 Like

OK - seems like a pragmatic way to deal with a huge issue in the short term - but in that case we need:

  • A lot more (independently run and well distributed) boundary nodes.
  • Incentives for BNs to have a process for checking whether takedown requests are legitimate and legally challenging egregious ones not just censor everything so as to minimise legal risk or even to extort application developers.

Long term work on this question for example:

  • On SEV / plausible deniability for node operators.
  • Replacing boundary nodes as censors with DNS as censors.DNS as Censor (variation on Boundary Nodes as Censors)
  • Censorship resistant messaging as an alternative to accessing the IC over HTTP via boundary nodes. (Idea is to ensure that Candid interfaces can be accessed via a slow and expensive way so that censors cannot freeze funds but only censor content. This would allow us to claim that the IC is at least as censorship resistant as existing chains with respect to DeFi type applications. Also a Waku/Hopr/Nym like P2P messaging layer would be great for other applications.)
2 Likes

Nodes serving content from DMCA jurisdictions will always need a way to censor content in a timely manner in response to “valid” DMCA notices to avoid legal consequences. They also have to restore access to content in a timely manner if the censored user provides a counter-notice.

Google receives millions of DMCA notices per day and thus employs dedicated teams to review and respond to takedown requests (in addition to proprietary automated systems).

The NNS should hire legal contractors to manage the DMCA notices on behalf of boundary node operators. This will reduce the burden of running a boundary node and help bootstrap more nodes:

  1. NNS DAO approves term-based hiring of legal teams
  2. Boundary nodes can give blacklist modify permission to legal team
  3. All DMCA requests posted in public
  4. All censor/uncensor decisions in public

Long term, integrate a crypto-native solution like a bonded dispute process via Kleros.io court system. This will allow users to dispute improper censor decisions.

Also, we should run some boundary nodes in non-DMCA jurisdictions.

I think this proposal is a great first step towards finding a practical solution to the censorship problem on the Internet Computer.

This will most likely not be the final solution, but I do not believe we have all of the knowledge and experience required to create that final solution. Implementing this proposal will hopefully make us better off than we are now and prepare us for the next set of challenges.

5 Likes

I’m wondering, how the address to access canisters will look with this. Isnt *.ic0.app the dfinity owned boundary nodes? When others are allowed, it will have different names? Does that mean a canister can be addressed by multiple names?

1 Like

Fleek does that, but my experience has been that https://canister-id.ic.fleek.co is not available at https://canister-id.ic0.app

Why should boundary nodes ever have the ability to choose the content they facilitate? The whole point of IC is to allow apps that we could previous not create due to various national regulations. Why should LGBT content be inaccessible because some government thinks so? We shouldn’t be submitting to things like DMCAs. Next we’ll be stopping apps because of every countries domestic laws and their court orders.

I dont support this approach!

1 Like

This compromise only makes it easier for powerful actors to hound the boundary node operators. So anything the USG doesnt want on the IC wont be because running a non compliant boundary node will be made nearly impossible.

What looks like a compromise is essentially a submission to censorship. IC needs to stand together.

2 Likes

This proposal only introduces censorship through the back door.

  1. If it is nearly impossible to run a non DMCA compliant boundary node, then this isnt a realistic option for anyone.
  2. Why expose boundary nodes to so much of the risk? They can easily be muscled by powerful states like USG to effectively block all content they dont like. They will simply divide and conquer all these operators.
  3. We are essentially submitting canisters owned by non Americans to American laws or other powerful states.
2 Likes

I agree at the very least they should make it so that canisters are always reachable as long as there is at least one boundary node serving them, in the worst case it should be slow to use due to latency or the node not being able to serve all requests, but never unreachable only cause there is no boundary node in my area, anonymous and permissionless boundary nodes should also be a thing.

Ideally boundary nodes shouldn’t be able to manually select which canisters they dont want to serve, they should only be able to deny requests to canisters marked with some tags (CP, DMCA risk, illegal content, etc…) by the NNS.

1 Like

Thanks for the information about the canisters. Hope to make the most out of this forum.

Can you help me resolve issues with some apps.

If anyone can make a boundary node in order to bypass sanctions will those people making said third party boundary nodes have to use a different DNS?

We wouldn’t want countries to block ico.app

1 Like