WQR
Security

Security Center

We’re building WQR with a simple principle: your secrets stay on your device. Our servers can help protect unlocking and defend against abuse — but they are not a storage place for your vault.

On this page
TransparencyResponsible disclosureAudit & bug bountySecurity changelogStatus & incidents
Transparency

What we store (and what we don’t)

What we store

  • Your WQR vault stays locally on your device.
  • We do not store your vault content on our servers.
  • We do not store your master password or any key that can reveal plaintext.

What we log (operational)

  • Request timestamps (for reliability and abuse defense).
  • Error codes and service health metrics.
  • Rate-limit / abuse signals (to stop brute force and misuse).
We do not log plaintext passwords, decrypted secrets, or secret payload contents.
Retention: We keep operational logs only as long as needed to operate, defend, and investigate abuse. If an incident requires extended investigation, we may retain incident-related logs longer.

Where servers run

We will publish the exact regions as the product goes live. Our default direction is to keep security infrastructure in privacy-friendly jurisdictions whenever feasible.

Subprocessors

When we rely on infrastructure providers (hosting, CDN/DDoS, email), we’ll list them here so customers can make an informed choice.

How we communicate incidents

Major incidents will be communicated through the status section below and, when appropriate, through on-site notices.

Security

Responsible disclosure policy

We welcome good-faith security reports. If you believe you’ve found a vulnerability, please report it privately so we can investigate and fix it responsibly.

How to report

  • Email: security@whyqr.de
  • Include: steps to reproduce, affected versions, impact, and a safe proof-of-concept (if applicable).
  • If sensitive data is involved, please describe the issue without exposing other users’ data.

Safe harbor

  • Act in good faith and avoid privacy violations.
  • Avoid service disruption (no destructive testing, no large-scale scanning).
  • Give us reasonable time to fix before public disclosure.

In scope (examples)

  • Authentication / authorization weaknesses
  • Encryption and key-handling mistakes
  • Data exposure (client or server)
  • Rate-limit bypass / abuse pathways
  • Client vulnerabilities that could expose secrets

Out of scope (examples)

  • Social engineering without a technical vulnerability
  • Physical attacks without a technical weakness
  • Spam reports without reproducible evidence
Response: We aim to acknowledge reports quickly (typically within a few business days), then triage and prioritize fixes based on severity. If you want credit, tell us how you’d like to be listed.
Validation

Audit & bug bounty

Trust is stronger when it’s verified. Our goal is to support independent validation as we grow — starting with clear disclosure, then audits and a bug bounty program as resources allow.

Third‑party audit

Planned

Audit focus areas (intended):

  • Cryptography usage and key handling
  • Server‑gated unlock mechanism
  • Client storage and memory handling
  • Abuse controls and rate limiting
  • Update / release integrity

Bug bounty

Planned

We expect to start with a limited program and expand over time. Rewards may begin small (for example, subscription time or fixed bounties) and scale as the product matures.

For now, the best path is responsible disclosure via security@whyqr.de.

Transparency

Security changelog

We publish security-related hardening and fixes to show steady improvement — without posting exploit instructions. When a change requires user action, we’ll say so clearly.

Format

YYYY-MM-DD — Version X.Y.Z
- Fixed: <what changed>
- Hardened: <what improved>
- Changed: <behavior or defaults>
- Notes: <anything users should do>
We describe fixes without providing step-by-step exploit guidance.

Entries

Coming soon

We’ll publish entries as releases stabilize. Until then, security-relevant changes will be summarized in release notes and in this page.

Reliability

Status & incident updates

Because WQR uses a server shield for unlocking, availability matters. This section explains what we monitor and how we communicate incidents.

Components

  • API (unlock shield & security operations)
  • Website
  • Download distribution
  • Support inbox

Current status

Info

A dedicated status page is planned. Until it’s live, we’ll post major incident updates here and respond through support.

Need help now? Contact support@whyqr.de.

Past incidents

None published yet

When incidents happen, we’ll publish: date, duration, impact summary, and mitigation steps — without exposing sensitive defense details.

Contact supportRead the security model