User.js: SWs (2302) and push (2306)

[Thorin-Oakenpants]

re: https://github.com/ghacksuserjs/ghacks-user.js/commit/7b667db7669155952323bf0aad2894cd09b32728

@claustromaniac said

FWIW, disabling SW alone does not stop Firefox from making requests to push.services.mozilla.com. Disabling Push (via the above prefs) does.

@Thorin-Oakenpants said

please open a new ticket so I can track it: thanks

[Thorin-Oakenpants]

I don't understand this fully: someone give me a ELI5 flowchart :) Does it stop the websites popping up notifications? i.e what role does push.services.mozilla.com play in the mechanism? What is being sent that affects privacy/security/tracking? I'm also probably mixing up notifications and push, and have never really understood them

I'm not in a good position anecdotally as I block all cookies which in turn renders SW's dead as a door-nail. I have never seen a web notification in my main everyday FF browser... ever.

[claustromaniac]

In that commit you commented out the prefs that disable push because, as I originally pointed out, push also requires SW, which was already disabled. What I was pointing out in that then-new comment was that, without properly disabling push, Firefox still polls push.services.mozilla.com (unnecessarily). Does that represent a risk? probably not. If you trust Mozilla and its associates/providers and you don't care whether Firefox makes unnecessary requests or not, then maybe you shouldn't care about these push requests. See the problem? That's a subjective matter.

Just to be clear, I wasn't suggesting any particular course of action, which is why I didn't open a new issue when you asked me to, and is also why I didn't open a new issue in the first place. I was merely informing folks (not just you) that disabling SW does not prevent those unnecessary requests from happening.

As for what's the deal with push.services.mozilla.com, my guess (without giving the whole thing significant inspection, because I don't use push or notifications either, and I'm not that interested - so don't quote me on this, unless it's just for fun) is that it is used as a way for web servers to talk to clients as if the latter were servers (which is how push is meant to work). By definition, TCP clients (like browsers) can't take inbound connections (only servers can), so when web servers want to push notifications to clients they speak to another server instead (push.services.mozilla.com), saying something like "yo dawg, I want this user to get this here notification ASAP", and then the push server just waits around for the client to poll (which constitutes an outbound connection). The client doesn't know when there will be a push notification available, so it just polls the push server at regular intervals, asking something like "Excuse me, do you have any new notifications for me?", and the push server then replies with either "not at this time" or with "my dude! this here server wants you to show this notification to your lame-ass user".

I hope that explanation is ELI5 enough, because I won't be doing any further 'splaining, because I never cared what you end up doing with these push-related prefs.

[Thorin-Oakenpants]

^^ awesome. "Firefox still polls push.services.mozilla.com (unnecessarily). Does that represent a risk? probably not." .. that's what I thought it might be about

Just to be clear, I wasn't suggesting any particular course of action...

That's cool: I understood that. I should have filed a new issue myself for followup, because when you say things, I pay attention: and I learn things ("I drink and I know things" doesn't always work, god knows I've tried 🍻 ).

I hope that explanation is ELI5 enough

Yup. My five is like everyone else's four: and it sufficed :)

[claustromaniac]

when you say things, I pay attention: and I learn things.

Likewise.

("I drink and I know things" doesn't always work, god knows I've tried 🍻 ).

You drink, therefore you are. Not that that's relevant though.

