Bugzilla

I'm still concerned about the prospect of providing free delayed execution.  But I think we could probably leverage your notification sidebar idea to deal with this.

The pipeline of states leading to a displayed desktop notification is:
1. Site requests push notification permission.
2. The permission is granted.
3. Site sends push notification.
4. ServiceWorker gets to run.
5. Desktop notification may possibly be displayed (somewhere)

Right now, we stall things and require annoying user interaction at step 1.  Your proposal is to let sites get to 5 but eventually we shut them down after we've detected abuse, lack of user interest, or explicit user dis-interest.

We could potentially let all sites get to step 3 for the first time, but not actually run the ServiceWorker (step 4) until the user has expressed positive interest by tapping on a notification thingy that says "example.com wants to send you a notification".  Once they've expressed interest, we let the ServiceWorker run and see how things shake out, with a desktop notification potentially being displayed.

The obvious downside to this strategy is it's possible that:
a. The SW may take some time to run leading to latency while the user has to stare at it waiting for a notification to show up.
b. The site may no longer want to show a desktop notification and so there's nothing to show.  For example, a calendar notification for an event now in the past or an email that's already been read, etc.
c. The site is a nefarious bad site and the user is now watching as nothing happens and the site just burns CPU mining bitcoin. 
d. The user may be offline right now...

For 'a', well, we want the push notification handling to be fast and responsive, so if the user ends up deciding to penalize the site for having a slow/laggy SW, that's okay.  For 'b', well, that's less good, but we can at least have whitelisted progress.  Sites could also learn to show a desktop notification in this case.  Step 'c' is a case where it could be good for the user to explicitly blocklist the site, and we could help this by informing them that the site ended up using CPU/battery for N minutes, but it's still weird UX.  For 'd', I think the notification bar would need to display "you're offline, but see these next time?"

It would also be possible to put something in the notification bar once the permission had been requested and auto-granted (pipeline step 1).  And it would also be possible to speculatively grant full permissions to run SW based on an overwhelming indication of use of the site per history/heuristics.

I'm still concerned about the prospect of providing free delayed execution.  But I think we could probably leverage your notification sidebar idea to deal with this.

The pipeline of states leading to a displayed desktop notification is:
1. Site requests push notification permission.
2. The permission is granted.
3. Site sends push notification.
4. ServiceWorker gets to run.
5. Desktop notification may possibly be displayed (somewhere)

Right now, we stall things and require annoying user interaction at step 1.  Your proposal is to let sites get to 5 but eventually we shut them down after we've detected abuse, lack of user interest, or explicit user dis-interest.

We could potentially let all sites get to step 3 for the first time, but not actually run the ServiceWorker (step 4) until the user has expressed positive interest by tapping on a notification thingy that says "example.com wants to send you a notification".  Once they've expressed interest, we let the ServiceWorker run and see how things shake out, with a desktop notification potentially being displayed.

The obvious downside to this strategy is it's possible that:
a. The SW may take some time to run leading to latency while the user has to stare at it waiting for a notification to show up.
b. The site may no longer want to show a desktop notification and so there's nothing to show.  For example, a calendar notification for an event now in the past or an email that's already been read, etc.
c. The site is a nefarious bad site and the user is now watching as nothing happens and the site just burns CPU mining bitcoin. 
d. The user may be offline right now...

For 'a', well, we want the push notification handling to be fast and responsive, so if the user ends up deciding to penalize the site for having a slow/laggy SW, that's okay.  For 'b', well, that's less good, but we can at least have granted the permission from user intent.  Sites could also learn to show a desktop notification in this case.  Step 'c' is a case where it could be good for the user to explicitly blocklist the site, and we could help this by informing them that the site ended up using CPU/battery for N minutes, but it's still weird UX.  For 'd', I think the notification bar would need to display "you're offline, but see these next time?"

It would also be possible to put something in the notification bar once the permission had been requested and auto-granted (pipeline step 1).  And it would also be possible to speculatively grant full permissions to run SW based on an overwhelming indication of use of the site per history/heuristics.