Security & Threat Model · Trent Power
Author: Trent Power
Description: Security architecture, operational controls, public verification surfaces and residual risks

Skip to content

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

Browser
  HTTPS · no cookies · no analytics
Static host
  Apache · Gandi · Paris · SFTP deployment
Site files
  HTML · CSS · vanilla JS · self-hosted fonts
Offline cache
  Service worker · local cache after first visit
Trust
  Integrity · Verify · Source · Releases
Archive
  Frozen signed releases

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.

### Delivery & freshness

- A stale but validly-signed release served in place of a newer one
- A poisoned or stale browser / service-worker cache on the client

## 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), a first-visit marker that retires 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.

### Operator assumptions

- A single trusted author controls the source and each release
- The only private signing key lives on the author's local machine, never in CI
- That machine's integrity is assumed; a compromise there is out of scope
- Readers confirm the key fingerprint out of band before trusting a signature

## 7. Disclosure

Responsible disclosure is welcome. Security contact details and encrypted communication instructions are published at `/.well-known/security.txt`.

Read the security.txt disclosure policy for this site

## 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/`.

## 10. Accessibility

The site targets WCAG 2.2 AA. Each published edition's signed test snapshot records an automated accessibility check, and keyboard navigation, landmark structure and focus order are verified by hand. Known exceptions are listed here rather than implied; none are currently asserted.

01 Architecture

Static HTML, CSS, vanilla JavaScript. Self-managed deployment on Apache (Gandi, Paris). No public database.

02 Security headers

CSP default-deny. HSTS. COOP / COEP / CORP. Referrer-Policy no-referrer. Locked-down Permissions-Policy.

03 Assets protected

Identity. Published content. Public verification files. Source integrity.

04 Threat model

Content injection. Hosting credential compromise. Spoofed identity. Stale or tampered files.

05 Controls

No third-party scripts. No public forms. Signed integrity manifest. Restricted file exposure. Service-worker-controlled cache.

06 Residual risk

Hosting and registrar risk remain. Static-site exposure is reduced, not eliminated. Responsible disclosure route is published.

Under Construction