gauntface
commented
8 years ago I'm torn on this issue.
If a developer knows they won't encrypt payloads, they'll do something else (which is a valid use case), the encryption keys may not be sent and VAPID is voluntary, so could be skipped. This combo means you wouldn't be able to use the Go library at all (Which I confess offer minimal assistance if you are only sending a web push protocol request).
Just for the record. Firefox will validate the VAPID header if it is set (i.e. the public cert sent in the header, against the signed JWT header). However, unlike Chrome, Firefox doesn't require the applicationServerKey to be passed into the subscribe call, so there is still no validation of the person who sent, only validation that the VAPID headers is correct.
Clients that don't support encryption and/or VAPID can't verify that the sender is correct[1]. Even without VAPID, encrypting an empty message still provides some authentication as the sender will need more than just the endpoint.
Once these clients pass some threshold of age or usage, we should remove support for them.
cc: @gauntface
[1]: Ok, technically old Chrome does have validation, because we required the gcm_sender_id. But the same code paths that allow us to send pings to old Chrome also allow unauthenticated pushing to FF, since they don't require VAPID.