Open-Source-Plan von SingLinkVPN | Doku, Daten und Code

Open Source ist der Anfang langfristigen Vertrauens.

SingLinkVPN hat sein Open-Source- und Technikforschungsprogramm offiziell gestartet und auf GitHub das offizielle Repository SingLinkVPN Open Source and Technical Research angelegt.

Das ist keine einmalige Veröffentlichungsaktion und keine Dokumentationsseite, die nur zum Durchblättern gedacht ist. Es ist ein langfristiges technisches Vorhaben, das laufend aktualisiert und mit der Zeit erweitert wird.

Was heute verfügbar ist, ist die erste Phase des umfassenderen Programms.

Die erste Phase umfasst öffentliche technische Dokumentation, Sicherheits- und Datenschutzmodelle, reproduzierbare Methoden für Leistungstests, maschinenlesbare Datenformate, einen Rahmen für öffentliche Datensätze, Berichtsverzeichnisse, Forschungswerkzeuge, ein Verfahren zur Offenlegung von Sicherheitsproblemen und Standards für die Veröffentlichung von Nachweisen.

In späteren Phasen plant SingLinkVPN, weitere technische Unterlagen, Forschungsberichte und Produktquellcode schrittweise zu veröffentlichen, jeweils nach Prüfung von Sicherheit, Datenschutz, Lizenzen und Produktstabilität. Geplant sind unter anderem das VPN-Protokoll, die VPN-Clients und weitere VPN-Kerntechnologie, die sich nach der Prüfung für eine Veröffentlichung eignet.

Die aktuelle Veröffentlichung ist daher nicht das Ende des Programms, sondern der erste Schritt eines fortlaufenden Open-Source-Prozesses.

Das offizielle Repository enthält jetzt die Verzeichnisse docs, data, reports, tools, tests sowie GitHub-Automatisierung, um öffentliche Dokumentation, Forschungsdaten, Sicherheitsunterlagen, Leistungstests und offene Prüfwerkzeuge zu pflegen. Das Repository wird ausdrücklich als aktiv gepflegtes Projekt beschrieben.

Offizielles Repository: SingLinkLabs / singlink-vpn-open-source Aktueller Stand: Die erste Phase ist öffentlich. Weitere technische Unterlagen, Forschungsberichte und Produktquellcode werden schrittweise veröffentlicht.

Warum startet SingLinkVPN ein Open-Source-Programm?

Ein VPN ist eng mit Netzwerktransport, Sicherheit, Datenschutz und Datenverarbeitung verbunden.

Der Großteil eines VPN-Dienstes läuft in Systemen, die Nutzer nicht direkt einsehen können. Nutzer sehen vielleicht die App-Oberfläche, die Serverliste, die Verbindungsgeschwindigkeit und die Produktbeschreibung, können aber nicht ohne Weiteres überprüfen:

wie veröffentlichte Geschwindigkeitswerte gemessen wurden;
welche Softwareversion und Netzwerkumgebung verwendet wurden;
ob fehlgeschlagene Tests vollständig erfasst wurden;
ob eine Sicherheitsaussage eine Richtlinienzusage, ein interner Test oder eine unabhängige Bewertung ist;
ob ein Bericht Datum, Versionen, Methoden und Korrekturverlauf enthält;
ob ein anderer Forscher das Ergebnis reproduzieren kann;
ob sich technische und sicherheitsrelevante Änderungen über Versionen hinweg nachverfolgen lassen.

Aussagen einer Marke allein können diese Fragen nicht vollständig beantworten.

Das Programm soll die technischen, sicherheits-, datenschutz- und leistungsbezogenen Informationen von SingLinkVPN von Produktaussagen in öffentliches Material verwandeln, das andere einsehen, zitieren, überprüfen, reproduzieren und weiter kritisch prüfen können.

Dafür braucht es ein fortlaufendes Veröffentlichungssystem, nicht nur das Hochladen von Dateien:

wichtige technische Unterlagen brauchen eine definierte Version;
messbare Aussagen müssen Testdatum und Umgebung nennen;
Leistungsergebnisse müssen durch entsprechende Daten belegt sein;
interne Tests und Bewertungen Dritter müssen klar unterschieden werden;
wesentliche Korrekturen müssen öffentlich nachvollziehbar bleiben;
Produktquellcode muss nach einer Sicherheitsprüfung schrittweise veröffentlicht werden;
die Community muss Datenstruktur und Vollständigkeit mit öffentlichen Werkzeugen prüfen können.

