1313939 - allow users to deny notification permissions globally

Status: RESOLVED DUPLICATE of bug 1368744

(Core :: Permission Manager, defect, P1)

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently users can click "never ask again" to deny permissions for a site, but they have to do this on a site-by-site basis.  I've seen multiple people on twitter ask for a way to disable notifications globally.  The latest:

https://twitter.com/mattblaze/status/792768947296829445

In the past I have recommended disabling dom.push.enabled, but that seems to break some sites.  I believe it removes the push subscription API completely and some sites assume its there if the UA has service workers.

What we really need is a way to auto-reject the permission globally.

Kit, what do you think?

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Ideally this should be accessible via the preferences UX.

Comment 2

[Lina Butler [:lina]]

Definitely. We used to let you do this in about:permissions, but I don't know if there's new UX for disabling permissions globally. Matt, is there a plan for this?

Alternatively, we could add an "Allow sites to send me notifications" checkbox to about:preferences#content. Unchecking would hide the "Exceptions" button and disable the permission.

Comment 3

[Matthew N. [:MattN]]

I think this should be part of bug 1275599 but unfortunately it was decided to work on a one-off storage management UI first instead of the management for all extra privileges.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

This is unfortunate as I've seen multiple users request this specific feature.  It seems similar to our other privacy and anti-nuisance features in preferences.

In fact, nightly already has a section under preferences->content->notifixations that lets you remove the permission for all currently granted sites.  I don't see why we couldn't add a global "don't ask" option there.

I really don't underatand the argument for lumping this with every other permission when we already have a preferences item dedicated to it.

Matt would you reconsider re-opening this?

Comment 5

[Matthew N. [:MattN]]

