Page MenuHomePhabricator

Put collapse key in encrypted MacOS notification payload
ClosedPublic

Authored by marcin on Dec 4 2023, 11:20 PM.
Tags
None
Referenced Files
F3333686: D10188.id34288.diff
Thu, Nov 21, 4:49 AM
F3333685: D10188.id34286.diff
Thu, Nov 21, 4:49 AM
F3333684: D10188.id34280.diff
Thu, Nov 21, 4:49 AM
F3333683: D10188.id34277.diff
Thu, Nov 21, 4:49 AM
F3333682: D10188.id34262.diff
Thu, Nov 21, 4:49 AM
F3333679: D10188.id.diff
Thu, Nov 21, 4:49 AM
F3333678: D10188.diff
Thu, Nov 21, 4:49 AM
Unknown Object (File)
Fri, Nov 8, 11:02 PM
Subscribers

Details

Summary

This differential fixes urget issue:
https://linear.app/comm/issue/ENG-6010/invariant-violation-collapsible-notifications-encryption-currently-not.
We want to keep the invariant active since it protects us against accidentally exposing unencrypted
collapseID in notification headers. We just need to put it in notification payload for MacOS notifs as well.
Putting collapseID in notification.collapseID results in collapseID being exposed in notification
headers. Putting it in notification.payload results in collapseID being encrypted.

Test Plan
  1. Build MacOS desktop app.
  2. Send collapsible notifications (chenge the color of the thread for instance).
  3. Ensure that notifications are displayed correctly and version field in MariaDB of relevant olm session

is incremented with each notification.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

keyserver/src/push/send.js
970 ↗(On Diff #34262)

This is a weird condition to see. Why are the conditions for iOS and macOS named differently? Can we rename them to be more similar? And maybe canDecryptIOSNotifs can be more like iosCanOnlyDecryptNonCollapsibleNotifs or something?

Enhance variable naming in contitions that determine whether notifications should be encrypted

Much better with the naming change

This revision is now accepted and ready to land.Dec 5 2023, 6:43 AM