Security & Threat Model
Static.Self-managed.Verification-led.
How this site is hosted, what it protects, what it doesn't - and how anyone can verify it independently.
1. Architecture
Architecture
Public inspection routes expose the signed manifest, page records, readable source mirrors and archived releases without exposing private infrastructure.
2. Assets protected
The controls described here protect:
- Domain ownership
- DNS integrity
- Hosting account integrity
- Public content integrity
- The signing key used for release authenticity
3. Threat model
Infrastructure compromise
- Registrar account takeover
- DNS hijack
- Hosting credential compromise
Content tampering
- Post-deployment file modification
- Malicious JavaScript injection
- Silent alteration of static assets
Administrative abuse
- Credential stuffing
- Automated vulnerability scanning
Commodity internet noise
Continuous automated probing for common CMS paths, configuration files, or known endpoints. These are treated as persistent background conditions rather than exceptional events.
4. Controls
Registrar & DNS
- MFA enabled
- Registrar lock active
- DNSSEC enabled and validated
- CAA records restrict certificate issuance
Hosting
- Multi-factor authentication enabled
- SFTP-only deployment
- No SSH shell exposure
- No scheduled background execution
Public content
- Static architecture reduces server-side attack surface
- Strict CSP starting from
default-src 'none' - No external resource loading
- No dynamic script execution
- Local browser storage limited to reader preferences (language, appearance), first-visit markers that retire the homepage imprint and the French machine-translation notice, and service-worker install timestamps used solely to display when the offline cache was last refreshed; readable on the Local Device Console; no cookies, no analytics or advertising identifiers, no session tracking or behavioural profiling
Monitoring
- Structured log analysis
- Pattern detection and anomaly scoring
- File integrity drift detection against the signed release baseline
5. Public verification surface
Inspection routes
The site exposes public inspection routes so published content can be checked without private infrastructure access.
/integrity/records signed releases, public key and manifest/verify/records one page’s canonical URL, source mirror and fingerprint/source/publishes readable mirrors of selected public files/integrity/releases/preserves frozen signed snapshots
What it does not cover
These routes support inspection and provenance. They do not remove the need to protect DNS, hosting credentials and the private signing key.
6. Residual risk
This model protects the public static site. It does not protect against registrar compromise, hosting compromise, client-device compromise or private key compromise.
Out of scope
This model does not attempt to address:
- Physical compromise of hosting infrastructure
- Global DNS root compromise
- Certificate authority (CA) compromise
- State-level adversaries
- Zero-day browser exploits on client devices
Where the risk concentrates
The main risks remain domain, DNS, hosting and private key compromise.
7. Disclosure
Responsible disclosure is welcome. Security contact details and encrypted communication instructions are published at /.well-known/security.txt.
8. Design principles
- Simplicity over complexity
- Deterministic behaviour over dynamic systems
- Transparency over obscurity
- Verifiable integrity over trust assumptions
9. Verification & Testing
Per-edition checks
Every published edition is checked against a fixed set of public targets. The checks cover availability, privacy, security headers, accessibility, SEO and markup, and the result is recorded as a signed snapshot alongside the edition.
View the latest test results at /tests/.