(In reply to Ben Kelly [:bkelly] from comment #4)
> This is unfortunate as I've seen multiple users request this specific
> feature.  It seems similar to our other privacy and anti-nuisance features
> in preferences.

The reason this is a nuisance is because we didn't require user interaction in order to request notification permissions which I argued for many times e.g. https://github.com/w3c/permissions/issues/77/

> In fact, nightly already has a section under
> preferences->content->notifixations that lets you remove the permission for
> all currently granted sites.  I don't see why we couldn't add a global
> "don't ask" option there.

That dialog is generic for all permissions so we could do that perhaps if the permission manager has support for setting a default permission value e.g. setting a permission for an origin of `*` which would match how Chrome also allows you to always allow a permission.

> I really don't underatand the argument for lumping this with every other
> permission when we already have a preferences item dedicated to it.

With bug 1275599 the preference item would be replaced with a permission management interface.

My argument is for consistency in how we handle this instead of implementing it in a custom fashion for each permission. If we implement it as a checkbox we have to write additional DOM code for web and push notifications to do the right thing rather than having the permission manager just returning the proper ALLOW/DENY from the existing checks. If people want to maintain this additional code and UX is fine with putting a checkbox beside the existing pref line then fine but I personally would rather solve this properly for all permissions at once.

Consider these questions:
* Which has precedence: the checkbox or the permission manager? We're inconsistent with existing features now so we would be adding to that problem.
* Does the checkbox control whether we prompt or whether the feature is disabled? i.e. would existing permissions or manually added ALLOWs would still work? This answer is also not clear.

Comment 6

[Johann Hofmann [:johannh]]

In both bug 1275599 and bug 1363856 we're looking for this kind of functionality. Here's my proposal for it:

Similar to the permissions.default.image pref (that is currently only used by DOM code) we could change the permission manager to fall back to a permissions.default.* pref instead of simply returning UNKNOWN when no permission for a certain principal/uri has been found. This pref could be set by the add-on API (they will lock it down to only allow globally blocking permissions) and by the permissions management interface.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

I keep seeing users complain about notifications:

https://twitter.com/wvdschel/status/880321449080356865

Many users really see the notification permission prompt as the new popup window.

I think we should handle this as a specific abuse case.  I'd like to keep this bug for that.  If you want to make a generic permission thing please do that in a separate bug.

Andrew, do you know how we can get this directed to the right place in the org to address it?  Its been a persistent complaint from users for a while and we can't seem to make any progress here.

Comment 8

[Asa Dotzler [:asa]]

I filed bug 1368744 which now feels like a dupe of this one except it's got product and UX input.

Comment 9

[Johann Hofmann [:johannh]]

(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #7)
> I keep seeing users complain about notifications:
> 
> https://twitter.com/wvdschel/status/880321449080356865
> 
> Many users really see the notification permission prompt as the new popup
> window.
> 
> I think we should handle this as a specific abuse case.  I'd like to keep
> this bug for that.  If you want to make a generic permission thing please do
> that in a separate bug.
> 
> Andrew, do you know how we can get this directed to the right place in the
> org to address it?  Its been a persistent complaint from users for a while
> and we can't seem to make any progress here.

I find it a bit irritating that you decided to change the scope of this bug without needinfoing me first. We're solving this as part of the site permission management project.

This is now an exact duplicate of bug 1368744. There's no platform work required for that. AFAIK we can just make a checkbox for dom.webnotifications.enabled in about:preferences. It's not a clean solution, since existing permission manager information will not accurately reflect the fact that notifications are disabled globally. This bug was supposed to be about properly implementing the back-end requirements in the permission manager. I guess I'll make my own bug then. We can alter the functionality of the checkbox later, if you're keen on adding it now.

FYI, Product scratched this feature from our initial MVP just to reconsider adding it in bug 1368744. There are significant concerns about making it trivial to disable web platform features in preferences. We still don't have a clear idea on how to best expose this setting or what impact it would have, although it will probably end up as a simple checkbox.

I would suggest pinging Tina for the updated spec in bug 1368744 if you really want to move this forward. We could just implement a checkbox but I consider it rude to ignore pending requests.

Comment 10

[Johann Hofmann [:johannh]]

> This is now an exact duplicate of bug 1368744. There's no platform work required for that. AFAIK we can just make a checkbox for dom.webnotifications.enabled in about:preferences. It's not a clean solution, since existing permission manager information will not accurately reflect the fact that notifications are disabled globally. This bug was supposed to be about properly implementing the back-end requirements in the permission manager. I guess I'll make my own bug then. We can alter the functionality of the checkbox later, if you're keen on adding it now.

Rethinking that statement: We might want to avoid changing the underlying pref for such a checkbox, since we'd have to do some sort of migration otherwise.

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

> I find it a bit irritating that you decided to change the scope of this bug
> without needinfoing me first. We're solving this as part of the site
> permission management project.

Well, I found it equally irritating this was re-scoped from my original bug report and the actual feedback I see from users.  They don't complain about permissions in general.  The complaints I see are specifically about notifications.  Probably because notifications have similar incentives as popups when it comes to spam.

> This is now an exact duplicate of bug 1368744. There's no platform work
> required for that. AFAIK we can just make a checkbox for
> dom.webnotifications.enabled in about:preferences. It's not a clean
> solution, since existing permission manager information will not accurately
> reflect the fact that notifications are disabled globally. This bug was
> supposed to be about properly implementing the back-end requirements in the
> permission manager. I guess I'll make my own bug then. We can alter the
> functionality of the checkbox later, if you're keen on adding it now.

Ok.  I didn't know that bug existed because it was written after this bug.  I just came back to the bug I knew that I had written.

By the way, I asked about doing something simple like you suggest in comment 4 and MattN shut me down in comment 5.  So it doesn't seem like that would be accepted.

> FYI, Product scratched this feature from our initial MVP just to reconsider
> adding it in bug 1368744. There are significant concerns about making it
> trivial to disable web platform features in preferences. We still don't have
> a clear idea on how to best expose this setting or what impact it would
> have, although it will probably end up as a simple checkbox.
> 
> I would suggest pinging Tina for the updated spec in bug 1368744 if you
> really want to move this forward. We could just implement a checkbox but I
> consider it rude to ignore pending requests.

If there is on going work I'll just step back from this.  I didn't know that was going on at all because every time I've tried to get interest in this it was dismissed with "we'll rewrite permissions eventually, doing nothing till then".

As someone who works on platform I don't feel like I have a lot of visibility into UX/product work.  My only recourse AFAICT is to file bugs and try to get people's attention there.

Anyway, sorry for the mess.

Comment 12

[Johann Hofmann [:johannh]]

Yup, sorry, I should have been more communicative about this. I filed bug 1379560 to solve it.