3 ms·

UnifiedPush is compatible with WebPush: both just involve an HTTP POST to a specific URL. If your application server supports WebPush, it can send encrypted not

UnifiedPush is compatible with WebPush: both just involve an HTTP POST to a specific URL. If your application server supports WebPush, it can send encrypted notifications to UnifiedPush servers (that is how we're planning to support Telegram, for example). You can then decrypt these notifications in the app [1]. However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively. There, encryption is unnecessary complexity. However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol). [1] One example, https://github.com/UnifiedPush/dart-webpush-encryption https://github.com/UnifiedPush/dart-webpush-encryption

kevincox 4y ago
> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for uses which do need encryption to forget to turn it on or accidentally turn it off. For many apps the benefit here is indeed tiny, but so is the cost. So I think it is best to not support unencrypted messages altogether.
- karmanyaahm 4y ago
  I agree that mandatory encryption would massively help privacy, integrity and even compliance [1]. However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As a small project, ease of adoption has been our most important goal. However, as we work towards better WebPush compatibility [2], I personally absolutely want to promote RFC8291 encryption and make it easy to implement for developers using UnifiedPush, hopefully making it the norm. [1] https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-noti... [2] https://github.com/UnifiedPush/wishlist/issues/15 https://github.com/UnifiedPush/wishlist/issues/15
  - nightpool 4y ago
    Making it the "norm" isn't good enough, because developers will always want to cut corners to ship, either based on pressure from management or (in open source projects) just not feeling comfortable with encryption or thinking that it's important enough to implement. Web push libraries are already widely available for major languages to handle implementing encryption, and keeping track of keys isn't any harder than keeping track of device IDs or endpoints would be without encryption—it's just one more row in your database.
  - ohbtvz 4y ago
    > However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As soon as you need encryption in at least one place in your software, it's going to happen.
  - kevincox 4y ago
    WebPush doesn't really have keys to keep track of. Other than the VAPID signature (which is optional but may be enforced by the push service) all of the keys are ephemeral. They are used for just one subscription so storing them is just as easy as storing the rest of the notification URL.
- MayeulC 4y ago
  I agree, though it of course it depends on the threat model. As a self hoster, encryption is pretty much irrelevant, as my push server is controlled by myself, and accessible with https. Not having encryption makes it easy to debug and experiment. I agree encryption should be the default choice though. Maybe we can introduce it in a future protocol revision? Client side, I expect most people use libraries, making this easy. Server side? Not so much. The main goal was to get it adopted as widely as possible though, and encryption certainly seemed like something that would slow the effort.
  - kevincox 4y ago
    Even for self-hosted I'd rather trust the server as little as necessary. Just in case it is completed why let it see things that it doesn't need to see?
nightpool 4y ago
> However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively While I understand that some developers may think of security as wasteful, having unencrypted data be the default relies on every developer to spend much more time considering the possible threat models and how . Case in point here is Matrix—the IDs they send aren't random at all, they actually send full room IDs and event IDs for each message, so you'd be able to build up someone's entire social graph just from reading their unencrypted push notification data and looking up room IDs on the Matrix server in question or even correlating room IDs across different Element installs. This also hurts users, since they're not in a position to inspect the source code and understand how or whether they need to trust their "push provider" with whatever data the app developers might have chosen to regard as "less sensitive"—WebPush's encryption-by-default design removes trust from the equation entirely and prevents of these sorts of "passive surveillance" attacks (except those based on timing or message length) > You can then decrypt these notifications in the app This pushes all of the complexity of supporting encryption onto the app developer, instead of having it be provided by the platform where it can be centrally audited and securely managed. > However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol). Why not do this innovation in an open standards body like the IESG where other stakeholders can give feedback and review? The web push standard does allow for Push Servers to use other custom wire protocols besides the default RFC8030, but having open and standards-based discussion of the possible performance improvements would "lift all boats" in terms of being able to provide low-power devices with timely push notifications

kevincox 4y ago

> There, encryption is unnecessary complexity. If you are sending a small amount of data it is likely a tiny overhead for some notable benefits. 1. If all data is encrypted then no data stands out for being encrypted. 2. It provides integrity which may prevent push servers from changing message to be invalid or triggering parsing bugs in applications. 3. If only encrypted messages are supported it is impossible for uses which do need encryption to forget to turn it on or accidentally turn it off. For many apps the benefit here is indeed tiny, but so is the cost. So I think it is best to not support unencrypted messages altogether.

karmanyaahm 4y ago
I agree that mandatory encryption would massively help privacy, integrity and even compliance [1]. However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As a small project, ease of adoption has been our most important goal. However, as we work towards better WebPush compatibility [2], I personally absolutely want to promote RFC8291 encryption and make it easy to implement for developers using UnifiedPush, hopefully making it the norm. [1] https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-noti... [2] https://github.com/UnifiedPush/wishlist/issues/15 https://github.com/UnifiedPush/wishlist/issues/15
- nightpool 4y ago
  Making it the "norm" isn't good enough, because developers will always want to cut corners to ship, either based on pressure from management or (in open source projects) just not feeling comfortable with encryption or thinking that it's important enough to implement. Web push libraries are already widely available for major languages to handle implementing encryption, and keeping track of keys isn't any harder than keeping track of device IDs or endpoints would be without encryption—it's just one more row in your database.
- ohbtvz 4y ago
  > However, the main cost is developer-effort involved in keeping track of keys and implementing encryption. As soon as you need encryption in at least one place in your software, it's going to happen.
- kevincox 4y ago
  WebPush doesn't really have keys to keep track of. Other than the VAPID signature (which is optional but may be enforced by the push service) all of the keys are ephemeral. They are used for just one subscription so storing them is just as easy as storing the rest of the notification URL.
MayeulC 4y ago
I agree, though it of course it depends on the threat model. As a self hoster, encryption is pretty much irrelevant, as my push server is controlled by myself, and accessible with https. Not having encryption makes it easy to debug and experiment. I agree encryption should be the default choice though. Maybe we can introduce it in a future protocol revision? Client side, I expect most people use libraries, making this easy. Server side? Not so much. The main goal was to get it adopted as widely as possible though, and encryption certainly seemed like something that would slow the effort.
- kevincox 4y ago
  Even for self-hosted I'd rather trust the server as little as necessary. Just in case it is completed why let it see things that it doesn't need to see?

nightpool 4y ago

> However, some protocols only send a wake-up ping or random ID in the push notification, Trifa and Matrix respectively While I understand that some developers may think of security as wasteful, having unencrypted data be the default relies on every developer to spend much more time considering the possible threat models and how . Case in point here is Matrix—the IDs they send aren't random at all, they actually send full room IDs and event IDs for each message, so you'd be able to build up someone's entire social graph just from reading their unencrypted push notification data and looking up room IDs on the Matrix server in question or even correlating room IDs across different Element installs. This also hurts users, since they're not in a position to inspect the source code and understand how or whether they need to trust their "push provider" with whatever data the app developers might have chosen to regard as "less sensitive"—WebPush's encryption-by-default design removes trust from the equation entirely and prevents of these sorts of "passive surveillance" attacks (except those based on timing or message length) > You can then decrypt these notifications in the app This pushes all of the complexity of supporting encryption onto the app developer, instead of having it be provided by the platform where it can be centrally audited and securely managed. > However, we don't use the WebPush API between the push server and distributor since there is a lot of scope for innovation in that space (for example Google's FCM uses a custom XMPP based protocol). Why not do this innovation in an open standards body like the IESG where other stakeholders can give feedback and review? The web push standard does allow for Push Servers to use other custom wire protocols besides the default RFC8030, but having open and standards-based discussion of the possible performance improvements would "lift all boats" in terms of being able to provide low-power devices with timely push notifications