search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
146 stars 40 forks source link

Add a messageHandlingError event #214

Closed bbangert closed 8 years ago

bbangert commented 8 years ago

There's a pushsubscriptionchange event for if a subscription expires, or with #116, a user revokes permission. Given that there's a few different ways an event can be processed (or not), it seems odd that there's no subscription-level event that fires when an error associated with the subscription processor fails.

This can't be dealt with using an exception catcher in the message fire event, as some messaging errors occur in the browser level without even firing that event. The most obvious one in this case, if a browser fails to decrypt the message properly (app-server improperly encrypted the message), the subscription event handler doesn't fire at all.

The registered messageHandlingError would fire if the browser receives a message intended for a subscription, that cannot be decrypted (bad encryption error), or the event handler did fire but ran longer than the browser allows service worker handlers to run for.

A beneficial side-effect of this is that it might reduce an app-servers desire to use the WebPush spec's receipt's feature just to ensure the client didn't error out processing a message.

martinthomson commented 8 years ago

If this is a decryption problem, that's either a programming error or a DoS attack. You are suggesting that we compound the DoS by waking the application as well as the browser.

What other reasons are there for a message arriving for a subscription that isn't going to be delivered?

Note that most browsers log decryption failures to developer consoles, so a developer can debug their code that way.

bbangert commented 8 years ago

I consider it reasonable that developers will make programming errors more frequently than be on the receiving end of a DoS attack. To send messages to an endpoint requires a DoS victim to have been hacked sufficiently to leak the endpoints in the first place.

Controls could be taken to reduce the frequency of calling the application's error handler to process an error.

Logging to the developer console assumes a developer is testing it when it occurs. Sometimes bugs occur infrequently in the real-world under edge-cases a developer didn't consider testing.

martinthomson commented 8 years ago

Discussed with @beverloo. This is better done with browser diagnostics. Field debugging of encryption errors is not a good idea.

jrconlin commented 8 years ago

The problem may well be a programming error, but one that only manifest a percentage of the time. This can lead programmers to believe that a push service is either unreliable or broken. It may be useful if there was a "development" flag that passed along the event and failure without requiring the developer to have arcane knowledge of the browser.

It's certainly possible for each push provider to have their own means to indicate such a developmental flag, but that's probably not the friendliest thing for developers.