Comment Shomerli protège vos données — sans compromis halakhique.

Vos données en termes simples.

Sans jargon technique. Pour les parents qui veulent comprendre l'essentiel avant d'inscrire leur foyer.

Whitepaper technique.

Architecture, encryption, hosting honnête, contrôles API et détection des contournements. Tous les claims sont vérifiables indépendamment.

B.1 — Architecture multi-couches

Shomerli n'est pas un filtre DNS solo. C'est une architecture multi-couches conçue pour la communauté observante, où chaque couche apporte une protection distincte. Aucune couche n'est suffisante seule — c'est leur composition qui rend le contournement coûteux et la détection rapide.

B.2 — Où sont vos données ?

Shomerli a été conçu et opère depuis Montréal. Notre engagement est la résidence canadienne pour toute donnée sensible. Voici l'état actuel — et notre roadmap publique. Pas de claim « 100% Canadian infrastructure » qu'un IT auditor démonterait en trois minutes.

B.3 — Encryption, du bout en bout

# Tester notre grade SSL publiquement :
$ curl -I https://shomerli.com
HTTP/2 200
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: DENY

Vous pouvez vérifier indépendamment notre configuration TLS via SSL Labs ou Mozilla Observatory.

B.4 — Couches API & access control

• ·RBAC. 5 rôles stricts (SUPER_ADMIN, ORG_ADMIN, PARENT, MEMBER, CHILD). Hiérarchie enforced server-side dans le middleware tRPC, vérifiée à chaque appel.
• ·Rate limiting. Redis-based, par IP + par user + par endpoint. Backoff progressif. CAPTCHA après 3 échecs consécutifs.
• ·Input validation. Schemas Zod côté client et serveur. Sanitization HTML. Prisma parameterized queries (anti-SQL injection).
• ·CORS. Origines strictes — domain dashboard + scheme app mobile uniquement.
• ·CSP. Content Security Policy strict (script-src 'self', style-src 'self' + Tailwind, img-src 'self' + CDN).
• ·Dependency scanning. Snyk + npm audit dans CI/CD. Politique : zéro vulnérabilité CRITICAL en production sans hotfix sous 48h.
• ·Audit trail. Table PostgreSQL append-only immuable. Action / user / timestamp / IP / metadata pour chaque action sécurité-relevante. 90 jours hot retention, 7 ans cold archive.

B.5 — Détection des contournements

Une partie de la valeur de Shomerli est sa résistance aux contournements — VPN, proxy, DoH alternatif. Nous ne pouvons pas tout détecter ; voici ce que nous faisons techniquement :

• ✓Détection des connexions VPN (Knox API, mode kernel-level prévu post-activation)
• ✓Détection DoH / DoT vers serveurs non-Shomerli
• ✓Détection des configurations proxy HTTP(S)
• ✓Détection des tentatives de SSL pinning bypass
• ✓Notification temps-réel à l'admin du foyer ou de l'école
• ✓Logs de tentative sans révéler l'identité (privacy-first par défaut)
• ⚠Aucun système de filtrage n'est 100% bypass-proof. Un user déterminé avec accès root au device peut contourner. Notre approche : élever le coût d'effort + détecter rapidement.

B.6 — Audit trail immuable

Tous les events sécurité (login, password change, RBAC change, data export, deletion) sont loggés dans une table PostgreSQL append-only. Pas d'UPDATE ou DELETE possible. Vérifié via DB constraints + tests automatisés.

-- Audit log structure (simplified):
CREATE TABLE audit_log (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  action VARCHAR(100) NOT NULL,
  resource_type VARCHAR(50),
  resource_id UUID,
  ip_address INET,
  user_agent TEXT,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
-- No UPDATE or DELETE permissions granted

Conformité B2B et halakhique.

Frameworks réglementaires, Privacy Officer désigné, plan d'incident response, et engagements contractuels — tous auditable sur demande.

C.1 — Frameworks de conformité

Tous les claims sont auditable. Sur demande pour rabbins ou avocats Vaad : documentation interne complète (DPIA, RoPA, incident response plan).

C.2 — Privacy Officer & contacts

L'article 3.2 de la Loi 25 (Québec) exige qu'une organisation qui collecte des données personnelles désigne une personne responsable de la protection de la vie privée. Pour Shomerli, c'est notre fondateur, en attendant que l'équipe grandisse pour formaliser un DPO indépendant.

C.3 — Réponse aux incidents

En cas de breach ou d'incident de sécurité, le process suivant est appliqué — chaque étape avec un SLA explicite et logué dans l'audit trail :

1. 01

   Containment< 1 h

   Isolation des systèmes affectés. Révocation des credentials potentiellement compromises. Snapshot forensic préservé.

2. 02

   Investigation< 24 h

   Forensic analysis, scope of breach, identification des données touchées et des users concernés.

3. 03

   Notification utilisateurs< 72 h

   Email à tous les users potentiellement affectés (PIPEDA + Loi 25 art. 3.5). Détails de l'incident, données touchées, actions recommandées.

4. 04

   Notification autorités< 72 h

   CAI Québec si requis par Loi 25 art. 3.5. Commissariat à la protection de la vie privée du Canada si applicable.

5. 05

   Post-mortem public< 14 j

   Publication sur /securite#incidents — engagement de transparence. Timeline, root cause, mesures correctives.

Aucun incident de sécurité ne s'est produit à ce jour (Shomerli a 4 mois d'existence). Si cela arrivait, ce process serait suivi et cette page mise à jour publiquement avec un post-mortem.

C.5 — Engagements contractuels

• ✓Pas de vente de données à des annonceurs ou tiers commerciaux.
• ✓Pas de profilage publicitaire — aucun audience-building, aucun look-alike modeling.
• ✓Pas d'utilisation des données pour entraîner des modèles AI tiers. Les données restent dans Shomerli + Anthropic API avec PII redaction.
• ✓Suppression complète à la demande, en moins de 72 heures (limite légale 30 jours Loi 25).
• ✓Export complet à la demande, en moins de 72 heures, format JSON portable.
• ✓Notification 30 jours avant tout changement de privacy policy (Loi 25 art. 8.2).

Vous voulez vérifier nos claims ?

Roadmap publique