Das Repository verlangt, dass jede messbare Aussage Testdatum, Softwareversion, Umgebung, Methode, Stichprobengröße, Roh- oder aggregierte Daten und bekannte Einschränkungen enthält. Nicht überprüfbare Superlative wie „am schnellsten“, „am sichersten“ oder absolute Datenschutzversprechen gelten nicht als Nachweis.

Was ist in der ersten Phase verfügbar?

Die erste Phase richtet acht öffentliche Arbeitsbereiche ein:

VPN-Entwicklungsarchitektur und öffentliche technische Dokumentation;
Produkt- und Versionsaufzeichnungen von SingLinkVPN;
ein Sicherheits- und Datenschutzmodell;
reproduzierbare Methoden für Leistungstests;
Formate für Testdaten und ein Rahmen für öffentliche Datensätze;
Verzeichnisse für Sicherheits-, Leistungs- und Transparenzberichte;
offene Werkzeuge zur Datenprüfung und Forschung;
Meldung von Schwachstellen und verantwortungsvolle Offenlegung.

Zusammen bilden sie die Grundlage für die spätere Veröffentlichung von Quellcode, öffentliche Daten und unabhängige Forschung.

1. Öffentliche VPN-Entwicklungsarchitektur und technische Dokumentation

Die erste Phase enthält eine plattformübergreifende Architektur für VPN-Clients.

Sie ist an keine bestimmte Programmiersprache und kein bestimmtes Betriebssystem gebunden. Stattdessen beschreibt sie die wichtigsten Module, die ein plattformübergreifender VPN-Client braucht, darunter Oberfläche, Verbindungslebenszyklus, Tunnelverwaltung, Routing, DNS, Konfiguration, Sicherheitstests und lokale Diagnose.

1. Oberflächenschicht

Die Oberflächenschicht zeigt Kontostatus, Serverauswahl, Verbindungsstatus, Fehler, Diagnoseergebnisse und Funktionen zur Barrierefreiheit an.

Der in der Oberfläche angezeigte Verbindungsstatus muss aus der tatsächlichen Zustandsmaschine der Verbindung abgeleitet werden und nicht nur daraus, ob ein Nutzer auf Verbinden getippt hat.

2. Schicht zur Steuerung der Sitzungen

Diese Schicht übernimmt:

Verbinden;
Trennen;
automatische Wiederholungsversuche;
Netzwerkwechsel;
Ruhezustand und Aufwachen des Geräts;
Neustart der Anwendung;
Wiederherstellung nach einer unerwarteten Unterbrechung.

Sie muss verhindern, dass veraltete Verbindungsergebnisse neuere Vorgänge überschreiben, und sicherstellen, dass wiederholte Aktionen keine Konflikte erzeugen.

3. Tunnel-Adapterschicht

Diese Schicht bindet die nativen VPN-APIs der verschiedenen Betriebssysteme an, darunter:

Ein- und Ausgabe von Paketen;
den Lebenszyklus des Tunnels;
die MTU-Konfiguration;
Berechtigungen des Betriebssystems;
Beschränkungen der Hintergrundausführung;
Rückmeldungen bei Tunnelunterbrechungen.

4. Routing- und DNS-Schicht

Diese Schicht verwaltet:

Standardrouten;
Split-Tunneling;
ausgenommene Routen;
die DNS-Auswahl;
Richtlinien für IPv4 und IPv6;
den Zugriff auf das lokale Netzwerk;
den Schutz vor DNS- und Routing-Lecks.

Lecktests dürfen sich nicht auf den ersten Verbindungsaufbau beschränken. Sie müssen auch Neuverbindungen, Netzwerkwechsel, Ruhezustand und Aufwachen sowie das unerwartete Beenden der Anwendung abdecken.

5. Transportschicht

Die Transportschicht ist zuständig für authentifizierte Sitzungen, Transportverhalten, Umgang mit Überlastung, Keepalive-Strategie und Netzwerkmigration.

6. Konfigurationsschicht

Die Konfigurationsschicht verarbeitet versionierte, signierte und auf das Nötige reduzierte Remote-Konfiguration und weist ungültige, abgelaufene oder herabgestufte Konfiguration zurück.

7. Beobachtungsschicht

Unter Wahrung des Datenschutzes liefert diese Schicht:

lokalen Gesundheitsstatus;
Verbindungsdiagnose;
Fehlerklassifizierung;
reproduzierbare Testausgaben;
technische Statusdaten, die keine Netzwerkaktivität von Nutzern enthalten.

