Trust boundary
Measure connection quality, not user activity.
NODIF separates local VPN operation, optional typed telemetry, provider-safe aggregates and business contact data. Providers receive only their own sufficiently large operational cohorts—never browsing records or individual-user telemetry.
The boundary in one view
| Layer | What exists | Who can use it |
|---|---|---|
| VPN operation on device | Subscription credential, raw configuration, eligible hosts/routes, route state and tunnel process data needed to connect. | The app locally. These values are not routine NODIF telemetry. |
| Local diagnostics | A small rotating timeline of coded stages, timings, state transitions and redacted error categories. | The user, and support only when the user deliberately copies a safe extract. It is not uploaded automatically. |
| Opted-in typed telemetry | Strict, bounded operational events sent to NODIF after separate consent. | NODIF processing systems for service improvement and deletion handling; providers cannot browse or export raw events. |
| Provider analytics | Tenant-scoped summaries that meet the live minimum cohort threshold. | Authorized provider keys with analytics entitlement and analytics:read. |
| Provider lead | Business contact and request details deliberately submitted through the provider-interest form. | Restricted NODIF provider-administration workflow; never joined to VPN telemetry. |
Optional operational data
When telemetry is enabled, NODIF accepts only typed, allowlisted fields needed to understand app and connection reliability:
- Random app-specific installation, event, batch, attempt and session identifiers that are not derived from an account, hardware identifier, advertising ID, subscription or endpoint.
- Connection outcome, stable lifecycle/failure stage, bounded duration and retry information.
- Handshake time, latency, jitter, packet-loss percentage, bounded download/upload measurement, route or health score and connection duration.
- Supported app version/build, OS family or major version, CPU family, release channel and broad network type.
- Protocol, transport, entry category, balancer category and aggregate topology counts.
- NODIF-issued random catalog identifiers only for eligible provider-owned infrastructure when the released client contract supports them.
- Optional coarse country, region/city code and broad network category from a short-lived signed pre-tunnel context.
- Stable coded app errors without exception text, process output or stack traces.
Unknown JSON fields and unknown enum values are rejected. Measurements are sampled and bounded; NODIF does not run continuous high-volume speed tests solely to collect analytics.
Data routine telemetry does not accept
Never part of routine telemetry
- Browsing destinations, URLs, DNS queries or search history
- Packets, payloads, traffic contents, SNI or application names
- Public/local IP fields, subnets, SSID/BSSID, GPS or exact location
- Subscription URL/token, VPN credential, HWID or account identifier
- Raw VPN configuration, host/domain/IP list, share link or key material
- Email, phone, name, advertising ID or OS account name
- Free-form logs, exception messages, file paths or crash stack traces
Provider output never includes
- An installation, user, device, session or individual event row
- Raw IP, precise location or full ISP/ASN identity
- Raw endpoint/configuration mapping
- Traffic destination, DNS or application history
- Another provider’s data or a cross-provider profile
- A query language, raw table or suppressed cohort
- A list of users who opted in or declined
Consent, withdrawal and deletion choice
- Off by default. “Help improve NODIF” is separate from accepting terms and starts unticked.
- Plain-language disclosure first. The app describes the operational categories, coarse context, purpose, retention, delayed upload and withdrawal behavior before registering a telemetry identity or recording an upload event.
- VPN remains available. Declining telemetry must not disable connection, reduce provider service or change account eligibility.
- Versioned affirmative choice. Consent records the disclosure version and grant time. Providers cannot enable it remotely or on a user’s behalf.
- Immediate local stop. Turning it off stops new telemetry events/uploads and clears the encrypted pending queue.
- Credential revocation and deletion. The random telemetry credential is revoked and a durable request removes associated raw server events.
- No silent restoration. Collection may resume only after a new affirmative user choice under the applicable disclosure.
Already released cohort statistics without an installation identifier are not individual records and may remain unless applicable policy or law requires otherwise.
Local logs are not uploaded telemetry
| Data class | Storage and transfer | Important distinction |
|---|---|---|
| Local diagnostic timeline | Rotating app-private local storage for up to seven days; copied or cleared by the user. | Not uploaded automatically and never copied wholesale into telemetry. |
| Pending telemetry queue | Encrypted app-private queue after opt-in; bounded by age, size and count; uploads when normal connectivity is available. | Contains strict typed events, not raw diagnostic JSONL or child-process output. |
| Server-side typed events | Validated, short-lived operational rows used to form aggregates and process deletion. | NODIF operational storage, not a provider-facing raw-event product. |
| Provider aggregate result | Metrics by an allowlisted dimension/time bucket only after the live distinct-install threshold is met. | No install identifier or drill-down. A missing row can be deliberate suppression. |
A user may intentionally share a redacted diagnostic extract with support. That support action is separate from telemetry consent and must follow the provider’s approved secure support process.
Transient source-IP handling
Only the pre-tunnel context endpoint may momentarily receive the transport source address, and only after telemetry opt-in. It passes that address directly to an in-process resolver to derive approved coarse codes, then releases it. The full address must not enter application/access logs, PostgreSQL, NATS, ClickHouse, caches, analytics results or backups.
- The safe resolver can return
unknown; location is not required for VPN operation. - Approved geolocation uses a local, read-only database. NODIF does not send the address to a third-party geolocation API.
- GPS is not used for telemetry context.
- The later batch-upload address is never treated as user location because it may be a VPN exit.
- ASN number and organization identity are reduced to a broad category before analytical storage.
Retention and deletion
The portal/API exposes the live raw-event retention and cohort threshold. The table below describes current defaults and enforced configuration ceilings; an applicable notice or contract may set a shorter period.
| Data class | Current default | Boundary/disposal |
|---|---|---|
| Local diagnostics | Up to 7 days | Rotating local history; user can clear it. |
| Encrypted pending events | Up to 7 days | Oldest-first bounded queue; cleared on withdrawal. |
| Typed server events | 30 days | Configuration maximum 90 days; TTL plus deletion mutation. |
| Batch idempotency records | 30 days | Configuration maximum 90 days; scheduled cleanup. |
| Cohort aggregates without install ID | 395 days | Configuration maximum 730 days; aggregate TTL. |
| Provider/admin audit metadata | 395 days | Scheduled policy cleanup; contains action metadata, not request bodies or secrets. |
| Provider-interest leads | 90 days | Configurable reviewed lead window; deleted by scheduled cleanup and never joined to telemetry. |
Backups inherit the classification and expiry of the protected data; they are not a mechanism to extend raw retention. Deletion is complete only after local queue purge, credential revocation, raw-row deletion processing, and backup expiry or documented cryptographic erasure under the active policy. Operations monitor pending deletion work and failed mutations.
Tenant isolation and disclosure control
- Provider attribution comes from a server-verified signed context. An event cannot assign itself to a plain provider ID.
- A
prv_key is fixed to one tenant. Provider routes take tenant identity from authentication, never from a caller-controlled path, body or query filter. - Every provider aggregate query applies the tenant predicate before execution and enforces the live minimum cohort threshold server-side.
- Each overall window, cohort row and time-series bucket must independently qualify. The browser and API consumer cannot lower the threshold.
- Provider endpoints expose no install lookup, raw-event browser, arbitrary SQL, raw export, credential hashes or previously issued plaintext secrets.
- Provider databases, queues, backups and NODIF administrator routes are not provider-accessible. Platform-admin routes also remain behind a network restriction.
- Repeated queries, overlapping windows and subtraction must not be used to reconstruct a small or suppressed group.
Credential handling
| Credential | Authority | Required handling |
|---|---|---|
prv_ provider key | Portal/API actions allowed by its fixed tenant, role and scopes. | Plaintext shown once and stored hashed server-side. Keep in an approved password/secrets manager, use least privilege, rotate after exposure or staff change, and revoke with another authorized key. |
| Branding token | Read-only retrieval of one provider’s approved signed profile when paired with its public slug. | Scope to the correct External Squad, redact from logs, rotate with a canary, then revoke the predecessor. |
| Subscription token/URL | User access to provider subscription material. | Keep on device/provider systems; never send as NODIF telemetry or provider-support evidence. |
| Random telemetry credential | One opted-in app installation’s bounded ingestion/revocation flow. | App-managed secure storage; not a provider account identifier and not provider-visible. |
| NODIF admin or infrastructure secret | Platform-wide privileged operation. | Never place in a provider portal, Remnawave response, browser documentation example or provider automation. |
The provider portal keeps the entered provider key only in that browser tab’s session storage, not in a URL. Use a trusted operator device, close the tab when finished, and do not share one owner key among staff or services.
Provider-interest form data
The public provider-interest form is a separate business-contact purpose. It accepts the contact and company details, requested plan and message that the submitter deliberately provides with privacy acceptance. It does not create a telemetry identity and is never joined to app, connection or provider-cohort data.
- Access is restricted to the NODIF provider-administration workflow.
- Automatic cleanup uses the configured lead-retention window, currently 90 days by default.
- Rate limiting keeps only a short-lived keyed digest in process memory rather than persisting a raw source address.
- A lead submission is not consent to a mailing list, traffic analytics or individual-user profiling.
- Do not put provider API keys, subscription credentials, user data or infrastructure secrets into the message.
Permitted and prohibited provider use
Permitted service-improvement use
- Compare qualifying connection success by protocol, route category or app release.
- Identify a sufficiently large coarse network/city cohort with elevated failure.
- Measure latency, jitter, loss and throughput before and after a controlled change.
- Prioritize provider capacity using available random catalog attribution.
- Detect aggregate platform/OS/app-version regressions.
- Document aggregate reliability conclusions and rollback decisions.
Prohibited use
- Search for, identify, fingerprint or score one subscriber/device.
- Join aggregates to account, billing, gateway or support records to single someone out.
- Infer a suppressed group through repeated filters, windows or subtraction.
- Use NODIF data for advertising, eligibility, pricing, surveillance or individual enforcement.
- Request, expose or reconstruct raw IPs, hosts, configs, DNS, destinations or traffic content.
- Sell/share analytics as audience, precise-location, individual device or individual-user data.
No-sale and monetization boundary
Permitted aggregate access remains purpose-limited after export. A provider must not resell it as audience/location/device data, combine it to create an individual profile, or advertise unavailable raw access. Commercial terms cannot weaken these technical and privacy boundaries.
Privacy and security incidents
- Stop the affected processing or export. Preserve consent withdrawal and deletion capability where safe.
- Contain the correct layer. Remove mis-scoped Remnawave headers, revoke exposed credentials, pause unsafe automation or isolate affected data as appropriate.
- Preserve minimal evidence. Record UTC time, impact, safe request/audit IDs and affected release/tenant. Do not copy prohibited data or plaintext secrets into chat, tickets or screenshots.
- Use the verified escalation channel. Notify the provider’s designated incident lead and the agreed NODIF security/privacy contact from the provider agreement or current official notice. Do not send credentials with the notification.
- Assess obligations. Authorized privacy/security personnel and qualified counsel determine processor, contractual and notification duties for the relevant markets.
- Recover and verify. Test tenant isolation, revocation, deletion, regression canaries and safe rollout before re-enabling the affected path.
- Complete root cause. Document control failure, time window, remediation, prevention and evidence disposal without reproducing sensitive content.
Treat wrong-tenant branding, exposed provider/admin credentials, a raw IP or subscription secret in analytics, suppression bypass, unexpected raw export, and prohibited log ingestion as security/privacy incidents.
Safe escalation evidence
| Include | Exclude |
|---|---|
| Impact and affected provider/environment | Provider/admin/branding keys |
| UTC start, last-known-good and detection time | Subscription URL/token or QR code |
| App version, platform, OS major and architecture | HWID, account ID or user identity |
| Stable error code/stage and safe API request ID | Raw config, host/domain/IP list or process command line |
| Recent redacted change, canary and rollback result | Packet capture, DNS/browsing history or unredacted logs |
| Aggregate scope/estimated impact without naming users | Individual event rows or suppressed-cohort inference |
Technical documentation versus legal terms
This page documents implemented technical and provider-use boundaries; it is not legal advice and does not invent the operator’s registered legal identity, address, governing law, subprocessor list, international-transfer mechanism, market-specific rights process, support SLA or contractual incident deadline. Those facts must be completed and reviewed in the applicable public privacy notice, store disclosures and provider agreement before relying on NODIF for a public launch in a target market.
See the current NODIF privacy notice for the public disclosure status, and use the verified contacts stated in the executed provider agreement or current official notice.
