Adds docs/privacy.md — the end-to-end data flow and privacy posture for the LibreMail debug bug-report pipeline, written so it can be linked from LibreMail's README and F-Droid metadata (LibreMail#16, LibreMail#20).
Documentation only — no code, no behaviour change. docs/privacy.md is the sole file added.
What the doc covers
End-to-end flow, stage by stage: opt-in submission from the app's review/submit screen (LibreMail#33) → HTTPS ingest (POST /v1/reports, 256 KiB cap, schema validation, per-IP limits, 202 contract) → best-effort PII scrub (#8) → encrypted-at-rest R2 storage (AES-256-GCM, key in Cloudflare Secrets Store) → manual maintainer review/removal window (#11) → weekly publish (Fri 17:00 America/Chicago) as labelled GitHub issues on JMR-dev/LibreMail.
Stated plainly: submission is opt-in / user-initiated only (never automatic); PII scrubbing is best-effort, not a guarantee, with the concrete limitations pulled from internal/scrub (weak key-directed name heuristic; address-shaped emails only; only recognisable secrets/JWTs; IPv4 vs. dotted-version/OID ambiguity); encryption-at-rest means stored reports are unreadable without the maintainer-held key, plus what that does not protect (compromised platform, published issues, key loss).
Honest about maturity: every stage is tagged live vs. designed, and an Implementation-status table records that only the scrub library (#8) is built (and not yet wired), while the ingest endpoint (#7), encrypted storage (#9), lifecycle (#10), removal window (#11), and publish job (#14/#15) are specified but not yet implemented.
## Summary
Adds `docs/privacy.md` — the end-to-end data flow and privacy posture for the LibreMail debug bug-report pipeline, written so it can be linked from LibreMail's README and F-Droid metadata ([LibreMail#16](https://github.com/JMR-dev/LibreMail/issues/16), [LibreMail#20](https://github.com/JMR-dev/LibreMail/issues/20)).
Documentation only — no code, no behaviour change. `docs/privacy.md` is the sole file added.
## What the doc covers
- **End-to-end flow**, stage by stage: opt-in submission from the app's review/submit screen ([LibreMail#33](https://github.com/JMR-dev/LibreMail/issues/33)) → HTTPS ingest (`POST /v1/reports`, 256 KiB cap, schema validation, per-IP limits, `202` contract) → best-effort PII scrub (#8) → encrypted-at-rest R2 storage (AES-256-GCM, key in Cloudflare Secrets Store) → manual maintainer review/removal window (#11) → weekly publish (Fri 17:00 America/Chicago) as labelled GitHub issues on `JMR-dev/LibreMail`.
- **Stated plainly:** submission is **opt-in / user-initiated only** (never automatic); PII scrubbing is **best-effort, not a guarantee**, with the concrete limitations pulled from `internal/scrub` (weak key-directed name heuristic; address-shaped emails only; only recognisable secrets/JWTs; IPv4 vs. dotted-version/OID ambiguity); encryption-at-rest means stored reports are unreadable without the maintainer-held key, plus what that does **not** protect (compromised platform, published issues, key loss).
- **Honest about maturity:** every stage is tagged live vs. designed, and an Implementation-status table records that only the scrub library (#8) is built (and not yet wired), while the ingest endpoint (#7), encrypted storage (#9), lifecycle (#10), removal window (#11), and publish job (#14/#15) are specified but not yet implemented.
Links [ADR #5 (encryption)](https://github.com/JMR-dev/LibreMail-Bug-Report-Ingest/blob/ticket-12-privacy-doc/docs/decisions/encryption.md) and [ADR #6 (labels/abuse)](https://github.com/JMR-dev/LibreMail-Bug-Report-Ingest/blob/ticket-12-privacy-doc/docs/decisions/labels-and-abuse.md). Tone matches the existing README/ADR voice.
Closes #12
️✅ There are no secrets present in this pull request anymore.
If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.
🦉GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
#### ️✅ There are no secrets present in this pull request anymore.
If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find [here](https://docs.gitguardian.com/platform/remediate/remediate-incidents) more information about risks.
---
<sup><sub>🦉 [GitGuardian](https://dashboard.gitguardian.com/auth/login/?utm_medium=checkruns&utm_source=github&utm_campaign=cr1) detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.<br/></sup></sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Adds
docs/privacy.md— the end-to-end data flow and privacy posture for the LibreMail debug bug-report pipeline, written so it can be linked from LibreMail's README and F-Droid metadata (LibreMail#16, LibreMail#20).Documentation only — no code, no behaviour change.
docs/privacy.mdis the sole file added.What the doc covers
POST /v1/reports, 256 KiB cap, schema validation, per-IP limits,202contract) → best-effort PII scrub (#8) → encrypted-at-rest R2 storage (AES-256-GCM, key in Cloudflare Secrets Store) → manual maintainer review/removal window (#11) → weekly publish (Fri 17:00 America/Chicago) as labelled GitHub issues onJMR-dev/LibreMail.internal/scrub(weak key-directed name heuristic; address-shaped emails only; only recognisable secrets/JWTs; IPv4 vs. dotted-version/OID ambiguity); encryption-at-rest means stored reports are unreadable without the maintainer-held key, plus what that does not protect (compromised platform, published issues, key loss).Links ADR #5 (encryption) and ADR #6 (labels/abuse). Tone matches the existing README/ADR voice.
Closes #12
️✅ There are no secrets present in this pull request anymore.
If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.