URnetwork docs

Welcome to the URnetwork docs where we go into more details about how to hack and use the network.

BringYour White Paper [very rough draft]

Aliases not used today but may be used in the future:

• (World Wide Access) ww.dev

• vpn.dev

Mission

Be the fastest way to solve network security and privacy needs for all people.

• Connect people and services globally with a peer-to-peer network that co-mingles normal web traffic with secure transport. Work across international boundaries and regional restrictions.

• Give visibility and control on the digital footprint of your data: where it goes, what it is, what it means, actions to limit or stop.

• Allow seamless collaboration of networks and identity.

Business plan

BringYour is an overlay ISP that adds security and privacy value to network usage. The business model is pay per use (GiB transfer), with an emphasis on web standards and peer to peer to keep fixed costs low, and a freemium core. The technology is build with a secure core managed by the company that manages users, contracts, payment, and the network; and extenders that handle peer to peer and provide additional IPs and hostnames. All peer to peer traffic is secured end to end with TLS hence the extenders can facilitate the traffic without eavesdropping.

There are many underutilized network resources today. BringYour will help make those more efficiently used to delivery value among people.

BringYour is built on a network to facilitate web standard end to end encryption between:

• endpoint to endpoint

• endpoint to subnet

• subnet to endpoint

• subnet to subnet

Product development is to start with consumer mobile devices, and then expand into prosumer and business networks. The product roadmap is:

Phase 1 Consumer: decentralized VPN with distributed providers and extenders, to compete in the same segment as the top VPN apps on the app stores, etc. Uses excess network capacity of people which gives the most realistic egress and extensive reach. Build on peer to peer web standards that also allows freemium sharing with self, friends and family. e.g. share your network with self and family. Packet inspection on each packet sent and API allows visibility and control of data. Administered from a mobile app with emphasis on speed of setup and ease of use.

Phase 2 Pro: add additional device suppport and features relevant to prosumers and business use cases. Example features are access control management and super peer. Super peer exposes endpoints and subnets from a host to self, friends, and family. This focuses on prosumer and smb use cases like local servers, smart home and iot devices. Key innovation is to transparently map a local subnet to a peer to peer connection from user to host to the resource, and to maintain a directory of resources per user. Example additional devices are desktop, router, and key open source integrations.

Phase 3 B2B: focus on business networks that use peer to peer routing to make connections to endpoints as fast as possible. Focus on SSO, SOC2, ease of setup, and interconnectivity and compliance use cases. Be the Slack of networks.

Phase 1 Pricing:

Beat low usage cost versus popular consumer VPNs ($10/month)

The standard pay per use price is $.1 per gb. The monthly revenue for different levels of sustained transfer are below:

A typical 4k video stream is 20mbps. A typical user watches 4k video 0.5-2 hours per week. 1 hour of 4k video costs $.9

100mbps $3.2k 1gbps $32k 2.5gbps $83k ($1m arr) 10gbps $324k

