NODIF DocsProvider knowledge center

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.

Explicit opt-inTenant isolatedNo traffic contentNo individual-data sale

The boundary in one view

LayerWhat existsWho can use it
VPN operation on deviceSubscription 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 diagnosticsA 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 telemetryStrict, 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 analyticsTenant-scoped summaries that meet the live minimum cohort threshold.Authorized provider keys with analytics entitlement and analytics:read.
Provider leadBusiness 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
  1. Off by default. “Help improve NODIF” is separate from accepting terms and starts unticked.
  2. 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.
  3. VPN remains available. Declining telemetry must not disable connection, reduce provider service or change account eligibility.
  4. Versioned affirmative choice. Consent records the disclosure version and grant time. Providers cannot enable it remotely or on a user’s behalf.
  5. Immediate local stop. Turning it off stops new telemetry events/uploads and clears the encrypted pending queue.
  6. Credential revocation and deletion. The random telemetry credential is revoked and a durable request removes associated raw server events.
  7. 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 classStorage and transferImportant distinction
Local diagnostic timelineRotating 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 queueEncrypted 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 eventsValidated, short-lived operational rows used to form aggregates and process deletion.NODIF operational storage, not a provider-facing raw-event product.
Provider aggregate resultMetrics 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 classCurrent defaultBoundary/disposal
Local diagnosticsUp to 7 daysRotating local history; user can clear it.
Encrypted pending eventsUp to 7 daysOldest-first bounded queue; cleared on withdrawal.
Typed server events30 daysConfiguration maximum 90 days; TTL plus deletion mutation.
Batch idempotency records30 daysConfiguration maximum 90 days; scheduled cleanup.
Cohort aggregates without install ID395 daysConfiguration maximum 730 days; aggregate TTL.
Provider/admin audit metadata395 daysScheduled policy cleanup; contains action metadata, not request bodies or secrets.
Provider-interest leads90 daysConfigurable 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

CredentialAuthorityRequired handling
prv_ provider keyPortal/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 tokenRead-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/URLUser access to provider subscription material.Keep on device/provider systems; never send as NODIF telemetry or provider-support evidence.
Random telemetry credentialOne 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 secretPlatform-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

  1. Stop the affected processing or export. Preserve consent withdrawal and deletion capability where safe.
  2. Contain the correct layer. Remove mis-scoped Remnawave headers, revoke exposed credentials, pause unsafe automation or isolate affected data as appropriate.
  3. 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.
  4. 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.
  5. Assess obligations. Authorized privacy/security personnel and qualified counsel determine processor, contractual and notification duties for the relevant markets.
  6. Recover and verify. Test tenant isolation, revocation, deletion, regression canaries and safe rollout before re-enabling the affected path.
  7. 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

IncludeExclude
Impact and affected provider/environmentProvider/admin/branding keys
UTC start, last-known-good and detection timeSubscription URL/token or QR code
App version, platform, OS major and architectureHWID, account ID or user identity
Stable error code/stage and safe API request IDRaw config, host/domain/IP list or process command line
Recent redacted change, canary and rollback resultPacket capture, DNS/browsing history or unredacted logs
Aggregate scope/estimated impact without naming usersIndividual event rows or suppressed-cohort inference

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.