YuraNetwork PRIVACY
Home Apps FAQ Bug report Privacy
Privacy by architecture

Private by default. Public by choice.

YuraNetwork’s strongest privacy feature isn’t a checkbox — it’s the architecture: a private DNS namespace (.yura) that is hard‑blocked from the public internet and only exists for tunnel clients.

Public-safe page: we describe mechanisms, boundaries, and controls — no keys, no internal IP lists, no private registry contents.

App privacy (Yuragram)

No ads / trackers

No ad SDKs. No marketing pixels. We don’t build a surveillance pipeline.

Minimal telemetry

Diagnostics exist for reliability, not profiling. We avoid collecting what we don’t need.

User-controlled reporting

Bug reports are user-submitted; you decide what to include.

Bug reports (stored as files)

Reports submitted via /bug-report are stored as plain text files for the dev team to reproduce issues. Don’t paste passwords, private keys, or seed phrases.

Send a report

Security posture

  • Prefer short retention for operational logs
  • Gated admin operations (reduce abuse surface)
  • Focus on reliability + least data necessary
If you want the app to be stronger: we can publish a clear “data we store / data we don’t store” table. No vague marketing — just facts.

Tunnel privacy (YuraNetwork / .yura)

What makes this unique

Most “private hosting” systems fail in one place: they still expose a public surface that can be scanned, crawled, and enumerated. YuraNetwork flips that: the .yura namespace is inside-only, and the gateway enforces that boundary at the edge.

Anti-enumeration edge block

nginx blocks .yura unless the client is inside the tunnel subnet (10.77.0.0/24). This prevents public scanning and crawling by design.

Private DNS namespace

.yura resolves via tunnel DNS (10.77.0.1). There’s no public DNS listing to scrape, mirror, or index.

Encrypted transport

WireGuard encrypts client↔gateway traffic. You aren’t punching random public ports through your router.

Trust & security controls

Public + private trust

Public portal uses standard web PKI. Private .yura browsing uses the Yura Root CA + revocation list.

/api/ca/root.crt /api/ca/root.crl

Gated sensitive operations

Admin-only / expensive actions (example: search reindex) must be token-gated to prevent abuse (DoS-style load) and reduce exposure.

Protected endpoints require admin token (implementation detail varies by deployment)

Security controls checklist (public-safe)

Edge boundary

  • .yura blocked unless inside tunnel subnet
  • No public directory of domains

Transport

  • WireGuard encrypted client↔gateway
  • DNS for tunnel clients is pinned (10.77.0.1)

Abuse resistance

  • Token-gate admin operations
  • Rate-limit expensive endpoints

Trust

  • Private CA + CRL for .yura
  • Clear separation: public portal vs private network

Key hygiene

  • Publisher/site key lifecycle
  • Rotation support for operational hygiene

Logging stance

  • Minimize what’s stored
  • Retention-limited where possible

Key hygiene

Publisher/site key rotation exists in the system design for operational hygiene.

Inside-only discovery

Discovery happens via yurasearch.yura inside the tunnel — not on public pages.

Boundary clarity

Public portal is documentation + onboarding. Private namespace is the network. No confusion.

Identifiers & lifetimes (privacy-relevant)

One-time provisioning tokens

Tunnel onboarding uses a single-use tokenId + tokenSecret. Unused tokens expire quickly (default ~20 minutes). This reduces linkability and limits replay.

Long-lived identifiers

Publishing uses a publisher identity (publisherId) and per-site keys (siteKey) so you can update targets and rotate credentials without re-installing clients.

Threat model (explicit)

Attacker: Public internet scanner Goal: enumerate private services Control: .yura blocked at edge unless inside tunnel subnet Attacker: Passive observer on public network Goal: read tunnel traffic Control: WireGuard encrypted transport Attacker: Abuse actor Goal: trigger expensive operations / DoS Control: token-gated admin operations Attacker: Connected member (inside tunnel) Goal: access a shared domain Reality: being connected + knowing the domain grants access Control: domain distribution + organizational controls

What we log (and what we avoid)

Operational logging (minimal)

We keep operational logs focused on reliability and abuse prevention, with retention limits. Where possible, we prefer minimized/hashed references over raw identifiers.

Machine-readable privacy status

What we avoid

  • Publicly listing private domains or counts
  • Unbounded retention of sensitive operational data
  • Unprotected “expensive endpoints” that can be abused

Metadata minimization (routing vs storage)

Metadata required to deliver traffic

  • Which hostname routes to which private target
  • Whether the client is inside the tunnel boundary
  • Enough state to provision/revoke access safely

What we don’t need to store long-term

  • Public searchable inventory of private sites
  • Long-lived provisioning tokens
  • Excessive access logs for inside-only services

Guarantees & limitations (clear)

ClaimWhy it holdsLimit
Public internet cannot crawl/enumerate .yura Hard edge block enforces tunnel membership before routing. If you publish something on the public web, that’s outside the tunnel model.
Tunnel traffic is encrypted WireGuard provides encrypted client↔gateway transport. Endpoints still must be secured like any server/app.
No public directory of private domains Discovery is inside-only (yurasearch.yura), public site does not list. Connected users can still share domains with each other.
Provisioning links expire Single-use tokens with short TTL reduce replay/linkability. Long-lived publisher/site keys are still needed for operations.

Why this is stronger than “private hosting”

Most systems

  • Expose a public origin you can scan
  • Rely on obscurity or random URLs
  • Accidentally leak existence through public DNS

YuraNetwork

  • Private namespace exists only for tunnel clients
  • Hard edge blocks enforce membership
  • Discovery is internal (yurasearch.yura)
The privacy win is structural: no public reachability + no public enumeration by default.