NAPP STACK — PRIVACY & NETWORK-BEHAVIOR NOTICE Last updated: [DATE] (applies to EULA-1.0) This notice describes every way the NAPP Stack binary ("napp") communicates over the network on its own initiative. It is provided for transparency; see the EULA (`napp licenses`) for the governing terms. WHAT NAPP NEVER COLLECTS NAPP never collects, transmits, or sells your configuration contents, secrets (API token, database passwords, ACME keys), logs, the state database, domains, IP addresses, file paths, or any of your site/application data or your end users' data. None of that ever leaves the machine. NAPP MAKES AT MOST TWO OUTBOUND CALLS, BOTH ON ITS OWN HOST ONLY: 1. SIGNED UPDATE CHECK (always, when the daemon runs) The daemon (`napp serve`) periodically fetches signed metadata from Licensor's distribution host (default https://dl.nappstack.com): - the component catalog/manifest (so component updates we publish reach the node), retrieved at daemon startup and approximately daily; and - on `napp self-update` / when checked, the napp release metadata. These are ordinary HTTPS GETs with no body and no NAPP-specific identifiers; standard request metadata (your IP, timestamp, User-Agent) is visible to the host serving the file, as with any download. Metadata and binaries are cryptographically verified (baked-in ed25519 key + SHA-256) before anything is trusted or installed. To run fully air-gapped, install from local component sources (NAPP_SOURCES) so no request is made. 2. OPTIONAL, ANONYMOUS USAGE REPORTING (off by default) If — and only if — you opt in, the daemon sends an anonymous usage report to the telemetry endpoint to help us understand how NAPP is used and improve it. - OFF BY DEFAULT. You are asked once at first run (interactive `serve`); the answer defaults to "no", and a headless/service install stays OFF unless you pass `--telemetry on` or later run `napp telemetry enable`. If no telemetry endpoint is built into your binary, the feature is fully inert. - WHAT IS SENT (anonymized): NAPP version + edition, OS/arch, profile (dev/prod), the active component versions, which database engines are in use, feature flags (redis/mail/WAF mode/ACME in use), counts of sites/ workers/cron, and one row per enabled site describing only its stack (engine, database engine, PHP/runtime version, TLS mode). Plus a random "install id" generated locally (16 random bytes — not derived from your hardware, IP, or domains) so unique installs can be counted; reset it any time with `napp telemetry reset-id`. - WHAT IS NEVER SENT: domains, site names, IP addresses, file paths, ports, configuration contents, secrets, or any site/user data. - SEE EXACTLY WHAT WOULD BE SENT: `napp telemetry preview` prints the precise payload at any time, whether reporting is on or off. - TURN IT OFF ANYTIME: `napp telemetry disable` (takes effect immediately, no restart). `napp telemetry status` shows the current state. The report is a small JSON HTTPS POST sent after a short delay at startup and then about once a day, in the background, with a short timeout and no retries; a failure is silently ignored and never affects your stack or its performance. DATA HANDLED LOCALLY ONLY Everything else — configuration (napp.yaml), secrets, logs, the state database (napp.db), and all site/application data — stays on the machine you run NAPP on. THIRD-PARTY COMPONENTS AND YOUR SITES The stack components NAPP runs (Nginx, Apache, PHP, PostgreSQL, MariaDB, Redis, Mailpit, Adminer) and the websites/applications You host with them may have their own network behavior and their own privacy obligations to Your end users. That is outside NAPP's control and Your responsibility as the operator. CONTACT Privacy questions: [CONTACT EMAIL / URL — TBD]. ================================================================================ PLACEHOLDER — to be reviewed/completed by the publisher. Not legal advice. ================================================================================