Die aktuelle Veröffentlichung umfasst die übergeordnete Architektur und Grundsätze sicherer Entwicklung. Spezifischere Module und Quellcode kommen erst hinzu, wenn die entsprechenden Prüfungen abgeschlossen sind.

2. Eine versionierte öffentliche Produktaufzeichnung

SingLinkVPN hat außerdem eine öffentliche Produktaufzeichnung eingerichtet, die verschiedene Arten von Informationen voneinander trennt.

Produktfakten

Dazu gehören:

unterstützte Plattformen;
öffentliche Versionen;
Veröffentlichungsdaten;
offizielle Download-Quellen;
verfügbare Prüfsummen;
wesentliche Änderungen an Funktionen und Kompatibilität.

Architekturbeschreibungen

Sie liefern übergeordnete Entwürfe, ohne sensible Systeme, Zugangsdaten oder Produktivumgebungen offenzulegen.

Messergebnisse

Leistungs- und technische Ergebnisse müssen Datum, Methode, Umgebung, Stichprobe und belegende Daten enthalten.

Richtlinienaussagen

Sie betreffen Zusagen zu Produktbetrieb, Sicherheit und Datenschutz. Eine Richtlinienaussage wird nicht als unabhängige Überprüfung dargestellt.

Diese Trennung verhindert, dass Richtlinien, interne Tests, Implementierungsdetails und unabhängige Forschung vermischt werden. Offizielle Release-Aufzeichnungen werden schrittweise Plattform, Version, Datum, Quelle, verfügbare Prüfsummen, wesentliche Sicherheits- und Kompatibilitätsänderungen, bekannte Einschränkungen sowie unveränderliche Git-Tags oder Release-Links enthalten.

3. Ein öffentliches Sicherheits- und Datenschutzmodell

Sicherheit lässt sich nicht nur mit Wörtern wie „sicher“ oder „verschlüsselt“ beschreiben.

Die erste Phase veröffentlicht deshalb ein Sicherheits- und Datenschutzmodell, das die Risiken festlegt, die spätere Tests, Berichte und unabhängige Bewertungen untersuchen sollen.

Der aktuelle Bedrohungsumfang umfasst:

Beobachtung des Verkehrs im lokalen Netzwerk;
DNS-Lecks;
IPv6-Lecks;
WebRTC-Lecks;
Routing-Unterbrechungen beim Neuverbinden;
Schutz des Verkehrs beim Wechsel zwischen WLAN und Mobilfunknetz;
böswillige Änderungen der Remote-Konfiguration;
Herabstufung der Konfiguration;
Offenlegung von auf dem Gerät gespeicherten Zugangsdaten;
Risiken durch Abhängigkeiten von Dritten;
Lieferkettenrisiken bei Build und Release;
Kontomissbrauch;
nicht autorisierte Sitzungen;
übermäßige Erhebung von Diagnose- oder Supportdaten.

Jeder öffentliche Sicherheitstest muss angeben:

die betroffene Client-Version;
das Betriebssystem;
das Testdatum;
die Netzwerkbedingungen;
die Methode;
das erwartete Verhalten;
das beobachtete Verhalten;
bekannte Einschränkungen.

Das Modell trennt außerdem Richtlinien, Architekturdokumentation, interne Tests und Bewertungen Dritter.

Nur ein Bericht eines namentlich genannten unabhängigen Prüfers oder Forschers, gestützt auf einen überprüfbaren Bericht, darf als Bewertung durch Dritte bezeichnet werden. So entsteht ein einheitlicher und prüfbarer Standard für künftige Sicherheitsberichte.

4. Eine reproduzierbare Methode für VPN-Leistungstests

Die VPN-Leistung wird von vielen äußeren Faktoren beeinflusst:

Land oder Region des Testenden;
Breitband- oder Mobilfunkanbieter;
Qualität des lokalen Netzwerks;
internationaler Transit;
Tageszeit;
Geräteleistung;
Client-Version;
Protokoll;
Serverauslastung;
Testserver;
Zielregion.

Eine einzelne Spitzengeschwindigkeit steht daher nicht für das Erlebnis jedes Nutzers.

Die veröffentlichte Methode verlangt, dass jeder Datensatz Folgendes enthält:

die Testzeit in UTC;
eine eindeutige Testkennung;
Client-Version;
Betriebssystem;
Gerätetyp;
Protokollbezeichnung;
Version der Methodik;
Testland oder -region;
Netzwerktyp;
Anzahl der Stichproben;
Nachweisstufe.

Die wichtigsten Kennzahlen sind:

Median der Verbindungslatenz

Der Median der Latenz in Millisekunden über mehrere Stichproben statt eines einzelnen Bestwerts.

Jitter im 95. Perzentil

Das höhere Maß an Latenzschwankung, das in den meisten Stichproben beobachtet wurde.

Paketverlustrate

Der Anteil der Pakete, die während des Tests verloren gingen.

Median der Download-Geschwindigkeit

Der Median des Download-Durchsatzes in Mbps über mehrere Stichproben.

Median der Upload-Geschwindigkeit

Der Median des Upload-Durchsatzes in Mbps über mehrere Stichproben.

Erfolgsquote beim Verbinden

Der prozentuale Anteil erfolgreicher Versuche bei wiederholten Verbindungstests.

Median der Zeit bis zur Neuverbindung

Die mittlere Zeit (Median), die nach einem Netzwerkwechsel oder einer Unterbrechung bis zur Wiederherstellung nötig ist.

Der offizielle Ablauf ist:

das Ausgangsnetzwerk ohne VPN erfassen;
Gerät, Netzwerk, Ziel und Messzeitfenster konstant halten;
einen nicht gewerteten Aufwärmlauf durchführen;
Verbindungs- und Übertragungstests wiederholen;
fehlgeschlagene Stichproben behalten, statt sie stillschweigend zu löschen;
aggregierte Ergebnisse und maschinenlesbare Daten veröffentlichen;
bekannte Einschränkungen, Ausfälle und ausgeschlossene Stichproben offenlegen.

Direkte Vergleichstests müssen vergleichbare Bedingungen nutzen. Ein Wechsel von Anbieter, Route, Gerät, Testserver oder Messzeitfenster muss offengelegt werden. Datierte, versionierte und herunterladbare Datensätze werden im Rahmen dieser Methode mit fortlaufenden Tests ergänzt.

5. Ein maschinenlesbares öffentliches Format für Testdaten

Neben gut lesbaren Berichten veröffentlicht SingLinkVPN ein maschinenlesbares Format für Leistungsdaten.

Das JSON Schema verlangt, dass jeder Leistungsdatensatz Folgendes enthält:

test_id: Testkennung;
tested_at_utc: Testzeit in UTC;
client_version: Client-Version;
platform: Testplattform;
protocol_label: Protokollbezeichnung;
country: Testland oder -region;
network_type: Netzwerktyp;
sample_count: Anzahl der Stichproben;
latency_ms_median: Median der Latenz;
jitter_ms_p95: Jitter im 95. Perzentil;
packet_loss_pct: Paketverlustrate;
download_mbps_median: Median der Download-Geschwindigkeit;
upload_mbps_median: Median der Upload-Geschwindigkeit;
connection_success_pct: Erfolgsquote beim Verbinden;
reconnect_ms_median: Median der Zeit bis zur Neuverbindung;
methodology_version: Version der Methode;
evidence_level: Nachweisstufe.

Nachweise können derzeit gekennzeichnet werden als:

interner Test;
unabhängige Reproduktion;
Bewertung durch Dritte.

Mit dem Format können Entwickler und Forscher Pflichtfelder und Wertebereiche direkt prüfen und dieselbe Struktur für Reproduktion und Vergleich nutzen, statt sich nur auf Diagramme oder erzählende Schlussfolgerungen zu verlassen.

6. Sicherheits-, Leistungs- und Transparenzberichte

Das Repository enthält ein eigenes Berichtsverzeichnis für die fortlaufende Veröffentlichung von:

Sicherheitsberichten;
Leistungsberichten;
Datenschutzforschung;
Transparenzberichten;
Bewertungen durch Dritte;
unabhängig reproduzierten Ergebnissen;
Hinweisen zu wesentlichen Sicherheitskorrekturen.

Vor der Veröffentlichung muss jeder offizielle Bericht angeben:

Veröffentlichungsdatum;
Autor oder Verantwortlichen;
betroffene Produktversion;
Methode;
Datenquelle;
Nachweisstufe;
bekannte Einschränkungen;
Korrekturverlauf.

Interne Tests und unabhängige Bewertungen tragen unterschiedliche Kennzeichnungen. Die erste Phase legt Berichtsstruktur, Nachweisregeln und Versionierungsrahmen fest; Berichte werden ergänzt, sobald ihre Daten und ihre Prüfung bereit sind, statt einmal veröffentlicht und dann vergessen zu werden.

7. Offene Prüf- und Forschungswerkzeuge

Die erste Phase veröffentlicht außerdem mehrere Forschungs- und Prüfwerkzeuge in Python.

publication_guard.py

Es prüft Dokumente, Daten und Werkzeuge vor der Veröffentlichung auf:

Zugangsdaten;
Schlüsselformate;
private Pfade;
Archive;
Binärdateien;
Quellcodetypen, die nicht zur Veröffentlichung freigegeben sind;
übergroße Dateien;
gängige Formate echter Geheimnisse;
Inhalte, die sensible Systeme beschreiben könnten.

validate_benchmark.py

Es prüft CSV-Dateien aus Leistungstests, darunter:

Spaltennamen;
Pflichtfelder;
Wertebereiche;
Nachweiskennzeichnungen;
Struktur der Testdaten.

check_relative_links.py

Es prüft relative Links in Markdown und bestätigt, dass die referenzierten öffentlichen Dateien existieren.

check_multilingual_seo.py

Es prüft mehrsprachige Dokumente und suchrelevante Strukturen, damit englische, vereinfacht chinesische und traditionell chinesische Unterlagen aufeinander abgestimmt bleiben.

Diese Werkzeuge sind nicht der Kern der VPN-Verbindung. Sie sind Veröffentlichungsinfrastruktur, die Formatfehler, defekte Links, versehentlich offengelegte sensible Informationen und Versionsinkonsistenzen verringern soll. Externe Mitwirkende können dieselben Werkzeuge für ihre Beiträge nutzen.

8. Ein fünfstufiger öffentlicher Nachweisstandard

Stufe eins: Richtlinienaussage

Eine vom Betreiber veröffentlichte Zusage zu Produkt, Sicherheit, Betrieb oder Datenschutz. Sie ist eine öffentliche Zusage, kein Nachweis der Umsetzung und kein unabhängiges Audit.

Stufe zwei: Implementierungsdokumentation

Eine versionierte übergeordnete technische Beschreibung ohne Serveradressen, Zugangsdaten, private APIs oder andere sensible Informationen.

Stufe drei: interner Test

Ein von SingLinkLabs nach einer öffentlichen Methode durchgeführter Test mit Datum, Version, Umgebung und Daten.

Stufe vier: reproduziertes Ergebnis

Ein unabhängiges Ergebnis, das ein anderer Entwickler oder Forscher mit derselben Methode und öffentlichen Daten erzielt hat.

Stufe fünf: Bewertung durch Dritte

Eine Bewertung durch einen namentlich genannten unabhängigen Forscher oder eine unabhängige Organisation mit einem überprüfbaren offiziellen Bericht.

Diese Stufen sind nicht austauschbar. Interne Tests dürfen nicht als Bewertung durch Dritte bezeichnet werden, Richtlinien gelten nicht als unabhängige Überprüfung, und die Veröffentlichung einer Methode bedeutet nicht, dass ein Ergebnis bereits reproduziert wurde.

Jeder Bericht sollte beantworten: Wer kam zu dem Ergebnis, wann, mit welcher Version und mit welcher Methode?

Wesentliche Korrekturen erfordern einen neuen Git-Commit und einen Eintrag im Änderungsprotokoll. Veröffentlichte Daten dürfen nicht stillschweigend ersetzt werden, und überholte Daten müssen erkennbar bleiben.

9. Meldung von Schwachstellen und verantwortungsvolle Offenlegung

Offene Veröffentlichung und sichere Offenlegung müssen zusammen funktionieren.

Nicht behobene Schwachstellen, echte Zugangsdaten, private Endpunkte, Serveradressen und Nutzerdaten dürfen nicht in einem öffentlichen Issue gepostet werden.

Schwachstellen müssen vertraulich über die Sicherheits-E-Mail-Adresse oder GitHub Security Advisories gemeldet und klar als Sicherheitsmeldung gekennzeichnet werden. Wenn keine Sicherheits-E-Mail-Adresse veröffentlicht ist, lesen Sie die Datei `SECURITY.md` des Repositorys und raten Sie keine Adresse.

Eine Meldung sollte enthalten:

betroffene Version;
betroffene Plattform;
Bedingungen zur Reproduktion;
Auswirkungen auf die Sicherheit;
einen sicheren Weg, den Meldenden zu kontaktieren;
Material zur Reproduktion, das keine echten Nutzerdaten enthält.

Sicherheitsmeldungen durchlaufen:

Sichtung und Bestätigung;
Bewertung der Auswirkungen;
Behebung;
Veröffentlichung einer korrigierten Version;
ein angemessenes Zeitfenster für Updates;
Veröffentlichung eines Sicherheitshinweises.

