8 ms·

I believe it is essential for Firefox to allow installing extensions in a private way that does not force us to upload our source code to Mozilla, especially co

I believe it is essential for Firefox to allow installing extensions in a private way that does not force us to upload our source code to Mozilla, especially considering their renewed push for user privacy. It could be a feature that can only be enabled from the browser UI, with appropriate warnings, but the choice must be offered for those who need it. Until that happens, those with private extensions must resort to compiling their own browser, use unbranded or developer builds, or patch Firefox at runtime to disable signature checks. This is how you allow unsigned extensions in Firefox on Arch Linux, the same files can be edited on Windows and macOS, restart the browser after changes: sudo tee /usr/lib/firefox/defaults/pref/config-prefs.js &>/dev/null <<EOF pref("general.config.obscure_value", 0); pref("general.config.filename", "config.js"); pref("general.config.sandbox_enabled", false); EOF sudo tee /usr/lib/firefox/config.js &>/dev/null <<EOF // keep this comment try { Components.utils .import('resource://gre/modules/addons/XPIDatabase.jsm', {}) .XPIDatabase['SIGNED_TYPES'].clear(); } catch (ex) { Components.utils.reportError(ex.message); } EOF

Wowfunhappy 7y ago
At minimum, Unbranded should be able to automatically update itself, so that it can be a legitimate choice for users.
Vinnl 7y ago
> use unbranded or developer builds Is that such a problematic thing?
- dessant 7y ago
  Unbranded builds do not auto-update, and Firefox Developer Edition is based on Firefox Beta, so it can be less stable than the release build.
  - Vinnl 7y ago
    Auto-update would be convenient indeed. That said, Developer Edition is really very stable, so while I see why you would not want that, it's not that bad a stop-gap measure until unbranded builds auto-update.
    - dessant 7y ago
      It's perplexing that Mozilla insists on forcing signature checks at any cost in release builds, when there is no consensus on the fundamental reason for doing so. > Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. https://wiki.mozilla.org/Add-ons/Expired-Certificate-Technical-Report#Recommendations https://wiki.mozilla.org/Add-ons/Expired-Certificate-Technic...
cesarb 7y ago
> It could be a feature that can only be enabled from the browser UI, with appropriate warnings That's not the issue. The problem is: where do you record the fact that the user has seen and acknowledged these warnings? Wherever it is, malware can go there and write "yes, the user has already seen the warnings, no need to ask them, you can run the extension".
- dessant 7y ago
  You request administrative rights to store the configuration change. With root access malware can just replace Firefox. Even with signature checks enabled malware can trick users by pointing Firefox shortcuts to a patched browser, changing shortcuts doesn't require root access.
- Groxx 7y ago
  Why not in the OS's keyring?
- mirimir 7y ago
  But here's the thing: It's my browser, not Mozilla's.
- Thorrez 7y ago
  Once there's malware on the system you've completely lost, there's nothing Firefox can do ever, so there's no point in trying to provide any protection in that case.
  - bzbarsky 7y ago
    That depends. If the malware (and to be clear, "malware" here includes various anti-virus vendors and other gray-hat software that is nominally providing the user a service but _also_ attempting to insert itself into Firefox) is only running with the privileges of the user, it can't modify the Firefox install itself, if that install requires administrator access (sudo on Linux, etc) to modify. That gives you a trusted place to bootstrap from. The addon database is stored in the user's profile, so _can_ be edited by such malware, but that's where the the trusted code could try to verify integrity in some way. Which is how we got where we are now. Disclaimer: I work on Gecko, not extensions and the "things injecting into the browser" situation, but have overheard a bunch of discussions about it.
cmroanirgo 7y ago
I for one am OK with Firefox's mandatory code signing. In fact I prefer it over Chrome's. At least with Firefox you can then publish the extension using your own servers, whereas with Chrome you must use their store, even though it will be hidden from the general public. Thus, I don't really understand your statement: > those with private extensions must resort to compiling their own browser I certainly would never recommend such a thing, myself. If I were paranoid about 3rd party access to my extension to the point I felt I needed to compile by own browser, then one thing I'd certainly do is also disable addons and build mine right into the core product... I'd certainly trust Mozilla far more than I can trust every addon out there that might coexist with my private addon, which is where most of the attack surface would come from (if such were my threat model).
- mehrdadn 7y ago
  What's the main difference for you between using their store vs. your own server?
