1. What the architecture guarantees

1. Data minimisation. Each service keeps only the fields listed in our Privacy Policy. A new field cannot launch without a data-map entry and a policy update first.
2. On-device processing. Re·UI reads the hand on the phone; only numbers and words leave it. Meta DAX learning records are built and saved on your device.
3. Encryption in transit. All our sites use HTTPS; plain HTTP is redirected, and daxfoundation.org tells browsers to use HTTPS only. Our providers encrypt stored data at rest.
4. Least-privilege access. Administration pages are behind Cloudflare Access with Google sign-in and an allow-list of administrator addresses, and our own code verifies the Access token again before showing anything.
5. Secrets never in code. Keys and tokens are generated inside our build system (for example with a random generator in the build runner), bound directly as encrypted secrets, and never printed. Only their names are ever listed.
6. Per-room keys, stored as hashes. A Re·UI room created with a key stores only the key’s SHA-256 hash. Without the key, the room’s records stay closed.
7. Logs kept small. No IP address is stored with a form entry; spam limits use a salted hash per hour, deleted after two hours; technical logs are kept for days, not months.
8. No third-party trackers. Cookieless analytics only; pages that ask for consent load none.
9. Takedown that holds. A room that is taken down answers “gone” to everyone, administrators included.
10. Release gates. Every publication of this site runs automated checks before it goes live (for example: no unsupported claims, no trackers on consent pages, every page linked to these policies). A failed check stops the release.
11. Public source. The source of this site is published at github.com/ObsidianDelta/published.

2. Known limits, stated plainly

• Data is stored by Cloudflare, mainly in the United States. There is no Canadian data residency today.
• Re·UI room records have no automatic deletion period yet (deletion on request). Automatic periods come before any school use.
• Re·UI downloads its hand-reading software from Google’s and jsDelivr’s servers.
• If your browser cannot recognise speech on the phone, it uses its own speech service (in Chrome, Google’s). Turn voice off to avoid that.

3. Reporting a vulnerability

Write to [email protected] with “Security” in the subject. Please include what you found, where (address, steps to reproduce), what an attacker could do with it, and how to reach you. English or French. Our machine-readable contact file is at /.well-known/security.txt.

Scope

• daxfoundation.org and every *.daxfoundation.org service we run, including re.ui.research.daxfoundation.org, research.daxfoundation.org and approve.daxfoundation.org;
• the Re·UI relay service our pages connect to;
• our public source code.

Out of scope: the services of our providers themselves (report those to them), denial-of-service and load testing, social engineering of people, physical attacks, spam, and reports from automated scanners with no demonstrated impact.

Rules for good-faith research

• Only test against your own rooms, entries and data. Do not access, change or delete anyone else’s data; if you reach some by accident, stop, do not keep it, and tell us.
• Do not degrade the services for other people.
• Give us a reasonable time to fix the issue before telling anyone else; we will agree on a date with you.

Safe harbour

If you follow these rules, we consider your research authorised, we will not take legal action against you, and we will not ask anyone else to. If someone else does, we will make it known that you acted with our authorisation.

Our response targets

• Acknowledgement: within 3 business days.
• First assessment: within 10 business days.
• Fix: critical issues within 7 days, high within 30 days, others within 90 days, or sooner when we can.
• We keep you informed and, if you wish, credit you by name when the fix is public. We do not offer payment for reports.

4. Incidents

When an incident happens we contain it first, then assess what was affected. If personal information is involved, we follow the breach section of the Privacy Policy: we notify the people affected and the authorities when the law requires it, and we keep a record of every incident for at least 24 months.

5. How this policy evolves

This is version 1.0, in force since 5 November 2026. It changes together with the Privacy Policy, under the same rules: every new service is reviewed for security before it launches, the policy is reviewed every quarter (next: 5 February 2027), and every change is listed on the changelog. The security.txt file carries an expiry date and is renewed before it lapses.

1. Ce que l’architecture garantit