The total data transferred per month on the internet in 2016 is estimated around 100 exabytes (0.000308641975312ebps or 308640gbps) [https://en.m.wikipedia.org/wiki/Zettabyte_Era]

A contract is for 4gb of data ($.4). Bring Your must process around 11k contracts per hour per 10gbps assuming a contract is on average 10% filled.

The MVP of BringYour is to deliver a faster, cheaper, more capabable consumer VPN experience than exists today.

Overview

Local internet egress is a popular feature with many use cases [^1]. Typically this is served by a trusted party who provides in (supposed) confidence. The goal of this project is to enable an efficient market to provide local internet egress using modern web standards, while maximizing choice for speed and anonymity. This will allow more efficient usage of excess capacity that exsits in bandwidth allocation. It may also help to anonymize traffic for servers to the ISP by adding noise to a bandwidth allocation. WebRTC gives the user control to choose between speed (peer to peer) and their own trusted confidential parties (TURN servers).

This market is built on a common protocol described in the protocol section. The protocol connects a currency contract for data transfer with a provider to a peer to peer connection to enable the data transfer, including closing the contract and disputes.

The market is a layer 2 network that spans potentially several layer 1 blockchains. Each contract on the market enables data transfer between a user (client) and service provider (server). The contract reserves a market price of a currency for the maximum contract GiB value from a market wallet into an escrow wallet to ensure that, when closed, each contract can be fully paid. The transfer into the market wallet may incur a network fee and an exchange fee. The fees and rates are exposed in the market stats API, and all transaction on the market can reference a fixed market stat to ensure price transparency.

For example, the network sets 1GiB of transfer at $0.20 with a network fee of 5%. A user sends 1XCH to their transfer wallet, 0.05XCH is taken by the market as a fee, and 0.95XCH is deposited into their market wallet. Each contract moves XCH from the market wallet into the escrow wallet equal to a market rate, (contract GiB value * $0.20)/(current dollar exchange of XCH). The value reserved in escrow is called the escrow value of the contract. When the contract closes, the agreed consumed prorated escrow value is transferred to the service provider and the rest returned to the market wallet, or a dispute is initiated following the dispute process described in the dispute section.

As soon as a contract is closed, the respective balances are updated and the contract meta data is deleted. The network retains no historical record of past contracts.

Extenders

BringYour is built on end to end encryption between:

• endpoint to endpoint

• endpoint to subnet

• subnet to endpoint

• subnet to subnet

Extenders facilitate the end to end connection as either a peer to peer connection or a tunneled connection.

Peer to peer traffic may need turn servers and/or protocol translation to facilitate in different network environments. Additionally a decentralized network benefits from additional ips and/or hostnames. The security model of extenders is TLS, where clients only trust the core apis with certificates from Bring Your, and peer to peer traffic is always encrypted end to end with TLS.

There are two types of extenders: ip and url.

IP extenders sit on a public IP and relay https/wss api traffic to api.bringyour.com. The identity of the extender is the public ip. Additionally they facilitate peer to peer traffic.

Url extenders sit on a public web server and do a wrapped tls relay of traffic from some path to api.bringyour.com. For example, https://foobar.com/bringyour would use the wrapped tls protocol to connect to api.bringyour.com and identify itself as the extender. Additionally they facilitate peer to peer traffic from a hostname, foobar.com .

An extender must be registered with a user (user.bringyour.network). Also an extender must open incoming tcp traffic to port 443 and tcp and udp traffic to the peer to peer ports.

An extender can also run as a free extender, which will allow facilitating non-paid traffic. Users have an option to choose free extenders. By default the client will choose free extenders when there is no remaining balance, and choose paid extenders otherwise.

When a client connects to Bring Your, it must first choose an extender. The extended can be set manually to a known good extended. Otherwise this is done via the "find closest extender" api route, using the root api route. The root api route is api.bringyour.com by default, but it can be changed to use a known good extended for example. The client will typically maintain a list of N good extenders, and switch between them as needed.

Joining

Becoming a user or service provider on the market is tied to creating a VPN connection. The WW VPN uses an ECDA key pair for identity management, by default stored on per computer user at ~/.ww/key or in the local secure storage for the application.

Joining the network starts by creating a root account, which is associated with a network (you.bringyour.network). The root account and additional user accounts are managed with standard SSO (Apple, Google), email+password, and MFA.

Additional users and devices can be added through a secret phrase process. A candidate will generate a secret phrase with the API associated with their local key, and share that secret phrase with a root account user. The root account enters the secret phase to associate the key with the account.

All administration is done via the admin portals on web, iOS, and Android.

Wallets

Each user of the market has four wallets per layer 1 blockchain:

1. Transfer wallet

2. Market wallet

3. Escrow wallet

4. Dispute wallet

The only real wallet address on the blockchain will is the transfer wallet. The currency will be held there until settlement or transfer out. The other wallets are maintained as part of the layer 2 meta data to enable fast contract handling and reduce blockchain fees.

Currency are put into the transfer wallet either by direct transfer from the blockchain or ACH purchase. In direct transfer currency minus network fees are moved into the market wallet. ACH purchases exchange dollar to currency at the market rate and put currency into the market wallet minus network fees and exchange fees. Currency can be transferred out of the market wallet using the set transfer API, which may incur a blockchain fee.

The sum of tokens across all users of (market wallet + market transfers out + escrow wallet + dispute wallet) remains constant during usage of the market. No fees are applied during usage of the market.

Protocol

Communication to the platform is via HTTPS. Communication to peer is via WebRTC data channel. Data transfer follows the QUIC protocol where the transmit buffered is indexed, and the frame of transfer is a message. Messages in the buffer are processed in order of acknowledged index.

The reference for the peer to peer transfer protocol is the WW vpn project, which has implementations in Go.

The client maintains a list of servers identified by public key. The arbiter of the protocol is the API. For any number, client requests a new contract with the server. The arbiter may deny the request for any reason (insufficient funds, ban, etc). On success, the arbiter returns a signed contract Id using the secret from the server session. If not already connected, client initializes an ice connect via the arbiter using the public key. The arbiter may deny the ice connect if there are no active contracts between parties. Client maintains a peer connection with message buffer. The first message is start contract with the signed contract id. The client sends messages until contract expires or done. Client sends an end contract message. Client send arbiter a close contract with the stats. Only one open contract per connection is allowed.

[Ice connect shares public key of client to server. Can ban public key at any time.]

The client must send a open contract message before starting transfer on a contract. The client must end a contract before reaching a transfer exception in the contract, such as exceeded data. The client sends the close contract stats to the API and also a close contract message to the server. When the server receives the close contract message, it sends close contract stats to the API. The server may keep the data channel open and will expect a new open contract message before transfer.

The protocol supports IPv4 and IPv6. If IPv4 or IPv6 is not routable on the server, data transfer will still be charged. The arbiter may track servers by the amount of data left unused on contracts to find routing errors. Future extensions may allow the API to surface these quality rankings.

Security

Only public networks are allowed as destinations. Sending data to addresses in private networks is not allowed. Attempting to send to an address in a private network will result in an immediate close of the contract with a dispute status of malicious client. Correct server code will enforce this, and correct client code will filter traffic to private networks on the client side.

Listing of private networks for IPv4 and IPv6 are below.

IPv4

IPv6

Contract Disputes

The WW arbiter connects client to server with a maximum transfer (value) for each contract. The value of the contract is locked in the escrow where only the used portion of the contract is transferred from client to server. At the end of the contract, the client and server both send a summary to the arbiter of the contract according to the contract protocol. Typically a contract is a small value, and the client automatically negotiates follow on contracts as needed. A dispute happens if at the end of the contract the client and server send a different summary to the arbiter.

A dispute can happen for several (non exclusive) reasons:

• a malicious client

• a malicious server

• a client does not follow the protocol (disappear)

• a server does not follow the protocol (disappear)

• technical errors in either the client or server that are not the fault of either

The design of disputes deters repeated abuse by removing the incentives from each of these cases. In a dispute, the value of the contract remains locked in dispute escrow and registered as a dispute in both the client and server wallets. The server is not paid for any transferred data. No further contracts between a client and server are allowed while a dispute is active between them.

A dispute resolution process assesses the pending disputes on a regular basis, and makes a decision:

• was it a malicious client

• was it a malicious server

• client did not follow protocol

• server did not follow protocol

• was it a technical error and no fault

If a malicious client, the client is permanently banned from the network and the escrow amount is released to the server. If a malicious server, the server is permanently banned from the network and the escrow amount is released to the client. If it was no fault, the value reported by the server is is deducted from the escrow account and released to the server, and the remaining value (if any) is released to the client.

Identity

Joining the network gives you an identity on the network. Inter-network routing maintains exposes the identity of the sender. The identity is known as a network name, you.bringyour.network.

Service provider accounts payable

BringYour is a saas product. It sells gib transfer on a metered pay as you go package based on $ per gib. These are stored in a balance of gbio per account.

Customers can pay using dollars (stripe, Apple Pay, android pay, etc) or crypto (xch or sol). Wwa maintains a balance per customer in gib available backed by a blend of assets - $ and crypto. The current available gib is given based on the blend and current market prices. Transfer out of the assets is not allowed however in the future it may be possible to transfer out or in a by a gibio coin.

When making transfer contracts on the network, the payout depends on the backing asset. For $ backing a credit is added to the vendor for each context based on gib value. For crypto asset the value at the time of contract is converted to gib and that amount is credited.

Ap runs twice a month and converts the credits to a payout. Each crypto is paid to a linked wallet for each network. If there is no linked wallet for a network, a notice is sent to the vendor and the vendor must add a wallet within 30 days or forfeit the payout. For $ the credited amount is converted to the primary payout wallet (xch) at a determined market price. Then the converted amount is distributed to the linked wallet.

Conversion of $ to crypto for payout follows a human in the loop process. Ap is notified that a dollar amount needs to be converted to coins on a network for each network. Ap does the conversion based on the best available market price. Ap enters the net converted amount (minus network and exchange fees) for each network. The payout then happens based on the net converted amount. The payout network is chosen to minimize the network and exchange fees. For example defi xch currently has 0 network and exchange fees using peer to peer offers.

Validation

The usefulness of the network increases with provider stability. The network incorporates incentives for providers to maximum uptime and service level called validation. The network incorporates an active and passive assessment of stability.

Active assessment is spot checking done as a user would against an internet target owned or authorized by the network. The test measures include throughout, connection statistics, and total time to complete. The tests create real load and pay the provider as any user would.

Passive measurements happen as part of the contract. These include the percentage of contract accepted and percentage of contracts that end with an error.

The active and passive statistics are combined for 90 days to create a validation score. Providers with higher scores rise to the top of matchmaking and recommendation in the network.

Providers who keep their system perfectly up for 90 days will have the highest validation score.

Leases

A user can star a provider to add them to the top of their personal matching and recommendation. Additionally a user can commit a minimum contract amount per month to a provider. This functions as a star with an additional incentive to the provider. The monthly amount credits the usage of that provider up to that amount, and over usage will be charged as normal. When the lease amount is not fully used, the amount is paid out to the provider prorated by the validation score. For example a provider with a .5 validation score will get only .5 of the committed lease amount.

The lease allows users to give incentive to the providers they care about to remain stable . The provider can see how much they are losing by not achieving maximum validation score.

Synthetic load

The network can drive synthetic contracts to any provider. These contracts test the provider to network link and are used for stress testing the environment. Synthetics are built into the protocol.

URnetwork can integrate with Ubiquiti EdgeOS routers to provide and route traffic on the network.

All EdgeRouter models are supported. Popular models for home users are ER X and ER4.

Provide

TODO integrate to start automatically

Route traffic on the network

TODO integrate to start automatically and route traffic

BringYour earns revenue from user premium subscriptions. We build and operate the protocol that connects users to a global network of egress providers, which are access points to localized internets all around the world. Our goal is to have the largest network of egress providers, so that traffic from our network is indistinguishable from normal internet traffic. We designed our economic model to both 1. reward people who help run and grow the network, and 2. build a great business.

Because the number of egress providers grows with the number of users, our data center costs are almost fixed. We're able to offer access for free because, simply, you’ve earned it by participating in the network to provide security and privacy to other users. This is a completely new design that lets us build a free, fast, private VPN in a transparent and ethical way.

Traditional VPNs need to spend money on bandwidth and operations. To pay for this, traditional free VPNs monetize their users - your data, ads, scraping, malware, botnets. Because in our network users run the egress providers and trade bandwidth with each other, we do not have to spend money on bandwidth and operations. Instead we spend money on building the protocol, automated processes, and simple apps to scale the network.

We’re focused on making the network safe, scalable, and fast. We’re continually improving our protocol to thrive in the realities of the global internet. We're also focused on premium features that matter to you, like private sharing, third-party blocking, anti-censorship, and data management. Because we charge a small subscription for premium, we're able to spend more on bandwidth and servers for our premium users.

We see a future where a significant portion of internet users switch away from sketchy traditional VPNs to us, because we work better, more private, and cheaper. It’s important that we have an economic model that rewards the community and leads to a great business as we scale. If we didn't have a realistic model that leads to a great business at scale, one could conclude we also plan to monetize our users. For this reason we want to be transparent with our economic model.

Our current model factors in three components:

• Paid transfer (the old way)

• Subsidized transfer (the new way)

• Referral bonuses

Note that with subsidized transfer, paid transfer trends to zero. We keep it in the model since that was the operation of the network from public beta launch in H1 2024 to “v0” launch in H2 2024.

Payments to the community

We set our subsidy payment as 10% of premium revenue with a guaranteed minimum amount of $.1 per MAU. MAU does not include automation and bots. The payout amount per device is determined by the amount of data routed, weighted 75% against all global devices and 25% against devices in the same country, where all countries are weighted equally . The guaranteed minimum amount will adjust every year after launch.

We set our referral bonus as 50% of the earnings of the referred user and 50% of their referral bonus.

This means that we’re paying out up to 20% of our premium revenue back to the community, with a minimum amount up to $.2 per MAU.

This also means that we’re targeting margins between 70-80% at scale, which is where we want to be as a business. This is competitive in the market and allows us to run as an independent company.

The revenue share of paid transfer is 50%. However, the amount of paid traffic trends to zero after our launch in H2 2024.

The payouts to the community are sent to each network’s active wallet, as USDC, either on Polygon or Solana. The active wallet is managed in the app, and a default user-controlled wallet can be created directly in the app.

Payouts to the active wallet subtract the gas fee from the payout. The payout is held and combined with future payouts until the value minus the gas fee is positive.

There is no cost to participate as a provider.

Phases of the company

The launch of the network and community payments creates four phases of the company:

1. Repeatable network

2. Repeatable premium product

3. Scale

4. Profitable company

In phase 0, we will focus on a network that is better than other consumer VPNs, and scaling the network in a cost efficient way. The exit is a scalable network with almost fixed operating costs.

In phase 1, the premium revenue is not enough to subsidize the community payments. We’ll be in this phase as long as premium conversion per MAU is less than .2/premium price . At our current premium price of $5/month, the break-even exit of phase 1 is at 4% conversion of users to premium users. In this phase the company will focus on a repeatable premium offering that converts above the break-even rate to exit.

In phase 2, the company can scale revenue with an almost fixed operating cost by scaling MAU. The company will scale faster if the conversion to premium is higher than the break-even. In this phase the company will focus on volume to cover operating costs and exit.

In phase 3, the company will be profitable as it scales. At this point we will look at expanding our TAM with new premium products starting at phase 1.

Payout sweep

Payouts are done weekly and the subsidy is computed from the previous week’s revenue and the previous month’s MAU.

Privacy

Payment on our network is private.

Transfer between a user and provider is preceded by a contract. A contract combines payment information, access control, and priority so that a user and provider can directly communicate and apply the right rules. Both user and provider close a contract, and if they agree, the contract is settled and added to the payout.

Settled contracts used for a payout are removed one week after the payout. This is in line with our approach of aggressively deleting user information from our system. If there are any issues with a payout, participants must contact us within one week.

Products Privacy Policy

Last modified: April 3, 2023

Introduction

Bring Your, LLC ("Company" or "We") respect your privacy and are committed to protecting it through our compliance with this policy.

This policy describes the types of information we may collect from you or that you may provide when you visit the BringYour website or use the BringYour app (our "Products") and our practices for collecting, using, maintaining, protecting, and disclosing that information.

This policy applies to information we collect:

• On these Products.

• In email, text, and other electronic messages between you and our Products.

• Through mobile and desktop applications you download from this Product, which provide dedicated non-browser-based interaction between you and this Product.

It does not apply to information collected by:

• Us offline or through any other means, including on any other website or app operated by Company or any third party; or

• Any third party, including through any application or content (including advertising) that may link to or be accessible from or on the Products.

Please read this policy carefully to understand our policies and practices regarding your information and how we will treat it. If you do not agree with our policies and practices, your choice is not to use our Products. By accessing or using this Product, you agree to this privacy policy. This policy may change from time to time (see Changes to Our Privacy Policy). Your continued use of this Product after we make changes is deemed to be acceptance of those changes, so please check the policy periodically for updates.

Children Under the Age of 16

California residents under 16 years of age may have additional rights regarding the collection and sale of their personal information. Please see Your California Privacy Rights for more information.

Information We Collect About You and How We Collect It

We collect several types of information from and about users of our Products, including information:

• By which you may be personally identified, such as name, postal address, e-mail address, telephone number, or any other identifier by which you may be contacted online or offline ("personal information");

• That is about you but individually does not identify you; and/or

• About your internet connection, the equipment you use to access our Products, and usage details.

We collect this information:

• Directly from you when you provide it to us.

• Automatically as you navigate through the site. Information collected automatically may include usage details, IP addresses, and information collected through cookies.

Information You Provide to Us

The information we collect on or through our Products may include:

• Information that you provide by filling in forms on our Products. This includes information provided at the time of subscribing to our service. We may also ask you for information when you report a problem with our Products.

• Records and copies of your correspondence (including email addresses), if you contact us.

You also may provide information to be published or displayed (hereinafter, "posted") on public areas of the Product, or transmitted to other users of the Products or third parties (collectively, "User Contributions"). Your User Contributions are posted on and transmitted to others at your own risk. Although we limit access to certain pages, please be aware that no security measures are perfect or impenetrable. Additionally, we cannot control the actions of other users of the Products with whom you may choose to share your User Contributions. Therefore, we cannot and do not guarantee that your User Contributions will not be viewed by unauthorized persons.

Information We Collect Through Automatic Data Collection Technologies

As you navigate through and interact with our Products, we may use automatic data collection technologies to collect certain information about your equipment, browsing actions, and patterns, including:

• Details of your visits to our Product, including communication data and the resources that you access and use on the Products.

• Information about your computer and internet connection, including your IP address, operating system, and browser type.

The information we collect automatically is only statistical data and does not include personal information. It helps us to improve our Products and to deliver a better and more personalized service, including by enabling us to:

• Estimate our audience size and usage patterns.

• Store information about your preferences, allowing us to customize our Products according to your individual interests.

• Speed up your searches.

• Recognize you when you return to our Products.

The technologies we use for this automatic data collection may include:

• Cookies (or browser cookies). A cookie is a small file placed on the hard drive of your computer. You may refuse to accept browser cookies by activating the appropriate setting on your browser. However, if you select this setting you may be unable to access certain parts of our Products. Unless you have adjusted your browser setting so that it will refuse cookies, our system will issue cookies when you direct your browser to our Product.

We do not collect personal information automatically, but we may tie this information to personal information about you that we collect from other sources or you provide to us.

How We Use Your Information

We use information that we collect about you or that you provide to us, including any personal information:

• To present our Products and its contents to you.

• To provide you with information, products, or services that you request from us.

• To fulfill any other purpose for which you provide it.

• To provide you with notices about your account, including expiration and renewal notices.

• To carry out our obligations and enforce our rights arising from any contracts entered into between you and us, including for billing and collection.

• To notify you about changes to our Products or any products or services we offer or provide though it.

• In any other way we may describe when you provide the information.

• For any other purpose with your consent.

Disclosure of Your Information

We may disclose aggregated information about our users without restriction.

We may disclose personal information that we collect or you provide as described in this privacy policy:

• To our subsidiaries and affiliates.

• To contractors, service providers, and other third parties we use to support our business.

• To a buyer or other successor in the event of a merger, divestiture, restructuring, reorganization, dissolution, or other sale or transfer of some or all of BringYour's assets, whether as a going concern or as part of bankruptcy, liquidation, or similar proceeding, in which personal information held by BringYour about our Product users is among the assets transferred.

• To fulfill the purpose for which you provide it.

• For any other purpose disclosed by us when you provide the information.

• With your consent.

We may also disclose your personal information:

• To comply with any court order, law, or legal process, including to respond to any government or regulatory request.

• and other agreements, including for billing and collection purposes.

• If we believe disclosure is necessary or appropriate to protect the rights, property, or safety of BringYour, our customers, or others.

Changes to Our Privacy Policy

It is our policy to post any changes we make to our privacy policy on this page with a notice that the privacy policy has been updated on the Product home page. If we make material changes to how we treat our users' personal information, we will notify you. The date the privacy policy was last revised is identified at the top of the page. You are responsible for ensuring we have an up-to-date active and deliverable email address for you, and for periodically visiting our Website and this privacy policy to check for any changes.

Contact Information

TERMS AND CONDITIONS FOR PROVISION OF INTERNET SERVICES:

THESE TERMS AND CONDITIONS CONTAIN IMPORTANT INFORMATION REGARDING YOUR USE OF BRINGYOUR SERVICES

PLEASE READ THEM CAREFULLY

This Terms and Conditions (the "Agreement") is entered into between the Customer ("You", "Your", "Customer") and Bring Your, LLC (hereinafter referred to as "Provider"). This Agreement includes BringYour's Privacy Policy as set forth at bringyour.com (the "Website") and any restrictions, instructions, and prohibitions located on the Website or Mobile App (collectively, "Agreement"). BY INSTALLING OR USING THE APPLICATION OR SERVICES, YOU: (A) ACKNOWLEDGE THAT YOU HAVE READ AND UNDERSTAND THIS AGREEMENT; (B) REPRESENT THAT YOU ARE OF LEGAL AGE TO ENTER INTO A BINDING AGREEMENT; AND (C) ACCEPT THIS AGREEMENT AND AGREE THAT YOU ARE LEGALLY BOUND BY ITS TERMS. IF YOU DO NOT AGREE TO THESE TERMS, DO NOT USE THE APPLICATION AND DELETE IT FROM YOUR DEVICES.

Customer and Provider enter into an agreement, (the "Agreement") as follows:

1. Provider has developed peer-to-peer networking technology and a mobile application (the "Application") to enable Customer to access its own networks or subnetworks as described on the Website or Mobile App (and incorporated here by reference) (the "Service"). Subject to the terms of this Agreement, Provider grants you a limited, non-exclusive, and nontransferable license to:

   a. download, install, and use the Application for your personal use on a device owned or otherwise controlled by you ("Mobile Device") strictly in accordance with the Application's documentation; and

   b. use on such Mobile Device the Services made available in or otherwise accessible through the Application, strictly in accordance with this Agreement

2. Application License Restrictions. You shall not:

   a. copy the Application, except as expressly permitted by this license;

   b. modify, translate, adapt, or otherwise create derivative works or improvements, whether or not patentable, of the Application;

   c. reverse engineer, disassemble, decompile, decode, or otherwise attempt to derive or gain access to the source code of the Application or any part thereof;

   d. remove, delete, alter, or obscure any trademarks or any copyright, trademark, patent, or other intellectual property or proprietary rights notices from the Application, including any copy thereof;

   e. rent, lease, lend, sell, sublicense, assign, distribute, publish, transfer, or otherwise make available the Application, or any features or functionality of the Application, to any third party for any reason, including by making the Application available on a network where it is capable of being accessed by more than one device at any time; or

   f. remove, disable, circumvent, or otherwise create or implement any workaround to any copy protection, rights management, or security features in or protecting the Application.

3. Reservation of Rights. You acknowledge and agree that the Application is provided under license, and not sold, to you. You do not acquire any ownership interest in the Application under this Agreement, or any other rights thereto other than to use the Application in accordance with the license granted, and subject to all terms, conditions, and restrictions, under this Agreement. Provider and its licensors shall retain its entire right, title, and interest in and to the Application, including all copyrights, trademarks, and other intellectual property rights therein or relating thereto, except as expressly granted to you in this Agreement.

4. Your Contributions. If you decide to provide egress sites or contribute bandwidth (as further described on the Website or Mobile App ("Your Contributions"), you may receive credits (minus any service fees) in the form of digital assets. These amount per service or may vary depending on market conditions and timing, and the digital assets may increase or decrease in value. These digital assets are provided as an incidental benefit to the Service and you agree that the maximum redeemable value owed by Provider for any digital assets outside of the Service is $0.01. You agree that contributing egress sites or bandwidth is at your own risk and that Provider is not responsible for the actions of any users or any violations of agreements or laws. Please see the Website or App for additional pricing or restrictions.

5. Service and Performance. PROVIDER WILL FURNISH THE SERVICE ON AN "AS IS" AND "AS AVAILABLE" BASIS AND PROVIDER EXPRESSLY DISCLAIMS ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF TITLE OR NON-INFRINGEMENT, OR THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOUR USE OF AND RELIANCE ON THE SERVICES OR ANY INFORMATION OR FEATURE PROVIDED THEREIN ARE AT YOUR OWN RISK. WE WILL NOT BE RESPONSIBLE FOR ANY DAMAGES, LOSSES, OR LEGAL CONSEQUENCES WHICH OCCUR AS A RESULT OF YOUR USE OF THE SERVICES or YOUR CONTRIBITIONS. WE MAKE NO WARRANTY THAT THE SERVICES WILL BE AVAILABLE ON A CONTINUOUS BASIS, SECURED, FREE OF VIRUSES, WORMS, OTHER HARMFUL COMPONENTS, OR PROGRAM LIMITATIONS. WE MAKE NO WARRANTY THAT WE WILL CORRECT ANY ERRORS, DEFECTS OR OMISSIONS. WE DO NOT, EITHER EXPRESSLY OR IMPLIEDLY ASSUME ANY RESPONSIBILITY FOR ANY LOSS, INJURY OR DAMAGES INCURRED AS A RESULT OR IN CONNECTION WITH YOUR USE OF THE SERVICES (INCLUDING, WITHOUT LIMITATION, ANY LOSS OF DATA OR OTHER DAMAGE TO DEVICE). THIS DISCLAIMER SHALL APPLY TO ALL ADVICE, ASSISTANCE, DATA, INFORMATION, OR SERVICE, NOW OR SUBSEQUENTLY FURNISHED, DELIVERED OR MADE AVAILABLE BY PROVIDER, ITS AFFILIATES, ITS CONTRACTORS, MANAGERS, MEMBERS OR THEIR RESPECTIVE EMPLOYEES OR AGENTS.

6. Neither Provider, nor its agents, contractors, employees, manager(s), or members (collectively referred to hereafter as "Provider's Group"), will be responsible for, and Customer waives and relinquishes any claim against Provider's Group for any damage, loss, cost or other expense, whether direct, indirect, consequential or incidental, that Customer or any third party may suffer which is related to, or results from Customer's use of the Service. This includes, but is not limited to, loss of data or business resulting from delays, non-delivery, mis-delivery, or interruptions as a result of Provider's or Customer's (in)actions. CUSTOMER EXPRESSLY ASSUMES ALL RISKS ASSOCIATED WITH CUSTOMER'S USE OF THE SERVICE, including but not limited to those that might occur from the introduction into Customer's computer(s) or networks of viruses, worms, Trojan Horses, or from unauthorized entry or entries into Customer's computer(s) or any other problem, which result from use of, or occur through the Service. Customer agrees to defend, indemnify and hold harmless, to the extent permitted by law, Provider's Group from any damage, loss, cost, or expense that may occur to Customer or any third party as a result of the use of the Service. Customer agrees to defend, indemnify and hold Provider's Group harmless from any and all liabilities, costs, judgements and expenses, including reasonable attorney's fees, related to or arising from: (a) any violation of this Agreement by Customer, or by a third party or parties accessing the Service through Customer; (b) use of the Service or the Internet or the placement or transmission of any message, information, software or other materials on the Internet by Customer, or by a third party or parties accessing the Service through Customer: (c) claims for infringement of patents, trademarks, trade secrets or copyrights arising from Customer's use or use by a third party or parties accessing the Service through Customer, of equipment and software, apparatus and systems, (whether or not furnished by Provider), in connection with the Service.

7. No Liability for Content. Customer acknowledges that Provider exercises no control over the form, content or nature of data, images, information, material or anything of whatever nature passing through the connection, (hereafter collectively referred to as "Data") between Customer and Provider or obtained from any Data base maintained by Provider or others, except as may occur pursuant to the provisions of this Agreement. Customer assumes the entire risk that may arise from the use or transmission from, through or to itself of any Data, WHICH MAY INCLUDE SEXUALLY EXPLICIT MATERIAL OR MATERIAL OFFENSIVE OR OBSCENE TO SOME PERSONS. Provider shall have no duty or obligation to advise Customer of any risk that may arise from the availability, use, possession or transmission of Data or provide any information relating thereto, even if at any time Provider should attempt to do so. Provider does not monitor has no obligation to monitor any data that passes through the Service and avails itself of the rights and immunities afforded to service providers under the Digital Millennium Copyright Act and Section 230 of the Communications Decency Act. Should Provider, become aware of Data which, it, in its sole discretion, deems to be in violation of this Agreement, unacceptable or undesirable, it may remove or refuse to post or transmit the Data or terminate Customer's access. Provider's liability for any allegedly defective service provided under this Agreement shall not exceed the amount paid by Customer to Provider over the past six months. The Service provided to Customer shall be considered to have been accepted unless Customer shall provide written notice detailing the portion or portions of the Service alleged to be defective or inadequate to Provider no later than ten days after the day the allegedly defective or inadequate services were furnished by Provider.

8. YOU EXPRESSLY ACKNOWLEDGE AND AGREE THAT IN NO EVENT WE (INCLUDING, WITHOUT LIMITATION, OUR AFFILIATES AND THEIR RESPECTIVE OFFICERS, DIRECTORS, EMPLOYEES AND AGENTS, VENDORS, DISTRIBUTORS, THIRD PARTY LICENSORS, OR EQUIPMENT AND SERVICE PROVIDERS) SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, VICARIOUS, INCIDENTAL, SPECIAL, PUNITIVE, CONSEQUENTIAL OR EXEMPLARY DAMAGES, INCLUDING BUT NOT LIMITED TO, DAMAGES FOR LOST PROFITS, LOST BUSINESS OR LOST OPPORTUNITY, BREACHES OF CONTRACT, GOODWILL, OR OTHER INTANGIBLE LOSSES (EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES) OR OTHER RELIEF ARISING OUT OF, OR RELATED TO, THESE TERMS, THE SERVICES, OR YOUR USE OR INABILITY TO USE THE SERVICES. OUR LIABILITY SHALL NOT EXCEED THE COST OF THE SERVICES. SOME STATES OR JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR THE LIMITATION OF LIABILITY FOR DAMAGES, IN SUCH STATE OR JURISDICTIONS, OUR LIABILITY SHALL BE LIMITED TO THE EXTENT PERMITTED BY LAW.

9. Lawful Use. Customer is solely responsible for complying with all applicable laws and agreements with third parties and ensuring that use of the Services does not result in breach of any laws, agreements, or obligations to third parties. Customer agrees that it shall only use the Services and to access networks to which it has express rights or permission by the respective network owner. All use of Provider's services must be for lawful purposes and in accordance with any policy of any network accessed through Provider. Customer shall neither use, nor permit use of Provider's services in violation of any applicable federal, state or local statute, law, ordinance, regulation or rule, all of which are hereafter collectively referred to as "Governmental Rule". Customer agrees that Provider may monitor and disclose information where required to do so by law or government order. Should use of the Service by Customer or by a third party or parties accessing the Service through Customer, cause Provider's internet source to advise Provider that it will terminate or restrict Provider's connectivity to the Internet, unless some specified action is taken, Provider may temporarily suspend the Service, or some part thereof, limit or prevent use of the Service by a particular person, group or entity, and/or terminate this Agreement. No reduction in the Service Fee will be made if the Service or a part thereof is suspended or if a particular person, group or entity is not permitted to use the Service as provided in the previous sentence.

10. Customer Use. Any conduct by Customer that, in Provider's sole discretion, inhibits or restricts any other customer, person or entity from using or enjoying Provider's Internet Service shall entitle Provider to immediately disconnect Provider's Internet Service to Customer and terminate this Agreement without notice. Customer agrees to use Provider's Internet Service only for lawful purposes. Customer may not use, or allow others to use, Customer's Provider's Internet Service account, either directly or indirectly, to:

    a. post, transmit, promote, or facilitate the distribution of any unlawful or illegal material, including but not limited to, material that would constitute or encourage copyright or trademark infringement, a criminal offense, give rise to civil liability or otherwise violate any applicable local, state, national or international law;

    b. post, transmit, promote, or facilitate the distribution of any unsolicited advertising (including but not limited to mass or bulk e-mails), promotional materials or other forms of solicitation to other individuals or entities;

    c. unlawfully access other computers or services, or to cause a disruption of service to other on-line users; or

    d. cause disruption to Provider's network, nodes, or services.

11. Notices.

    a. We may amend this Agreement from time to time, at our sole discretion and without any notice. It is your obligation to periodically review this Agreement to ensure compliance. We will make a reasonable effort, at our sole discretion, to provide you with a notification regarding what we believe are material changes to these terms. Such material changes will take effect seven (7) days after such notice was provided. Otherwise, all other changes to these terms are effective as of the stated "Last Revised" date and your continued use of the Services following the Last Revised date will constitute acceptance of, and agreement to be bound by, those changes. Notices or other communications required or permitted to be given pursuant to this Agreement shall be in writing and shall be considered as properly given if sent by email or mailed by certified mail, or provided through the application interface.

    Copy

    FOR PROVIDER:
    
    <notice@bringyour.com>
    
    with Copy to:
    
    Bring Your, LLC
    2261 Market Street #5245
    San Francisco, CA 94114

    b. A party may change the address or phone numbers set out above for purposes of notice under this contract by giving written notice to the other party or parties hereto of such change in the same manner as is provided above.

12. Default. Default under this Agreement is a failure to comply with a material term or condition hereof. In the event of a default, the non-defaulting party may give the other party written notice specifying the default and the defaulting party shall have ten (10) days thereafter in which to cure same. If the default is by Customer, and not timely cured, Provider may; (i), terminate service to Customer and retain all prepaid amounts, or (ii) interrupt the Service until the default is cured with no refund of any prepaid amounts. In addition, Provider may also declare due and demand immediate payment of, any installments remaining unpaid, with interest thereon at the rate of (18%) per annum from the date of default in payment thereof until fully and finally paid, along with reasonable attorney's fees, court costs or other expenses it may incur in enforcing this Agreement. If this Agreement is terminated by mutual agreement or, if Provider fails to cure a noticed default, Customer's sole remedy is to cancel any subscription through the applicable Application Store. Failure to declare any default immediately upon occurrence, or a delay in taking any action in connection therewith, shall not waive such default nor any legal right or privilege to take action at any time thereafter. Termination of service by Provider does not relieve Customer of existing debts or obligations pursuant to this Agreement.

13. Export Regulation. The Application may be subject to US export control laws, including the Export Control Reform Act and its associated regulations. You shall not, directly or indirectly, export, re-export, or release the Application to, or make the Application accessible from, any jurisdiction or country to which export, re-export, or release is prohibited by law, rule, or regulation. You shall comply with all applicable federal laws, regulations, and rules, and complete all required undertakings (including obtaining any necessary export license or other governmental approval), prior to exporting, re-exporting, releasing, or otherwise making the Application available outside the US.

14. Governing Law. This Agreement shall be subject to and governed under the laws of the State of Texas. Any and all obligations and payments are due and performable and payable in Harris County, Texas. The parties agree that jurisdiction and venue for purpose of any and all lawsuits, causes of action, arbitration, or other disputes shall be in Harris County, Texas.

15. Force Majeure. Neither party shall be liable or responsible to the other party for any delay, damage, loss, failure or inability to perform caused by "force majeure". The term "force majeure," as used in this Agreement, shall include the following: an act of God, strike, act of a public enemy, war, mines or other items of ordinance, blockage, public rioting, lightning, fire, storm, hurricane, flood, explosions, inability to obtain materials, supplies, labor permits, servitude, or rights of way, acts or restraints of any governmental authority, epidemics, landslides, lightning storms, earthquakes, washouts, arrests, restraints of rulers and people, civil disturbances, explosions, breakage or accident to machinery or lines of equipment, temporary failure of equipment, freezing of equipment, and any other cause, whether of the kinds specifically enumerated above or otherwise, which is not reasonably within the control of the parties and which by the exercise of due diligence could not reasonably be prevented or overcome. Events reasonably within the control of the party having the difficulty shall not constitute "force majeure" and shall be remedied with the exercise of due diligence. This paragraph does not apply to payments due under this Agreement.

16. Payment. All payments are done through the applicable application store such as Google's Play Store or Apple's App Store (each an "Application Store") and are subject to such Application Store terms with regards to charge of the Subscription, cancellation, refunds all of the payment terms. For more information regarding Cancellation see the applicable Application Store subscription cancellation webpages.

17. Intellectual Property. Except as expressly granted herein, we retain all right, title and interest in and to our Services, as well as any content provided or made available in connection with the Services (excluding Third Party Services). We reserve the right to disable access to the Services by anyone who uses them to infringe intellectual property rights.

18. Provider reserves the right, at any time and from time to time, at its own discretion, to add Services, to modify, suspend, terminate or discontinue any or all the Services, or any part thereof or any user's access thereto. Where we assume that such change may affects an existing Service, we will provide you with a prior written notice and you may be able to terminate the Service. We may, at any time and at our sole discretion, change, modify, add, or remove features and functionality of our Services without notice. You hereby agree that we may automatically download and install updates, from time to time, without prior notification. These updates are designed to improve, enhance, and further develop the Services. You agree to receive such updates as part of your use of the Services. If we believe that such updates or upgrades shall materially affect your use of the Services or your rights, we will make a reasonable effort to provide notification to you of such.

19. Indemnification. You hereby expressly agree to indemnify, defend, and hold us (including our affiliates, subsidiaries, successors, contractors, employees, directors, agents, suppliers, licensors, service providers and partners) harmless from any and all claims, damages, obligations, losses, liabilities, costs, debts, and expenses (including but not limited to attorney fees) arising from: (i) your use of any of our Services; (ii) your violation and/or breach of any term of these Terms; and (iii) any damage of any sort, whether direct, indirect, special or consequential, you may cause to any third party which relates to your use of the Services (including your violation of any third party rights).

20. Termination. This Agreement, the license provided herein, and Customer's right to use Provider's Internet Service may be terminated by Provider at any time for violations of provisions contained in this Agreement, and most specifically, if Customer violates any of the terms of Section 13 of this Agreement. Customer may terminate this Agreement at any time deleting all apps or software and notifying Provider.

21. Binding Agreement. This agreement shall be binding upon and inure to the benefit of the parties, their respective heirs, executors, administrators, legal representatives, successors and assigns, except that it may not be assigned by Customer.

22. Arbitration. Any controversy or claim arising out of or relating to this contract, or the breach thereof, shall be settled by arbitration administered by the American Arbitration Association in accordance with its Commercial [or other] Arbitration Rules, and judgment on the award rendered by the arbitrator(s) may be entered in any court having jurisdiction thereof.

23. Severability. If any provision of this Agreement is illegal or unenforceable under applicable law, the remainder of the provision will be amended to achieve as closely as possible the effect of the original term and all other provisions of this Agreement will continue in full force and effect.

24. Waiver. No failure to exercise, and no delay in exercising, on the part of either party, any right or any power hereunder shall operate as a waiver thereof, nor shall any single or partial exercise of any right or power hereunder preclude further exercise of that or any other right hereunder. In the event of a conflict between this Agreement and any applicable purchase or other terms, the terms of this Agreement shall govern.

25. This document and the Privacy Policy and any other policies on the Website or Mobile App constitute the entire agreement between Provider and Customer. This agreement may not be modified except in writing and when signed by duly authorized representatives of Provider and Customer. In the event Customer issues a purchase order, memorandum, specifications or other instrument covering the services provided, such purchase order, memorandum, specifications, or instrument is for Customer's internal purposes only, and any and all terms and conditions contained therein, whether printed or written, shall not be of any force or effect as between the parties to this Agreement. All parties hereby acknowledge that they have read and understood this Agreement and any attachments and exhibits thereto. This agreement is effective as of the Commencement Date, and remains in effect until terminated pursuant to its terms.

URnetwork can integrate with Raspberry Pi devices to provide and route traffic on the network.

There are several popular adblocking and VPN projects for Raspberry Pi. URnetwork works with these projects to add additional networking options.

Provide

TODO integrate to start automatically

Route traffic on the network

TODO integrate to start automatically and route traffic

TODO steps to set up a local Wifi AP that routes traffic to URnetwork

Pi-hole

PiVPN

If you want to route only some clients to URnetwork, URnetwork has a Wireguard server mode that can be deployed side-by-side to create custom configurations that route to URnetwork. Follow the steps below.

Introduction

Bring Your, LLC welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us.

Systems in Scope

This policy applies to any digital assets owned, operated, or maintained by Bring Your, LLC.

Out of Scope

• Assets or other equipment not owned by parties participating in this policy.

Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority.

Our Commitments

When working with us, according to this policy, you can expect us to:

• Respond to your report promptly, and work with you to understand and validate your report;

• Strive to keep you informed about the progress of a vulnerability as it is processed;

• Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and

• Extend Safe Harbor for your vulnerability research that is related to this policy.

Our Expectations

In participating in our vulnerability disclosure program in good faith, we ask that you:

• Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail;

• Report any vulnerability you’ve discovered promptly;

• Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience;

• Use only the Official Channels to discuss vulnerability information with us;

• Provide us a reasonable amount of time (at least 90 days from the initial report) to resolve the issue before you disclose it publicly;

• Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;

• If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information;

• You should only interact with test accounts you own or with explicit permission from the account holder; and

• Do not engage in extortion.

Official Channels

Safe Harbor

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

• Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;

• Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;

• Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and

• Lawful, helpful to the overall security of the Internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.

The following CLIs are maintained for URnetwork

provider

The provider CLI runs and manages a local egress provider.

tether

The tether CLI runs and manages network interfaces and protocol servers. Anything packet routing from your OS to URnetwork will use this CLI.

bringyourctl

The bringyourctl CLI manages your own network space deployment.

warpctl

The warpctl CLI manages continuous deployment into your own network space.

The main URnetwork space follows a set of trust and safety rules and an economic model that keeps the network safe for providers, and rewards providers for participating. The network is free to use with a data cap, where users can become a supporter to get a higher data cap and priority speeds. The main URnetwork space supports email, SMS, Google, and Apple authentication.

Provide using an app

URnetwork builds apps for popular consumer platforms. Our goal is to support as much existing hardware as possible and make it "one tap" to get set up as a provider. When you install an app, select "Provide while disconnected" from the settings to enable always-on provider. Otherwise, the provider is only active while you are connected to the network.

Provide using a binary

The binary runs as any user and does not require special permissions.

The binary can be compiled and deployed from source, or deployed with our pre-built docker container. Both methods are documented below.

Provider binary

Run the following commands to build the provider binary from source. You will need go version of at least 1.23 and git.

mkdir urnetwork
cd urnetwork
git clone https://github.com/urnetwork/connect
git clone https://github.com/urnetwork/protocol
cd connect/provider
go build
# the provider binary is now at ./provider

To initialize a provider on your network, follow the steps below.

2. Once logged in, there is an button in the dialog called "Copy an Auth Code". Tap that button to copy a time-limited auth code. You'll use this in the next step to generate a local JWT file.

3. ./provider auth. Paste the auth code at the prompt to enter the auth code.

4. You should see output that says "Saved auth to ~/.urnetwork/jwt". Now any provider that runs in your user will be authenticated to your network. You can copy the $HOME/.urnetwork dir to new environments to quickly set up the provider.

To run a provider on your network, run the command below.

./provider provide
# you should see the message "Provider XXX started"

To run a provider all the time in the background, follow the steps below.

Linux

On modern Linux, background processes are managed with systemd using the commands systemctl and journalctl for logs. The following steps set up a basic systemd unit to run the provider binary using the configuration at $HOME/.urnetwork.

2. Edit the /path/to/provider to the actual provider path

3. Edit the $USER to the user you want to run as

4. Make sure for that user, $HOME/.urnetwork is in place

5. sudo cp <EDITED urnetwork-provider.service> /etc/systemd/system/urnetwork-provider.service

6. sudo systemctl enable urnetwork-provider.service

7. Verify the unit is running with journalctl -u urnetwork-provider.service. You should see the message "Running on port XX".

8. You're all set!

macOS

On modern macOS, background processes are managed with launchd using the command launchctl while the logs get appended to /var/log/system.log. The following steps set up a basic launchd unit to run the provider binary using the configuration at $HOME/.urnetwork.

2. Edit the /path/to/provider to the actual provider path

3. Edit the $USER to the user you want to run as

4. Make sure for that user, $HOME/.urnetwork is in place

5. sudo cp <EDITED urnetwork-provider.plist> /Library/LaunchAgents/urnetwork-provider.plist

6. sudo launchctl load /Library/LaunchAgents/urnetwork-provider.plist

7. sudo launchctl start /Library/LaunchAgents/urnetwork-provider.plist

8. Verify the unit is running with tail -f /var/log/system.log | grep -i provider. You should see the message "Running on port XX"

9. You're all set!

Provider binary on multiple platforms

If you want to build the binary for multiple platforms, use the Makefile.

mkdir urnetwork
cd urnetwork
git clone https://github.com/urnetwork/connect
git clone https://github.com/urnetwork/protocol
cd connect/provider
go build
# the provider binaries are compiled into binaries at ./build/$OS/$ARCH
# build/darwin/amd64/provider
# build/darwin/arm64/provider
# build/linux/amd64/provider
# build/linux/arm64/provider
# build/linux/arm/provider
# build/linux/386/provider
# build/windows/amd64/provider
# build/windows/arm64/provider

Choose the provider binary for your OS and architecture.

Note: darwin is for macOS

Note: if you have a modern Intel or AMD processor, choose amd64. If you have a modern Apple or Qualcomm processor, choose arm64. Otherwise for Linux IoT and router platforms, run uname -m to find your architecture.

Provider container

We publish an image for following the warp convention to make running an up-to-date provider easier. We continuously update the image with 4 service blocks, where the last block (g4) has been tested the longest and hence is the most stable.

Note: the images are built for amd64 and arm64 architectures only.

To initialize with the latest, most stable version, run the command below.

docker run bringyour/community-provider:g4-latest --mount type=bind,source=$HOME/.urnetwork,target=/root/.urnetwork auth

To run the latest, most stable version, run the command below.

docker run bringyour/community-provider:g4-latest --mount type=bind,source=$HOME/.urnetwork,target=/root/.urnetwork provide

Main Network Space

The main URnetwork space is below. Anyone can host a network space by deploying and maintaining the services in the server repo. The main network space is continuously deployed with the warp tools, where the continuous versions are committed as tags on GitHub for transparency.

The provider tools use the main network space by default.

URnetwork can integrate with MikroTik RouterOS routers to provide and route traffic on the network.

All hEX models are supported. Popular models for home users are RB750.

Provide

TODO integrate to start automatically

Route traffic on the network

TODO integrate to start automatically and route traffic

We made a few changes to the site to streamline our organization:

What's next? Update 2 will be focused entirely on iOS and payout improvements.

WireGuard Crash Course

First, let's go over the basics of WireGuard and how it works in order to understand what we expect from our solution.

WireGuard works by adding a logical (virtual) network interface, which acts as a tunnel between endpoints (peers). This interface can be controlled through normal means like ip-tables and if-config. A WireGuard client controls multiple interfaces, where each interface has a private and public key that is used when encrypting/decrypting traffic going through it. A peer is another WireGuard client's interface which we wish to communicate with.

In an interface, peers are defined by their public key, a local IP, and an endpoint through which the peer can be reached. When a packet is sent through a WireGuard interface, the destination is used to figure out which peer corresponds to the desired target. Then, the packet is encrypted with that peer's public key and is sent to the endpoint of the peer. When receiving a packet, it is decrypted with our interface's private key and authenticated for a peer. Then, the source IP and port of the packet are remembered as the endpoint of the authenticated peer. Once decrypted, the payload of the packet is the plaintext packet the peer is sending through the tunnel. Additionally, each peer is allowed to use only a certain range (or list) of local tunnel IPs, and if the plaintext packet is received outside of this range for a peer, then it is simply discarded as this peer is not allowed to send in this range.

For example, let's define two configurations, one for a WireGuard interface which will act as a server:

[Interface]
ListenPort = 33336
PrivateKey = 4HOYXaS0mtLH9ZChsPaDQ3W/L7Z/rrchr8CMDqZGgXg=

[Peer]
PublicKey = 10NguWHSLJ0tUOr4AkbTtOEYHoagq1KH/PJSIJ3SwFs=
AllowedIPs = 192.168.90.1/32

[Peer]
PublicKey = vi2iosrlXoDeZT08aXlq4AxXUNKO04NDuEeCw2Z7sD0= 
AllowedIPs = 192.168.90.2/32

And another for a WireGuard interface which will act as a client:

[Interface]
PrivateKey = 2JB7HwgWaOnmCpKA9TlMLTLdIYeNOZMnrmy3YI7JYnk=
ListenPort = 29043

[Peer]
PublicKey = UESAy9LgT3PR77Tl1RCnHuj+ZtFvYMeWahnTIEhEvXM=
AllowedIPs = 0.0.0.0/0
Endpoint = 88.42.58.36:33336

So, the client wants to send its packets through the server to appear as if the server is sending them (*VPN magic*). As we can see, configuration files in WireGuard are quite simple. They are ini formatted, and each interface has a private key (used to decrypt packets) and a port (through which packets will be sent). Each peer has a public key (with which outgoing packets meant for that peer will be encrypted) and a list of allowed IPs (only packets from these IPs will be accepted from this peer).

Desired Solution

Now that we know how WireGuard works, let's define what we want to achieve. Simply put, we want an intuitive way for users to connect existing WireGuard clients to the URnetwork.

This entails that we want URnetwork providers to function as routers of the traffic of WireGuard clients of already existing distributions, e.g., your phone's WireGuard app. From a user perspective, a user can choose a provider that will act as a router for their WireGuard traffic and set up a WireGuard tunnel in any WireGuard distribution, allowing them to route all of their traffic in that tunnel through the chosen provider.

This article focuses on how we developed a proof of concept solution that allows anyone to create a WireGuard interface that uses a URnetwork client to add peers, create configuration files for existing WireGuard distributions, and, most importantly, route the traffic of peers.

Task Division

Let's divide in a more concrete manner the features we expect from our solution and try to address each separately. The main goal is we want our solution to be able to use a single command to create a WireGuard interface, configure it, and make it accessible for users to add their own peers to the interface. Additionally, we want the ability to:

1. manage peers in an interface (list, add, remove, etc.);

2. get a configuration file that a peer can use in an existing WireGuard distribution;

3. manage interfaces (list, add, remove, etc.);

4. configure an interface (change its keypair, listening port, local/tunnel address space);

5. change the availability of an interface (bring it up or down).

Moreover, some other quality-of-life features which we can add are a way to:

• generate <public, private> key pairs;

• view the configuration of an interface;

• save the configuration of an interface so it can be started up more easily;

• run commands before or after an interface is started or stopped, similar to how some common WireGuard tools allow.

Problem 1: WireGuard Implementation

The first dilemma we encounter when trying to build our solution is that we need to pick a WireGuard implementation that URnetwork clients will run. We can try using existing WireGuard modules; for example, since version 5.6, the Linux Kernel has built-in WireGuard support, making for an optimized kernel-level integration. However, using this approach will make our solution platform-dependent or, at the least, not available on all platforms. Additionally, we will need a way to make the WireGuard network interfaces route their traffic through a URnetwork client.

This version, however, is very bloated as it has implementations for several platforms (Linux, Windows, macOS, FreeBSD, and OpenBSD), which all use a logical interface. Thus, we will need to remove this platform dependence and re-write it to work in userspace. The way we go about this is to first leave only one implementation (in our case the Linux one since the machine we use is running Ubuntu). Then, as URnetwork runs fully in userspace, we can replace all of the logic for handling packets through a logical interface with a URnetwork client (we use a local user NAT for the proof of concept).

Here, we encounter a problem: how to route the packets as they need to be sent through URnetwork with the public IP of the server machine, but they are received with the (local) tunnel address of the WireGuard interface. The solution is simple—a NAT table that stores which pair of IP:port to map to which tunnel IP. So, for each outgoing packet, we save its tunnel IP in the NAT table using the public IP of the server and the source port of the packet as the key. Then, when we receive a packet, we can check the NAT table (using destination IP and port as the key) and reverse the IP back to the tunnel IP. Since we are modifying each packet, we need to also recalculate the checksums to make it a valid packet. It should be noted that the current implementation only works with TCP and UDP packets, as most traffic is sent using TCP and UDP in the modern Internet. Additionally, ICMP packets are ignored as they do not have a transport layer and hence a port for the NAT table. This is not detrimental, as ICMP packets are not strictly necessary for basic Internet functionality.

	// 1. set up logger with desired log level (available - LogLevelVerbose, LogLevelError, LogLevelSilent)
	logger := logger.NewLogger(logger.LogLevelVerbose, " (userspace-wireguard)")

	// 2. configure the public IPs of the server (it has no ipv6 so we set it to nil)
	var publicIPv4 net.IP = net.IPv4(1, 2, 3, 4)
	var publicIPv6 net.IP = nil

	// 3. create a tun device that uses userspace sockets to send packets
	utun, err := tun.CreateUserspaceTUN(logger, &publicIPv4, &publicIPv6)
	if err != nil {
		logger.Errorf("Failed to create TUN device: %v", err)
		os.Exit(1)
	}

	// 4. create the wireguard device
	device := device.NewDevice(utun, conn.NewDefaultBind(), logger)
	logger.Verbosef("Device started")

	// 5. get the private key of the server and a peer that wishes to communicate with the server
	privateKeyServer, err := wgtypes.ParseKey("4HOYXaS0mtLH9ZChsPaDQ3W/L7Z/rrchr8CMDqZGgXg=")
	if err != nil {
		logger.Errorf("Invalid server private key provided: %w", err)
		os.Exit(1)
	}
	publicKeyPeer, err := wgtypes.ParseKey("10NguWHSLJ0tUOr4AkbTtOEYHoagq1KH/PJSIJ3SwFs=")
	if err != nil {
		logger.Errorf("Invalid peer public key provided: %w", err)
		os.Exit(1)
	}

	// 6. set configuration (CPI)
	port := 33336
	config := wgtypes.Config{
		PrivateKey:   &privateKeyServer,
		ListenPort:   &port,
		ReplacePeers: true,
		Peers: []wgtypes.PeerConfig{
			{
				PublicKey:         publicKeyPeer,
				ReplaceAllowedIPs: true,
				AllowedIPs:        []net.IPNet{{IP: net.IPv4(192, 168, 90, 1), Mask: net.CIDRMask(32, 32)}},
			},
		},
	}
	if err := device.IpcSet(&config); err != nil {
		logger.Errorf("Failed to Set Config: %v", err)
		os.Exit(1)
	}
	
	// 7. start up the device
	device.AddEvent(tun.EventUp)

	//... wait for termination signal ...
	
	// Finally, clean up
	device.Close() 

Problem 2: Managing Interfaces

Device Configuration Files

• [Interface] - contains the configuration for the device/interface (mandatory, exactly one). The following options are available:

  • Address - a comma-separated list of IPs in CIDR notation to be assigned to the interface (can appear multiple times).

  • ListenPort - the port on which the interface listens.

  • PrivateKey - the private key of the interface (mandatory).

  • PreUp, PostUp, PreDown, PostDown - bash commands which will be executed before/after bringing up/down the interface (can appear multiple times). The special string %i is expanded to the interface name.

  • SaveConfig - a boolean value to save the configuration of the interface when being brought down. Any changes made to the device while the interface is up will be saved to the configuration file.

• [Peer] - contains the configuration for a peer (optional, can appear multiple times). The following options are available:

  • PublicKey - the public key of the peer (mandatory).

  • AllowedIPs - a comma-separated list of IPs in CIDR notation that the peer is allowed to access through the interface (can appear multiple times).

  • Endpoint - the public IP of the server where the peer can be contacted.

CLI Commands

However, since our implementation operates in userspace rather than directly in the kernel, some differences arise. Additionally, while kernel-based WireGuard allows for lower latency due to its direct access to network interfaces, a userspace implementation can offer flexibility across different platforms and is often easier to extend with custom logic, such as choosing the depth of logs provided or operating devices programmatically.

The list of commands that are currently supported by the CLI tool can be found below:

Tether cli.

Usage:
    tethercli add [--dname=<dname>] [--log=<log>] [--ipv4=<ipv4>] [--ipv6=<ipv6>]
    tethercli remove [--dname=<dname>]
    tethercli up [--dname=<dname>] [--config=<config>]
    tethercli down [--dname=<dname>] [--config=<config>] [--new_file=<new_file>]
    tethercli get-config [--dname=<dname>] [--config=<config>]
    tethercli save-config [--dname=<dname>] [--config=<config>] [--new_file=<new_file>]
    tethercli gen-priv-key 
    tethercli gen-pub-key --priv_key=<priv_key>
    tethercli get-device-names
    tethercli get-device [--dname=<dname>]
    tethercli change-device [--dname=<dname>] [--lport=<lport>] [--priv_key=<priv_key>]
    tethercli add-peer --pub_key=<pub_key> [--dname=<dname>] [--endpoint_type=<endpoint_type>]
    tethercli remove-peer --pub_key=<pub_key> [--dname=<dname>]
    tethercli get-peer-config --pub_key=<pub_key> [--dname=<dname>] [--endpoint_type=<endpoint_type>]

Options:
    --dname=<dname>                   WireGuard device name. Keeps the last set value [initial: bywg0].
    --config=<config>                 Location of the config file in the system [default: /etc/tetherctl/].
    --log=<log>                       Log level from verbose, error, and silent [default: error].
    --ipv4=<ipv4>                     Public IPv4 address of the device.
    --ipv6=<ipv6>                     Public IPv6 address of the device.
    --new_file=<new_file>             Location where the updated config should be stored. If not specified, the original file is updated.
    --endpoint_type=<endpoint_type>   Type of endpoint to use for peer config [default: ipv4].
    --lport=<lport>                   Port to listen on for incoming connections.
    --pub_key=<pub_key>               Public key of a WireGuard peer (unique).
    --priv_key=<priv_key>             Private key of a WireGuard device.

So, for the server, we define the following configuration stored in a file called tbywg0.conf:

[Interface]
Address = 192.168.90.0/24
ListenPort = 33336
PrivateKey = 4HOYXaS0mtLH9ZChsPaDQ3W/L7Z/rrchr8CMDqZGgXg=
SaveConfig = true

[Peer]
PublicKey = 10NguWHSLJ0tUOr4AkbTtOEYHoagq1KH/PJSIJ3SwFs=
AllowedIPs = 192.168.90.1/32

Then, we can start tetherctl in CLI mode using the go run . cli command in a terminal. Next, we are presented with the integrated CLI where we can run commands after a provided input prompt >. What we will do is:

1. Create a device called tbywg0 (it has to match the name in the configuration file).

> add --dname=tbywg0 --log=v

1. Then, we bring up the device with verbose logging, providing the path to the above-created configuration file.

> up --config=/root/connect/tetherctl/

That's it! We have a running device with a peer added to it. To make sure, we can see the device's current configuration we can use the following command:

> get-config --dname=tbywg0 --config=/root/connect/tetherctl/

Or if we want to see the underlying wgtypes.Device object, we can use:

> get-device --dname=tbywg0

Additionally, we can get the configuration file that the peer needs using:

> get-peer-config --dname=tbywg0 --pub_key=10NguWHSLJ0tUOr4AkbTtOEYHoagq1KH/PJSIJ3SwFs=

The output we get after running the command is:

# Config for public key "10NguWHSLJ0tUOr4AkbTtOEYHoagq1KH/PJSIJ3SwFs="
[Interface]
PrivateKey = __PLACEHOLDER__ # replace with your private key
Address = 192.168.90.1/32
DNS = 1.1.1.1, 8.8.8.8

[Peer]
PublicKey = UESAy9LgT3PR77Tl1RCnHuj+ZtFvYMeWahnTIEhEvXM=
AllowedIPs = 0.0.0.0/0
Endpoint = 88.42.58.36:33336

The output from this command can be used in any WireGuard app to connect to the device and route all of our traffic through the newly created device. The only thing that should be changed is the peer's private key, as the device does not have it. Hooray! We have achieved our goal of making a fully interactable userspace WireGuard distribution that runs on URnetwork. But how can users obtain their peer's configuration, as they cannot access the CLI?

Problem 3: Availability for Users

As this is a proof of concept, we decide to go for an API. The API can be exposed through a simple HTTP server that users can send requests to. Thus, we add several endpoints, each serving a distinct purpose, including: * /peer/add/:endpoint_type/*pubKey (request method: POST) - adds a peer with the given public key to the WireGuard device. The endpoint type specifies which type of endpoint the peer wants to communicate with the server on (available values: any, ipv4, ipv6, domain). The request has no body. The config that the peer can use to set up its own WireGuard client is returned here (essentially runs the CLI add-peer command). * /peer/remove/*pubKey (request method: DELETE) - removes a peer with the given public key from the WireGuard device (essentially runs the CLI remove-peer command). The request will succeed even if the peer does not exist, meaning that if a request is accidentally repeated, the peer will only be removed once.

• /peer/config/:endpoint_type/*pubKey (request method: GET) - returns the configuration of a peer with the given public key (essentially runs the get-peer-config command) and the specified endpoint type of the server (available values: any, ipv4, ipv6, domain). The configuration can be used in any existing WireGuard distribution.

Additionally, we have added several commands so that a developer can start the API for any of its WireGuard devices through the CLI:

Tether cli.

Usage:
    tethercli start-api [--dname=<dname>] [--api_url=<api_url>]
    tethercli stop-api
    
Options:
    --api_url=<api_url>               API url [default: localhost:9090].

The --api_url option defines the address and port where the API will be accessible. By default, it is set on localhost:9090, but if you want to expose it to be accessible through your public IP, you can set --api_url=:9090. As an example, let's continue from where we left off in the last section. Let's say the developer wants users to be able to access the device through the API. Then, they can run:

> start-api --dname=tbywg0 --api_url=:9090

Then, a user with a peer defined by the keypair <vi2iosrlXoDeZT08aXlq4AxXUNKO04NDuEeCw2Z7sD0=, WDxx84eTgEdpZ+ykGHSNWEtYKzFAXshtPSLLCUbr4XE=> needs to make a POST request with the following URL: http://88.42.58.36:9090/peer/add/any/vi2iosrlXoDeZT08aXlq4AxXUNKO04NDuEeCw2Z7sD0=

The response of the request is the configuration file that can be used by the user to create a tunnel with the device (after putting in their peer's private key). In our case, this is:

# Config for public key "vi2iosrlXoDeZT08aXlq4AxXUNKO04NDuEeCw2Z7sD0="
[Interface]
PrivateKey = __PLACEHOLDER__ # replace with your private key
Address = 192.168.90.2/32
DNS = 1.1.1.1, 8.8.8.8
	
[Peer]
PublicKey = UESAy9LgT3PR77Tl1RCnHuj+ZtFvYMeWahnTIEhEvXM=
AllowedIPs = 0.0.0.0/0
Endpoint = 88.42.58.36:33336

Additionally, as we can see, the peer is given the next available IP (192.168.90.2) in the local address space, as defined by the device's configuration. Currently, choosing the next available IP is done in a brute-force manner by iterating through all IPs in the local tunnel subrange, checking if they are used by another peer, and if not, using it. This process can be greatly improved, however, prioritizing efficiency is not the primary goal of this proof of concept.

Well, anyway, job well done! We now provide users with a way to add their peers to a device and get a configuration file that can be used in any WireGuard distribution to set up a tunnel.

Problem 4: Single Command

We move on to the final problem that needs to be tackled: creating a single command for setting up a device with a desired configuration where users can add their peers to the device easily. Thankfully, having solved the previous problems makes this one quite straightforward to address.

• How can a class (the same construction process) create different representations of a complex object? For us, this is the device object.

• How can a class that includes creating a complex object be simplified? For us, this is the configuration process.

The design pattern comprises a Director object, which manages different Builder objects that are the separate "workflows." For now, we have implemented only one Builder type, called a DefaultBuilder, which implements the DeviceBuilder interface:

type IDeviceBuilder interface {
	CreateDevice(dname string, configPath string, logLevel int) error          // creates and brings up a device
	StopDevice(dname string, configPath string) error                          // brings down a device
	ManageEndpoint(opts EndpointOptions) error                                 // add/remove/reset endpoint
	ManagePeer(dname string, opts PeerOptions) (string, error)                 // add/remove peer from device (and get config if requested)
	StartApi(dname string, apiURL string, errorCallback func(err error)) error // start API for device
	StopApi(dname string) error                                                // stop api of device
	StopClient()                                                               // closes tether client
}

Then, we add a command that runs through our workflow (using the functions of the DeviceBuilder interface):

Tether control.

Usage:
    tetherctl default-builder --dname=<dname> --config=<config> --api_url=<api_url> [--log=<log>]
    
Options:
    --dname=<dname>         Wireguard device name.
    --config=<config>       Location of the config file in the system.
    --api_url=<api_url>     API url.
    --log=<log>             Log level from verbose(v), error(e), and silent(s) [default: error].

The workflow is as follows:

1. Use the provided log level for the logger.

2. Add an endpoint (use the public IP of the server).

3. Create the device by the provided name using the given configuration file (here we also start the device).

4. Start an API server at the provided URL (now users can add their peers and obtain configuration files).

5. Wait for an interrupt signal.

6. Stop the API, device, and WireGuard client.

So once again, hurrah! We solved another problem: automating the process of creating and configuring a device through a single command.

Summary

This brings the end of the project, so thank you for following this article. We quickly summarize what we did and provide an extra section where we discuss pitfalls and future work.

Pitfalls and Future Work

This project was not without its challenges. Initially, the exact solution wasn’t entirely clear, as we were still figuring out the requirements and the specific limitations tied to different platforms.

The problems we defined in this article were ordered from more detrimental to the design of the final solution to less detrimental. Unfortunately, during the development of the solution, we did not tackle them in the given order; hence, we were forced to redesign the solution and refactor the code base several times.

At first, we planned to rely on the Linux kernel WireGuard module and had bash scripts to handle parts of the setup automatically. However, we quickly hit a compatibility barrier due to differences across platforms and their corresponding WireGuard implementations, which pushed us toward a userspace solution. Shifting to this approach required several rounds of refactoring, impacting everything from CLI commands to the API and the service structure. Each shift brought us closer to the final solution.

A lot of time was spent at the start researching WireGuard’s features to decide exactly what our solution should include. This helped shape our configuration format and clarified what the final setup should look like. This early research gave us confidence and a foundation to move forward with a better sense of direction.

Looking to the future, there are a few areas we want to expand. First, as previously mentioned, we can improve the selection of the next allowed IP, which would make the process more efficient. Also, while currently both IPv4 and IPv6 are supported, only IPv4 is tested in the full setup, so IPv6 functionality may require additional testing and adjustments to ensure full functionality within the system.

Second, our solution should be integrated more tightly with URnetwork, ideally allowing users to route their traffic through URnetwork providers rather than the current approach of using a user local NAT. We also want to give users the ability to pick specific providers to route their traffic, adding more control based on things like location or bandwidth needs.

Ultimately, we envision this project as part of the URnetwork app, where users can generate configurations compatible with any WireGuard distribution. In the URnetwork app, users should also be able to directly manage routing options and provider choices, making it easier to get everything set up the way they need. With these improvements, we’re aiming for a more adaptable, all-in-one tool for the next stages of the project as a standalone feature.

The existence of this page confirms:

• BringYour has never turned over our encryption or authentication keys or our customers' encryption or authentication keys to anyone.

• BringYour has never installed any law enforcement software or equipment anywhere on our network.

• BringYour has never provided any law enforcement organization a feed of our customers' content transiting our network.

• BringYour has never modified network content at the request of law enforcement or another third party.

• BringYour has never weakened, compromised, or subverted any of its encryption at the request of law enforcement or another third party.

This page lists quarterly statistics of the number and type of abuse reports, decryptions of the abuse logs, and type of outcomes since the start of the company.

Statistics

Outcomes

April-June 2024

No outcomes.

January-March 2024

No outcomes.

Our trust and safety process is how we create a network for all users to safely participate with the most access and the most privacy possible. At BringYour our goal is to create a network where everyone can participate knowing they will be safe, and users are confident their traffic is uncensored, anonymous, and encrypted.

The process we use is to combine an automated "frontline" with a catch-all "backline" abuse audit process that preserves privacy. Most issues are resolved automatically by the frontline, which involves a mix of protocol and economic incentives. It involves turning off protocols associated with botnets and copyright abuse, while keeping web and app traffic uncensored and free. All levels are opt-out, meaning there are ways for providers to change the rules. Our stance is that we want to have a safe default, but allow users to have freedom of choice.

Warrant canary

• BringYour has never turned over our encryption or authentication keys or our customers' encryption or authentication keys to anyone.

• BringYour has never installed any law enforcement software or equipment anywhere on our network.

• BringYour has never provided any law enforcement organization a feed of our customers' content transiting our network.

• BringYour has never modified network content at the request of law enforcement or another third party.

• BringYour has never weakened, compromised, or subverted any of its encryption at the request of law enforcement or another third party.

Transparency report

Frontline protocol and economic incentives

The frontline are automated rules embedded within the clients and providers. If the client and provider mutually agree to change the rules, it is possible to use different rules. However, it is not possible for one party to to change the rules without the other party, and a mismatch in rules will raise a contract dispute. In this way these rules are the default, but there are ways that two parties can opt-out of the rules. Our stance is that we want to have a safe default, but allow users to have freedom of choice. We explain the directions to change the rules at the end.

The current default set of frontline rules are split into protocol limits, rate limit, and contract limits.

Protocol limits

No local network access

Only public unicast addresses are routable. Traffic to private or multicast addresses will not route.

Disable unencrypted protocols

Plain DNS and HTTP are disabled. The device must use DoH/DoT and HTTPs.

Unencrypted mail protocols are disabled. The encrypted versions of these protocols are supported.

DNS (port 53) is blocked.

HTTP (port 80) is blocked.

IMAP (port 143) is blocked.

SMTP (port 25) is blocked.

POP (port 110) is blocked.

Block restricted ports

The restricted port range is used by many core internet protocols which are most susceptible to abuse. Our goal is to block all restricted ports except protocols needed by mainstream users to access almost all of the web, communication, apps, and gaming.

HTTPS (port 443) is unblocked.

DoH (port 443) in unblocked.

DoT (port 853) is unblocked.

IMAP TLS (port 993) is unblocked.

SMTP TLS (ports 587 and 465) is unblocked.

POP TLS (port 995) is unblocked.

SFTP (port 990) is unblocked.

Block protocols that commonly lead to abuse to providers

We unblock all user ports except protocols that lead to an excess number of abuse reports for providers. It does not mean these protocols are inherently bad. Rather, they cause an a strain for providers that makes it harder to safely be a provider. Generally user ports are used widely in WebRTC, communication, and gaming.

Bittorrent (ports 6881-6889) is blocked.

IRC (port 6667) is blocked.

Rate limits

Connection rate limit per source

Each source can only create a limited number of new TCP connections and UDP streams per second. The number is high enough that it does not impact normal use cases. The goal of the rate limit is to prevent traffic abuse using the network.

Parallel connections limit per source

The number of parallel connections per source is limited. Additionally the number of parallel connections per provider is limited by the ulimit settings of the provider device. The goal of the parallel limit is to prevent prevent traffic abuse using the network.

Contract limits

Contract priority

Contracts are assigned a priority by the platform. The contract priority for a client is determined by its contribution to the network. Providing and being a premium user are considered contributions to the network. Providers may dynamically rate limit connections based on contract priority.

To make the network more resilient to bots, contract priority is weighted towards premium users and providing premium traffic. In other words, the spend per GiB is the core unit used to confer priority to providers. In this way priority is correlated with money flow and is harder to influence without spending money.

Minimum contract close

Minimum contract close has been deprecated in favor of contract priority. This lets us better support free users.

Changing the rules

On our roadmap is to let providers turn off any of the default rules. The providers would do this knowing the network is not able to keep them safe. We are considering a way to let providers signal which rules are enabled, so that clients who want to choose a different set of rules can choose the providers that match those rules. In other words, users could select providers that disable rules when searching for providers.

For example providers with absolutely free internet could remove most rules and serve clients who want that.

Backline abuse audit process that preserves privacy

We operate as a US company and want to stay and scale in the US. We take the stance that the company itself may be an adversary to user privacy, so that users must be protected with hard cryptography and properly distributed protocols. Our goal is to advance the state of art of logging with better cryptography, so that we can have proper duty of care to resond to abuse, while taking the position that the company should not know anything about the users. Our approach is detailed below on how we response to abuse reports and take action to remove abuse from network.

• When

• Source IP and port

• Destination IP and port

• SHA256 hash of the TLS client random if the abusive connection is TLS encrypted

• Reporter contact email. This must be from an official domain that we can use to verify.

• Reporter abuse notice

We will need to verify the identify of the reporter, as well as the validity of the abuse notice. We will typically reach out directly to the reporter contact to do the verification.

Typically an abuse notice is submitted by a provider when they receive a notice. However we also work with abuse reporting services so that notices can be filed directly to the network.

We are able to enforce abuse notices because the network maintains an encrypted audit log. Providers opt-in to send encrypted records to the log, and throw away their key. Only the destination or ISP would be able to derive the key, which is what they send in an abuse report.

This ensures extracting data is intractable unless a mostly-complete key is provided, as from an abuse notice. In this way the company cannot decode the data without a legitimate abuse report. With a mostly-complete key, finding the accounts involved in a single record is possible, but it is still computationally intensive by design. We are able to extract single records in sufficient time to feed into the trust and safety process. The technical details can be found in the audit protocol.

The encrypted audit log is maintained for 24 months.

The trust and safety process involves looking at both parties involved in any incident, as well as the submitter of the incident. The result may be that any of the parties or submitter may be removed from the network. Additionally abuse patterns are considered as candidates to incorporate into the frontline system.

Opting out

Providers may opt out of sending encrytped audit records to the platform. However in these cases we will not be able to take action on abuse reports submitted by the provider.

SHA256 hash of the TLS client random

Today the TLS client random value is not typically logged on servers and ISPs. We believe this leads to a standard of logging that forces proxy companies to store logs in a way that compromises user privacy. Using a 256-bit hash of the TLS client random creates enough entropy in the encrypted record key such that it could not be brute forced without a mostly complete abuse report.

When you browse the internet or use an app on your phone, a significant portion of your traffic is not related to the content or services you’re accessing. Websites and apps often include elements from third-party services, such as analytics providers, content delivery networks, and advertising networks. These third parties can track your behavior, collect data on your browsing habits, and even influence where your data is routed. Often, users aren’t fully aware of this data-sharing, which can impact privacy and online experiences.

In this article, we aim to tackle this issue by exploring an approach that categorizes the web traffic of users by the website/app they are using as well as if any third parties are involved. Thus, giving users a clear view of who is interacting with their data and allowing them to make informed choices on how it flows, promoting transparency and giving control back to the user.

Understanding The Problem and Constraints

To start, let’s look at what we’re trying to solve and the data we can work with. As a VPN, the URnetwork app has access to all of a user’s internet traffic. The goal is to use this traffic data to help users better understand how their data is being accessed and enable them to control this flow of data effectively.

To give users a clear picture of their traffic patterns, we need to identify the applications they use and categorize any third-party connections, such as ads, analytics, or other services. This information enables users to make informed choices about their data—for example, blocking specific third parties. This could also allow them to save profiles for apps, such as, "when I'm using this app, always route my traffic through a certain country." Additionally, we want to guarantee that user traffic is never shared with unauthorized parties. An easy way to achieve this is by developing a solution that works entirely on-device. This ensures privacy by keeping the user’s information confidential and under their control.

We also chose to avoid deep packet inspection (DPI) because users generate a vast amount of data daily, and processing it all on-device would be computationally expensive, potentially infeasible under a time constraint, and certainly raise privacy concerns. Avoiding DPI means we need to find a way to categorize traffic without actually looking into what users are sending or receiving. Hence, we will only consider the headers of packets as available information.

First Steps

We define four transport messages that correspond to the different packet types in a session:

• TransportOpen - this is the opening message; if the session is a TLS one, we can also extract the name of the server with which the user is communicating (domain name).

• TransportClose - this is the closing message; here, we also have information on why the connection was closed (error, timeout, etc.).

• WriteDataChunk - this is application data sent by the client.

• ReadDataChunk - this is application data received by the client.

Interpreting the Data

Currently, we have a collection of transport sessions where each consists of different transport messages, but how can we interpret this data for our needs? Well, our main goal is to relate the different sessions to each other to try and figure out the ones that are part of the same application. This is a perfect use case for clustering. Most clustering algorithms work using the distance between the different input points. We, however, have sessions (and their packets), so we need to make our own relation that can be used as distance.

The first idea that comes to mind is to define each session by the times at which the packets were sent, as it can be expected that sessions relating to the same application will be active during the same intervals of time. So we extract, for each session, a list of times (corresponding to the send/receive time of the packets) and compare them.

Sessions Comparison

Now, the question is, how can we compare two sessions? Let's say that sessionA was active at timeA, and sessionB was active at timeB. Do we count this as a match between the sessions only if timeA = timeB, or if the two times have a 1-second difference, or somehow else entirely? Let's, for now, take the simplest approach—two times count as overlapping if they are within 1 second of each other. Then, we define the total overlap to be the number of pairs of times between the two sessions that overlap. For example, if we have sessions with times [10, 15, 17, 18] and [11, 16], then the total overlap is 3 because there are 3 pairs that overlap (<10, 11>, <15, 16>, <17, 16>). We will later explore other approaches that might be better for overlap calculation.

Domain Interpretation

Another piece of information that we don't fully use is the domain names of each session. As each domain can be broken down into hierarchical levels (top-, second-, third-level domains), we could potentially group sessions based on parent domains. For instance, ipv4-abc.1.api.urnetwork.com can be split into api.urnetwork.com, urnetwork.com, and .com as parent domains. So then, for example, if we encounter api.urnetwork.com and vpn.urnetwork.com, we can store their times separately as expected, but also group them under urnetwork.com. This approach allows us to relate sessions originating from the same parent domain better. Furthermore, if two domains that share the same parent domain are not related, this might prove that one (or both) of them is a third party that cannot be correlated to the bigger parent domain group. Note, we intentionally ignore top-level domains (like .com), as they are too general to provide meaningful relations. Thus, we split each domain into a second- and a third-level domain and aggregate times that share the same parent domain.

Test Data

As we can see, there are several times that seem to correlate. For example, in green we see domain names for Wikipedia, in purple there seems to be some traffic for WhatsApp (which was running in the background at the time of recording the test session), in orange are Netflix-related domains, and in blue - New York Times. In the future, we can use these related times to verify our clustering by checking if they are grouped together in the same cluster.

Overlap and Distance

Now, we see that the most prominent region is the WhatsApp one (in purple), with the rest being somewhat recognizable. So we have not made any improvements to our distance relation.

Clustering

Now, let's try and cluster using the two approaches. To build the distance matrix, we choose to use Gaussian overlap with a standard deviation of 10ms as per the results of the last section. We also need to choose the constant λ for the exponential decay. After some testing, we find that when using OPTICS, a large value (we use λ=150) is needed to exaggerate the differences between the smaller overlap values. For HDBSCAN, the decay value does not matter (as long as it is bigger than 1) as HDBSCAN is actually an algorithm that builds upon DBSCAN by finding the most optimal value (in a quite efficient manner) for one of its parameters (ε), which is normally quite unintuitive to choose. Thus, the rate of decay λ for HDBSCAN doesn't matter as changing λ changes the optimal ε value, but HDBSCAN will still choose the correct one, which will ultimately produce the same clustering. The main advantage of having a bigger λ in general is that the differences are exaggerated, so it is easier to visualize the relationships between the sessions.

Next, to cluster, we need to choose the main (intuitive) parameter for each algorithm, which is the minimum size at which a cluster will form. Normally, this would be 2, as any two related sessions should be clustered, but since we also include parent domains, we make it 3. Also, both approaches put the unclustered domains together in a cluster with ID=-1 to indicate that they are unclustered. Now, after running the clustering for OPTICS, we get 6 clusters:

Running HDBSCAN, we get 8 clusters:

From these first results, we see that both methods form good clusters based on our distance matrix. Comparing the two, it seems that OPTICS is better at finding closely related sessions, whereas HDBSCAN is a bit more lax in what it considers a cluster. However, the more pressing concern is why some clusters were not formed, i.e., the Wikipedia one? There are several possible causes for this:

• The data is too small to form the clusters (it is only ~4 minutes of traffic after all);

• The overlap function used is still not good enough;

• The cluster algorithm's other parameters can be further exploited to achieve better clustering.

Relating to the first issue, we try generating a second dataset that is 3 times bigger and cluster similarly to how we did with the first one. The results seem to be better, with more of the meaningful clusters forming and even HDBSCAN outperforming OPTICS. So we can partially attribute for the "lackluster" first results to the size of the data. Next, we believe that the overlap function that is currently used is good at extracting the prominent features of the data and that, for this preliminary implementation, is sufficient.

Conclusion

In this article, we outlined our approach on clustering transport sessions of packets such that similar sessions are clustered together. We defined a method to relate the sessions using the time of each packet. We further analyzed several approaches to calculate the relationships between sessions, including fixed margin overlap and Gaussian overlap. Both approaches represent the time of each packet as a continuous interval and calculate the total overlap between pairs of times of different sessions. We then proposed a method, exponential decay, to convert the overlap values to distance values that can be used to cluster the sessions.

Finally, we evaluated two algorithms, HDBSCAN and OPTICS, by using them to cluster a small test dataset. We conclude that the two methods are quite similar in results, producing well-defined and meaningful clusters. When tweaking the hyperparameters, we find that HDBSCAN outperforms OPTICS in terms of finding more and smaller clusters. This, however, can be due to our relatively small test data, so a final conclusion cannot be drawn until further analysis is performed using more traffic data.

Discussion and Future Work

Our main goal was to "identify the applications users use and categorize any third-party connections entirely on-device only considering the headers of packets." We showed that identifying the application/websites used can be achieved by grouping them into clusters. However, we have not directly addressed how to identify third-parties; hence, we theorize an approach that uses the results from the clustering to achieve this. As we split the domain of a session into parent domains, we can use these parent domains and the unclustered sessions to identify third-parties. If a session has sufficient overlap with other sessions but is still left unclustered, we might consider this session as a third-party. Additionally, if there is a small cluster where most of the sessions have parent domains that are either unclustered or clustered in another cluster, then we can consider the small cluster as a third-party cluster. Thus, in a future implementation of our approach, we believe there is enough information in the current results to obtain the third-parties present in the dataset.

Finally, we compose a short list of the directions where this project can go in the future:

• More efficient implementation of the clustering algorithm;

• Use more of the data in the packet headers, e.g., size of the packet;

• Optimize memory usage of clustering;

• Technique for extracting third-parties;

• Compose bigger test data.

The next section outlines some specific challenges we encountered during development as well as how we use tests in our approach.

Challenges and Testing