Privacy Architecture
How Your Privacy is Protected
A detailed look at how Remain Faithful processes content without compromising your privacy — from device to partner notification.
The Two-Tier On-Device Classification Pipeline
Every screen frame is classified entirely on your device. No screen content is ever sent off-device — only alert metadata (category, severity, summary, timestamp) is uploaded.
Your Device Captures a Screen Frame
Apple's ReplayKit creates a sandboxed broadcast extension process. All classification happens on-device. When a frame is flagged, only the alert metadata — category, severity, and a static summary — is uploaded. Screen content, OCR text, and screenshots are never transmitted.
Rules: URL Blocklist + Keyword Matching
Known adult domains are checked against a local blocklist. Visible text is pattern-matched against regex rules. Fast, deterministic, 100% on-device. No AI required.
On-Device AI: Apple SensitiveContentAnalysis + Vision OCR + Text Classifier
Apple Vision OCR extracts text; SensitiveContentAnalysis detects explicit imagery; a local keyword classifier scores the result. All three run on the device's Neural Engine — the dedicated AI chip in modern iPhones. No server involved at any stage.
Discreet Alert Delivered to Partners
Partners receive: category label (e.g., 'Adult Content'), severity level, and timestamp. Never a screenshot. Never your browsing history. Never raw content. The open-source code lets anyone verify exactly what is uploaded.
What We Can See vs. What We Cannot See
The architecture enforces these limits, not just our policies.
| Data type | Remain Faithful server | Your partners |
|---|---|---|
| Screenshots / screen frames | ✗ Never | ✗ Never |
| Raw screen content or text | ✗ Never | ✗ Never |
| Browsing history or URLs | ✗ Never | ✗ Never |
| App usage details | ✗ Never | ✗ Never |
| Passwords or financial data | ✗ Never | ✗ Never |
| Message content | ✗ Never | ✗ Never |
| Photos and videos | ✗ Never | ✗ Never |
| Alert category (e.g. "Adult Content") | ✓ Encrypted metadata | ✓ Yes |
| Severity level (Low / Medium / High) | ✓ Encrypted metadata | ✓ Yes |
| Timestamp | ✓ Encrypted metadata | ✓ Yes |
| System-generated description | ✓ Encrypted metadata | ✓ Yes |
| Your name and email (account info) | ✓ Encrypted at rest | ✗ No |
Data Flow Diagram
How a flagged event travels from your device to your partner's notification — with encryption at every step.
Your Device
Screen frame classified locally
Alert Metadata
Category + severity only
RF Server
Encrypted at rest (AES-256)
APNs
Apple Push (TLS 1.3)
Partner's Device
Notification received
All communication between the app and server uses TLS 1.3. Data at rest is AES-256 encrypted. The broadcast extension uploads only alert metadata — never screen content — over an encrypted connection.
Threat Model
What happens in the worst-case scenarios? We've thought through them.
What if your servers are hacked?
We do not store screenshots or browsing content. The database contains only encrypted alert metadata (category, severity, timestamp) and account information (name, email, bcrypt-hashed password). A breach would expose metadata, not your screen content.
What if data is intercepted in transit?
All communication between the app, server, and Apple Push Notification Service uses TLS 1.3. Interception would yield only encrypted ciphertext. All data in transit is encrypted end-to-end.
What if a partner is malicious?
Partners only see alert categories and timestamps — never raw content, screenshots, or browsing history. A malicious partner has nothing to expose. You can remove a partner instantly at any time.
What if the app itself is compromised?
The entire codebase is open source and auditable by anyone. We run pre-commit secret scanning on every contribution. Anyone can read the source and confirm that classification is fully on-device and that only alert metadata — never screen content — is ever transmitted.
Open Source Commitment
The entire Remain Faithful codebase — iOS app, Go backend, and this website — is publicly available on GitHub. This is not optional for an app that handles sensitive behavioral data.
Our privacy architecture is not a policy claim. It is verifiable in the code. Anyone can confirm that classification happens entirely on-device and that only alert metadata — never screen content — is ever transmitted.
Security researchers and privacy advocates are invited to review, test, and report findings. We take responsible disclosure seriously.
View Source on GitHubWhy open source matters for trust
- Anyone can verify our privacy claims by reading the code
- Security researchers can find and report vulnerabilities
- The community can audit every update before it ships
- No "trust us" black boxes when handling intimate behavioral data
- Pre-commit secret scanning prevents credential leaks
How We Compare to Other Tools
Privacy dimensions compared across the most common accountability apps.
| Privacy Dimension | Remain Faithful | Provider A ($16/mo) | Provider B ($20/mo) |
|---|---|---|---|
| On-device AI processing | ✓ Yes | ✗ No (cloud) | ✗ No (cloud) |
| Open source codebase | ✓ Yes | ✗ No | ✗ No |
| Screenshots stored on server | ✗ Never | ✓ Yes | ✓ Yes |
| Partners see raw content | ✗ Never | ✓ Yes | ✓ Yes |
| Cloud dependency for classification | Zero — fully on-device | Always | Always |
| Cost | 100% Free | Paid subscription | Paid subscription |
| Auditable by security researchers | ✓ Yes | ✗ No | ✗ No |
Competitor information based on publicly available documentation. All claims are verifiable via our open-source codebase.
Questions About Our Privacy Model?
Read the source code, open a GitHub issue, or contact us directly. Transparency is not just a commitment — it is a practice.