Öffentliche Hinweise unterscheiden bestätigte Auswirkungen von hypothetischen Risiken und nennen betroffene und korrigierte Versionen.

10. Öffentliche Daten bedeuten nicht öffentliche Nutzerdaten

Technische Transparenz darf nicht auf Kosten der Privatsphäre der Nutzer gehen.

Das Repository verbietet, dass Issues, Pull Requests, Datensätze oder Forschungsdokumente Folgendes enthalten:

personenbezogene Daten;
Kontokennungen;
Zahlungsdaten;
Supportgespräche;
private IP-Adressen;
Zugriffstokens;
Zugangsdaten für die Produktivumgebung;
Produktivprotokolle;
unverarbeiteten Produktivverkehr;
Testdaten, die einen einzelnen Nutzer identifizieren können.

Leistungsdaten müssen aggregiert oder anonymisiert sein. Prüfer müssen vor der Veröffentlichung bestätigen, dass ein Datensatz keine Daten auf Nutzerebene, keine Zugangsdaten und kein Material enthält, das einen echten Nutzer identifizieren kann.

Das Programm macht Technik, Methoden, Berichte und geprüften Quellcode transparent. Es veröffentlicht keine Nutzerinformationen, keine sicherheitskritischen Serverdaten und keine Zugangsdaten der Produktivumgebung.

11. Wie kann sich die Community beteiligen?

Entwickler, Sicherheitsforscher und Mitglieder der Community können:

die technische Dokumentation verbessern;
Fehler in der Dokumentation korrigieren;
die Übersetzungen ins traditionelle Chinesisch, vereinfachte Chinesisch und Englisch verbessern;
die Reproduzierbarkeit der Testmethode verbessern;
die Qualität öffentlicher Daten verbessern;
die Barrierefreiheit verbessern;
Forschungswerkzeuge ergänzen;
die Formatprüfung verbessern;
defekte Links finden;
neue öffentliche Forschungsmethoden vorschlagen;
Verbesserungen am Testdesign anregen;
öffentliche Tests im Rahmen der Sicherheitsregeln reproduzieren.

Beiträge dürfen nicht enthalten:

nicht freigegebenen Produktquellcode;
Informationen über private Infrastruktur;
Zugangsdaten oder Schlüssel;
Nutzerdaten;
private Endpunkte;
Produktivprotokolle;
vollständige Exploit-Anleitungen für eine nicht behobene Schwachstelle.

Jeder messbare Beitrag muss außerdem Quelle, Methode, Datum und Einschränkungen angeben.

Heißt das, SingLinkVPN ist jetzt vollständig Open Source?

Nein. Dies ist die erste Phase, nicht die letzte.

Die erste Phase priorisiert:

technische Dokumentation;
Entwicklungsarchitektur;
Sicherheits- und Datenschutzmodelle;
Methoden für Leistungstests;
maschinenlesbare Datenformate;
Prüfwerkzeuge;
Richtlinien für Nachweise und Veröffentlichung;
verantwortungsvolle Offenlegung;
einen Rahmen für spätere Berichte und Quellcode-Veröffentlichungen.

Nicht in der ersten Phase enthalten sind:

der vollständige Quellcode des VPN-Clients;
serverseitiger Quellcode;
Quellcode des Zahlungssystems;
Konfiguration der Produktivserver;
private APIs;
Authentifizierungsdaten;
sensible Implementierungsdetails zur Umgehung von Sperren oder zur Abwehr von Netzwerkangriffen;
der vollständige Quellcode des Kernprotokolls.

Sie sind nicht zwangsläufig vom Gesamtprogramm ausgeschlossen. Jedes Produktmodul braucht eine eigene Prüfung von Sicherheit, Datenschutz, Abhängigkeiten und Lizenzen.

Nach Abschluss der Prüfung werden spätere Veröffentlichungen enthalten:

ein klar abgegrenztes Open-Source-Verzeichnis;
die passende Lizenz;
einen Versionsverlauf;
Sicherheitsgrenzen;
ein Änderungsprotokoll;
ein Veröffentlichungsdatum;
ein überprüfbares Git-Tag oder Release.

Wer zuerst Veröffentlichungsstandards, Datenstrukturen, Sicherheitsregeln und Forschungswerkzeuge aufbaut, schafft eine sicherere Grundlage und senkt das Risiko, Zugangsdaten, Infrastruktur, Nutzerdaten oder Code Dritter offenzulegen, der rechtlich nicht weitergegeben werden darf.

