Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: set 4503 `*block_mozAddonManager` to active #259

Closed
Thorin-Oakenpants opened this issue Oct 19, 2017 · 14 comments

Comments

@Thorin-Oakenpants
Copy link
Member

commented Oct 19, 2017

privacy.resistFingerprinting.block_mozAddonManager which landed in FF57 will allow uBlock Origin (and other extensions) to work on zilla's three protected hard-coded domains, the only one we really care about is AMO itself (godamn GA) - the downside is that AMO will always get your spoofed UA from RFP. Personally this is not a big deal

  • there is no guarantee yet that the new AMO will use the mozAddonManager
  • come 57, its all WE anyway and breakage within WE is likely to be rare (but of course extension devs can set min FF version numbers as APIs open up)
  • its no big deal to just download the file as an xpi and install if from local

I guess someone better test it first. Anyone running 57/58 with uBo? Just implement a cosmetic filter to detect the diff (or block GA and sniff your traffic)

@earthlng

This comment has been minimized.

Copy link
Member

commented Oct 21, 2017

to work on zilla's three protected hard-coded domains

I'm pretty sure that's not what this pref does.

AMO will always get your spoofed UA from RFP

because of this I think keeping the pref inactive is better for most people

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Oct 21, 2017

I think you are misunderstanding what I am proposing this for - I do not care about the UA, and YES, the new AMO may use this method but it has not been decided - I am proposing this so AMO is no longer protected from extensions - hence my auto copy will work, hence uBo can still block GA, user styles will be able to be applied etc

@earthlng

This comment has been minimized.

Copy link
Member

commented Oct 21, 2017

I am proposing this so AMO is no longer protected from extensions

and I am saying that this is not what this pref does :)

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Oct 22, 2017

I guess someone better test it first

Which is why I said the above. The reason I mentioned this whole thing at all is that in a bugzilla it was mentioned that this was a workaround (side-effect) and someone else confirmed it AFAICanRemember (and no-one disputed it) - PS: I have no idea what zilla that was now

@Atavic

This comment has been minimized.

Copy link

commented Oct 22, 2017

This one?

its no big deal to just download the file as an xpi and install if from local

Yep, that's me! I do that for security reasons, as if someone gets a malicious extension, there's a possible problem: https://bugzilla.redhat.com/show_bug.cgi?id=1395101

@earthlng

This comment has been minimized.

Copy link
Member

commented Oct 30, 2017

ok you were right, I was wrong, sorry for doubting you :)
Up to you if you want to make it active. IMO inactive is fine because users need to understand what the pros and cons are and then make the decision themselves.

the downside is that AMO will always get your spoofed UA from RFP.

the upside is that you can use an extension to send the real UA to AMO.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Oct 31, 2017

UA - I have not tested with any extensions, does an extension override RFP? i.e does it inject it's changes after RFP looks up its bits?

The upside is that AMO will now be treated like any other page. I am not worried about AMO tracking, and at the end of the day - 1 site & GA (first party isolated) is not a big deal. I am not even sure GA gets anything because FF blocks all cookies by default - or use a site block exception). But I will be glad I can remove some elements via uBo picker.

The downside is, and I need to check, that some protections for AMO are now removed - something about injected scripts can now cause silent extension installs. I am not 100% convinced of this

from https://www.reddit.com/r/firefox/comments/792209/psa_use_hidden_pref/

AMO has permissions to install add-ons without the permission prompt (regardless of the pref enabled), and since WE now have access to AMO, they can take advantage of that to silently install malicious add-ons.

There's a loophole in this pref that gives WebExtensions access to mozAddonManager. Add-ons can register a Service Worker that makes use of mozAddonManager, then once that pref is turned off, the add-on has full access mozAddonManager.

So... a user must be on AMO, and another WE you have installed needs to be rogue, and service workers must be enabled. [As for his FP'ing downside - there is none (it is AMO only) - if you have a rogue extension you have bigger issues]


What to do ... I think I will leave the pref inactive (security trumps privacy in general), but add some more info (personally I will flip this in 57). If it's good enough for TBB ... but I want to check the security claims

@earthlng

This comment has been minimized.

Copy link
Member

commented Oct 31, 2017

UA - I have not tested with any extensions, does an extension override RFP?

I don't think so but you can always change the UA header regardless of RFP.

something about injected scripts can now cause silent extension installs.

Thanks for the quotes. I think the first part can be easily disabled by setting permissions.manager.defaultsUrl to an empty string. I actually suggested to set this a long time ago. The 2nd part sounds like a bug. So ... extensions can know and possibly change information about other installed extensions? anything else that's possibly worse? It kind of doesn't matter whether it can change information in the mozAddonManager because with the pref enabled it's never used anywhere anyway, right? I can't quite wrap my head around the potential problems tbh other than information leakage about installed extensions.

(personally I will flip this in 57)

I already have it set and I'm still on ESR xD

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 1, 2017

The current value in 56 is resource://app/defaults/permissions. I don't exactly follow what this "permissions" thing is. If it is set to blank, does this affect manually installing from AMO (I assume not, as I can still install from places like github), and does it affect manually updating via addons panel? Where do we put it and how do we word it?

/* xxxx: remove default permissions **blah blah** (FF35+)
 * [1] https://bugzilla.mozilla.org/show_bug.cgi?id=506446
 * [2] https://dxr.mozilla.org/mozilla-central/source/browser/app/permissions ***/
user_pref("permissions.manager.defaultsUrl", "");
@earthlng

This comment has been minimized.

Copy link
Member

commented Nov 6, 2017

does this affect manually installing from AMO

no, I have the pref set to blank for a while and can still install from AMO. I think all it does is show a prompt instead of silently allowing it to install.

and does it affect manually updating via addons panel?

nope

Where do we put it and how do we word it?

2600 as something like "xxxx: remove special permissions for certain mozilla domains". I don't think we need link [1] and instead of [2] maybe directly linking to resource://app/defaults/permissions would be better because it shows the permissions for your current FF version instead of the one for the latest nightly.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 6, 2017

^^ sounds good to me - feel free to do a direct commit

PS: Are u sure resource://app/defaults/permissions can be loaded in 57+
Edit: I do not have a 57 handy: I assume it can since it's not "web" content / mixed

@earthlng

This comment has been minimized.

Copy link
Member

commented Nov 6, 2017

yes it can be loaded in FF58.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member Author

commented Nov 7, 2017

https://bugzilla.mozilla.org/show_bug.cgi?id=1406795 - didn't link to this earlier, but seems Zilla aren't concerned about the (possible) privilege escalation

Thorin-Oakenpants added a commit that referenced this issue Nov 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.