So funktioniert URnetwork
URnetwork ist ein Privacy-Netzwerk, getragen von seinen Mitgliedern. Dein Datenverkehr verlässt das Netz über das Gerät eines anderen Mitglieds, nicht über einen VPN-Server im Rechenzentrum. Websites sehen die IP-Adresse dieses Geräts statt deiner. Dieser Überblick erklärt den Pfad und was jede Partei sehen kann.
Die Exits sind Tausende Mitgliedsgeräte in mehr als 2.000 echten Städten in über 90 Ländern, keine virtuellen IPs aus einer Handvoll Rechenzentren. Die Live-Zahlen stehen unter api.bringyour.com/stats/last-90.
Der Pfad
Der Datenverkehr nimmt vier Etappen: du → Extender → Operator → Provider → Internet.
- Client. Die App oder SDK-Instanz auf deinem Gerät. Ein Netzwerk ist URnetworks Wort für dein Konto, die Abrechnungs- und Identitätseinheit; es kann viele Nutzer, Geräte und Clients umfassen.
- Extender. Ein von Freiwilligen betriebener Weiterleitungs-Hop auf einer unabhängigen Adresse, und die erste Etappe. Er leitet deine verschlüsselte Sitzung an die Plattform weiter, ohne sie zu terminieren, und trägt damit Bytes, die er nicht lesen kann. Als dein erster Hop sieht er allerdings deine IP-Adresse.
- Operator. BringYour, Inc., die Partei, die das Netzwerk koordiniert. Ihre Plattform (
connect.bringyour.com,api.bringyour.com) authentifiziert Clients, vermittelt dir Provider, leitet Datenverkehr weiter und wickelt Verträge und Zahlungen ab. - Provider. Ein Mitgliedsgerät, das seine Internetverbindung teilt und deinen Datenverkehr ins Internet weiterleitet — Websites sehen also eine Privatanschluss-Adresse in der Stadt des Providers.
Operator und Provider sind die beiden Relay-Parteien, und das Design teilt das Wissen zwischen ihnen auf. Der Extender ist ein Erreichbarkeits-Hop außerhalb dieser Aufteilung und fügt keine eigene Verschlüsselung hinzu. Er hält das Netzwerk erreichbar, wo die Plattform blockiert ist.
Wer was sehen kann
Auf dem Standardpfad hält keine einzelne Partei zugleich deine Identität und deine Aktivität. Diese Aussage ruht auf zwei Eigenschaften mit unterschiedlicher Reichweite.
Der Provider erfährt nie, wer du bist. Der Operator steht zwischen dir und dem Provider, also sieht der Provider eine Geräte-ID und die Ziele, die er bedient — nie deine Adresse. Das gilt auf jedem Relay-Pfad, ohne eine Einstellung, die man falsch setzen könnte.
Der Operator kann nicht lesen, was du sendest. Die Sitzung zwischen Client und Provider ist Ende-zu-Ende versiegelt, in den nativen Apps standardmäßig an — der Operator trägt also Chiffretext plus Timing und Volumen. Das gilt auf dem versiegelten Standardpfad; die Modi unten zeigen die Pfade ohne Versiegelung.
Die Browser-Erweiterung und die Proxy-Endpunkte haben gar keine versiegelte Sitzung. Das ist Geltungsbereich, kein Standardwert, und es liegt an der Architektur: Ein Browser oder ein einfacher Proxy-Client kann die Engine des Netzwerks nicht ausführen, also betreibt der Operator das Client-Gerät aus der Ferne und übersetzt zwischen den Protokollen — eine Versiegelung, die von diesem Gerät ausginge, begänne im Inneren des Operators, also genau der Partei, die sie blind machen soll. Die Implementierung hat die Versiegelung dafür eingetauscht, diese Plattformen überhaupt zu erreichen. Dort hält nicht Verschlüsselung, sondern eine per Test festgenagelte Speicherdisziplin den Operator davon ab, deine Ziele anzusammeln (Bedrohungsmodell §2.4).
| Modus | Operator sieht | Provider sieht | Standard und Verfügbarkeit |
|---|---|---|---|
| Relay, versiegelt | Konto/Quellverbindung, Provider-Zuordnung, Chiffretext sowie Timing/Volumen | Ziel-Datenverkehr, Geräte-/Vertrags-ID, nicht deine echte Quell-IP | der native Standard, ab Werk |
| Relay, Standard | Konto/Quellverbindung, Provider-Zuordnung, innere Ziele und Paketbytes | Ziel-Datenverkehr, Geräte-/Vertrags-ID, nicht deine echte Quell-IP | Browser- und Proxy-Pfade oder Versiegelung aus; ist sie an, wird ein Provider, zu dem sie sich nicht aufbauen lässt, übersprungen statt hier bedient |
| Direkt | weniger Relay-Beteiligung | deine echte Quell-IP und Ziel-Datenverkehr | opt-in, durch Ausschalten von Starke Anonymisierung (Strong Anonymization) |
Die Tabelle ist maßgeblich. Das Bedrohungsmodell spielt dieselbe Aufteilung gegen benannte Angreifer durch, einschließlich eines feindseligen Operators und kolludierender Provider.
Warum vier Etappen
Geschwindigkeit ist ein Designziel, kein Zugeständnis. Jeder zusätzliche Hop verlängert den Hin- und Rückweg zwischen dir und dem Internet — deshalb tun lange Ketten im Alltag weh. Den Pfad bei vier Etappen zu begrenzen hält das Wissen aufgeteilt, bei Geschwindigkeit auf Streaming-Niveau. URnetwork beziffert die durchschnittliche Streaming-Geschwindigkeit im Netzwerk mit 40 Mbps+.
Die formale Beschreibung: ein latenzbegrenztes Multi-Hop-Design mit Datentrennung. Das Wire-Protokoll unterstützt das Verketten weiterer Provider-Zwischenstationen; das ausgelieferte Netzwerk nutzt den Pfad mit einem einzelnen Provider. Andere Designs machen andere Abwägungen. Tor bezahlt längere Ketten mit Latenz. Apples Private Relay ist eine verschlüsselte Aufteilung auf zwei Parteien, in geschlossenen Implementierungen, bei der ein Unternehmen beide Parteien auswählt und bezahlt. Die meisten VPNs versuchen gar keine Aufteilung. Die Vergleichskarte geht sie Produkt für Produkt durch.
Was beim Verbinden passiert
- Anmelden. Die App meldet sich mit einem Token an, das nach etwa einem Tag abläuft und sich automatisch erneuert — ein gestohlenes Token wird also schnell wertlos. Techniker nennen es JWT. Konten können E-Mail oder Telefonnummer nutzen, Google- oder Apple-Anmeldung, eine Solana- oder Bittensor-Wallet-Signatur, eine Seedphrase oder ein Sofort-Konto (Instant Account): ohne E-Mail, in einem Tipp erstellt, dessen ganzer Zugangsnachweis eine Wiederherstellungs-Seedphrase ist. Die Phrase ist mit Mullvads Nummernkonten vergleichbar und übersteht eine Neuinstallation; der Server erzeugt sie, zeigt sie genau einmal und behält nur Hashes — sie zu verlieren heißt, das Konto zu verlieren.
- Die Plattform erreichen. Der Client öffnet einen verschlüsselten Kanal zur Plattform: TLS über WebSocket, oder QUIC/HTTP-3, wo das Netz es zulässt. Der Kanal läuft durch einen Extender und terminiert an der Plattform. Direkte Routen werden zuerst im Wettlauf probiert; die Extender-Etappe übernimmt, wenn sie scheitern.
- Provider finden. Der Client fragt nach Providern passend zu deiner Auswahl: bester verfügbarer, ein Land aus der Liste oder eine Stadt, die du findest, indem du ihren Namen ins Suchfeld tippst. Die Plattform bewertet Kandidaten laufend nach Zuverlässigkeit und gemessener Geschwindigkeit und liefert eine sortierte Auswahl zurück.
- Verträge öffnen und los. Der Client hält ein Fenster aus mehreren Providern und verteilt deine Verbindungen darüber. Das Standardprofil fährt zwei Fenster: ein Qualitäts-Set aus 2–6 Providern für HTTPS und ein Geschwindigkeits-Set aus 1–2 für alles andere. Typischerweise sind drei bis acht Provider gleichzeitig aktiv. Verbindungen zu einer bestimmten Website bleiben auf einen Provider gepinnt, sodass diese Website für deine ganze Sitzung eine stabile Adresse sieht. Ein Provider, der schwächelt oder wegfällt, wird ersetzt; der Rest des Fensters fängt seine Arbeit auf. Jedes Byte bewegt sich unter einem Transfervertrag (transfer contract), der Abrechnungseinheit, die misst, was jeder Provider trägt.
Deine Exit-Identität ist plural: mehrere Provider zugleich, mit Wechsel über die Zeit, sodass kein einzelner Exit mehr als einen Ausschnitt deines Surfens sieht. Das Fenster ist zugleich die Geschwindigkeitsstrategie: Privatanschlüsse schwanken stärker als Server im Rechenzentrum, und das Abwerfen langsamer Provider hält Streaming flüssig.
Verschlüsselung
Der Kanal zwischen Client und Plattform ist immer verschlüsselt: TLS 1.3 oder QUIC.
Die versiegelte Sitzung. Die App verschlüsselt den Datenverkehr bis zum Provider durch, sodass der Operator Bytes weiterleitet, die er nicht lesen kann. Bei ihm kommen Chiffretext plus Timing und Volumen an. Der Schalter heißt Post-Quanten-Verschlüsselung (Post Quantum Encryption) im Connect-Drawer der Android-, iOS-, macOS-, Windows- und Linux-Apps, standardmäßig an in allen fünf. Die Versiegelung ist ein TLS-1.3-Handshake direkt zwischen Client und Provider, mit dem hybriden Post-Quanten-Schlüsselaustausch X25519MLKEM768 und AES-256-GCM pro Nachricht. Identitätsschlüssel sind Ed25519; „Post-Quanten“ meint nur den Schlüsselaustausch.
Geltungsbereich: Bei eingeschalteter Versiegelung trägt ein Provider, der sie nicht aufbauen kann, deinen Datenverkehr überhaupt nicht. Der Client weigert sich, Anwendungsdaten im Klartext zu senden, statt still zurückzufallen — ein Provider, zu dem sich keine Versiegelung aufbauen lässt, wird übersprungen und nicht unversiegelt genutzt. Jeder aktuelle Provider-Build unterstützt die Versiegelung, das betrifft also überwiegend ältere Builds, und es kostet Verfügbarkeit statt Vertraulichkeit. Schalte die Post-Quanten-Verschlüsselung aus, und das alte Verhalten kehrt zurück: Der Datenverkehr kann dann den Standardpfad nehmen, auf dem die Plattform Paketadressen und -inhalte lesen kann.
Grenze: Noch meldet keine App, ob eine bestimmte Verbindung versiegelt ist. Diese Lücke ist real, aber nicht mehr die gefährliche — still herabgestuft werden kannst du bei eingeschalteter Versiegelung nicht. Das und alles Übrige, wogegen URnetwork nicht schützt, steht im Bedrohungsmodell.
Starke Anonymisierung, und der Direktmodus. Ein Provider sieht die Zieladressen des Datenverkehrs, den er bedient — wie heute dein Internetanbieter. Wer du bist, erfährt er nicht: Standardmäßig sieht er nie deine echte IP, nur die Plattform sieht sie. Dieser Standard ist der Schalter Starke Anonymisierung im Connect-Drawer, ab Werk an. Ihn auszuschalten wählt den Direktmodus: Der Client spricht direkt mit dem Provider, und der Durchsatz steigt. Der Preis: Dieser Provider sieht jetzt deine echte Adresse. Gehostete Profile erzwingen unabhängig davon, dass der Direktmodus aus ist.
Was jede Partei sieht
| Partei | Sieht | Sieht nicht, oder behält nicht |
|---|---|---|
| Operator (Plattform) | dein Konto; deine Adresse im Moment des Verbindens; grob Stadt/Region/Land, daraus abgeleitet; welche Provider du genutzt hast; Bytezahlen; Chiffretext mit Timing und Volumen | Paketziele und -inhalte (standardmäßig versiegelt); deine rohe Adresse (stattdessen ein Block-Hash mit geheimem Schlüssel); irgendein Zielfeld im Transferregister |
| Provider | Ziel-IPs/SNI des Datenverkehrs, den er nach außen trägt; eine Geräte-ID am Vertrag | deine Identität oder echte IP auf den Relay-Pfaden; nur der Operator kann die Geräte-ID zu einem Konto auflösen |
| Extender | verschlüsselte Bytes; deine IP | irgendetwas im Inneren des Tunnels |
| Website | eine Privatanschluss-Adresse des Providers | deine IP; die Identität deines Internetanbieters |
Hinter der Operator-Zeile:
- Die gespeicherte Form deiner Verbindungsadresse ist ein Einweg-Hash mit geheimem Schlüssel über den umgebenden /29-Block (IPv4) bzw. /56-Block (IPv6), nicht die Adresse selbst. Ein aus der Adresse abgeleitetes grobes Stadt/Region/Land wird pro Verbindung behalten.
- Die Disziplin steckt im Code, nicht nur in einer Richtlinie. HTTP-Logging läuft durch eine Allowlist aus fünf Headern. Das Transferregister verzeichnet Client- und Netzwerk-IDs und Bytezahlen — ohne ein Feld für Ziel, Host, URL, SNI, Port oder Domain, in das man schreiben könnte. Der Proxy-Datenpfad loggt nichts, festgenagelt durch einen Regressionstest.
- Die Versiegelung macht deinen Datenverkehr für den Operator unlesbar. Die Speicherdisziplin deckt ab, was der Operator weiterhin sieht (Provider-Zuordnungen, Bytezahlen, groben Standort), und springt ein, wo es keine Versiegelung gibt: die Browser-Erweiterung, die Proxy-Endpunkte und die nativen Apps mit ausgeschalteter Versiegelung.
- Grenze: Das sind Eigenschaften der Datensätze, die der Code schreibt. Die Zugriffslogs des vorgelagerten Load-Balancers wurden nie geprüft, und Zeilen mit Adressen und SNI erreichen das stderr der Dienste, dessen Ziel in Produktion nicht geklärt ist. Vollständige Aufstellung: das Bedrohungsmodell.
Open Source, und was nicht auditiert ist
Der gesamte Stack ist Open Source: die Apps, das SDK, die Protokoll-Engine und der eigene Server-Code des Operators — die hier beschriebenen Mechanismen lassen sich also nachlesen statt glauben. Open Source belegt das Design, nicht, welcher Build deployt ist.
Kein unabhängiges Audit deckt das Protokoll, die Connect-Engine oder den Server-Code des Operators ab — die Schicht, auf der die Privacy-Zusagen liegen. Zwei externe Prüfungen aus 2025 decken andere Flächen ab. Die eine ist ein unabhängiger Penetrationstest der Web-Anwendung und der API (April–Mai 2025). Die andere ist eine MASA-AL2-Prüfung der Android-App durch die Leviathan Security Group, die bestanden wurde; Leviathan grenzt sie selbst als keine ganzheitliche Sicherheitsbewertung ein. Offener Code unter dauerhafter Beobachtung ist URnetworks Antwort auf das jährliche Stichtags-Audit. Vollständige Aufstellung: das Bedrohungsmodell.
Sicher teilen: die ip_security-Schicht
Die eigene Verbindung zu teilen sollte nicht heißen, das rechtliche Risiko eines Fremden zu erben. Der Provider-Client bringt ip_security mit, eine quelloffene Traffic-Sicherheitsschicht in der Connect-Engine und eine ihrer größten Komponenten. Sie inspiziert den eigenen Ausgang des Providers, seinen Exit ins Internet. Riskanter Datenverkehr wird blockiert, bevor er die Verbindung des Mitglieds verlässt:
- Filterung der DMCA-Klasse. Ein zustandsbehafteter Detektor erkennt BitTorrent- und Filesharing-Signaturen und verwirft opaken Datenverkehr, der zu keinem legitimen Protokoll passt — rechtsverletzende Peer-to-Peer-Übertragungen verlassen die Leitung des Mitglieds also nicht.
- Filterung der CFAA-Klasse. Muster von unbefugtem Zugriff, Scans und Ausnutzung werden ins Leere geleitet — die Verbindung wird so nicht zur Startrampe für den Einbruch eines anderen.
- Ein Detektor, gebaut, um nicht zu sehen. Die Filesharing-Prüfung löscht den Servernamen aus ihrem eigenen Flow-Schlüssel. Sie entscheidet anhand von Adressen, Ports und den ersten Bytes eines Flows und führt ihre Zähler nach Protokoll und Port, nie nach Adresse.
Ein Treffer erzeugt ein verworfenes Paket. Ein BitTorrent-Treffer sendet zusätzlich eine Missbrauchsmarkierung an den Operator: die Geräte-ID des Peers und ein Ja/Nein — ohne Ziel, Domain oder Inhalte. Der Operator liefert heute keinen Handler für die Markierung aus, beim Empfang wird also nichts gespeichert. Verwürfe opaker Protokolle bleiben still, ohne Meldung.
Die Schicht läuft am Rand, und zwar auf beiden Seiten davon: auf deinem Gerät, wenn du dich verbindest — Datenverkehr, den das Netzwerk nicht tragen wird, erreicht so nie einen Provider — und auf dem Gerät des Providers, wo der Datenverkehr austritt. Der Operator inspiziert Datenverkehr nicht zentral, und die Versiegelung umgeht den Filter nicht, denn der Filter läuft an den Endpunkten, die die Versiegelung verbindet. Mit eingeschaltetem Kill Switch (ein expliziter Schalter in jeder App, in der Browser-Erweiterung standardmäßig an) stoppt blockierter Datenverkehr, statt auf deine eigene Verbindung zurückzufallen. Die meisten Länder haben Gesetze der CFAA- und DMCA-Familie; ein Standard beantwortet sie an jedem Exit, und URnetwork hält sich an das Recht überall dort, wohin es ausliefert. Der Filter wird gepflegt, nicht eingefroren: Seine Bedrohungslisten werden bei jedem Release aus öffentlichen Malware-, Missbrauchs- und Botnetz-Feeds neu erzeugt (Spamhaus DROP, der Botnetz-Tracker von abuse.ch, Emerging Threats und andere) — eine aktuelle App blockiert also den zuletzt bekannten bösartigen Adressraum. Die Nutzungsbedingungen regeln das Teilen.
Durch Netzsperren hindurch
Extender tragen den Pfad durch lokale und regionale Firewalls. Jeder antwortet mit TLS auf glaubwürdigen Dienst-Ports (443, DNS-over-TLS 853, LDAPS 636 und andere) und wirkt auf Scanner wie ein falsch konfiguriertes CDN. Jeder ist fest darauf verdrahtet, den verschlüsselten Strom über eine eigene Adresse an die Plattform weiterzuleiten — connect.bringyour.com zu blockieren versperrt also nicht den Weg hinein. Der Client rotiert durch generierte Extender-Personas, mit zufälliger Paketfragmentierung und -umordnung, bis eine funktioniert. Wo nur DNS herauskommt, formt ein DNS-förmiger Transport QUIC-Pakete zu DNS-Anfragen und -Antworten um. Einen Extender betreiben kann jeder.
Provider und Abdeckung
Standorte sind präsenzgestützt: Eine Stadt wird nur angeboten, solange dort das Gerät eines Mitglieds online ist. Die Plattform geolokalisiert die Verbindung, die sie beobachtet; ein Provider kann nicht selbst eine Stadt deklarieren. Eine Adresse, die nach Rechenzentrum, VPN oder neu announciertem Adressblock aussieht, wird herabgestuft statt geglaubt. Grenze: Keine außenstehende Partei hat die Flotte vermessen, und nichts weist nach, dass die einem Client angebotenen Provider voneinander oder vom Operator unabhängig sind. Siehe das Bedrohungsmodell.
Das Teilen der Verbindung ist opt-in und gibt ungenutzte Bandbreite ab: aus, bis du es einschaltest, nur über WLAN, sofern du Mobilfunk nicht erlaubst, und wahlweise auf öffentlichen Datenverkehr oder allein auf deine eigenen Geräte gerichtet. Öffentlicher Datenverkehr wird gemessen: Die Plattform stempelt jeden Transfervertrag mit einem Geheimnis, das nur dieser Provider hält — der Provider kann also prüfen, dass ein Vertrag echt ist und für das Publikum, dem er zugestimmt hat. Die Treuhand ist in Bytes bemessen; beide Enden melden, was sie übertragen haben, und der abgerechnete Wert ist ihr Mittel innerhalb einer Toleranz. Provider nehmen am UR Protocol teil; ur.xyz dokumentiert die Vergütung, und diese Seite wiederholt sie nicht. Kostenlose Tarife gibt es, weil zahlende Mitglieder das Wachstum des Netzwerks finanzieren. Teilen kann jeder.
Tarife und die Operator-API
Es gibt zwei Tarife: einen kostenlosen mit täglichem Datenkontingent und Pro mit einem großen monatlichen Kontingent, mehr gleichzeitigen Clients und den Proxy- und WireGuard-Extras. Pro lässt sich mit On-Chain-USDC aus einer Wallet bezahlen. Das Kontingent wird gezählt, nicht gedrosselt: Ist es aufgebraucht, öffnet das Netzwerk keine neuen Transfers mehr, statt dich auszubremsen. Der Tunnel wird still, deine eigene Verbindung bleibt unberührt, und das Kontingent füllt sich in seinem Zyklus wieder auf. Aktuelle Zahlen stehen auf ur.io/products, maschinenlesbar unter GET https://api.bringyour.com/x402/skus.
Alles, was die Apps tun, läuft über die öffentliche Operator-REST-API (Auth, Geräte, Provider-Discovery, Abos, Statistiken), dokumentiert in der API-Referenz. Agents bekommen erstklassigen Zugang: einen MCPv2-Server unter mcp.bringyour.com (OAuth; die Tools providerLocations und fetch) und x402-Kauf nach Bedarf. Siehe ur.io/agents.
Fallback-Endpunkte: HTTPS, SOCKS5, WireGuard
Für Software, die das SDK nicht einbetten kann, betreibt der Operator Brücken-Endpunkte: einen HTTPS-CONNECT-Proxy, SOCKS5 und einen WireGuard-Endpunkt für unveränderte WireGuard-Apps. SOCKS5 unterstützt CONNECT und UDP-Associate; BIND wird nicht unterstützt, und UDP-Datagramme über 2 KiB werden bewusst verworfen. Grenze: Der WireGuard-Pfad vergibt eine stabile Tunnel-Adresse aus einem privaten Pool der Plattform, nicht deine echte IP. Diese stabile Adresse erlaubt es, einen Client über mehrere Provider hinweg zu korrelieren, und der Endpunkt gibt dem Client einen festen öffentlichen Resolver mit (1.1.1.1). Die Apps und das SDK bleiben der privateste Weg, das Netzwerk zu nutzen.
Wie es weitergeht
- Einrichten: die Erste-Schritte-Guides für Android, iOS, macOS, Windows, Linux, die Browser-Erweiterung und das SDK.
- Tiefe pro Plattform: die Tour-Docs.
- Andere Produkte: die Compare-Docs und die Vergleichskarte.
- Das Protokoll: ur.xyz für Whitepaper, Ökonomie und Provider-Vergütung.