Webext Flagfox doesn't work if workers are disabled

Any feedback, suggestion, bug reports, problems....
Post Reply
WorkersUnite
Posts: 3
Joined: Tue Feb 06, 2018 4:35 pm

Webext Flagfox doesn't work if workers are disabled

Post by WorkersUnite » Tue Feb 06, 2018 4:47 pm

The webextension version of Flagfox doesn't work if web workers are disabled using dom.workers.enabled = false . It doesn't show any flags in the address bar and the Flagfox options page is broken. When dom.workers.enabled is switched back to the default true, everything works fine.

Maybe you already knew this but it could be useful to tell it to users somewhere like on the AMO page or on your addon site because it could take them some time to diagnose by themselves why Flagfox is broken if they block workers. Especially considering that it's the only addon I have that broke because of workers being disabled, and also that the previous, non webextension, versions of flagfox worked fine for people disabling workers.

It would be even better if Flagfox could work without having to enable workers but I understand this might not be possible.

Firefox 58.0.1 x64 on windows 7 x64, Flagfox 6.0.1.

User avatar
DaveG
Flagfox Developer
Posts: 723
Joined: Wed Oct 03, 2007 9:06 pm
Location: Philadelphia, USA

Re: Webext Flagfox doesn't work if workers are disabled

Post by DaveG » Wed Feb 07, 2018 7:36 am

I'm curious as to why you'd disable workers at all. Is there something it can break?

It's a little odd that Mozilla doesn't have separate web & browser/addon prefs here, as they have for many things in the past, but apparently that's the case.

Flagfox 6.0+ runs the IPDB in a worker, so it is required to function. I do not intend to change that. There are of course other addons that use workers, and I expect that more will do so in the future.

As to how we got to this issue here, however: the dom.workers.enabled pref appears to be going away. I did a quick search and it looks like Mozilla removed it for Firefox 60+, only 5 days ago. They tend to add these switches for new features so they can test them more easily and disable them if they screw something up, but they are rarely intended to be permanently available. If this change rides the trains as scheduled (which it may or may not) then this pref will no longer work when Firefox is updated to version 60 on 2018-05-08.

WorkersUnite
Posts: 3
Joined: Tue Feb 06, 2018 4:35 pm

Re: Webext Flagfox doesn't work if workers are disabled

Post by WorkersUnite » Wed Feb 07, 2018 9:46 am

Thank you for your answer !
I don't think workers break anything, it's rather the opposite, disabling them may break sites although rarely enough for me, and as I discovered here, extensions too.

But I disable them as a general safety measure because it's yet another powerful tool in the hands of website owners to run javascript crapware on my computer that may spy, cryptomine and so on. More generally I don't like the idea of websites having with every new browser feature more power to run stuff however they want on my machine (like push notifications, webRTC to steal my upload bandwidth without asking or even notifying, ...) so I'm very careful with what new features I activate and I often distrust them by default. I enable workers on the very few sites I have met that require them. Consider this a less extreme version than disabling javascript by default except on trusted sites. The ghacks user.js disables workers by default too, with a similar mindset I think. I disable service workers too (dom.serviceWorkers.enabled=false), I don't like sites installing persistent things on my browser that stay here when I leave the site. There is also the concept of a "shared worker" that doesn't sound that good for privacy.

And Mozilla can't be trusted not to implement potentially user hostile features, we have to investigate dangers by ourselves. I didn't know they planned to forbid disabling workers, but it's typical arrogance from them. Well I'll probably find a way to block them globally using uBlock Origin, with the benefit of being able to add site exceptions and not break extensions. Not giving independent switches for extension and site workers also smells like Mozilla's way of forcing us to use features, they did the same thing with webextension and website storage having to be allowed/cleared together or not at all, breaking lots of webextensions for those who don't let sites store whatever they want locally. It may also be related to a suspect underlying Mozilla philosophy that blurs the line between local code and website code in preparation for the future.