1. Minimisation des données. Chaque service ne garde que les champs listés dans notre Politique de confidentialité. Un nouveau champ ne peut pas être lancé sans entrée dans la carte des données et mise à jour de la politique d’abord.
2. Traitement sur l’appareil. Re·UI lit la main sur le téléphone ; seuls des nombres et des mots en sortent. Les dossiers d’apprentissage Meta DAX sont construits et enregistrés sur votre appareil.
3. Chiffrement en transit. Tous nos sites utilisent HTTPS ; le HTTP simple est redirigé, et daxfoundation.org demande aux navigateurs de n’utiliser que HTTPS. Nos fournisseurs chiffrent les données stockées.
4. Accès au strict nécessaire. Les pages d’administration sont protégées par Cloudflare Access avec connexion Google et une liste d’adresses d’administration autorisées, et notre propre code vérifie de nouveau le jeton d’accès avant d’afficher quoi que ce soit.
5. Jamais de secrets dans le code. Les clés et jetons sont générés dans notre système de construction (par exemple par un générateur aléatoire dans l’exécuteur de construction), liés directement comme secrets chiffrés, et jamais affichés. Seuls leurs noms sont listés.
6. Une clé par salle, stockée en hachage. Une salle Re·UI créée avec une clé ne garde que le hachage SHA-256 de la clé. Sans la clé, les dossiers de la salle restent fermés.
7. Des journaux réduits. Aucune adresse IP n’est gardée avec une inscription ; les limites anti-pourriel utilisent un hachage salé par heure, effacé après deux heures ; les journaux techniques sont gardés quelques jours, pas des mois.
8. Aucun traceur tiers. Seulement une mesure d’audience sans témoins ; les pages qui demandent un consentement n’en chargent aucune.
9. Un retrait qui tient. Une salle retirée répond « disparue » à tout le monde, administrateurs compris.
10. Contrôles avant publication. Chaque publication de ce site passe des vérifications automatiques avant d’être en ligne (par exemple : aucune affirmation non fondée, aucun traceur sur les pages de consentement, chaque page liée à ces politiques). Une vérification échouée arrête la publication.
11. Code public. Le code de ce site est publié à github.com/ObsidianDelta/published.

2. Limites connues, dites simplement

• Les données sont stockées par Cloudflare, surtout aux États-Unis. Il n’y a pas de résidence des données au Canada aujourd’hui.
• Les dossiers des salles Re·UI n’ont pas encore de durée d’effacement automatique (effacement sur demande). Des durées automatiques viendront avant toute utilisation scolaire.
• Re·UI télécharge son logiciel de lecture de la main depuis les serveurs de Google et de jsDelivr.
• Si votre navigateur ne peut pas reconnaître la parole sur le téléphone, il utilise son propre service vocal (dans Chrome, celui de Google). Coupez la voix pour l’éviter.

3. Signaler une vulnérabilité

Écrivez à [email protected] avec « Sécurité » dans l’objet. Indiquez ce que vous avez trouvé, où (adresse, étapes pour reproduire), ce qu’un attaquant pourrait en faire et comment vous joindre. En français ou en anglais. Notre fichier de contact lisible par machine est à /.well-known/security.txt.

Portée

• daxfoundation.org et chaque service *.daxfoundation.org que nous exploitons, dont re.ui.research.daxfoundation.org, research.daxfoundation.org et approve.daxfoundation.org ;
• le service de relais Re·UI auquel nos pages se connectent ;
• notre code source public.

Hors portée : les services de nos fournisseurs eux-mêmes (signalez-les-leur), les attaques par déni de service et les tests de charge, l’ingénierie sociale visant des personnes, les attaques physiques, le pourriel et les rapports d’outils automatiques sans impact démontré.

Règles de la recherche de bonne foi

• Ne testez que vos propres salles, inscriptions et données. N’accédez pas aux données d’autrui, ne les modifiez pas et ne les effacez pas ; si vous en atteignez par accident, arrêtez, ne les gardez pas et dites-le-nous.
• Ne dégradez pas les services pour les autres.
• Laissez-nous un délai raisonnable pour corriger avant d’en parler à d’autres ; nous conviendrons d’une date avec vous.

Protection juridique (« safe harbour »)

Si vous suivez ces règles, nous considérons votre recherche comme autorisée, nous n’intenterons aucune poursuite contre vous et ne demanderons à personne de le faire. Si quelqu’un d’autre le fait, nous ferons savoir que vous avez agi avec notre autorisation.

Nos délais de réponse

• Accusé de réception : dans un délai de 3 jours ouvrables.
• Première évaluation : dans un délai de 10 jours ouvrables.
• Correction : problèmes critiques en 7 jours, élevés en 30 jours, autres en 90 jours, ou plus tôt si possible.
• Nous vous tenons informé et, si vous le souhaitez, vous nommons quand la correction est publique. Nous n’offrons pas de paiement pour les signalements.

4. Incidents

Lors d’un incident, nous le contenons d’abord, puis évaluons ce qui a été touché. Si des renseignements personnels sont en cause, nous suivons la section sur les atteintes de la Politique de confidentialité : nous avisons les personnes touchées et les autorités lorsque la loi l’exige, et nous tenons un registre de chaque incident pendant au moins 24 mois.

5. Comment cette politique évolue

Ceci est la version 1.0, en vigueur depuis le 5 novembre 2026. Elle change avec la Politique de confidentialité, selon les mêmes règles : chaque nouveau service est examiné du point de vue de la sécurité avant son lancement, la politique est révisée chaque trimestre (prochaine : 5 février 2027), et chaque changement est inscrit au journal des modifications. Le fichier security.txt porte une date d’expiration et est renouvelé avant qu’elle arrive.