The entire content of this page is under Creative Commons Attribution 4.0 International Public License.
This page is a part of Nym Community Legal Forum and its content is composed by shared advices in Node Operators Legal Forum (Matrix chat) as well as though pull requests done by the node operators directly to our repository, reviewed by Nym DevRels.
This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a clear policy, one which will remain the same for all operators running Nym nodes. The proposed Exit policy is a combination of two existing safeguards: Tor Null ‘deny’ list and Tor reduced policy.
All the technical changes on the side of Nym nodes - Project Smoosh - are described in the FAQ section.
Nym core team cannot provide comprehensive legal advice across all jurisdictions. Knowledge and experience with the legalities are being built up with the help of our counsel and with you, the community of Nym node operators. We encourage Nym node operators to join the operator channels (Element, Discord, Telegram) to share best practices and experiences.
This document outlines a plan to change Nym Gateways from operating with an ‘allow’ to a ‘deny’ list to enable broader uptake and usage of the Nym Mixnet. It provides operators with an overview of the plan, pros and cons, legal as well as technical advice.
Nym is committed to ensuring privacy for all users, regardless of their location and for the broadest possible range of online services. In order to achieve this aim, the Nym Mixnet needs to increase its usability across a broad range of apps and services.
Currently, Nym Gateway nodes only enable access to apps and services that are on an ‘allow’ list that is maintained by the core team.
To decentralise and enable privacy for a broader range of services, this initiative will have to transition from the current ‘allow’ list to a ‘deny’ list - exit policy. In accordance with the Tor Null ‘deny’ list and Tor reduced policy, which are two established safeguards.
This will enhance the usage and appeal of Nym products for end users. As a result, increased usage will ultimately lead to higher revenues for Nym operators.
Nym core team cannot provide operators with definitive answers regarding the potential risks of operating open Gateways. However, there is online evidence of operating Tor exit relays:
- From a technical perspective, Nym node operators may need to implement additional controls, such as dedicated hardware and IP usage, or setting up an HTML exit notice on port 80.
- From an operational standpoint, node operators may be expected to actively manage their relationship with their ISP or VPS provider and respond to abuse requests using the proposed templates.
- Legally, exit relays are typically considered “telecommunication networks” and are subject to intermediary liability protection. However, there may be exceptions, particularly in cases involving criminal law and copyright claims. Operators could seek advice from local privacy associations and may consider running nodes under an entity rather than as individuals.
This document serves as the basis for a consultation with Nym node operators on any concerns or additional support and information you need for this change to be successful and ensure maximum availability, usability and adoption.
Nym supports privacy for everyone, everywhere.
To offer a better and more private everyday experience for its users, Nym would like them to use any online services they please, without limiting its access to a few messaging apps or crypto wallets.
To achieve this, operators running Exit Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays following this exit policy.
Previous setup: Running nodes supporting strict SOCKS5 app-based traffic
|Aspirational||- Very limited use cases, not supportive of the “Privacy for everyone everywhere” aspiration|
- Limited appeal to users, low competitiveness in the market, thus low usage
|Technical||- No changes required in technical setup|
|Operational||- No impact on operators operations (e.g., relationships with VPS providers)|
- Low overhead
- Can be run as an individual
|Legal||- Limited legal risks for operators|
|Financial||- Low revenues for operators due to limited product traction|
The new setup: Running nodes supporting traffic of any online service (with safeguards in the form of a denylist)
|Aspirational||- Higher market appeal of a fully-fledged product able to answer all users’ use cases|
- Relevance in the market, driving higher usage
|Technical||- Very limited changes required in the technical setup (changes in the allow -> denylist)||- Increased monitoring required to detect and prevent abuse (e.g. spam)|
|Operational||- Higher operational overhead, such as dealing with DMCA / abuse complaints, managing the VPS provider questions, or helping the community to maintain the denylist |
- Administrative overhead if running nodes as a company or an entity
|Legal||- Ideally requires to check legal environment with local privacy association or lawyer|
In our previous technical setup, Network Requesters acted as a proxy, and only made requests that match an allow list. That was a default IP based list of allowed domains stored at Nym page in a centralised fashion possibly re-defined by any Network Requester operator.
This restricts the hosts that the NymConnect app can connect to and has the effect of selectively supporting messaging services (e.g. Telegram, Matrix) or crypto wallets (e.g. Electrum or Monero). Operators of Network Requesters can have confidence that the infrastructure they run only connects to a limited set of public internet hosts.
The principal change in the new configuration is to make this short allow list more permissive. Nym’s exit policy will restrict the hosts to which Nym Mixnet and Nym VPN users are permitted to connect. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym Mixnet VPN and VPN clients (both wrapped in the same app).
As of now we the Gateways will be defaulted to a combination of Tor Null ‘deny’ list (note: Not affiliated with Tor) - reproduction permitted under Creative Commons Attribution 3.0 United States License which is IP-based, e.g.,
ExitPolicy reject 184.108.40.206/23:* and Tor reduced policy. Whether we will stick with this list, do modifications or compile another one is still a subject of discussion. In all cases, this policy will remain the same for all the nodes, without any option to modify it by Nym node operators to secure stable and reliable service for the end users.
For exit relays on ports 80 and 443, the Gateways will exhibit an HTML page resembling the one proposed by Tor. By doing so, the operator will be able to disclose details regarding their Gateway, including the currently configured exit policy, all without the need for direct correspondence with regulatory or law enforcement agencies. It also makes the behavior of Exit Gateways transparent and even computable (a possible feature would be to offer a machine readable form of the notice in JSON or YAML).
We also recommend operators to check the technical advice from Tor.
Giving the legal similarity between Nym Exit Gateways and Tor Exit Relays, it is helpful to have a look in Tor community Exit Guidelines. This chapter is an exert of tor page.
Note that Tor states:
This FAQ is for informational purposes only and does not constitute legal advice.
Check legal advice prior to running an exit relay
- Understand the risks associated with running an exit relay; E.g., know legal paragraphs relevant in the country of operations:
- Top 3 advice
- Consult a lawyer / local digital rights association / the EFF prior to operating an exit relay, especially in a place where exit relay operators have been harassed or not operating before. Note that Tor DOES NOT provide legal advice for specific countries. It only provides general advice (itself or in partnership), eventually skewed towards US audiences.
Run an exit relay within an entity
As an organisation - it might help from a liability perspective
- Within your university
- With a node operators’ association (e.g., a Torservers.net partner)
- Within a company
Be ready to respond to abuse complaints
- Make your contact details (email, phone, or even fax) available, instead of those of the ISP
- Reply in a timely manner (e.g., 24 hours) using the provided templates
- Note that Tor states: “We are not aware of any case that made it near a court, and we will do everything in our power to support you if it does.”
- Document experience with ISPs at community.torproject.org/relay/community-resources/good-bad-isps
Tor abuse templates:
DMCA response templates:
The Node Operators Legal Forum pages are divided into pages according the region:
See the next chapter to learn how to edit information or add findings about your jurisdiction.
Our aim is to establish a strong community network, sharing legal findings with each other. We would like to encourage all the current and future operators to do research about the situation in the jurisdiction they operate and update this page.
First of all, please join our Node Operators Legal Forum (Matrix chat) and post any information or questions there.
To do so, follow the steps below:
- Write your legal findings down in a text editor (Soon we will share a template)
nymtech/nymrepository and switch to develop branch
# Clone the repository git clone https://github.com/nymtech/nym # Go to the directory nym cd nym # Switch to branch develop git checkout develop # Update the repository git pull origin develop
- Make your own branch based off
developand switch to it
git branch operators/legal-forum/<MY_BRANCH_NAME> # choose a descriptive and consiose name without using <> git checkout operators/legal-forum/<MY_BRANCH_NAME> # you can double check that you are on the right branch git branch
- Save your legal findings as
- Don’t change anything in
SUMMARY.md, the admins will do it when merging
- Add, commit and push your changes
cd documentation/operators/src/legal git add <FILE_NAME>.md git commit -am "<describe your changes>" git push origin operators/legal-forum/<MY_BRANCH_NAME>
- Open the git generated link in your browser, fill the description and click on
Create a Pull Requestbutton
# The link will look like this https://github.com/nymtech/nym/pull/new/<MY_BRANCH_NAME>
- Notify others in the Node Operators Legal Forum (Matrix chat)