Hacker News Reader

Comment by kevincox | Hacker News Reader

> 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.

View on HN

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-noti...

[2] https://github.com/UnifiedPush/wishlist/issues/15

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.

> 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.

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.

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.

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?

Reply on news.ycombinator.com