# IF.TTT Security Hardening — Public Summary (IF.ARMOUR crossover)

**Author:** InfraFabric Research  
**Status:** Summary (safe to share)  
**Updated:** 2025-12-29  
**Version:** 1.3 (summary)  
**Citation:** `if://doc/ifttt-security-hardening-summary/v1.3`  

This is a **public summary** of the internal hardening proposal:
- Internal full paper: `if://doc/ifttt-security-hardening/v1.3`
- This summary intentionally omits operator details (hostnames, container IDs, internal network layout).

## What problem this solves (black/white)

IF.TTT’s job is to publish receipts that survive skepticism:
- A source artifact → `source_sha256`
- An output artifact → `output_sha256`
- A trace record binding them → `trace_id` + public `shareId`
- Optional offline bundles → `lightweight` / `standard` / `full`

Hardening is necessary because IF.TTT is exposed to adversarial pressure:
- spam and resource exhaustion
- scraping and tampering attempts
- epistemic attacks (“make the receipts look unreliable”)
- signer/key compromise attempts (the highest-value target)

Hardening does **not** mean “unhackable.” It means:
- failures are detected early
- damage is contained
- compromised components can be isolated
- receipts remain explainable and verifiable

## The hostile-world assumption (required)

Operate as if:
- clients are adversarial
- the network is hostile
- servers will eventually have unknown vulnerabilities
- the goal is to protect the **signing process** and preserve an auditable record

## IF.ARMOUR → IF.SECURITY.* (naming)

“IF.ARMOUR” is the research umbrella for adversarial hardening patterns.

In the product naming system, these patterns surface as:
- `IF.SECURITY.DETECT` — detect abuse/anomaly patterns
- `IF.SECURITY.CHECK` — validate inputs, policies, integrity
- `IF.SECURITY.WATCH` — liveness/drift checks + escalation rules
- `IF.SECURITY.TRAP` — honeypots/tarpits/deception

## Control themes (what gets hardened)

### 1) Economic defenses (rate limits + PoW)

Goal: make bulk abuse expensive while keeping normal users fast.

Mechanisms:
- per-route rate limiting on public surfaces
- “proof-of-work” challenges for suspicious upload paths (optional, adaptive)

### 2) Honey-traces (canary receipts)

Goal: detect scrapers and receipt poisoning attempts by publishing decoy shareIds and measuring interaction patterns.

Mechanisms:
- decoy receipts that look valid but are tagged internally
- automated triage when decoys are accessed at scale

### 3) Tarpits / time vampires

Goal: consume attacker resources (time, concurrency) while extracting behavioral signals.

Mechanisms:
- deliberate slow paths for suspicious clients (bounded)
- jitter and challenge escalation for repeated probing

### 4) Swarm-Lock + Purgatory Protocol (containment)

Goal: if a component is suspected compromised or desynchronized, **freeze** before poisoning receipts.

Mechanisms:
- liveness checks and quorum-based gating for critical state
- “lock” mode that halts signing/publishing
- “purgatory” mode that isolates and requires explicit rejoin validation

### 5) Backups and survivability (two realities)

Reality A (single-host prototype):
- local backups and snapshots are adequate for early-stage iteration

Reality B (portable production profile):
- tiered backups (hot/warm/cold)
- optional replication to a secondary host (or later to cloud object storage)
- recovery procedures documented as part of the trust model

### 6) Verifier supply-chain hardening

Goal: the offline verifier must be trusted.

Mechanisms:
- publish hashes for verifier artifacts
- optionally sign verifier releases
- keep “what is verified” vs “what is not” explicit in tool output

## What to expect (deployed vs planned)

Deployed (proof layer):
- public receipts + stable no-login aliases
- hash binding + signatures (including PQ receipts when available)
- offline verification path via triage bundles + verifier tooling

Planned (hardening layer):
- honey-traces and deception
- adaptive PoW + tarpits for abusive clients
- Swarm-Lock/Purgatory containment
- stronger backup tiers and survivability procedures

## Why this matters

Without hardening, public receipts can become a new kind of theater:
- visible, but easy to undermine
- impressive, but fragile under adversarial pressure

With hardening, IF.TTT becomes:
- boring to operate
- legible to reviewers
- resilient under skepticism and abuse