EU prepares ground for wider data retention and VPN's are among the targets

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:

1. 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?

2. 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.

3. Data ownership model: The VPN provider doesn't "own" the data - users do. The provider is just a technical intermediary. Who must retain what?

4. 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:

1. Requiring that VPN services must be architecturally capable of collecting AND DECRYPTING this data to operate in the EU
2. Mandating minimum account lifespans (e.g., "accounts must exist for at least 12 months")
3. 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:

1. Finding legal loopholes in the legislation itself?
2. Designing technically compliant architectures that render the law's intent ineffective?
3. The legal defensibility of "Ignorance by Design" approaches?
4. Client-side encryption architectures where the provider has zero access to decryption keys?
5. 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.