Architecture local-first : pourquoi aucune donnée ne quitte votre poste
Vether tourne intégralement sur votre machine. Comprendre cette architecture explique pourquoi le logiciel est résistant aux compromissions serveur et aux exigences légales.
Beaucoup de logiciels de sécurité fonctionnent en mode client-serveur : votre app envoie vos données vers un serveur central qui fait l'analyse et renvoie un verdict. Cette architecture est plus simple à développer, mais elle a un défaut fondamental — si le serveur est compromis ou contraint légalement, vos données sont exposées. Vether prend l'approche inverse.
Le principe local-first
Local-first signifie que toute la logique métier tourne sur votre machine, sans dépendance à un service distant. Vether est un binaire WPF C# .NET 6 qui invoke directement :
- Les APIs Windows natives (P/Invoke kernel32, advapi32, ntdll)
- PowerShell pour les modifications privilégiées (services, tâches, GPO)
- Le registre Windows (HKLM, HKCU)
- WMI pour la collecte d'informations système
- Les exécutables tiers embarqués (VeraCrypt, VBoxManage, mullvad CLI)
Ce qui sort de votre machine, et pourquoi
Trois types de requêtes seulement quittent votre poste, toutes nécessaires et minimales :
| Requête | Vers | Données envoyées | Fréquence |
|---|---|---|---|
| Vérification de licence | vether.org | Jeton Ed25519 opaque + nonce aléatoire | 1× par semaine |
| Check de mise à jour | vether.org/api/version | Version actuelle (X.Y.Z) | 1× au démarrage |
| Tunnel VPN | Serveur Mullvad | Trafic chiffré ChaCha20-Poly1305 | Continu si activé |
Pourquoi cette architecture est plus résistante
Contre une compromission serveur
Si demain notre infrastructure est piratée, qu'est-ce que l'attaquant peut faire ? Lire notre base : il trouve juste des e-mails clients et des transactions Stripe/BTCPay. Pas votre fingerprint matériel, pas votre historique de navigation, pas votre clé VeraCrypt. Le pire scénario est que l'attaquant pourrait pousser une fausse mise à jour — mais elle serait invalidée par la vérification de signature Authenticode + hash SHA-256 côté client.
Contre une contrainte légale (subpoena, warrant)
Si MADE GROUP LLC reçoit une demande judiciaire (réquisition policière, ordonnance de la CNIL, etc.) demandant 'donnez-nous les données du client X', nous ne pouvons donner que :
- L'adresse e-mail utilisée pour l'achat de licence
- Les transactions Stripe/BTCPay associées (méthode, montant, date — sans détails carte)
- La date d'émission de chaque licence et son statut
Et c'est tout. Aucun usage produit n'est journalisé, donc il n'y a rien à donner. C'est par design — pas un effort post-hoc.
Architecture technique en bref
┌─────────────────────────────────────────────────────────────┐
│ Votre machine Windows 10/11 x64 │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Vether.exe (WPF C# .NET 6) │ │
│ │ • UI XAML (12 modules) │ │
│ │ • DI Autofac · Service per module │ │
│ │ • P/Invoke Win32 · Registry · WMI │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Sous-processus invoqués à la demande : │
│ ├─ VeraCrypt.exe (chiffrement volumes) │
│ ├─ VBoxManage.exe (gestion VM) │
│ ├─ mullvad.exe (CLI VPN WireGuard) │
│ ├─ firefox.exe (Firefox Portable ESR) │
│ ├─ powershell.exe -ExecutionPolicy Bypass (modifications) │
│ └─ schtasks.exe / sc.exe / netsh.exe (config système) │
└─────────────────────────────────────────────────────────────┘
│
▼ HTTPS uniquement, sortie limitée
┌─────────────────────────────┐
│ vether.org (licence + MAJ)│
│ Mullvad servers (tunnel) │
└─────────────────────────────┘