') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Document user-data trust boundaries and decide the E2EE architecture · Issue #312 · OpenMapX/openmapx · GitHub
Skip to content

Document user-data trust boundaries and decide the E2EE architecture #312

Open
Open
Document user-data trust boundaries and decide the E2EE architecture#312
Labels
enhancementNew feature or requestneeds-triageNeeds initial review and categorization

Description

@Medformatik
Medformatik
opened on Aug 31, 2026

Problem

OpenMapX is adding increasingly sensitive user data: timeline connections, saved places/routes, parked location, public/private sharing, and potentially live location. “Use E2EE” is not yet an implementable requirement because server-side search, routing, sharing, recovery, self-hosting, and multi-device sync impose different trust and key-access needs.

Current state

  • Service credentials and linked-account tokens have server-side encryption-at-rest paths.
  • Dawarich timeline data passes through the application server.
  • Mangrove review signing keys support client-side passphrase/WebAuthn wrapping, but only for that keypair use case.
  • Better Auth/passkeys protect authentication; they do not provide general user-data E2EE.
  • SECURITY.md exists, but there is no comprehensive user-data inventory or trust-boundary/cryptography ADR.

Proposed solution

Publish a user-data trust model and an E2EE feasibility ADR before implementing a general encryption layer. Inventory data flows and classify which fields need confidentiality from other users, operators, backups, infrastructure providers, or a compromised server. Evaluate a client key hierarchy, device enrollment, passkey-assisted wrapping, recovery, sharing, and migration against concrete product operations.

Acceptance criteria

  • A data inventory covers accounts, saved content, routes, vehicles/parking, timeline, integration credentials, reviews, shares, social graph, and live location.
  • For each item, document storage, processors, logs/caches/backups, retention, deletion, current encryption, and required server operations.
  • Threat actors and trust boundaries distinguish hosted, self-hosted, database-only, operator, infrastructure, stolen-device, and compromised-server scenarios.
  • Existing at-rest, TLS, passkey, token-vault, and Mangrove protections are described accurately without calling them E2EE.
  • Candidate client key hierarchy covers devices, rotation, revocation, backup/recovery, account reset, and loss of every device.
  • The ADR evaluates passkey PRF/WebAuthn wrapping portability and a non-passkey recovery path.
  • A feature matrix identifies which search, sync, sharing, federation, notifications, and server processing remain possible for each encryption option.
  • Metadata leakage, traffic analysis, key directory authenticity, replay, rollback, and malicious-client behavior are considered.
  • Migration/versioning and cryptographic agility are specified; custom cryptographic primitives are explicitly prohibited.
  • The decision records fields to encrypt now, fields to defer, and conditions for a full E2EE implementation issue.
  • User-facing privacy/security documentation matches the selected trust model.
  • Security review/sign-off is required before implementation begins.

Alternatives considered

Declaring all user data E2EE without a processing/recovery model would be misleading. Relying only on disk/database encryption does not address operator or application-server access.

Area

Security architecture, accounts, storage, sync, documentation.

Non-goal

This issue produces an auditable decision and bounded follow-up work; it does not implement a new cryptosystem.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-triageNeeds initial review and categorization

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions