Skip to content

Latest commit

 

History

History
309 lines (209 loc) · 8.76 KB

File metadata and controls

309 lines (209 loc) · 8.76 KB

UbiCity Threat Model

Version: 1.0 Last Updated: 2025-11-22 Status: Active

Executive Summary

UbiCity is a privacy-first learning capture system. This threat model identifies security risks, threat actors, attack vectors, and mitigations to protect learner data and system integrity.

Primary Asset: Learning experience data (WHO/WHERE/WHAT) Security Goal: Confidentiality, integrity, availability of learner data


System Architecture

┌─────────────┐
│   Learner   │ (captures experiences via CLI)
└──────┬──────┘
       │
       v
┌─────────────┐
│     CLI     │ (/ runtime)
│ (src/*.ts)  │
└──────┬──────┘
       │
       v
┌─────────────┐
│  Validator  │ (Rust/WASM, )
│   (WASM)    │
└──────┬──────┘
       │
       v
┌─────────────┐
│   Storage   │ (Local JSON files)
│   (./data)  │
└─────────────┘

Threat Actors

1. Malicious Local User

Motivation: Access private learning data, modify experiences Capability: Filesystem access, command execution Likelihood: Medium Impact: High (privacy violation)

2. Malicious Dependency

Motivation: Supply chain attack, data exfiltration Capability: Code execution during install/runtime Likelihood: Low (zero npm dependencies) Impact: Critical

3. Accidental Data Leak

Motivation: None (unintentional) Capability: User error (sharing private data) Likelihood: Medium Impact: Medium (privacy violation)

4. WASM/ Exploit

Motivation: Code execution, memory corruption Capability: Exploit WASM sandbox escape Likelihood: Very Low Impact: High


Attack Vectors & Mitigations

1. Unauthorized Data Access

Threat: Malicious user reads private learning data Attack Vector: - Direct filesystem access to ./ubicity-data/ - Memory dump while CLI running - Shared computer access

Mitigations: - ✅ File permissions (user-only read/write) - ✅ No cloud sync by default (local-only) - ✅ Privacy levels (private/anonymous/public) - ⚠️ Encryption at rest (not implemented - future)

Risk: MEDIUM → LOW (with mitigations)


2. Data Tampering

Threat: Malicious modification of experiences Attack Vector: - Direct JSON file editing - CLI command injection - WASM validator bypass

Mitigations: - ✅ WASM validation (integrity checks) - ✅ permissions (--allow-write limited to data dir) - ✅ compile-time checks - ⚠️ Cryptographic signatures (not implemented - future)

Risk: LOW


3. Supply Chain Attack

Threat: Malicious dependency exfiltrates data Attack Vector: - Compromised npm package - Malicious module - Backdoored compiler

Mitigations: - ✅ ZERO npm dependencies (production) - ✅ JSR registry (cryptographically signed) - ✅ Nix reproducible builds (pinned dependencies) - ✅ GitLab CI verification on every commit - ✅ cargo audit for Rust dependencies

Risk: VERY LOW


4. Command Injection

Threat: Attacker executes arbitrary commands via CLI Attack Vector: - Malicious input in description field - Filename injection (../../etc/passwd) - Shell metacharacters

Mitigations: - ✅ sandboxing (explicit permissions) - ✅ Path validation (no directory traversal) - ✅ Input sanitization (Zod schemas) - ✅ No eval() or dynamic code execution

Risk: VERY LOW


5. Privacy Violation (Accidental)

Threat: User accidentally shares private data Attack Vector: - Exporting with private experiences included - Publishing dataset without anonymization - Sharing visualization with PII

Mitigations: - ✅ Privacy levels enforced in exports - ✅ Anonymization tools (hash IDs, fuzz location) - ✅ PII removal (emails, phones) - ✅ Shareable dataset generator (excludes private) - ⚠️ User education (documentation, warnings)

Risk: MEDIUM


6. WASM Sandbox Escape

Threat: WASM code escapes sandbox, accesses host system Attack Vector: - WASM exploit (CVE in ’s V8 engine) - Unsafe Rust code in WASM module

Mitigations: - ✅ WASM sandbox (linear memory isolation) - ✅ Zero unsafe blocks in Rust code - ✅ cargo clippy enforces safety - ✅ auto-updates (security patches) - ⚠️ Regular dependency updates

Risk: VERY LOW


7. Denial of Service (Local)

Threat: Malicious input causes CLI crash or hang Attack Vector: - Extremely large JSON files - Infinite loops in mapper logic - Memory exhaustion

Mitigations: - ✅ File size limits (implicit via memory) - ✅ Async I/O (non-blocking) - ✅ WASM memory limits - ⚠️ Explicit resource quotas (not implemented)

Risk: LOW


Data Flow Analysis

Capture Flow

User Input →  CLI → WASM Validator → JSON File
    ↓           ↓             ↓              ↓
  [PII?]   [Sanitize]    [Validate]    [Encrypt?]

Threats: - PII in description field → Mitigated by user control
anonymization tools - Path traversal in filename → Mitigated by path validation

Export Flow

JSON Files → Mapper → Privacy Filter → Export (CSV/GeoJSON/DOT)
     ↓          ↓           ↓                  ↓
  [Private?] [Analyze]  [Exclude]         [Share]

Threats: - Private data in export → Mitigated by privacy level enforcement - Location precision → Mitigated by coordinate fuzzing


Security Controls

Preventive Controls

  • ✅ explicit permissions (--allow-read, --allow-write)

  • ✅ WASM sandboxing (linear memory isolation)

  • ✅ Input validation (Zod + WASM validators)

  • ✅ Zero npm dependencies (supply chain risk reduction)

  • ✅ Offline-first (no network calls)

Detective Controls

  • ✅ Security audit script (security/audit.sh)

  • ✅ cargo audit (Rust dependency CVEs)

  • ✅ Trivy filesystem scanner

  • ✅ GitLab CI security checks

  • ✅ Test suite (including security tests)

Corrective Controls

  • ✅ CVE disclosure process (.well-known/security.txt)

  • ✅ Coordinated disclosure (90-day window)

  • ⚠️ Incident response plan (not documented - future)


Privacy-Specific Threats

PII Exposure

Sensitive Data: - Learner names, emails, phone numbers - Precise GPS coordinates (< 100m) - Demographic information

Mitigations: - ✅ Minimal data collection (WHO/WHERE/WHAT only) - ✅ Privacy by default (no demographic fields in schema) - ✅ Location fuzzing (round to ~1km) - ✅ Learner ID hashing (SHA-256) - ✅ PII removal tools (regex-based)

Re-identification Attacks

Threat: Anonymized data re-identified via correlation Example: Unique location + timestamp + domain → identifies individual

Mitigations: - ✅ k-anonymity consideration (documentation) - ⚠️ Automated k-anonymity checks (not implemented - future)


Compliance

Privacy Regulations

  • GDPR (EU): ✅ Data minimization, privacy by design

  • CCPA (California): ✅ User data ownership (local storage)

  • COPPA (US, children): ⚠️ Age-gated features (not implemented)

Security Standards

  • OWASP Top 10: ✅ Mitigations for injection, broken access control

  • CWE Top 25: ✅ No common weaknesses (verified via Clippy)


Future Enhancements

  1. Encryption at rest (AES-256 for sensitive fields)

  2. Cryptographic signatures (verify data integrity)

  3. External security audit (penetration testing)

  4. Bug bounty program (coordinated vulnerability disclosure)

  5. Incident response plan (documented procedures)

Optional

  • Multi-factor authentication (if adding sync features)

  • End-to-end encryption (for shared datasets)

  • Audit logging (immutable append-only log)


Threat Model Maintenance

Review Cadence: Quarterly or on major releases Owner: Maintainers (see MAINTAINERS.md) Process: 1. Identify new features/changes 2. Enumerate new threats 3. Assess risk (likelihood × impact) 4. Implement mitigations 5. Update this document


Responsible Disclosure

Found a vulnerability? See .well-known/security.txt

  • Contact: security@ubicity.example.org

  • PGP Key: [Future: public key]

  • Disclosure Policy: 90-day coordinated disclosure

  • Bounty: No cash bounty (community project)


References


Document Classification: Public Version History: - v1.0 (2025-11-22): Initial threat model for Platinum RSR tier