Threat Model
Current status: high-level model for the planned platform. Detailed analysis and security review are deliverables of the reference Runtime development cycle — not yet completed.
This page summarises trust boundaries, assets, and threats for Faberio at a high level. It supports operator decisions and future hardening work. It is not a formal security audit.
Scope and assumptions
In scope: Faberio information spaces — peer networks of nodes that may include participants' personal devices (smartphones, tablets, laptops, personal computers) and always-on servers run by users or independent operators, synchronising state through background replication, with cryptographic identity and administrator approval for nodes and users. The current scope validates a Federated Community Hub demo on NixOS-hosted server runtimes.
Out of scope for this document: formal penetration test results, external federation protocol security, Flutter mobile Runtime (Phase 4), and nation-state adversary models.
Assumptions:
- Operators control their nodes and choose who receives approved membership.
- Private keys remain on nodes and user devices; they are not replicated in the database.
- Applications use the SDK or HTTP API; they do not initiate cross-node data operations directly.
- The Community Hub demo is accessed over HTTPS in validation environments.
Assets
| Asset | Owner | Protection goal |
|---|---|---|
| Node private keys | Operator | Confidentiality; used for node-level replication and peer auth |
| User private keys | User device | Confidentiality; used for authentication and user-level replication |
| Replicated database and files | Information space participants | Integrity and confidentiality per Data Access Control |
| Approval state (node/user status) | Administrators | Integrity — only approved members sync or access shared data |
| Operator infrastructure | Operator | Availability of 24/7 nodes; patching via NixOS/container updates |
Trust boundaries
- Inside: approved nodes and users in the same information space, enforcing DAC locally.
- Outside: unapproved peers, arbitrary Internet attackers, compromised credentials without valid keys.
Faberio does not assume all nodes globally are trustworthy — only explicitly approved members of a space.
No tracking or exploitation
Faberio is designed so everyday services can run without tracking and without exploitation of users. The platform is infrastructure for self-hosting, not a centralized SaaS product with a surveillance or advertising business model.
Platform posture
The reference Runtime and Faberio Protocol are designed so that:
| Principle | Requirement |
|---|---|
| No mandatory vendor telemetry | The reference Runtime MUST NOT phone home to Faberio or any third-party analytics service by default. |
| No behavioral profiling | The platform MUST NOT build cross-user advertising or attention profiles from replicated application data. |
| No data exploitation | Participant content and metadata in an information space MUST NOT be mined, sold, or licensed to third parties by the platform layer. |
| Operator sovereignty | Each operator runs their own node(s). Operational logs and metrics the operator enables stay under operator control unless the operator explicitly exports them. |
| Open inspection | Reference Runtime source will be published under Apache-2.0 so operators and auditors can verify the above. |
Local operational telemetry — replication lag, connectivity warnings, disk usage, structured logs for debugging — MAY exist on the node for the operator's maintenance. Such data MUST NOT be transmitted to a central Faberio service by default and MUST NOT include application message content unless the operator configures explicit export.
Applications and the web demo
Applications on Faberio choose their own policies. A third-party app MAY implement analytics; that is an application concern, not a platform requirement. Operators decide which applications run on their nodes.
The Federated Community Hub demo (reference validation application) MUST NOT embed third-party trackers (advertising pixels, social widgets, external analytics SDKs). Any usage measurement in the demo MUST be local or operator-configured and documented in operator materials.
Contrast with vertical SaaS
| Vertical SaaS | Faberio platform |
|---|---|
| Vendor hosts data and application | Operator hosts Runtime; data stays in the information space |
| Terms may permit profiling and resale | No platform-layer exploitation; DAC governs access |
| Users depend on vendor uptime and policy changes | Users and operators control membership, policies, and infrastructure |
This posture supports data decoupling and user control described in Application Examples — Service portability and data decoupling and Sustainability.
Threat summary
| Threat | Description | Mitigations (planned / specified) |
|---|---|---|
| Unauthorised access to data | User or node reads/writes without permission | Cryptographic authentication; admin approval gate; DAC default-deny; source-side policy enforcement before data leaves the origin node; local enforcement on every replica |
| Unapproved node joining | Hostile node syncs full space | Node membership pending/rejected until admin approved; no node-level replication before approval (Node Discovery) |
| Unapproved user access | Registered but not approved user | User status check before policy evaluation (Data Access Control) |
| Key compromise | Stolen node or user private key | Key rotation and revocation (operator procedures); scope limited to identities held by compromised key |
| Replication tampering | Malicious or corrupted replica | Ed25519 signatures on protocol operations; trusted-peer model within approved membership |
| Network interception | MITM on node or client traffic | TLS for client access; encrypted peer connectivity per Node Connectivity |
| Untrusted or unavailable relay | Operator uses malicious TURN, or all relays fail | Policy-controlled STUN/TURN lists; no silent public fallback when disabled; relay degraded mode and queued sync (Node Connectivity) |
| Denial of service | Flooding nodes or blocking sync | Operator-controlled rate limits and infrastructure; P2P + optional 24/7 anchor — not full DDoS immunity |
| Insider administrator abuse | Space admin approves malicious actors or over-broad access | Governance model — admins are trusted for membership; DAC limits data scope per user |
| Supply chain / dependency risk | Vulnerable Runtime dependencies | CI, dependency updates, basic security review (M3 deliverable) |
| Surveillance / vendor exploitation | Platform or demo exfiltrates usage or content for ads or third-party analytics | No mandatory vendor telemetry; no platform-layer profiling or data sale; open-source reference Runtime; demo without third-party trackers (No tracking or exploitation) |
| Web demo security | XSS, CSRF on Community Hub UI | Standard web hardening; security review scoped to demo |
Non-goals (current cycle)
- End-to-end encryption (E2EE) between users as in Signal — not claimed; access control is platform DAC on replicated state, not double-ratchet messaging.
- Byzantine fault tolerance across mutually suspicious operators — trust is administrator-gated membership, not proof-of-work or BFT consensus.
- External federation protocol security — out of current scope.
Security deliverables
The reference Runtime cycle includes basic security review of the server Runtime, replication paths, and Federated Community Hub demo, alongside CI and operator documentation. Findings feed spec updates (Phase 1) and maintenance priorities described in Sustainability.