|
|
| Line 1: |
Line 1: |
| − | == What is Content Filtering? == | + | ==Content Filtering on the IC== |
| | | | |
| − | Content Filtering is when a [[Boundary_Nodes|Boundary Node]] does not serve requests relating to a canister. The canister’s code and state remains on-chain and intact.
| + | With increasing adoption of the Internet Computer, there are more and more types of dApps running and different content hosted on it. Even though the Internet is global, the rules are local: not all content and dApps are legal in all geographies and jurisdictions. For example, online gambling is illegal in Switzerland, but not in other countries. |
| | | | |
| − | Examples of content filtering:
| + | Today, the server making the content accessible and its operator are responsible for complying with the rules of all the different jurisdictions. Failure to comply can lead to takedown of the server, domains being blocked by ISPs, and legal ramifications. |
| | | | |
| − | * A Boundary Node in Germany does not serve a gambling dapp to Switzerland-based users because online gambling is illegal in Switzerland, but it does serve the gambling dapp to Netherlands-based users where online gambling is legal.
| + | In the case of the Internet Computer, this mostly concerns the Boundary Nodes and their operators as they are the gateway to all content and dApps hosted on it. |
| − | * It does not matter whether the Boundary Node is in Germany, Switzerland, Netherlands, Mexico, India, US etc… What matters is where the user requests are from.
| |
| | | | |
| − | Content Filtering does not:
| + | ==Background== |
| | | | |
| − | * Delete or modify the canister in question. It remains on-chain with its state preserved.
| + | The discussion around content filtering started when a developer hosted a canister containing a Super Mario 64 emulator in February 2022. The Node Provider received a takedown request based on copyright infringement from Nintendo Co., Ltd. This incident sparked a discussion in the IC community. |
| | | | |
| − | == Why does the BN care about what content it serves and to whom (e.g. “content filtering”)? == | + | ==General Solution== |
| | | | |
| − | There are two levels to this question:
| + | After lots of brainstorming, the community together came up with a proposal on how to enable Boundary Node operators to comply with local jurisdictions, while providing access to the dApps hosted on the Internet Computer. |
| | | | |
| − | 1. Why the IC needs content filtering in the first place
| + | The solution consists of two parts: first, anybody has to be able to run a Boundary Node, and second, a Boundary Node Operator is responsible for the content they serve and can decide what they serve. Boundary Node Operators are encouraged to define their own policy and practices, and make them public. |
| | | | |
| − | 2. Why does the content filtering live at the boundary node level
| + | ==Today’s Situation== |
| | | | |
| − | Let’s go into each of these:
| + | Today, DFINITY operates Boundary Nodes using the icp0.io and ic0.app domains. It actively maintains a content filter and has defined its [https://dfinity.org/boundary-nodes/ic0-app/code-of-conduct/ policy]. The filter only applies to the HTTP endpoints, allowing other gateway providers and IC-native clients “unfiltered” access to the IC. |
| | | | |
| − | === Why the IC needs content filtering options ===
| + | Hence, any community member can set up and run a gateway using, for example, [https://github.com/dfinity/icfront IC Front] under their own domain and define their own policy. Several community projects have already gone this route (e.g., [https://dscvr.one/ DSCVR], and [https://distrikt.app/ distrikt]). |
| | | | |
| − | There are detailed threads on content filtering such as [https://forum.dfinity.org/t/path-forward-on-leveraging-boundary-nodes-for-content-filtering/10911 in this forum post], but here is a slight simplification:
| + | ==Future Situation== |
| | | | |
| − | In today’s world, servers (or data centers) get takedown notices from entities (e.g. countries, companies, etc). If a server does not comply, the server is typically removed from a data center and/or the domain in question is blocked by ISPs. For example: Swiss ISPs may block a server in the US if it considers it problematic (e.g., because it is a gambling site)… eliminating access to Swiss users of that server. Rather, than naively have an “all or nothing” strategy for content on the infrastructure edge of the IC, it is healthier to address the problem directly by:
| + | As the new boundary node architecture is being implemented and rolled out, it will become even simpler to run your own gateway. |
| | | | |
| − | * Enabling boundary nodes to choose what content they serve. This ensures that the decision to comply (or not) with the local laws belongs solely to the boundary node operators. The ones that choose to comply may have higher probability to remain online or accessible in the environment they are in or for the communities they want to serve. This maximizes the number of servers online and number of users getting access to IC content.
| |
| | | | |
| − | * Making it easier for people to run their own servers so that there are enough variety of policies and nodes that users can find access to the canister of their choice. This maximizes the probability of any given canister being served.
| + | ==References == |
| − | | + | * [https://forum.dfinity.org/t/content-filtering-via-boundary-nodes/18196 Content Filtering via Boundary Nodes] |
| − | === Why does the IC’s content filtering live at the boundary node level === | + | * [https://dfinity.org/boundary-nodes/ic0-app/code-of-conduct/ Code of Conduct for icp0.io and ic0.app] |
| − | | + | * [https://forum.dfinity.org/t/path-forward-on-leveraging-boundary-nodes-for-content-filtering/10911 Forum Post: Path forward on leveraging boundary nodes for content filtering] |
| − | The [https://forum.dfinity.org/t/path-forward-on-leveraging-boundary-nodes-for-content-filtering/10911 design intent of Boundary node architecture] is:
| + | * [https://forum.dfinity.org/t/nintendo-incident-feedback-summary-and-open-questions/9700 Forum Post: Nintendo Incident: Feedback Summary and Open Questions] |
| − | | |
| − | <div style="background-color: #ddf5eb; border-style: dotted;">
| |
| − | | |
| − | | |
| − | “'''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.”
| |
| − | | |
| − | </div>
| |
| − | | |
| − | | |
| − | Since then, DFINITY’s [https://dfinity.org/boundary-nodes/ic0-app/code-of-conduct Boundary Node policy has been made public].
| |
| − | | |
| − | Worth noting that post is a result of a significant brainstorming with the IC community where the community proposed choosing Boundary Nodes as the way to handle Content Filtering. This was what the IC community wanted to do (as a matter of fact it was against DFINITY's original proposal).
| |
| − | | |
| − | == What are the main differences between the current implementation and the long term design? ==
| |
| − | | |
| − | The [https://forum.dfinity.org/t/boundary-node-roadmap/15562 boundary node roadmap] goes into further detail, but I will lay out the basics:
| |
| − | | |
| − | Soon, “boundary nodes” will be split into two::
| |
| − | | |
| − | 1. '''“HTTP gateways”''': provide an endpoint to the users that terminates TLS, serves the service worker and translates the users’ HTTP requests to API canister calls. Anybody will be able to run any HTTP gateway they want without needing any NNS proposal. These nodes will NOT be rewarded with ICP.
| |
| − | | |
| − | 2. '''“API boundary nodes”''': provide an endpoint that handles API canister calls by routing them to the correct subnet and replica node, and provides caching and rate-limiting to protect the IC. These nodes will be allowed into the IC via NNS proposal and will be rewarded with ICP for their work (like consensus nodes).
| |
| − | | |
| − | '''A clear and immediate consequence of this upcoming work:''' Once this is complete, even if DFINITY’s HTTP gateways did not serve a canister X to US or Swiss users, the canister developer (or anyone really) could spin up their own HTTP gateway and serve the content themselves.
| |
| − | | |
| − | == Which entities run Boundary Nodes currently? ==
| |
| − | | |
| − | While consensus nodes are fairly decentralized [https://dashboard.internetcomputer.org/providers with an increasing number of nodes and node providers], as of January 2023, only DFINITY runs BNs. Worth stressing again that the Boundary Nodes do not affect anything on-chain.
| |
| − | | |
| − | The reason has to do with security: until the [https://forum.dfinity.org/t/boundary-node-roadmap/15562) boundary node roadmap] to replace “boundary node” architecture is complete, it is not secure (yet) to have more entities running boundary nodes (I am skipping the technical details for simplicity).
| |
| − | | |
| − | And yes, DFINITY as the only entity running Boundary Nodes is an intermediate phase that will soon be over (ETA Q2 2023) and anyone in the community will be able to run their own '''HTTP gateways''' (self managed) or '''API boundary nodes''' (NNS Managed).
| |
| − | | |
| − | == How will more “HTTP gateways” and “API Boundary Node providers” help? ==
| |
| − | | |
| − | Few obvious benefits:
| |
| − | | |
| − | 1. The thesis is that in a world with hundreds or thousands of HTTP gateways providers, if a user is looking for canister X, there will be some HTTP gateway provider that is willing to serve that canister (perhaps it's the canister’s developer themselves).
| |
| − | | |
| − | 2. As an additional measure, users will be able to target directly an API boundary node with an IC-native client (e.g., browser extension), which doesn't exist yet, but could be built by any community member. Using an IC-native client, one will be able to access any canister running on the IC without going through an HTTP gateway and verify data using the IC's public key.
| |
| − | | |
| − | == If a canister developer does not trust other HTTP Gateway providers to serve a canister, would it not be easier for the developer to run their app on a single server instead of deploying to the IC and run their own HTTP gateway? ==
| |
| − | | |
| − | Simple: a canister developer can rely on the tamperproof qualities of the IC and its consensus… while relying on their own HTTP Gateway to guarantee access.
| |
| − | | |
| − | As an example, users may trust a lottery or DeFi smart contract on the IC because it is executed on multiple consensus nodes, but they may not trust it if it ran on one machine entirely in control of the developer.
| |
| − | | |
| − | == How close is the IC to the new architecture? ==
| |
| − | | |
| − | As of January 2023, the Boundary roadmap is [https://forum.dfinity.org/t/boundary-node-roadmap/15562 here] here and the IC is months (not weeks, not years) from having the new architecture composed of HTTP gateways and API boundary nodes.
| |
| − | | |
| − | === Q1 2023: ===
| |
| − | | |
| − | * The team starts implementing the new boundary node architecture that decomposes boundary nodes into “HTTP gateways” and “API Boundary Nodes”.
| |
| − | | |
| − | === Q2 2023: ===
| |
| − | | |
| − | * New architecture with HTTP Gateway and API Boundary Nodes is shipped
| |
| − | | |
| − | === Q3 2023 ===
| |
| − | | |
| − | * Architecture will be managed by the NNS (API Boundary nodes are approved by NNS DAO).
| |
| − | | |
| − | == Are there any temporary solutions for making a dapp accessible independent of policies of BNs? ==
| |
| − | | |
| − | The obvious answer is “wait for the new architecture that does it right” then a developer can roll out your own HTTP Gateway (Or you can also provide an IC-native client that directly targets the API Boundary Nodes). Then you would not need to rely on anyone but yourself. Unlike consensus nodes, which are rather large machines running in data centers to keep up with consensus, the design intent is that HTTP Gateways be so simple they could run from people’s homes.
| |
| − | | |
| − | However, there are a few temporary workaround (and are looking into some more):
| |
| − | | |
| − | 1. A user could use something like a browser-extension. One can always directly target a boundary node with an IC-native client (e.g., browser extension), which doesn't exist yet, but could be built by any community member.
| |
| − | | |
| − | 2. A developer who wants to go the extra mile could use IC Front [https://github.com/dfinity/icfront icfront] and set up a custom domain so they do not go through ic0.app (DSCVR does this for example).
| |
| − | | |
| − | ==See Also==
| |
| − | | |
| − | * [https://forum.dfinity.org/t/content-filtering-via-boundary-nodes/18196/3 Content Filtering via Boundary Nodes] | |
Content Filtering on the IC
With increasing adoption of the Internet Computer, there are more and more types of dApps running and different content hosted on it. Even though the Internet is global, the rules are local: not all content and dApps are legal in all geographies and jurisdictions. For example, online gambling is illegal in Switzerland, but not in other countries.
Today, the server making the content accessible and its operator are responsible for complying with the rules of all the different jurisdictions. Failure to comply can lead to takedown of the server, domains being blocked by ISPs, and legal ramifications.
In the case of the Internet Computer, this mostly concerns the Boundary Nodes and their operators as they are the gateway to all content and dApps hosted on it.
Background
The discussion around content filtering started when a developer hosted a canister containing a Super Mario 64 emulator in February 2022. The Node Provider received a takedown request based on copyright infringement from Nintendo Co., Ltd. This incident sparked a discussion in the IC community.
General Solution
After lots of brainstorming, the community together came up with a proposal on how to enable Boundary Node operators to comply with local jurisdictions, while providing access to the dApps hosted on the Internet Computer.
The solution consists of two parts: first, anybody has to be able to run a Boundary Node, and second, a Boundary Node Operator is responsible for the content they serve and can decide what they serve. Boundary Node Operators are encouraged to define their own policy and practices, and make them public.
Today’s Situation
Today, DFINITY operates Boundary Nodes using the icp0.io and ic0.app domains. It actively maintains a content filter and has defined its policy. The filter only applies to the HTTP endpoints, allowing other gateway providers and IC-native clients “unfiltered” access to the IC.
Hence, any community member can set up and run a gateway using, for example, IC Front under their own domain and define their own policy. Several community projects have already gone this route (e.g., DSCVR, and distrikt).
Future Situation
As the new boundary node architecture is being implemented and rolled out, it will become even simpler to run your own gateway.
References