User avatar
DaveG
Flagfox Developer
Posts: 723
Joined: Wed Oct 03, 2007 9:06 pm
Location: Philadelphia, USA

Re: Webext Flagfox doesn't work if workers are disabled

Post by DaveG » Wed Feb 07, 2018 10:21 pm

WorkersUnite wrote:
Wed Feb 07, 2018 9:46 am
But I disable them as a general safety measure because it's yet another powerful tool in the hands of website owners to run javascript crapware on my computer that may spy, cryptomine and so on.
Workers are basically useless for attempting to spy/track/etc. They're just a way to run JS in another thread, and they're cut off from lots of other things they'd normally be able to access. I suspect they'd get used for cryptocurrency minning (for the love of all that is good, please don't call it "crypto"), but banning workers because it could be used to mine would be like banning cars because it could be used to rob a bank. If you're worried about coinminer crap, I'd suggest looking into using the blocklist maintained for exactly that:
https://github.com/hoshsadiq/adblock-nocoin-list/

I've been using it myself, and it hasn't caused any issues.
WorkersUnite wrote:
Wed Feb 07, 2018 9:46 am
More generally I don't like the idea of websites having with every new browser feature more power to run stuff however they want on my machine (like push notifications, webRTC to steal my upload bandwidth without asking or even notifying, ...) so I'm very careful with what new features I activate and I often distrust them by default.
That's a recipe for lots of mysterious breakage. I'm not aware of WebRTC doing anything without prompting. In general, run an adblocker, but beyond that, singling out new features is not a thing I'd recommend (usually). You're also likely to miss stuff you'd want to stop if you focus on features.
WorkersUnite wrote:
Wed Feb 07, 2018 9:46 am
I didn't know they planned to forbid disabling workers, but it's typical arrogance from them.
No, they've done some stupid stuff, but this is routine and normal. Web Workers are a built-in feature of the standard JS API. The pref was never intended to be permanent and removing it after it's no longer needed is the right call. The last thing Mozilla needs is to have more switches that leave for confusing compatibility issues and just add maintenance and security attack surface to worry about. There are some features that should probably be disableable on-demand, but I don't think workers is one of them.
WorkersUnite wrote:
Wed Feb 07, 2018 9:46 am
It may also be related to a suspect underlying Mozilla philosophy that blurs the line between local code and website code in preparation for the future.
Yeah, they have been moving in that direction. Sometimes this is a good thing and other times it's bad.

If you want to see something that I think will warrant the level of scrutiny you're putting here, wait until WebAssembly starts getting used everywhere. Even then, it's still memory safe sandboxed code. It'll just be completely opaque memory safe sandboxed code... :|

WorkersUnite
Posts: 3
Joined: Tue Feb 06, 2018 4:35 pm

Re: Webext Flagfox doesn't work if workers are disabled

Post by WorkersUnite » Thu Feb 08, 2018 5:54 pm

Thanks for you advices on workers, I will think about it.
DaveG wrote:
Wed Feb 07, 2018 10:21 pm
I'm not aware of WebRTC doing anything without prompting.
There was a controversy about "P2P CDN" like Edgemesh that steal users' upload bandwidth with webRTC :

https://news.ycombinator.com/item?id=15132811
https://github.com/uBlockOrigin/uAssets/issues/659

It's said several times in the first link that the users are not even notified that this is happening. If this is true it's quite shocking that Mozilla implemented it this way, but I didn't actually check myself that there wasn't any prompt.
uBlock Origin also has a "Resource abuse" internal list that blocks such bandwidth theft in addition to coin miners.
DaveG wrote:
Wed Feb 07, 2018 10:21 pm
If you want to see something that I think will warrant the level of scrutiny you're putting here, wait until WebAssembly starts getting used everywhere. Even then, it's still memory safe sandboxed code. It'll just be completely opaque memory safe sandboxed code... :|
That doesn't sound good, indeed.

Post Reply