Threat model
What nullpay. protects. What it doesn’t.
Every privacy system has boundaries. This page describes ours honestly: what the architecture guarantees, what it assumes, and what you need to do yourself.
What nullpay. protects against
Bank or card network linking you to a service
Your bank sees "NullPay SAS — €10". It cannot see which privacy service you chose, because that information is never part of the payment.
Service provider identifying who paid
The service receives a standard voucher code. It carries no card details, no customer ID, no reference to NullPay.
NullPay itself linking payment to redemption
The blind signature (RFC 9474) prevents NullPay from recognizing which token it signed. Payment records and redemption records share no key.
Payment processor inferring your service choice
The processor sees "NullPay SAS" and an amount. Service selection happens at redemption, which the processor has no involvement in.
What nullpay. does not protect against
Device compromise
Tokens are stored locally in your browser. If your device is compromised, an attacker can read your tokens, see which services you redeemed, and use unredeemed tokens.
Shared infrastructure correlation
If the same CDN, hosting provider, or logging service handles both payment and redemption traffic, a single subpoena or breach could yield correlated access logs.
Low-volume deanonymization
Batch processing creates an anonymity set, but at low volume, batches may be small. If only one payment and one redemption occur in a window, they are trivially linked regardless of the blind signature.
NullPay being compromised or coerced
NullPay controls both servers. A coerced or compromised operator could modify production code to log token-to-payment mappings. Open source and future audits mitigate this, but do not eliminate it.
IP and browser fingerprinting
If you use the same IP, browser profile, and TLS fingerprint for both payment and redemption, an observer with access to both flows could correlate them.
Trust assumptions
When you use nullpay., you are trusting:
NullPay operates the servers as described and as the open-source code specifies.
Payment and redemption infrastructure are genuinely separated (different servers, different providers).
Batch processing and dummy padding work as documented.
The blind signature implementation correctly follows RFC 9474 (not yet independently audited).
What would break the system
| Threat | Impact |
|---|---|
| Compromised signing key | Attacker can forge tokens, issue vouchers without payment. |
| Server-side logging introduced | Token-to-payment mappings become available, breaking unlinkability. |
| Shared infrastructure correlating both flows | Timing and IP correlation across payment and redemption. |
| Operator coerced into modifying production code | Silent logging or token tracking, undetectable to users until audit. |
Recommendations for maximum privacy
The blind signature handles the cryptographic layer. These precautions address the side channels.
Use a VPN or Tor for redemption
Prevents IP correlation between payment and redemption.
Purchase tokens well in advance
Temporal separation makes timing correlation harder.
Use a different browser or profile for redemption
Prevents browser/TLS fingerprint correlation.
Export and back up tokens securely
Tokens are bearer instruments — if lost, they cannot be recovered.
Redeem from a different network if possible
Prevents network-level correlation by your ISP.