Lizenzen werden mit der Veröffentlichung weiterer Unterlagen festgelegt

Das aktuelle Repository ist öffentlich einsehbar, doch vollständige Lizenzen zur Weiterverwendung von Code und Inhalten werden noch nach Art des Materials und des Quellcodes geordnet.

Solange keine ausdrückliche Lizenz veröffentlicht ist, dürfen Nutzer nicht davon ausgehen, Folgendes erhalten zu haben:

das Recht zu kopieren;
das Recht zu verändern;
das Recht zur Weitergabe;
das Recht zur kommerziellen Nutzung;
das Recht zur Neulizenzierung.

Klare Lizenzen sind ein wesentlicher Bestandteil von echtem Open Source. Jede spätere Veröffentlichung von Quellcode, Dokumentation, Daten oder Werkzeugen erhält Bedingungen, die zu ihren Abhängigkeiten, Upstream-Lizenzen und dem vorgesehenen Einsatz passen.

So wird vermieden, dass die Lizenz eines Moduls fälschlich auf ein anderes angewendet wird, und Mitwirkende, Upstream-Projekte und nachgelagerte Nutzer werden geschützt.

Langfristige Ausrichtung des Programms

Die Richtung ist klar: den Anteil technischer Unterlagen, die öffentlich, überprüfbar und reproduzierbar sind, laufend erhöhen.

1. Die öffentliche technische Dokumentation weiter ausbauen

Dazu gehören Verbindungslebenszyklen, Routing, DNS, Netzwerkwechsel, sichere Konfiguration und Tests auf verschiedenen Plattformen.

2. Weiterhin versionierte Produktaufzeichnungen veröffentlichen

Die Aufzeichnungen werden um Plattformen, Versionen, Daten, Prüfsummen, wesentliche Änderungen, bekannte Einschränkungen und stabile Zitierlinks ergänzt.

3. Weiterhin echte Leistungsdatensätze ergänzen

Datierte, versionierte, umgebungsspezifische und maschinenlesbare Daten werden nach der öffentlichen Methode veröffentlicht.

4. Weiterhin Sicherheits-, Leistungs- und Transparenzberichte veröffentlichen

Die Berichte unterscheiden Richtlinien, interne Tests, unabhängige Reproduktion und Bewertung durch Dritte.

5. Unabhängige Reproduktion fördern

Forscher können dieselben Methoden und Formate nutzen, um verschiedene Netzwerke, Geräte und Regionen zu vergleichen.

6. Veröffentlichungs- und Datenwerkzeuge weiter verbessern

Die Automatisierung wird rund um Formatierung, Sicherheit, Dokumentation und Testabläufe ausgebaut.

7. Quellcode des VPN-Produkts schrittweise veröffentlichen

Nach Prüfung von Sicherheit, Datenschutz, Abhängigkeiten und Lizenzen werden das geplante Protokoll, die Clients und weitere Kerntechnologie schrittweise veröffentlicht.

8. Eine umfassendere Aufzeichnung von Offenlegungen und Korrekturen aufbauen

Wesentliche Sicherheitsprobleme, betroffene Versionen, korrigierte Versionen und spätere Updates erhalten einen klaren Verlauf.

Das Repository enthält Metadaten zum Zitieren. Forscher sollten getaggte Releases, unveränderliche Commits und den tatsächlich genutzten datierten Bericht oder Datensatz zitieren, statt undatiertes Werbematerial.

Von öffentlichen Aussagen zu dauerhafter Überprüfbarkeit

Open Source sollte nicht nur ein Startereignis sein.

Langfristiges Open Source braucht Pflege, Beteiligung von außen, klare Lizenzen, Versionsverwaltung, Sicherheitskorrekturen und technische Unterlagen, die andere überprüfen und reproduzieren können.

Der Start mit Dokumentation, Forschungsmethoden, Datenformaten, Nachweisstandards, Berichtsstrukturen und Prüfwerkzeugen legt die Grundlage für eine breitere Veröffentlichung von Quellcode.

Erstens: einen öffentlichen Einstiegspunkt schaffen

Technische, Sicherheits-, Datenschutz- und Leistungsunterlagen, die bisher verstreut waren, werden in einem gepflegten GitHub-Repository zusammengeführt.

Zweitens: Veröffentlichungsstandards festlegen

Das Programm legt fest, was veröffentlicht werden darf, welche Felder Tests enthalten müssen, wie Nachweise eingestuft und wie Korrekturen festgehalten werden.

Drittens: die Grundlage für späteres Open Source schaffen

