Privacy considerations (Section 8.2) cover metadata exposure per transport but do not address push notification side-channels. The FBI/Signal case demonstrated recovery of deleted messages via Apple's push notification database.
Push notifications (APNs, FCM) transit through Apple/Google infrastructure. Even with E2E encryption, push metadata leaks: message timing, sender/recipient correlation, message existence proof. The headless daemon with Matrix/IMAP adapters will inherit those ecosystems' push mechanisms.
Proposal: add push notification metadata to Section 8.2 with a mitigation hierarchy: UnifiedPush with self-hosted relay (best) → opaque push (no content, just "check for updates") → polling (no push, trades battery for privacy) → native push (convenient, worst privacy). This should be a client/operator choice, consistent with transport trust classification philosophy.
Privacy considerations (Section 8.2) cover metadata exposure per transport but do not address push notification side-channels. The FBI/Signal case demonstrated recovery of deleted messages via Apple's push notification database.
Push notifications (APNs, FCM) transit through Apple/Google infrastructure. Even with E2E encryption, push metadata leaks: message timing, sender/recipient correlation, message existence proof. The headless daemon with Matrix/IMAP adapters will inherit those ecosystems' push mechanisms.
Proposal: add push notification metadata to Section 8.2 with a mitigation hierarchy: UnifiedPush with self-hosted relay (best) → opaque push (no content, just "check for updates") → polling (no push, trades battery for privacy) → native push (convenient, worst privacy). This should be a client/operator choice, consistent with transport trust classification philosophy.