- dessant 7y ago
  Chrome allows installing unsigned extensions by enabling developer mode in chrome://extensions. On browser startup you'll see a warning [1] that encourages you to disable unsigned extensions, but users are offered a choice. I do trust Mozilla, though I'd prefer if they'd also trust me to be capable of making an informed decision and give me a choice while using their product. [1] https://i.imgur.com/iGEYMwv.png https://i.imgur.com/iGEYMwv.png
  - Spivak 7y ago
    Do you not consider "run the Developer edition" of Firefox to be a choice?
    - girst 7y ago
      My distribution packages regular Firefox, but not the Developer Edition (or ESR). This is a showstopper for me.
    - 7y ago
girst 7y ago
You may want to keep an eye on https://bugzilla.mozilla.org/show_bug.cgi?id=1514451 https://bugzilla.mozilla.org/show_bug.cgi?id=1514451 -- mozilla wants to remove general.config.sandbox_enabled (again) in the future.

Wowfunhappy 7y ago

At minimum, Unbranded should be able to automatically update itself, so that it can be a legitimate choice for users.

Vinnl 7y ago

> use unbranded or developer builds Is that such a problematic thing?

dessant 7y ago
Unbranded builds do not auto-update, and Firefox Developer Edition is based on Firefox Beta, so it can be less stable than the release build.
- Vinnl 7y ago
  Auto-update would be convenient indeed. That said, Developer Edition is really very stable, so while I see why you would not want that, it's not that bad a stop-gap measure until unbranded builds auto-update.
  - dessant 7y ago
    It's perplexing that Mozilla insists on forcing signature checks at any cost in release builds, when there is no consensus on the fundamental reason for doing so. > Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. https://wiki.mozilla.org/Add-ons/Expired-Certificate-Technical-Report#Recommendations https://wiki.mozilla.org/Add-ons/Expired-Certificate-Technic...

cesarb 7y ago

> It could be a feature that can only be enabled from the browser UI, with appropriate warnings That's not the issue. The problem is: where do you record the fact that the user has seen and acknowledged these warnings? Wherever it is, malware can go there and write "yes, the user has already seen the warnings, no need to ask them, you can run the extension".

dessant 7y ago
You request administrative rights to store the configuration change. With root access malware can just replace Firefox. Even with signature checks enabled malware can trick users by pointing Firefox shortcuts to a patched browser, changing shortcuts doesn't require root access.
Groxx 7y ago
Why not in the OS's keyring?
mirimir 7y ago
But here's the thing: It's my browser, not Mozilla's.
Thorrez 7y ago
Once there's malware on the system you've completely lost, there's nothing Firefox can do ever, so there's no point in trying to provide any protection in that case.
- bzbarsky 7y ago
  That depends. If the malware (and to be clear, "malware" here includes various anti-virus vendors and other gray-hat software that is nominally providing the user a service but _also_ attempting to insert itself into Firefox) is only running with the privileges of the user, it can't modify the Firefox install itself, if that install requires administrator access (sudo on Linux, etc) to modify. That gives you a trusted place to bootstrap from. The addon database is stored in the user's profile, so _can_ be edited by such malware, but that's where the the trusted code could try to verify integrity in some way. Which is how we got where we are now. Disclaimer: I work on Gecko, not extensions and the "things injecting into the browser" situation, but have overheard a bunch of discussions about it.

cmroanirgo 7y ago

I for one am OK with Firefox's mandatory code signing. In fact I prefer it over Chrome's. At least with Firefox you can then publish the extension using your own servers, whereas with Chrome you must use their store, even though it will be hidden from the general public. Thus, I don't really understand your statement: > those with private extensions must resort to compiling their own browser I certainly would never recommend such a thing, myself. If I were paranoid about 3rd party access to my extension to the point I felt I needed to compile by own browser, then one thing I'd certainly do is also disable addons and build mine right into the core product... I'd certainly trust Mozilla far more than I can trust every addon out there that might coexist with my private addon, which is where most of the attack surface would come from (if such were my threat model).

mehrdadn 7y ago
What's the main difference for you between using their store vs. your own server?
dessant 7y ago
Chrome allows installing unsigned extensions by enabling developer mode in chrome://extensions. On browser startup you'll see a warning [1] that encourages you to disable unsigned extensions, but users are offered a choice. I do trust Mozilla, though I'd prefer if they'd also trust me to be capable of making an informed decision and give me a choice while using their product. [1] https://i.imgur.com/iGEYMwv.png https://i.imgur.com/iGEYMwv.png
- Spivak 7y ago
  Do you not consider "run the Developer edition" of Firefox to be a choice?
  - girst 7y ago
    My distribution packages regular Firefox, but not the Developer Edition (or ESR). This is a showstopper for me.
  - 7y ago

girst 7y ago

You may want to keep an eye on https://bugzilla.mozilla.org/show_bug.cgi?id=1514451 https://bugzilla.mozilla.org/show_bug.cgi?id=1514451 -- mozilla wants to remove general.config.sandbox_enabled (again) in the future.