V3.1 → V3.12 consolidated and tagged for the first GA release. Wire format unchanged from 0.4.x — 4.0 peers interoperate with 0.4.x peers byte-for-byte. The version bump is semantic: audit-cycle complete, opt-in surface fully exposed, threat model refreshed for every new surface. Highlights: - All 24 @shade/* packages bumped to 4.0.0 in lockstep. - CHANGELOG 4.0.0 section is the canonical manifest of what landed. - THREAT-MODEL extended (§10 fingerprint gates, §11 WebRTC P2P, §12 Web-Worker boundary) + residual-risks table refreshed. - OpenAPI now covers all 27 routes: prekey, transfer, KT, inbox, bridge, observer, /metrics, /healthz, /ready. - MIGRATION 0.3.x → 4.0 documented + smoke-tested against shade migrate-storage on a real SQLite DB. - docs/audit/REVIEW-BUNDLE.md + SCOPE.md ready for external reviewer. - scripts/soak.ts harness for the GA-stable 2-week soak window. - All V*.md plans archived under docs/archive/ with Status: Done. - Voice/Video carved out into V5.0; 4.0 audit focuses on the frozen non-realtime stack. Tests: TS 1000/1000 + Kotlin 11/11 cross-platform vectors green. Docker: gt.zyon.no/stian/shade-prekey:4.0.0 builds and reports version 4.0.0 on /health. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.6 KiB
Shade V2.3 — Tillit, retention, integrasjon og observability
Dette dokumentet beskriver høyere ambisjonsnivå og plattformkryssende arbeid: brukertilfeller der tillit må være eksplisitt, data må utkrympes/ryddes automatisk, apper må enkelt koble seg på kjente transportmønstre, og drift må observere uten å lekke innhold.
1. Key transparency / bundle-attestasjon eller kritiske fingerprint-øyeblikk i UI
Dette kan sees som to spor samme mål: redusere tillit til én korrumperbar prekey-server uten brukerens merknad.
Spor A — Key transparency / bundle-attestasjon (ambisiøst)
Idé: Logging av hvilket bundle som ble utlevert når, kryptografisk forankret og verifiserbar av klienter eller tredjeparts-audit (inspirert av KT-litteratur, tilpasset Shade sin trusselmodell).
Leveranser (målpris høyt):
- Trusselmodell-oppdatering: hva CT/attest løser vs fortsatt MITM før første verifisering.
- Designnotat: datastruktur, friskhetsbevis, klient-verifikasjonssteg, operatørkost.
Risiko: Kompleks drift og kryptodesign — bør være valgfritt lag for motiverte deploys.
Spor B — Fingerprints i app-UI på kritiske hendelser (pragmatisk)
Idé: Gjør safety numbers synlige og handlingspålagte i presiserte flyt:
- Før første stor fil (eller før første stream over terskel i bytes).
- Før «trust this device» / backup-importer / ny enhet som gjenbruker identitet.
Leveranser:
@shade/widgets+ SDK-hooks: modal/sheet med fingerprint, kopier-OOB-tekst, «jeg har verifisert».- Dokumenterte UX-retningslinjer (unngå «alert fatigue» kun på lave risiko-events).
Felles akseptansekriterier
Enten spor A eller B må ha eksplisitt testcoverage på «blokkerer/handhever verifisering» der det er lovet, og trusselmodellen må nevne kombinasjonen av OOB + tekniske grep.
2. Retention policies
Vision: Standardiserte TTL- og oppryddingsregler for data Shade-økosystemet etterlater på server eller i klient-lagring — spesielt:
- Stream-state og midlertidige chunk-referanser etter fullførte/avbrutte transfers.
- Eventuell inbox/relay-ciphertext (
V2.2). - Prekey-server: kobling til eksisterende
SHADE_STALE_DAYS/ cleanup, plus policy-dokumentasjon for operatører.
Leveranser:
- Default-anbefalinger (f.eks. «ferdige streams: prune etter N dager») i
@shade/storage-*helpers eller server-factory. - Konfigurerbare hooks:
maxAge,maxBytesPerIdentity, cron vs on-access prune.
Akseptansekriterier: Ingen «uendelig vekst» som default i nye templates; dokumentert adferd i streams.md / deployment.
3. Ferdig «bridge» (transport)
Vision: Apper som ikke kan eller vil bruke WebSocket, får ferdig mønster for mottak av små meldinger eller kontroll-signaler.
Eksempler:
- Server-Sent Events (SSE) som ren ciphertext-pipe eller som signal «hent fra inbox» uten plaintext på server (kombinasjon med
V2.2). - Lang-poll fallback dokumentert ved siden av WS i
@shade/transport.
Leveranser:
- Modulær
bridge-pakke eller tydelig undermodul med få eksponerte typer og én fellesIncomingMessage-modell på klient.
Akseptansekriterier: Ett fungende eksempel + test som viser dekryptering likt eksisterende transport.
4. Observability
Vision: Produksjonsteam får målepunkter og spor uten innholdslekkasjer eller kryptomatrise i logger.
Forslag til innhold:
- Metrics (Prometheus-stil eller vendor-nøytralt): opplastings-/nedlastings-varighet, lane-telling, retry counts, abort vs complete rates, HTTP/WS-feilkoder (aggregert).
- OpenTelemetry: spans rundt
TransferEngineog prekey-endepunkter (uten payload-lengde i klartekst som PII — bruk binære størrelser eller binning). - Sampling og PII-policy dokumentert (ikke logg adresser i full hvis compliance krever maskering).
Akseptansekriterier: Opt-in flags (default av i lib, på i server-container der det gir mening), og docs/ avsnitt om hva som aldri skal logges.
Prioritering mot V2.1 / V2.2
| Dette dokument (V2.3) | Naturlig forutsetning |
|---|---|
| Retention | Streams/transfer i bruk (V2.1 §5, V2.2 metadata) |
| Bridge | V2.2 store-and-forward eller egen meldingskanal |
| UI fingerprints | Widgets/SDK allerede i bruk |
| KT / attest | Moden trusselmodell + juridisk/operativ vilje |
| Observability | Stabil nok intern API for hooks |
Versjonering
- V2.3 — første samlet plan for tillit, retention, bridge og observability. Splitt i ADR-er når konkret design er valgt.