Prozesse für Sicherheit, Datenschutz, Lizenzen und Versionsverwaltung werden für Berichte, Datensätze, Protokolle, Clients und weitere Module vorbereitet.

Die erste Phase stellt also keine begrenzte erste Veröffentlichung als Gesamtergebnis dar. Sie eröffnet einen Prozess, der auf Erweiterung angelegt ist.

Häufige Fragen (FAQ)

Hat SingLinkVPN sein Open-Source-Programm offiziell gestartet?

Ja. Das offizielle Open-Source- und Technikforschungs-Repository ist online, und Dokumentation, Forschungsmethoden, Datenformate und Prüfwerkzeuge der ersten Phase sind öffentlich.

Ist jetzt der gesamte VPN-Quellcode öffentlich?

Nein. Protokoll, Clients und anderer Produktquellcode werden Modul für Modul nach Prüfung von Sicherheit, Datenschutz, Abhängigkeiten und Lizenzen veröffentlicht.

Warum nicht alles auf einmal veröffentlichen?

Ein VPN-Produkt kann Informationen über Produktivserver, Zugangsdaten, private APIs, sensible Abwehrmechanismen, Abhängigkeiten von Dritten und Code unter verschiedenen Lizenzen enthalten.

Eine schrittweise Prüfung senkt das Risiko, Nutzerdaten, Infrastrukturdetails, echte Zugangsdaten oder Code Dritter offenzulegen, der nicht weitergegeben werden darf.

Werden echte Leistungsdaten veröffentlicht?

Ja. Die Methode und das maschinenlesbare Format sind der erste Schritt. Datierte, versionierte Daten und Berichte folgen mit Angaben zu Umgebung, Stichprobengröße und Einschränkungen.

Werden Sicherheits- und Transparenzberichte öffentlich sein?

Ja. Das Repository hat ein eigenes Berichtsverzeichnis und Veröffentlichungsregeln. Berichte werden ergänzt, sobald ihre Nachweise, Methoden, Versionen und Einschränkungen bereit sind.

Bedeutet die Veröffentlichung eines Sicherheitsmodells, dass ein Audit durch Dritte abgeschlossen ist?

Nein. Das Sicherheitsmodell ist eine öffentliche Grundlage für spätere Tests und Bewertungen.

Eine Bewertung durch Dritte nennt den Prüfer und verlinkt auf einen überprüfbaren Bericht. Sie wird nicht als interner Test dargestellt.

Was können Entwickler beitragen?

Entwickler können zu Dokumentation, Übersetzung, Forschungsmethoden, Datenqualität, Barrierefreiheit, Prüfwerkzeugen und der Reproduktion von Tests beitragen.

Sicherheitslücken müssen vertraulich gemeldet und dürfen nicht in einem öffentlichen Issue gepostet werden.

Enthalten öffentliche Daten Nutzerdaten?

Nein. Öffentliche Daten müssen aggregiert oder anonymisiert sein und dürfen keine Kontodaten, Zahlungsdaten, privaten IP-Adressen, Zugriffstokens, Produktivprotokolle oder unverarbeiteten Produktivverkehr enthalten.

Fazit: Open Source ist der Anfang langfristigen Vertrauens

Das Open-Source-Programm von SingLinkVPN ist jetzt angelaufen.

Die erste Phase schafft technische Dokumentation, Forschungsmethoden, Nachweisstandards, Datenformate, Offenlegungsregeln, Berichtsstrukturen und Prüfwerkzeuge.

Weitere Sicherheits-, Leistungs- und Transparenzberichte werden folgen. Weitere öffentliche Daten kommen in einem einheitlichen Format hinzu. Weitere technische Unterlagen und Produktquellcode werden nach Prüfung von Sicherheit, Datenschutz und Lizenzen schrittweise veröffentlicht.

Das ist keine einmalige Markenankündigung und nicht der letzte Schritt. Es ist ein fortlaufendes technisches Vorhaben.

Unser Ziel ist es, die technischen, sicherheits-, datenschutz- und leistungsbezogenen Informationen von SingLinkVPN von Material, das nur die Marke beschreibt, in öffentliche Nachweise zu verwandeln, die die Community einsehen, zitieren, überprüfen, reproduzieren und weiter kritisch prüfen kann.

Wir begrüßen Entwickler, Sicherheitsforscher, Fachmedien und Nutzer aus der Community, die Dokumentation verbessern, Forschung reproduzieren, Daten prüfen und sich an der technischen Diskussion beteiligen möchten.