Just in case, I will emphasize that my speculations above (the part after I say don't quote me on this) are just that. Consider them a likely explanation for why push.services.mozilla.com exists, and an example of how Firefox might be using it. I know neither the Push specification (in detail), nor Mozilla's implementation, and I don't plan to research that anytime soon. You're better off asking your mozillian/tor contacts if you want actual details.

[Thorin-Oakenpants]

I plan to. Seems like an enhancement bug: if SW are unavailable (PB mode, pref), then they shouldn't poll the service: would save on network requests/traffic: IDK the numbers: they can do the number crunching: scales of economy and all that

[Thorin-Oakenpants]

I reached out to spammed 😀 @tomrittervg who said that "This behavior should be governed by dom.push.enabled - not ServiceWorkers" .

FWIW: TB disables push as follows

• https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-60.8.0esr-9.0-1#n255

   // user_pref("dom.push.enabled", false); <-- this might be default false in ESR?
   // user_pref("dom.push.connection.enabled", false); <-- I guess this is not needed
user_pref("dom.push.serverURL", "");
   // user_pref("dom.push.userAgentID", ""); <-- I assume it is never set by code

Our description is correct, in that without SW's notifications and push don't work. And I don't see any issue with polling a Mozilla server: I'll leave it up to Tom to decide if it's feasible to tie the polling to the pref and PB mode: maybe it adds unnecessary complexity, maybe the savings in pollings isn't worth it.

---

@earthlng : since you bumped this, I'm waiting on your input. Did you want us to make this active? Or add an extra note?

[claustromaniac]

They didn't tie the polling to SW in the first place probably because that would go against unit testing. They do that.

[Thorin-Oakenpants]

Well, I'm not a Mozilla engineer, but I bet they could easily do it. The question is do they want to: i.e do any benefits (less app overhead, faster startup, less push server traffic) outweigh the cost/complexity to implement and maintain? And that, I don't need to think about any more.

As far as privacy/security/tracking: I think we've done that. I have no issues with background polling of a mozilla server, and our my original decision during the snappening means end users only need flip a single pref to get back usability.

Slightly OT: Another thing to note re web notifications is that most are blocked now without user interaction (because most pop up as soon as you land on the web site). I think the figure was 90%

Just waiting on the earthman.... so I can close this

[claustromaniac]

By pure chance, I noticed the default value of dom.push.serverURL is actually wss://push.services.mozilla.com/, which means they use WebSockets for this, which in turn means the mechanism is far more complex and interesting than my initial guess. Now my guess is they use a single central server for that service so that clients only need to maintain a single connection to get all their push notifications, which is probably best for performance, and there are probably other reasons. I actually may want to investigate this later.

Just waiting on the earthman.... so I can close this

OK. I'm outta here.

[tomrittervg]

So Service Workers are required for push to display notifications, but I think only the dom.push.enabled pref is needed to poll the server and get notifications. The SW is responsible for finding it and displaying it. This seems to line up with @claustromaniac is saying, so I think we're in agreement.

[earthlng]

https://support.mozilla.org/en-US/kb/push-notifications-firefox#w_what-information-does-firefox-use-to-provide-web-push

Firefox maintains an active connection to a push service in order to receive push messages as long as it is open. The connection ends when Firefox is closed. On our server we store a randomized identifier for your browser, along with a randomized identifier for each site you authorize.

On Firefox for desktop, the push service is operated by Mozilla. Firefox for Android uses a combination of the Mozilla Web Push service and Google’s Cloud Messaging platform to deliver notifications to Firefox for Android.

In both cases, push messages are encrypted per the IETF spec and only your copy of Firefox can decipher them. The encrypted messages are stored on the server until they are delivered or expire.

---

Did you want us to make this active?

yes. Since all this shit requires SW which we currently disable, there's no point in opening a background connection to the push server. Who cares if people who want/need this stuff need to override more than 1 pref?!

Slightly OT: Another thing to note re web notifications is that most are blocked now without user interaction

really? Isn't that behind dom.webnotifications.requireuserinteraction which is still default false in FF69?

[Thorin-Oakenpants]

dom.webnotifications.requireuserinteraction - probably. Sorry, I haven't kept up with it since I'm not actively interested, I read an article about it in what seems like a very long time ago. FWIW it's true in 70

[Thorin-Oakenpants]

there's no point in opening a background connection to the push server

I agree. It's a bit pointless: hence why I thought it would be a good enhancement for Mozilla. Not my call. But where is the privacy, security, tracking issue with opening a connection to a Mozilla push server when the service isn't actually used (due to SW being disabled)?

Resetting the userAgentID in about:config: it gets a new one within a few seconds (I'm using the four push prefs at default). Who gets this ID ... if only Mozilla sees it, then that is not an issue. Maybe this could be a good pref to make active so every session you get a new ID (for those who want push/notifications).

Who cares...

I do. Not just for people who want SW's, but everyone. I want to reduce complexity and barriers to uptake.

I'm open to changes, but I just don't see an issue here from our primary goal

[rusty-snake]

But where is the privacy, security, tracking issue with opening a connection to a Mozilla push server when the service isn't actually used

Any unneeded connection is an unnecessary potientelles security risk. That's my opinion, other opinions are being tolerated.

[Thorin-Oakenpants]

I wouldn't call that a good argument - all your connections to the internet are a potential security risk in that case.

I'm more interested in what Tom said (emphasis mine)

So Service Workers are required for push to display notifications, but I think only the dom.push.enabled pref is needed to poll the server and get notifications. The SW is responsible for finding it and displaying it

If SW's are disabled, can web sites even attempt to send notifications? Can anyone get your ID (apart from Mozilla)?

[claustromaniac]

Here's the W3C Push API spec:

https://www.w3.org/TR/2019/WD-push-api-20190724/

If SW's are disabled, can web sites even attempt to send notifications? Can anyone get your ID (apart from Mozilla)?

This claustromaniac can't tell you how Mozilla implemented the server-side aspects, but, if they followed the spec (and assuming I understand correctly), the answer to the first question is no, and the answer to the second one is also no. Edit: well, maybe Google in Firefox for Android (see @earthlng's comment above)

The push server (referred to as push service in the draft) has to assign an individual endpoint to each subscription, and that's how the service can keep your ID private while still allowing the web application to send notifications to YOU. They need to get your permission for this first - now the question is, can they request that permission if you have SW disabled? I'm not sure, but if they want to use push notifications legitimately, they will generally inform you that you need SW for that, otherwise you could think the site is broken. That being said, I don't know the answer to this question (yet), but if they could request your permission with SW disabled, I'd consider that an oversight.

Setting the ID to an empty string would surely break past subscriptions. People who want to use Push may or may not want this, so I wouldn't add that pref active if I were you.

[Thorin-Oakenpants]

Setting the ID to an empty string would surely break past subscriptions

That's a good point: both for wiping it and retaining it

[Thorin-Oakenpants]

I think what we can do here is clean up a little bit of info in the user.js and just do what TB do: and that is to blank the push serverURL as an active pref

[Thorin-Oakenpants]

@claustromaniac

Can you confirm that dom.push.enabled alone blocks the polling? If so, then that's good enough for me. I'll make that active. And I'll fixup the note in 2302. If that's all that is needed, then I'll remove dom.push.serverURL as well.

push.connection.enabled seems to be redundant, or rather used internally? DXR e.g https://dxr.mozilla.org/mozilla-central/source/dom/push/PushService.jsm#555 - I'll dig some more. Update: in about a dozen bugzillas, I see this being used to disable/block push in tests

userAgentID can stay inactive: but I'll keep it

---

In 1542244 , they only set dom.push.connection.enabled = false to disable the feature.

TB have dom.push.enabled as false, and blank the URL (probably as defence in depth)

[claustromaniac]

Can you confirm that dom.push.enabled alone blocks the polling?

Yes.

[Thorin-Oakenpants]

^^ Cool

[Thorin-Oakenpants]

   // user_pref("dom.push.enabled", false); <-- this might be default false in ESR?

Yes: dom.push.enabled is default false in ESR. Interestingly, the two webnotifications ones aren't. ESR60. The same is true in TB.

[Thorin-Oakenpants]

Ahh .. and now I see ... https://developer.mozilla.org/en-US/docs/Web/API/Notification .. even with service workers disabled, I get a web notification ... I'm starting to piece it together

... edit .. and same on Tor Browser. Since FPI is in force, there's no privacy/tracking issue here.

[Thorin-Oakenpants]

In terms of push, you'd have to grant a website permission first (and have SW running to do so). Otherwise it wouldn't send you anything (and you couldn't grant permission). Once "subscribed", that website will send (self-expiring) messages for you on the Mozilla push server under your userAgentID - i.e you can receive messages "whether or not the web app is even currently loaded". And you wouldn't actually need any SW running to receive them. But you would to display them. I think I follow that now.

[Thorin-Oakenpants]

^^ if you have any nits, let me know