THE MODEL

How your connection works

One architecture, explained at two depths. Start with the relationship; open the details when they become useful.

From your phone to the VPN server#

PHONE TO SERVER01 / KURD
Your phoneYou control the device
KurdAuthenticated connection
VPN serverYou choose the server operator
Your profile contains the connection setup.The profile sets access rules. It is not another server.
Technical details

Android imports an explicitly chosen kurd:// profile. You compare the deployment identity; the core verifies its policy before opening an authenticated Kurd session to the owner’s relay.

The app does not receive the owner’s root signing keys. Transport and fallback choices stay inside the signed profile. Public production qualification remains a separate release gate.

Three decisions before a connection#

  1. Receive a profile

    The server operator gives you a profile for your device. The Kurdistan VPN project does not run a central server subscription.

  2. Check it, then decide whom to trust

    Profile verification checks the artifact. Comparing the full deployment fingerprint with the owner checks the relationship you intended.

  3. Use only the permitted path

    The app must stay inside the signed profile’s authority. It cannot silently invent a new relay or direct fallback.

Who controls each part?#

WHO CONTROLS EACH PART?

You

You choose the profile and grant Android VPN permission. A profile does not give its issuer control of your phone.

Technical details

Android grants VPN permission. Device-owned private material remains in protected local storage; the operating system controls its own always-on and lockdown settings.

Where that control ends

A compromised or unlocked device remains a separate risk. A VPN does not secure every app or permission on the phone.

WHO CONTROLS EACH PART?

The profile issuer

A profile is the connection setup you add to the app. Its signed rules define access to a particular server.

Technical details

The signed artifact binds permitted runtime policy, validity and deployment identity. A recipient-sealed profile is intended for its enrolled device.

Where that control ends

The issuer can expire or revoke that access. A valid signature does not, by itself, tell you whether to trust the issuer.

WHO CONTROLS EACH PART?

Your device

Device-bound keys open profiles made for this phone. They do not give the server operator remote control.

Technical details

The Android flow exports a public enrollment request. Private key material does not leave encrypted local storage except inside an encrypted backup.

Where that control ends

The public request is not a password. Backups and device compromise still need deliberate handling.

WHO CONTROLS EACH PART?

The person running the VPN server

The operator decides who may use the server. If you run the server, you can issue your own profiles.

Technical details

The deployment root is unique to its owner. Root private material is in a passphrase-encrypted recovery artifact; online issuer and relay keys have separate local custody.

Where that control ends

Control of a profile is not control of the phone. One independent deployment cannot revoke another deployment’s access.

WHO CONTROLS EACH PART?

The operator and hosting provider

The operator runs the VPN software. The hosting company controls the underlying VPS infrastructure. You decide whether to connect.

Technical details

kurd-node runs on an operator-controlled VPS. Host-level networking and resolver policy are outside the relay process’s authority.

Where that control ends

Self-hosting gives you operational control, not ownership of the hosting company’s equipment or guaranteed anonymity.

WHO CONTROLS EACH PART?

Project maintainers and contributors

Kurdistan VPN manages the connection on your phone according to the verified profile. It is software, not a remote device administrator.

Technical details

The public source contains the Kurd compiler, runtime, Android foundation and operator tooling. Review source and exact release provenance separately.

Where that control ends

Open source is not an independent audit. Build, distribution and operational evidence must be checked for each release.

What makes the protocol profile-driven?#

Technical details

Kurdistan compiles bounded protocol behaviour from a profile: framing, state transitions, scheduling, padding, probing, carrier policy and permitted fallback can vary while retaining authenticated stream semantics.

This is not permission for the client to select arbitrary transports. Every runtime choice stays inside the verified plan. Source presence does not prove censorship bypass or undetectability.

Runtime choices are bounded by the signed profile.Engineering / design previewView evidence
What this means
The app may narrow a verified plan, not invent a relay, strategy or fallback outside it.
How the design works
The compiler/runtime implements authenticated stream semantics, policy checks, replay and downgrade checks.
The limit
Source and controlled tests do not establish leak prevention on every phone. Android lockdown is a separate system policy.

Reviewed . Source code alone is not release qualification.

Source and scope

Reviewed . The linked source describes the implementation; released-build evidence is a separate check.

What do you need?

Search runs on this device.

Open the full search pageEsc