User.js: service workers & web notifications & SW cache

Created on 27 Apr 2019  路  24Comments  路  Source: arkenfox/user.js

relevant info: https://blog.nightly.mozilla.org/2019/04/01/reducing-notification-permission-prompt-spam-in-firefox/

2302 (Service Workers) & 2304 (web notifications)

service workers (2302) need to be enabled for notifications, and notifications are behind a prompt (but there is such a thing as prompt fatigue, see the linked article). We disable SW's by default, so AFAIC, there is no need for notifications (2304) to be active.

If someone flips SW to enabled, and then gets bombarded with notifications, that's on them. There is a UI setting for block by default, and also Firefox is working on getting rid of that 97% ignore rate (by removing 97% of prompts? yay!). It;'s not a big deal in my book, but just yet another item we flip that we don't need to.

Class discuss!

enhancement

All 24 comments

there is such a thing as prompt fatigue

A much more dangerous (and presumably common) case of prompt fatigue is the one with firewalls.

I was gonna point out that Notifications also govern Push but those require workers too, so IDK if there is any reason to keep that active. It doesn't look that way.

An example of SW + notifications is Slack. It's not hard to tell Slack notifications to go away, but for many people, the notifications are handy: been there done that: rather than keep an eye on numerous things, they can be out of sight and you just get notifications. I guess the same could be said for Push: i.e instead of keeping pages loaded as well...

So, I guess... push is FROM a server (not to it, well, not while the page is no longer loaded), so I guess it's probably no worse. I knew push requires SW, so yeah, it too could maybe be inactive.

The question would be does the permission prompt cover both? And there's maybe a bit more to consider - e.g push.serverURL and push.userAgentID <-- why are these global prefs?

The question would be does the permission prompt cover both?

https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API

Note: As of Firefox 44, the permissions for Notifications and Push have been merged. If permission is granted for notifications, push will also be enabled.

Edit: what do you mean by global prefs?

global, as in why would that need to be set in prefs, rather than each website server just pushing to your IP. But I think I understand (but I would have to read up on it). There's a "middle man" for lack of a better word, which means that even if you changed IP, they could still push to you? (or do you have to still load the site first?)

As of Firefox 44, the permissions for Notifications and Push have been merged. If permission is granted for notifications, push will also be enabled.

Feels like an evil plan. If I allow a website to show a toast in the right bottom angle of the desktop it doesn't mean I wanna allow it to put a piece of JS into my browser executing in background and call home.

^^ yeah, that's why I was ok with notifications, but not push - as the default in the template

it doesn't mean I wanna allow it to put a piece of JS into my browser executing in background and call home.

But does it actually send you executable JS? My understanding is it is only messages.

The permission is for both Notifications and Push, but the push. prefs control push, and the notification prefs control notifications. I should make that clear in the js. Will do a commit shortly.

But does it actually send you executable JS? My understanding is it is only messages.

IDK (I have not played with it yet), but MDN says that Push works via a service worker. Even if it involved no service workers but just hardcoded calling home and saving the info in the cache, available to a page when it is opened (making the feature completely useless for all legit use cases but downloading large data in background to be used when the page is opened), it still would be inacceptable to mix that with pure GUI stuff.

The other thing here is that we also have the SW cache pref (not to mention clearing local storage on close)

We need to find a wc3 spec on push and locate the privacy/security concerns section

User agents MUST NOT provide Push API access to webapps without the express permission of the user.

Would you like to show notifications from ...

(from the screenshot on https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API)

doesn't sound like allowing Push

Might be an old picture? I also think that since the UI only says "notifications` that they are being consistent with the wording, and simplifying it - 99% of web users wouldn't have a fucking clue about note vs push, just nerds like you :grinning: and a push from twitter is the same thing.

Edit: "notifications" is all encompassing, as "push notifications" are still "notifications"

Might be an old picture?

Seems to be. I have searched DXR by the text, have not found anything sensible.

I wouldn't worry about it. "Notifications" covers both web notifications and push notifications

I think I know what I will do here. I think:

  • SW: stays active

    • add setup-web tag and mention both notifications & SW cache can be hardened if they enable SW

    • add note that SW cache is cleared on close

  • web notifications: - inactive with a harden tag (and still has a default prompt of ask)
  • push notifications: - inactive with a harden tag (and still has a default prompt of ask)
  • SW cache: - inactive with a harden tag

    • add note that it is cleared on close

This means that by default, the template blocks the lot (SW, web note, push note, SW cache) as SW are needed. And if anyone wants to use SW, then it's up to them to reduce the fallout.

That fixes four of the items in my list and reduces the list if things to change for end users

Just a question, if someone already knows: is SW cache isolated by TC and when container is destroyed is the SW cache also cleared?

@KOLANICH

Here's Mozilla Slack, there is nothing under the site info dropdown
slack

Here's https://acme.com/webapis/notification.html
acmetest

Just a question, if someone already knows: is SW cache isolated by TC and when container is destroyed is the SW cache also cleared

Ask stoically. It clears using an API for containers (I forget the name), which is why it can clear IDB (i.e the domain is a container, so you clear the container, in effect you have cleared by host). Since SW cache uses IDB, I would think this is also being done.

Be aware though, and I'm not the one to ask, but there are instances of / bugs where persistent data is NOT being cleared. I think one of them is cases of thousands and thousands of IDB folders, and users are using scripts to clear em out.

The other issue is I have no idea how push and SW and SW cache and server URL and ID all work together to provide push. I mean, if SW cache is disabled, does push even work? If SW cache cleared, do you still get messages and a SW cache can get respawned? IDK!

Ask stoically

Will do and let you know.

Be aware though, and I'm not the one to ask, but there are instances of / bugs where persistent data is NOT being cleared. I think one of them is cases of thousands and thousands of IDB folders, and users are using scripts to clear em out.

That's bollocks. I noticed that some users reported this, but IDK where the get those. On Windows in "my" profile I can see those only for current active opened containers and no more, which is expected.
Maybe is some non-win problem... as said IDK where they get those.

Cheers

Yeah, let us know. I didn't mean it was common, otherwise there would be lots of screaming and we'd all know about it. I said to be aware that there are instances, which are clearly happening to those people :) I need some sleep .. night all

The stuff seems to be controlling both GUI toast notification and Push:

https://dxr.mozilla.org/mozilla-central/source/browser/modules/PermissionUI.jsm#768
https://dxr.mozilla.org/mozilla-central/source/dom/push/PushService.jsm#1188
https://dxr.mozilla.org/mozilla-central/source/dom/notification/Notification.cpp#219

I wouldn't worry about it. "Notifications" covers both web notifications and push notifications

It seems they are exploiting the ambiguity of naming to different things with the same name.

P.S. Service workers seem to have no permissions at all - a yet another big flaw.

Is Service Workers (SW) cache isolated by TC and when container is destroyed is the SW cache also cleared/destroyed?

Yep, you can check about:serviceworkers and see that they have ^userContextId= attached. Which means they are inside the container, and are also removed when the container is removed.

https://github.com/stoically/temporary-containers/issues/253#issuecomment-487673231

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Thorin-Oakenpants picture Thorin-Oakenpants  路  7Comments

GIPeon picture GIPeon  路  3Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  4Comments

crssi picture crssi  路  3Comments

earthlng picture earthlng  路  6Comments