Back to pegelWERK

Security & Licensing Principles

Our audio tools run entirely locally on your device. Even so, we treat licenses and customer data as if we were running a security-critical system. The following principles are fixed, documented invariants of our architecture — not marketing promises, but rules that every code change must respect.

Technical guarantees

Cryptographically signed licenses

Licenses are signed with modern cryptography (Ed25519) and verified locally by the app — a plain server “OK” (HTTP 200) is never enough to grant entitlement. A valid license cannot be forged without our private signing key.

Private keys stay in the backend

The secrets used to sign licenses and to verify payment webhooks never leave our server environment. The apps contain only the public key needed to verify signatures.

No server secrets in the client

Our desktop and iOS apps contain no API keys or credentials for backend services. Anyone analyzing an app binary finds at most public keys — never secret credentials.

Payment webhooks are “fail-closed”

Payment and license webhooks are cryptographically signed, verified in constant time, and strictly rejected on any mismatch — including suspicious timestamps (replay protection). There is no “let it through when in doubt” path.

Interfaces are deliberately constrained

Our server APIs accept browser requests only from explicitly allowed domains. We do not use open wildcard CORS for license- or data-mutating endpoints.

App Store compliance (iOS)

Our iOS apps contain no built-in external purchase or licensing code that would violate App Store rule 3.1.1. Purchases and subscriptions follow Apple’s intended path (StoreKit).

Clearly defined trust boundaries

License IDs are not passwords

We do not treat license identifiers as full secrets: they are high-entropy and unguessable, requests are rate-limited, and the actual entitlement always rests on a cryptographic signature — not on the ID alone.

Client tampering is planned for as a residual risk

We realistically assume that local tampering with an installed app can never be fully prevented. Our architecture is therefore designed so that such tampering affects at most that one device — never other customers or data on our servers.

Continuous hardening & audits

Security audits

We audit our licensing and payment components — including secret scans, code review, and tests of the crypto and webhook logic — and fix findings in a prioritized, traceable way. Last audit: June 2026.

Documented invariants instead of opaque automation

Even where we use modern tooling (including AI assistance) in development, every security-relevant guarantee is documented as a verifiable invariant. Every change — whether proposed by a human or an assistant — must uphold these rules.

Reporting a vulnerability

Responsible disclosure

If you discover a security issue in our apps, licensing, or backend services, please report it to [email protected]. We acknowledge receipt, keep you informed, and fix confirmed issues with priority. We will not pursue legal action against good-faith security research that respects third-party data and does not disrupt our services. Machine-readable contact: security.txt.

These principles describe the current state of our architecture and are updated as it changes. Questions or security reports: [email protected] · As of: June 2026