Legal loopholes vs. illegal workarounds - and the "Ignorance by Design" approach
I appreciate your commitment to staying within legal boundaries. However, I think it's worth clarifying the distinction between evasion (illegal) and elusion (legal), and exploring another powerful concept: Ignorance by Design.
Evasion = Breaking the law
- Falsifying logs
- Hiding required data
- Lying to authorities
→ This leads to fines, shutdown, criminal charges
Elusion = Exploiting legal loopholes
- Complex corporate structures across multiple jurisdictions
- Functional separation (who owns the data? who processes it? who stores it?)
- Narrow interpretation of legal requirements
- Decentralized models where no single entity has full control
→ This is what multinational corporations do for tax planning - it's legal
Ignorance by Design = Technical architecture that makes data collection impossible
- The system is designed so that certain data simply doesn't exist
- It's not "we won't give you the logs" - it's "the logs don't exist by design"
- Like Signal: they can't give authorities messages because they don't store them
→ It's not a choice, it's an architectural limitation
Examples that could be explored:
Jurisdictional complexity: Holding company in Switzerland, operational entity in Faroe Islands, servers managed by separate entities, payments processed by another company. Which entity is legally required to retain what data?
Technical architecture: If the law requires "storing user IP addresses" but users connect through intermediate proxies/nodes, you technically store something - just not the actual user IP. Letter of the law = complied. Usefulness for authorities = zero.
Data ownership model: The VPN provider doesn't "own" the data - users do. The provider is just a technical intermediary. Who must retain what?
Ignorance by Design implementation: Redesign the architecture NOW (before the law passes) to make data collection technically impossible. RAM-only servers, no persistent storage, user-controlled encryption keys. When the law comes into force: "We cannot collect data that our architecture doesn't support."
5. THE PARADIGM SHIFT - Client-side encryption keys:
This is the game-changer: Encryption keys exist ONLY on the user's client device. The VPN provider architecturally cannot access, store, or transmit user keys.
How this works:
- User generates encryption keys locally on their device
- All session data is encrypted with keys the provider never has access to
- Even if forced to keep logs, the logs exist but are heavily encrypted (Signal's triple-ratchet design or similar)
- The provider literally cannot decrypt the logs even if they wanted to
Legal compliance met, but useless for authorities:
- Regulator: "Give us the logs"
- Provider: "Here they are" ✓ (compliant)
- Regulator: "Decrypt them"
- Provider: "We don't have the keys. They're on user devices. Architecturally impossible." ✓ (still compliant)
The beauty of this approach:
- You ARE keeping logs (law complied with)
- The logs are encrypted garbage without user keys
- You CANNOT decrypt them (architectural limitation, not refusal)
- Users control their own keys (data ownership model)
6. DISPOSABLE ACCOUNTS - Breaking continuity:
Offer disposable, temporary accounts with maximum 30-day lifespan (or even shorter periods like weekly accounts).
Why this matters:
- Breaks tracking continuity: Even if authorities get logs for one account, it expires and a new one is created
- Prevents long-term profiling: Can't build a 12-month profile when accounts only exist for 30 days
- Defeats targeted persecution: By the time an investigation targets a specific account, it may have already expired and been replaced
- Legal compliance: You're still retaining data for the account's lifespan - just that lifespan is intentionally short
How it works in practice:
- User subscribes for (e.g.) 1 year of service
- Instead of one persistent account for 12 months, they get 12 monthly disposable accounts
- Each month, old account data is legitimately deleted (account expired)
- New account created with new credentials, new encryption keys
- From a regulatory perspective: each account's data is retained for its full lifespan
The legal beauty:
- You're not deleting data prematurely (each account's data is kept until account expiry)
- You're not hiding anything (full compliance during account lifetime)
- Authorities can request current data, but historical accounts are legitimately gone because they expired
- It's like prepaid SIM cards: use it, expire it, get a new one
Similar precedents:
- Prepaid SIM cards: Widely legal, expire after X days/months
- Temporary email services: 10minutemail, Guerrilla Mail - perfectly legal
- Burner phone apps: Legal services that provide temporary numbers
Critical timing consideration:
If you implement "Ignorance by Design" BEFORE the law passes, you can argue: "Our system was already designed this way." If you change the architecture AFTER the law passes, regulators could claim you're deliberately evading it.
The EU's potential counterattack:
The EU could respond by:
- Requiring that VPN services must be architecturally capable of collecting AND DECRYPTING this data to operate in the EU
- Mandating minimum account lifespans (e.g., "accounts must exist for at least 12 months")
- Requiring continuity tracking across account changes for the same payment method
However, these would face serious challenges:
- Banning client-side encryption would undermine E2E encryption principles the EU has endorsed
- Mandating minimum account lifespans could conflict with consumer choice and data minimization principles (GDPR actually encourages deleting data you don't need)
- Requiring cross-account tracking could violate privacy principles
Real precedents:
- Apple vs FBI (2016): Apple successfully argued "we don't have the keys, our architecture doesn't allow it" - they weren't charged with facilitating crime
- Lavabit (2013): Shut down rather than compromise architecture - founder wasn't prosecuted for the design itself
- Signal: Has publicly stated they'd shut down in countries rather than implement backdoors
- WhatsApp Brazil ban attempts: Courts couldn't force WhatsApp to decrypt E2E messages they don't have keys for
- Prepaid telecom services: Widely accepted despite making long-term tracking harder
Question: Have you consulted specialized lawyers in regulatory compliance who focus on:
- Finding legal loopholes in the legislation itself?
- Designing technically compliant architectures that render the law's intent ineffective?
- The legal defensibility of "Ignorance by Design" approaches?
- Client-side encryption architectures where the provider has zero access to decryption keys?
- Disposable/temporary account models that break tracking continuity while remaining compliant?
Because that's different from just "opposing the law" or "relocating" - it's about exploiting the law's own weaknesses and architectural impossibilities. You can comply with data retention while making the retained data cryptographically useless AND time-limited by design.
Combined approach could be devastating to surveillance efforts:
- Logs exist but are encrypted with client-side keys (compliant but useless)
- Accounts expire every 30 days, breaking long-term tracking (compliant but discontinuous)
- Multi-jurisdictional structure makes it unclear who's responsible for what (compliant but complex)
- Payment and service entities are separated (compliant but compartmentalized)
Just food for thought.