Firefox to Discontinue Sideloaded Extensions | Hacker News Reader

Firefox to Discontinue Sideloaded Extensions

blog.mozilla.org

432 pointsrahidz207 comments

This seems to be somewhat badly written copy on Mozilla's part. To clear up what this change actually means for an end user:

- You can still manually install extensions. From now on, all installations will need explicit user confirmation.

- No extensions can be installed silently. This is what sideloading did, all extensions in a special folder were installed in all Firefox instances on the computer without the user's consent.

This is most definitely a Good Thing, as it means for example no malicious extensions can be silently installed by malware etc. Communicating this change could've been done better, though.

"- You can still manually install extensions"

Yes, but not as XPI file. For manual installation, you can install similar to Chrome, that's from source code folder

Will Firefox stop copying Chrome's features that are hostile to power users at some point?

Probably not. There's a clear conflict between what (some) power users want and what the best/safest choices are for the general public. And, in general, mainstream platforms like Firefox should default to what's best for the general public. (Yes, you could have bypass mechanisms but backdoors like that are more or less asking for trouble.) See also Apple.

Added: It's not clear to me how "hostile to power users" this particular change is. But my general statement still applies.

It is not clear what is best for the general public.

You can aim for the "safest" choice, which seems to be what you are advocating. If so, it needs to be said explicitly and the implications of functionality reduction (that safety increases always brings) openly discussed and debated.

The model of claiming "we will do what is best for users" with a freedom to replace "best" by "X" has been thoroughly compromised by googles and facebooks of this world. We need to be explicit about goals and tradeoffs. Not attacking your post, just arguing for being clear and honest on goals of non-commercial software.

My 2c.

Yes, I'd argue "safest" is usually the best default for the general public. My reasoning is that a bit more fine-grained control, performance, choice, etc. doesn't have much upside for most people whereas getting compromised can be a very big downside.

Perhaps Firefox hasn't been very clear on its tradeoffs but Apple, for example, seems to have been IMO. (Yes, it tends to be wrapped in marketing rather than tech speak but I think they've been pretty consistent about their priorities.)

I personally have no objections (usually not even strong feelings) to setting defaults, as long as that's what they are -- default choices that users can change if they see fit.

But an option that cannot be changed is not a default choice -- it is a hard coded design decision. My 2c.

Firefox is open source. AFAIK you could always run a fork with your preferred behaviors. Same applies to speculative execution mitigations in Linux.

And so is, for example, Android. But due to some (shady) tactics, a successful fork of either is impossible for a small group. Saying to a hungry kid in a favela "you are free to get rich" is technically correct, but ignores practicalities.

You could argue that Mozilla is either a shepherd (making best decisions for most users and that's it; take it or leave it) or a partner (listen to users and try to implement features they want) but you cannot eat your cake and have it too.

What makes it nearly impossible to fork Firefox? Mozilla already distributes an unbranded "fork" that allows unigned extensions. It's just a build flag away. What potentially shady tactics am I missing?

What, specifically, is the feature you think Firefox is removing the option to have, that you think people want?

I suspect that if we drill down to this point, you'll find the feature is still available with a trivial amount of work, or on the outside case it's the more specific thing they actually talked about, it's not a trivial amount of work, but it's just not automated for enterprise installs anymore.

So, what's this feature you're referring to?

Manually installing extensions from an XPI file.

I also think the discussion moved to a more generic "safe default with options for users to change" vs "choices hard-coded based on perceived safety for general users".

> Manually installing extensions from an XPI file.

Everything I see indicates that is still supported. Especially if you read the comments to the post. XPI files seem to be supported, what they removed was the ability have an executable installer install them automatically.

The change, which seems to have been communicated poorly, seems to be that some actions within Firefox need to take place (allowing the user to opt-in to the extension) before it will be used by Firefox.

This comment[1] from Caitlin Neiman, who I just looked up on Google and appears to be the Firefox Addons Community Manager, states:

Developers will still be able to self-distribute, and you will still be able to install extensions from self-distributed (non-AMO) sources.

Going forward, developers won’t be able to distribute an extension through an executable application installer.

> I also think the discussion moved to a more generic "safe default with options for users to change" vs "choices hard-coded based on perceived safety for general users".

I'm pretty sure what they did is not hard coding choices. There are multiple ways to get an extension locally, the hardest of which but still works no matter what is installing the developer version and using source (XPI files can be unpacked).

What they actually did was lock down one method of installation which is almost never used by users and is used by orgs and malware, which is to drop extension into the plugin folder with the extension name as the folder name and have it automatically added to Firefox. Now they require you add it through the Firefox browser interface so the user has to opt-in to the extension.

1: https://blog.mozilla.org/addons/2019/10/31/firefox-to-discon...

They have those evil metrics about what users are doing.

If 1% of users are getting exposed to malicious software by a feature and 0.0001% of users are using it, it's a little more clear than you say. I've made both of those numbers up, but I think it's likely enough that very few end users are depending on the ability of other software to silently inject plugins.

> metrics

With the caveat that power users are probably the ones to have turned off metrics. Mozilla is probably aware of it, but it's still hard to compensate for that.

I do agree with you to a point. I do think they have a difficult task trying to balance protecting people from their own ignorance and catering to power users who know exactly what they are doing and desire more freedom.

An option that just occurred to me is to be able to start Firefox with a special flag that would give access to some extra options to allow actions that reduce security - such as sideloading for example.

To help prevent innocent users being coerced into starting Firefox with that flag it could be something like "Firefox.exe -pleasehackme".

Power users would know what the flag is for but even the most naive user might hesitate to start Firefox using a command inviting themselves to be hacked :-)

Probably a stupid idea, but just putting it out there.

That is a fine idea. We can make Firefox as safe as they want at startup. Just keep it as a default option -- something power users can turn off and do not make this a hardcoded choice "because those users turning it off may not know what are they doing". Inform, not restrict. My 2c.

They seem to agree, approximately: https://news.ycombinator.com/item?id=21418786

So now the malware edits the firefox shortcut to start it with that argument and then installs its malicious addons. That doesn't help at all.

Yeah, exactly. Malware could also just delete vanilla firefox and replace it with the developer edition. Just overlay ads over the browser window itself. Or anything else really.

Trying to protect against hostile code already running on the same computer as the browser is futile. At best, it should warn the user if suspicious modifications were made.

And it comes at such a high cost for such a narrow measure of protection.

That's a pretty weak argument. If you already have malware on your computer with enough privilege to change shortcuts then it's game over already.

This is about preventing the naïve from being tricked into manually installing malicious add-ons by a third party.

I don't think there is any way to enable unsigned extensions on vanilla Firefox, and I don't think they will ever allow it.

Their justification is that if there were some command line option to allow it, then users could be tricked into doing that.

But, couldn't the user not also be tricked into simply downloading the developer edition? Couldn't the user be tricked into deleting their home directory?

Personally, I find these justifications dubious. There is a kernel of truth that in some edge cases it can offer some protection. But it feels far more like something Google or Apple would do, and Mozilla is either cargo culting them, or has been pressured into doing this.

That's the point that mozilla name their signing-disabled firefox as 'unbranded'.

So hackers can't just download the signing-disabled firefox and replace your firefox with it.

The hacker can probably still compile one by their own, but at least it will makes them pain in the ass.

> The hacker can probably still compile one by their own, but at least it will makes them pain in the ass.

I've compiled a branded build of Firefox myself, and it is as simple as setting a single flag at compile time. Almost trivial. The only protection that branding has is legal, not technical. If I tried redistributing the branded build then Mozilla might sue me. Do you think they will be able to sue malware authors when they do it?

There is absolutely nothing stopping a hacker from replacing or patching Firefox.exe with a branded version that will run their hostile extension. Even if they do not have write access to Firefox.exe, they can download it somewhere else and change where the shortcut points to. It would be almost impossible to tell the difference.

This is not a serious security measure.

But I think you are missing the bigger point here. If they can write to files on your computer, then it is far too late. They can encrypt and ransomware your documents, they can install a keylogger, and they may be able to extract all of your passwords and cookies from Chrome and Firefox.

It would be like if someone stole your car, but at least they don't have the keys to the glove compartment.

It is not a justification for Mozilla is doing.

Not sure if that is what they do, but on many platforms, there is also code signing. E.g., even if you could trick someone to download your patched/hacked version of Firefox, I believe they'd get a warning on Windows that the software is unsigned.

>what the best/safest choices are for the general public.

Sometimes I think tech people forget 'the general public' is made up of adults capable of learning and making their own choices if educated properly on matters.

Sure. Most adults can learn lots of things. Most of us only care enough and have time enough to educate ourselves on a very small subset of the tools we use and tasks we perform on a daily basis. By and large, I trust the tools I use out of the box to be safe (subject to what common sense typical functional adults would be expected to have).

It is often reasonable to provide the option to use tools in ways that are less safe. Sometimes that's unavoidable. You can certainly use a chainsaw unsafely although I also think it's perfectly reasonable for chainsaw manufacturers to not provide easy ways to defeat the various safety mechanisms that are built in.

So you'd only buy a chainsaw with a codepad entry where you have to contact the manufacturer and ask them 'can I cut this log'; ooh, so much safer! But where does that leave the people who been buying that brand of chainsaw for a decade or more and don't want the restrictions?

Just remove the codepad, well yes, so long as the manufacturer doesn't weld it on ... oh, and they just decided to weld it on. Such safety, much wow.

How many topics do you have time and energy to be “educated properly” on? What are the odds that learning about the issue would lead to a different outcome than what Mozilla is doing? Firefox's openness means it attracts a lot of attention from people who have relatively uncommon preferences but believe they speak for a large group of users and that group tends to portray every disagreement as a betrayal rather than reasoned decisions.

I can properly educate myself on many, many things, especially over time. A major issue is correctly utilizing available time. In developed countries today, many "adults" would rather direct their time at very low-value activities, like having children and / or pet slaves, watching disgusting amounts of Netflix, wasting countless hours on Facebook ranting about personal issues or envying others, taking unnecessary and unproductive trips, etc.

While lots of readers will dislike this comment, are not ready to digest it, and will claim that I am wasting my time writing this comment, I think as a society we should prioritize creating competent humans who can appropriately use technology, whereas this move by Mozilla is just more of the same, prioritizing mindless consumers who have no idea how any of the things that their lives increasingly rely on function.

I think such consumers should be left to fend for themselves, as that is the only way a majority of people actually learn. This is especially true for Firefox, which has never been a "consumer" browser, and has always been a browser for people who wish to understand how it works and be able to modify it in a straightforward manner. If someone desires a browser that does whatever it wants without asking, Chrome is a perfectly fine option.

Do you really consider being able to provision your own profile a backdoor? I do it all the time. Do you think that Apple is a good example of what to do?

Having a single entity control what extensions you get to install is not what is best for the general public.

Personally, I think that Firefox should be the more flexible extensible alternative to Chrome. It should be to Chrome as Linux is to Windows.

They need to stop chasing the demographic that is going to hurt themselves.

>Do you think that Apple is a good example of what to do?

For certain purposes and audiences, yes.

In the end Firefox will anger power users and general public still will use Chrome because they can't resist when it's advertised from every corner (and, honestly, just works better).

No, I doubt they will. And thank you for voicing these concerns.

Power users should probably use unbranded versions of the browser that don't have these issues. AIUI, such versions are widely available, even from Mozilla themselves.

>don't have these issues

What issues does this change create?

Do unbranded builds get automatic updates now?

What exactly is hostile to power users here?

The documentation for self-distribution clearly shows the workflow for an XPI file: https://extensionworkshop.com/documentation/publish/submitti...

What gave you the impression that XPI files would not be supported?

That doesn't seem to show how to install an XPI file locally? Unless I'm missing something that's some web interface from AMO

The original article only discusses a specific, non-standard (to me, at least – probably made more sense for IT departments) method that Mozilla is calling ‘sideloading’ will be disabled. Per the article, ‘sideloading’ is defined as putting an extension file in a special folder that results in all instances of Firefox on the machine automatically loading that extension.

In the page yorwba linked, it shows how to generate a signed XPI file that can be distributed and installed locally from that file in a more conventional manner (e.g. drag & drop the file onto Firefox’s Add-ons page).

> probably made more sense for IT departments

Yes, the older method of extension side-loading, supported at some point by Edge, Chrome, and Firefox, was for IT departments who created OS deployment images with software (incl. extensions) burned into them. Usually this was combined with Group Policy / Device Profile settings that made the extensions impossible to deactivate or remove ("force enabled") and potentially blocked any extensions other than those preinstalled.

I believe that all the browser makers have, at this point, reached a consensus that deploying extensions directly as on-disk files this way makes it 1. too easy for malware to just set itself up as seemingly "deployed by Group Policy"; and 2. makes it too hard for these extensions to be updated as often as they might need to be, or disabled if the browser-maker declares incompatibility with an API in them, etc.

What all the browser-makers seem to favor nowadays, for IT departments who want to do OS-image deployment, is an approach where the burned-in Group Policy will just list out a set of extension IDs that are to be force-installed and force-enabled; and then the browser itself will do the work of retrieving and installing them (but will still treat them like any other extension as it goes through the install process, vetting it for compatibility, upgrading it through its registered upgrade channel, etc.)

This means that every extension in these browsers now has to live in the browser's extension store—even if it's a private, just-for-your-own-company extension. (Which, honestly, there's not much to be said against; the "enterprise deployment" parts of app-stores don't usually force developers to go through pre-vetting before new versions are published or anything. It's just cloud hosting—with the proviso that, due to having download logs, the app-store can see if your "enterprise extension" has an install profile that looks more like that of a virus rather than an enterprise, and then blacklist it.)

Here's Google's documentation on the Group Policy settings that modern Chrome looks for, for comparison: https://support.google.com/chrome/a/answer/7532015?hl=en. Probably Firefox wants to move toward a similar model. And more power to them, honestly; right now, Firefox's extension ecosystem is far too easy a target for malware authors.

From what I know (and I've got quite a few self developed addons running), installing unsigned XPI files has not been allowed for a while. I've been uploading them to my profile in the add-ons developer portal and getting back the signed XPI file. I could be misreading this though so apologies if I jumped the gun here.

If you have to upload your addons to the internet before you can install them (even if it is to have them signed) that's hardly "local".

Signing is only required on official release and beta builds -- users on developer edition, nightly, and unbranded builds can opt-out of the signing requirement by flipping a setting in about:config.

Unsigned extensions are also not for end-users.

> Unsigned extensions are also not for end-users.

Says who???

Part of the problem is the very delineation between developer and end user.

How about Firefox just be a powerful open platform that anyone can develop for easily with as few roadblocks as possible? We should all be one step away from being developers.

I am so glad I was on the old Firefox 12 years ago. I'm glad that I was able to quickly whip up extensions and share them with my friends. Wanting to automate bypassing my school's wifi captive portal, or wanting to change how the bookmark menu was displayed encouraged me to experiment.

The fact that Mozilla now sees only an audience of consumers that need to be protected from themselves and marketed to is the problem. Mozilla is afraid of their precious precious brand being sullied.

There's a developer edition which allows unsigned add-ons.

https://www.mozilla.org/en-US/firefox/developer/

The point of my post was that there should not be such a hard delineation between regular users and developers. A developer edition is not a helpful solution.

What’s the trade-off here? Browsers are trying to protect users against a metric ton of malware trying to exfiltrate login credentials, and the vast majority of users have no clue what an extension even is.

Last week my dad thought he had a virus, but really it was just a BS spam site that he had accidentally allowed to send him notifications. The screen in Chrome to revoke notification access was like 8 clicks deep.

Browser extensions are a powerful, beautiful, dangerous bit of tech. Is it asking too much to put some guard rails in place that really aren’t too much trouble to follow?

This would not have protected your father from any of that. If hostile code can inject an extension into your Firefox profile, it can also install a keylogger or read your unencrypted Firefox password store. There is almost no protection against your credentials being exfiltrated. Neither would it protect you against unwanted notifications. It will however greatly reduce the functionality of Firefox.

This is security theater.

> Browser extensions are a powerful, beautiful, dangerous bit of tech. Is it asking too much to put some guard rails in place that really aren’t too much trouble to follow?

There are many layers of guard rails already. The problem is that now they want to also inspect every extension that I use, even if it is for completely private use and will never be available to the public. And Mozilla does not exactly have a good track record with trust.

> Is it asking too much to put some guard rails in place that really aren’t too much trouble to follow?

No, but that's not what Mozilla is doing. A confirmation prompt is a guardrail. This is a fence.

> Last week my dad thought he had a virus, but really it was just a BS spam site that he had [...] allowed to send him notifications.

That's his own fault. Not an ideal outcome by any means but a private organization has no right to restrict people's freedom just to protect others from themselves.

Would setting up signatures have taken more than a few extra minutes?

Developers are end users too.

There are no release (as in, non-Alpha) builds with updates, last I checked.

Developer edition and nighties are not release builds.

Unbranded builds don't get updates.

Developer edition definitely gets regular updates, fwiw.

Developer edition has updates but it's a beta. Unbranded builds aren't a beta but don't get updates. There is no version that's just like normal firefox except without signing enforcement.

I worked around this with a script that patches the omni.ja zipfile to change the setting to require signing.

It needs to be unpatched for updates - I don't allow my normal day-to-day Firefox instance to write to it's own binary anyway. Firefox tells me when there is an update, and I then restart into my special script that unpatches, runs Firefox with permissions to modify itself and a profile that I don't use for day to day browsing, only for updates, and then patches it again.

Scripts to patch / unpatch it are here: https://github.com/A1kmm/enable-unsigned-firefox-addons

> What gave you the impression that XPI files would not be supported?

The title. In normal usage, the word "sideloading" implies installing an extension file (apk, xpi, ...) yourself instead of via an app store.

Reading the article, I understood they mean something different, but the title is very misleading.

In the domain you are used to, which isn't the only technical domain in existence.

Okay, Firefox is so big one could consider it a technical domain unto itself, but it's not so big its internal jargon overrides general usage.

Actually, in normal usage the word "sideloading" means transferring files laterally. That is to say, not in a client-server relationship.

In the world of android, "sideloading" became parlance for installing applications because historically you used adb on a computer to sideload the app on.

Did this change? Android-wise, I've always interpreted "sideload" as the adb method... just installing an apk in the UI isn't "sideloading", it's "install from apk" vs "install from play store".

This has not changed. It has always been considered sideloading to install an APK in the UI, as this is entirely identical to using adb.

Sideloading only means that you are providing the thing yourself, as opposed to using official channels.

Using F-Droid is considered sideloading.

You consider using F-Droid to be sideloading.

"sideloading" can mean many things.

Chrome allows installing local extensions from a source folder, and the installation persists across browser sessions. Firefox extensions installed from a local source folder in about:debugging are removed at the end of the browser session.

But if you can "manually install" an extension, why can't a third-party manipulate files on disk to reflect the same state of affairs as though you've manually installed?

And assuming that's possible, doesn't that mean they've just made side-loading more difficult to do than actually prevented it?

If that's the case, it just means that _you_ won't be able to sideload, effectively, but Skype et al will put in some programming time and be able to sideload again.

Correct me if I'm wrong!

There's no way Firefox can protect itself from a 3rd party that can write to the disk. It's only making it more difficult. Viruses will still manage OK.

I think his point was that the following statement doesn't make much sense:

> This is most definitely a Good Thing, as it means for example no malicious extensions can be silently installed by malware etc.

Great question!

I think you'll need to review whatever method Firefox uses to flag what extensions the user approved.

In general, the OS provides different ways to store data in an encrypted manner so that only your application can read it back. (Keychain on Mac, and DPAPI on Windows.)

Furthermore, modern OSes provide sandboxing so that your application can not be tampered with. I'm not sure if Firefox uses this.

Also, if you're able to figure out how to hide a private key, (perhaps in the Keychain or via DPAPI) you can then use things like digital signatures to know what the user really allowed, and know if your approval mechanism was tampered with.

Granted, these mechanisms aren't foolproof... They just make it harder for malware to see things it shouldn't.

AFAIK DPAPI is basically encryption with key specific for current user, not application. So malicious application can easily replicate that process.

Oh is this why some of my computers seem to have 2 1Password extensions installed and others have only 1. I was trying to figure out what the deal was with that.

Thanks for clearing this up.

I agree that installing extensions silently or making them unremovable are problematic - however I take issue at them removing the ability to install extensions automatically.

So, imagine I'm writing some kind of desktop app that needs a companion browser extension to work correctly - a malware scanner, password manager, etc. The program will break if the companion extension is not present.

I guess for the user who installs the program, the installer can ask the user to visit AMO and install the extension themselves - however, how would this be accomplished for other users?

If your application _needs_ a companion extension installed, be a good citizen of other people's computers and during the installation, add a step that says "this application needs the Bleep Bloop extension to work. Do that now?" and if they click yes, you do a system call to open https://yoursite.kibbles/products/bleepbloop/extension so they can take care of that part. And if they click no, go "in order for this software to work, you will need to install the Bleep Bloop extension. You can do this from help -> install web extension after installation" so that your users have a completion path afterwards, when they simply run your application.

Or, when they click OK you can make your installer tell the OS to "run" your .xpi file, which will open Firefox, and ask the user whether that extension is really something they want to install. And then when they click no you tell them that they can initiate the .xpi install process at any time by going to your application's help -> install extension or something.

What you _can't_ do, and what you should never have done in the first place, is copy a file into the magic Firefox directory that forces that extensions to be loaded outside of the control of every user and profile for Firefox on that computer.

Thanks for clarifying

Goodbye Avast Firefox Extension. I hate that thing so much.

Thanks for the clarification. My first thought was that manual installs were disabled ala the android manual install sideloading concept.

What this is:

• Preventing malware and enterprises from silently installing unremovable extensions through a special mechanism

What this is not:

• Preventing users from installing extensions without using the Internet (they can just load an xpi file like always)

• Preventing power users from installing unsigned extensions (already not possible in standard Firefox except non-persistently for development, but Mozilla provide unbranded builds which let you use extensions)

Why this is being done:

• Preventing adware adding itself to your browser without your consent and making itself difficult to remove

Not why this is being done:

• Mozilla hates users / the open Internet / freedom (their foremost concern is protecting users from malware nonconsensually installing extensions, they have always provided versions of Firefox allowing you to do whatever you want if you want that, and indeed standard Firefox does let you load unsigned extensions temporarily)

I do hope that Debian will start patching out these nanny features, though, including the ones we've already had for a while (like no unsigned extensions). Maybe it's time for a revival of Iceweasel.

If malware gains enough access to my system to put extensions in the sideloading folder I have bigger problems than Mozilla can protect me from.

Sounds like it'll be useful for stopping things like "McAfee" from automatically installing their crap into Firefox without asking.

It's not like you don't install McAfee on purpose.

Sometimes your organisation installs Mcafee, you then proceed to install Firefox.

In addition to this, many products come preinstalled as bloatware. McAfee products (amongst a hoard of other programs) have come preinstalled on Windows laptops I've purchased from Dell and Lenovo.

The "Fresh Start" feature in newer builds of Windows 10 (1709-onwards if I'm not mistaken) will automatically remove these kinds of applications preinstalled on new systems.

https://www.microsoft.com/en-us/software-download/windows10s...

Excellent feature. It's important to note that it's a good idea to have a copy of all of your devices' drivers before using it.

Excellent feature in itself, but also a cludge around a broken economic system. OEMs shouldn't be prioritizing their profits at the expense of the users their business exists for.

Then it's not your computer. What I meant is "the owner of the computer installs (or uninstalls) mcafee at will".

Anti viruses are typical bundleware installed when installing 'free' software. If you don't look carefully, when you click, 'i agree,' you'll get a bunch of other software you don't want.

Some crazy software companies then used a dark pattern - clicking 'I don't agree,' meant you agreed to install unwanted crap.

Adobe flash, Java runtime, utorrent and any installer from cnet.com are examples. That's why I installed Unchecky to protect me from bundleware and automatically uncheck, skip 'offerings' when installing new software.

Edit: As mentioned below, the Chrome team used bundleware extensively in its early days.

Chrome also did this at a massive scale. It's one of the many reasons why I will always prefer firefox.

Most AV software patch dlls, or inject their own code into running browsers.

They also work at the OS level or in kernelmode.

Most AV software is basically malware itself.

I've had a really annoying problem where various sites weren't rendering properly. In many cases you could see garbled mess instead of text, if I remember correctly. I eventually figured out that it was Avast side-loading an extension, without explicit consent I might add, that was causing this.

I thought they disabled these kinds of silently sideloaded extensions like five years ago. Or was that chromium only?

Yeah, they're disabled by default. But now they weren't install at all.

All is fine, but:

> If you self-distribute your extension via sideloading, please update your install flows and direct your users to download your extension through a web property that you own, or through addons.mozilla.org (AMO).

And what if I don't want to use a "web property" to distribute an extension? What if I want to give my users a honest-to-God file, whether via e-mail or IM message or USB drive?

> Please note that all extensions must meet the requirements outlined in our Add-on Policies and Developer Agreement.

Or what? I can't make an extension and give it to friends unless it meets your policy? That's pushing it a bit.

Maybe the file you distribute on a USB stick should contain a self-contained webserver on localhost that your users can run, then install the extension through Firefox?

This raises some security concerns in theory (your user now has to run an executable that is not sandboxed by the browser), but they were already trusting you enough to plug in a USB stick.

As you say, this wouldn't impact security any more than inserting the USB stick itself would - but having to run a HTTP server on loopback just to circumvent some security mechanism on the browser you own[0] would only say that some engineering mistakes have been made.

[0] - Do you still own a copy of Firefox? That's probably the hidden crux of the issue.

You can still do that of course, with the same file that you would offer your friends through your "web property". A file is still a file.

I doubt it. According to https://extensionworkshop.com/documentation/publish/submitti... the file has to be validated and signed through their submission form, and, I quote,

> Note, however, that your add-on may still be subject to further review, if it is you’ll receive notification of the outcome of the review later.

So other than hosting, I fail to see how this is different from distributing through the official channel — you still have to pass their review.

Note that I’ve never written a Firefox add-on (I’ve written plenty of Chrome extensions though), so please correct me if I’m wrong.

That's not what mozilla is changing with this policy change. You've had to either sign or temporarily load an unsigned packed/unpacked extension for a while now.

Okay, as bad as Chrome then. Thanks for the clarification.

Pretty much. There's a preference you can change to allow unsigned extensions, but it only works in dev/nightly firefox and "unbranded editions" of release/beta firefox.

https://wiki.mozilla.org/Add-ons/Extension_Signing#FAQ

Well, except there are other versions of Firefox (such as developer) where you could install it. This is for the base vanilla version, if you will.

If you're making extensions and distributing them by hand to your friends you're so far outside the mainstream of Firefox users that you might as well not exist and they shouldn't be making decisions based on your usage patterns.

This is aimed at Joe Average User who maybe downloaded a program from sourceforge and suddenly every user on the computer has Myway Search installed, or something with serious privacy problems that's injecting itself into every web page they visit.

What about Joe Average User who downloaded an extension from me? I can understand wanting to prevent third-party software from injecting extensions behind users' backs, but can these users still install extensions directly, from a file, regardless of how that file found its way to their hard drives?

Yes.

They can drag and drop it on the firefox window and it will install it just fine still. The only change that is happening is auto-installation of extensions found in a specific folder, which is how a lot of crapware extensions find their way into people's firefox installation, but almost no legit extensions get installed this way.

That doesn't appear to be correct. All unsigned extensions will be blocked in all release versions. Without a developer/unbranded/nightly version, you're not allowed to install anything that didn't come from Mozilla's add-ons site. https://news.ycombinator.com/item?id=21418604

Yes, but you can sign your xpi via a command line tool (which calls the AMO API) and then distribute that however you want. It can be installed by dragging into about:addons.

While what you want can still be achieved (as Mozilla has gone to great lengths to explain), what makes you think that "Joe Average User" would be best off downloading extensions from every you that tells them they can get a browser toolbar with whatever software install they're using?

So this means Firefox doesn't want power users who maybe just wanna write a quick hack for a website without distributing it?

Incorrect. As has been made clear previously, you can still install unsigned extensions if you're using Beta, Nightly, or Developer Edition, which are intended for power users. The discussion here is around the vanilla, mainstream version of Firefox. They still support power users.

What are my options if I want don't want to be a guinea pig running bugging prerelease software, and I want automatic updates because I don't want to accidentally be a chump running outdated software?

As far as I know, unbranded doesn't autoupdate while beta, nightly, and developer are all buggy software for guinea pigs.

Edit: Why are both the responses I've received worded rudely? Did I say something wrong?

Sucks to be you I guess.

You are not entitled to having your edge case supported in whatever specific manner you desire.

They're entitled to complain, though; that's a proper, by-the-rules way to signal preferences to the market.

FWIW, I agree. Having the choice only between casual user version and unstable dev version is missing a power user option in the middle. I'm personally not going to abandon Firefox over this, but I'm that less interested in embracing web as a platform for productive work.

They weren't until Mozilla took away their tools to support their edge cases themselves.

You could probably compile the release version and change anything you want to, but that won't get you automatic updates.

As a fully open source product, with a demand and will large enough, someone could make a fork, even a minimal one, where they take upstream and keep this feature enabled. I personally don't think sufficient demand and will exists for that to happen.

I suppose they could make an about:config option out of allowing it, but really, so few users will probably find it so much of a problem that even a bug report/feature request for that probably wouldn't get traction.

They can't please everyone. Overall, it seems like a reasonable move to me.

Then you educate yourself on those versions, and discover that the "dev" edition is not a prerelease version at all, unlike beta and nightly, which are. The Dev edition is a version of the main release channel with flags turned on/off to enable all the "only powerusers need these things" functionality out of the box.

Like installing whatever extension you want directly from file.

I think you're wrong about that. My Firefox Developer Edition install has upgraded itself to 71.0b6. My Firefox install is at 70.0.1. Both claim to be up to date...

Real Firefox power users should know that if they want to hack a website, they can

1) write an user script and load it into Violentmonkey, or CSS and load into Stylus. You can easily distribute some Javascript/CSS text via email or IM.

2) If user script or CSS not enough, you can write an addon, create a free Firefox account, submit the addon to your own account at https://addons.mozilla.org/en-US/developers/addon/submit/agr... and download the signed addon XPI file. Then you can distribute the file in whatever way you want, provided you are not violating any license agreement.

That's a strange thing to ask. IF you're a real poweruser, you're not using the standard release version of firefox, you're using the dev, beta, or nightly version. In which case you have all the power you want and you can install literally anything --no matter how insecure or horrible it is-- by opening the add-ons settings, clicking the gear, and selecting "Install Add-on from File".

No True Power User values stability and automatic updates?

> This is aimed at Joe Average User

It's not important who this is aimed at but who it hits.

> If you're making extensions and distributing them by hand to your friends you're so far outside the mainstream of Firefox users that you might as well not exist and they shouldn't be making decisions based on your usage patterns.

They should just release a Firefox preskool edition for Joe Average User.

But this is a great example of the rot in Mozilla. When Apple or Google sacrifice functionality to appeal to users that don't like computers, it is because they make more money by expanding their platform.

When Mozilla sacrifices functionality to try to attract new users, then what? They aren't really making any money off of it. They are just getting new users for the sake of it.

If Firefox has to remove so much functionality to become more popular, than why bother at all?

It is like if everyone is eating McDonalds, and you are selling healthy produce, but only 20% of the population ever wants your healthy food. So you start coating your healthy food in sugar and deep frying it. Even if you win, you lose.

> This is aimed at Joe Average User who maybe downloaded a program from sourceforge and suddenly every user on the computer has Myway Search installed, or something with serious privacy problems that's injecting itself into every web page they visit.

I think this is a lie. I mean, yes it does mitigate a specific kind of malware injection, sure. But if someone already can write to your filesystem, then it is game over. If Firefox actually had any marketshare and was a big enough target to care about, malware could simply inject malicious extensions some other way. Having the web browser trying to secure itself on a compromised system is a fool's errand. And it is not a justification for such a massive regression in functionality. It is not a rational decision.

I strongly suspect that it was a rational decision for Google to do this with Chrome; to put up roadblocks for users trying to have too much control of their browser, and justify it in the name of security. And then Mozilla irrationally copied them. Because they are a Google cargo cult.

Healthy food doesn't nearly as much rely no network effect to not be pushed out of the market. "Only works on Chrome" is real problem and won't get better if they don't also pander to those longing for sugar.

> They should just release a Firefox preskool edition for Joe Average User.

Seems like that's Developer Edition. The Joe Average won't know the difference, so obviously the default has to be for him.

And yeah, I also don't like were this is leading and wish they would have found a better way.

> Healthy food doesn't nearly as much rely no network effect to not be pushed out of the market. "Only works on Chrome" is real problem and won't get better if they don't also pander to those longing for sugar.

Users who are sick of the effects of unhealthy food will actively seek out Firefox. I and many others were willing to put up with the bugs and slowness of Firefox to leave Internet Explorer.

And when websites were IE6-only, the attitude was not that Firefox needed to win them over, but instead it was too bad for that site they would not get traffic from Firefox users.

And Firefox could afford to not be the best browser for all users, because they are a non-profit, and are not constrained by the same market dynamics as their competitors.

Firefox does not and should not pander to users wanting the sugar, because it will likely drive away loyal users more than it will win anyone over. And again, they can certainly afford to not win those users over. Their browser is not a cog in a content distribution platform like it is for Apple and Google. They can afford to not grow their user base at all, and focus instead on improvement. I would actually like to see Mozilla discard their user metrics and just blindly focus on making something good, instead of something popular.

> And what if I don't want to use a "web property" to distribute an extension? What if I want to give my users a honest-to-God file, whether via e-mail or IM message or USB drive?

You still can give your users a file, as long as it's signed my Mozilla.

> Or what? I can't make an extension and give it to friends unless it meets your policy? That's pushing it a bit.

You can still install unsigned extensions if you're using Beta, Nightly, or Developer Edition, which are intended for power users.

Note the "users" part in that sentence. If you self-distribute extensions _to other people on the internet_ then yeah, you probably want some web property for those files to live. Like a github repo, or a personal homepage, or AMO.

And if you don't want to be subject to AMO's security review process, then out of those options, don't pick AMO.

Everything is fine. This is blocking automatic extension installation. You can still install extensions manually.

Mozilla intends to remove all methods for installing private extensions in the release version of Firefox. The extension source code must be disclosed to Mozilla during signing, and it must adhere to their add-on policies [1].

Mozilla is blocklisting benign extensions distributed outside of Firefox Add-ons which do not follow these guidelines [2].

They are working on disabling a method which allows users with root access to configure Firefox to load unsigned extensions [3], citing concerns over adware with root access. The feature is being disabled even on Linux, where such adware was never really a problem, despite making several other use cases impossible.

Requiring extensions to be signed by default is a great initiative by Mozilla, but we must be given ways to install private extensions in the release version of Firefox without disclosing the source code to Mozilla, or worrying that an extension for personal use may be blocklisted.

Forbidding local extensions in the release version of Firefox, without a way to override the option, guarded by administrative access and appropriate warnings, is heavy-handed and has a questionable threat model.

Signing can be turned off in Firefox Developer Edition (based on Firefox Beta) and unbranded builds (no automatic updates), but those browsers are not meant for end users. We must be given ways to install private extensions in the best version of Firefox, and that is the release version of the browser.

Not even Google is this heavy-handed, they allow installing local extensions in Chrome after users enable an option, although a warning is shown on browser restarts about the presence of external extensions, which can be dismissed.

[1] https://extensionworkshop.com/documentation/publish/add-on-p...

[2] https://github.com/jeremiahlee/page-translator/issues/26

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1514451

But I think Chrome’s example clearly shows why they feel they have to do this. The average user doesn’t understand extensions the same way you do; to them, Firefox is Firefox no matter how many bells and whistles are added on. So it’s a serious reputational risk that Mozilla currently allows unsafe code to run in an official Firefox release.

edit: Like, look at your second link. The extension was running remote code loaded from a third-party site! I'm sure you see why Mozilla can't just let that happen.

Chrome's example clearly shows that having secure default options, while also giving users more control and educating them about possible drawbacks, is a viable alternative to restricting user freedoms and keeping users ignorant.

The extension was running remote code from Google Translate. The extension's author could no longer run a safe, unlisted extension in their own browser. Mozilla should have no business in what code people run in their own browsers, when that code was distributed outside of Mozilla services.

This is esentially arguing that user scripts, and the extensions which enable them, should be banned too.

Sometimes they should be. Consider CORS for example; Firefox will refuse to load some resources it's been instructed to load, and there's no way to make it load them without breaking other things, but this is completely uncontroversial. Enforcing security boundaries is a reasonable thing for a program to do.

Users should be treated with respect and given control over their own devices, while platforms should do their best to implement safe defaults, and educate users about the potential risks of certain actions.

CORS is a security directive set by sites over which users have full control through browser configuration and extensions.

And that's absolutely the right way to think about CORS. But what it actually does under the hood, the underlying behavior that makes CORS effective as a security directive, is:

* You instruct your computer to load site A. Site A has some scripts on it, so part of the process of loading site A is executing that Javascript code.

* The Javascript code instructs Firefox to display a resource from site B.

* Firefox refuses to display that resource, even though your website told it to, because it doesn't think displaying the resource would be safe.

I think that's also the right perspective here. Firefox won't run unsafe extensions, in the same way and for the same reasons as it won't run unsafe cross-origin requests.

Please do not label local extensions as inherently unsafe, it's extremely disingenuous to label software that has not been rubber-stamped by Mozilla as unsafe.

You keep bringing up CORS, but that is a security directive that can be disabled in Firefox. Even an essential security measure such as CORS is allowed to be disabled using extensions approved by Mozilla, opening users up to universal XSS by any site they visit.

In any case I don't think CORS is relevant in a discussion about Mozilla taking away user freedoms under the pretext of a threat model that falls apart once subjected to close scrutiny.

Maybe I'm missing something. As far as I know Firefox only allows you to disable a subset of CORS checks.

I just fundamentally don't agree that taking away extension functionality means taking away user freedoms. Even if Firefox developers are completely wrong about security, I have no moral right to make their project execute my code. My user freedom is to develop and run a modified version of the Firefox code, which Mozilla does allow by making Firefox free software.

And this I think is the crux of how FF has changed its no longer "here's a browser for you to have" it's "here's our browser, you can only use it like this".

This is how you get "we added an addon that you can't remove" and "we re-added icons to the toolbar that you removed" and now "we won't let you simply install any addon".

And presumably next year "only addons from the Mozilla walled-garden"? That seems to be the direction it's going.

Mozilla allow users to do stuff, you say. They used to be about enabling users. Only allowing things a user has a moral right to demand of you doesn't sound like FOSS.

> Consider CORS

Chrome has "--disable-web-security" command-line flag which disables CORS. They may start locking it to be only usable with "--user-data-dir" (see Chromium bug #327804) but that's a clear failsafe, not a limitation.

Firefox doesn't support anything like this. You don't have any control over its behavior, even if you may need this for some unconventional reason.

Or just have an about:config option that allows users to decide.

Why can't Mozilla treat their users as arbiter of what the use may do? They really don't have to decide for users what the only allowable extensions are; they could just advise rather than dictate.

This is horrifying on a number of levels. I don't think that even Google has tried exerting this much control over users.

This does not make sense if it is just to fight malware. I no longer believe that Mozilla is acting in good faith. It seems that Mozilla is trying to claw control of Firefox away from users.

I do not trust them to decide what extensions I can have. Once they have locked it down even more, are they still going to be so nice about approving extensions?

Either this is just hubris and contempt for users, or a poor attempt to copy Google's restrictions, or something worse.

> those browsers are not meant for end users.

1% of 500M users is still millions of users. I don't know what the actual fraction of Beta/Developer vs Release users is, but the scale is significant enough that the beta channel is definitely intended for end users.

IMO Beta is the best channel of Firefox. Release is just an outdated version maintained for corporate/enterprise installations.

I got concerned for a moment that this will end up forcing all extensions to be available only from Add On store, (similar to Chrome). Thankfully it’s not that. Note that even extensions distributed outside their store need an automatic signing. It takes a few seconds and is done through the web-ext cli tool. This is good!

> I got concerned for a moment that this will end up forcing all extensions to be available only from Add On store, (similar to Chrome). Thankfully it’s not that.

Mozilla is working on achieving exactly that, and in fact Firefox is already worse than Chrome in this aspect, see my comment here: https://news.ycombinator.com/item?id=21418604

Thanks for this. I want to say that it’s all bad choice from Mozilla and rant, but instead I want to understand the threat model they’re considering. Extensions do get a lot of access to browser, and may also use side-channels[1] to work around inaccessible apis. From a brief look at the linked discussions, I grock that they’re thinking about a malware with admin privileges installing the add-on. Is it likely that some malware only has access to “side-load addons” and nothing more? If not, then can’t it just install keylogger, network monitor, etc? I can’t find better answers other than my speculations.

[1]: Not that I have one such exploit, but even without access to “tabs” permissions, extensions can still query the status of tabs, run benchmark processes, and add context menus with various “filters” such as right click on a text or image. Sure this doesn’t give direct access to data, but timing attacks and such should be possible.

I agree that having a discussion on the actual threat model Mozilla is working with is the best way to approach this issue.

Mozilla is trying to defend against malware or adware with root access on the device.

Malware with root access can do what it wants, inluding just replacing the Firefox executable, keylogging, making screenshots, intercepting traffic, or patching Firefox in any number of ways.

Adware can legally do the same if users give consent. Most antivirus software in fact injects code and is capable of controlling processes, they also intercept traffic to monitor for threats.

If both malware and adware can do esentially what they want on the device, then we are left with how this change affects users.

Users can install a different browser, or patch Firefox, but it becomes prohibitive for regular users to control their own browsers if they choose to continue using Firefox, because they lack the expertise to make the necessary changes.

Disallowing local extensions at all costs in Firefox has minimal security benefits, while greatly harming user and software freedom.

You contradict yourself in your linked comment. Add-on install will not be locked to addons.mozilla.org. You can continue to use automatic signing and distribute through whatever channels you like, just as the comment you're replying to states.

> Add-on install will not be locked to addons.mozilla.org. You can continue to use automatic signing and distribute through whatever channels you like

Extensions which require signing by uploading to addons.mozilla.org are controlled by Mozilla and can be blocklisted, it does not matter from where the user ends up downloading the extension.

This practice is worse than what is allowed in Chrome. Google allows installing local and private extensions that have not been signed, after an option is changed in Chrome.

> all extensions to be available only from Add On store, (similar to Chrome)

...You absolutely can install extensions from outside the Chrome extension store, though?

How will this affect extensions packaged in Linux distributions, e.g. Debian's webext-* packages. I for one want to be able to do stuff like `sudo apt install firefox webext-ublock-origin` and have all the users on the system have this extension installed and enabled.

Debian will need to patch Firefox for this to continue to work.

I think Debian already compiles Firefox with a flag to allow unsigned extensions, but this may require further changes.

I was amused by this doublespeak:

"To give users more control over their extensions, support for sideloaded extensions will be discontinued."

Sideloading isn't always under the control of the user. Thus removing the option gives more control.

It's not like removing a hole in your city wall gives you less control over entry into your city, even though it does remove a method of entry.

I don't see how removing the option gives more control. If you want more control why not just add a confirmation step the first time the extension is loaded, and make it possible/easy to remove it?

In you analogy it doesn't give the users of the hole more control of how they get in to their city, it gives the city gate controllers more control.

This doesn't give users more control, it gives less.

People who wanted to control their own 'hole' might have wanted to let people in that the city elders didn't care for.

I know where you're coming from, I don't see a contradiction here. This is about extensions that are side-loaded e.g. through an enterprise group policy or by a snake oil product, where the user in front of the screen did not explicitly approve the installation of the extension. Disabling this means that users have to approve each extension, which does indeed give them more control.

Thẹn why not just leave the functionality there but force users to confirm the installation the next time you restart the browser? And make it possible to remove the sideloaded extension always?

They're converting these "sideloaded" extensions into "normally installed" ones, and then the user will gain that ability. They're not just wiping these extensions without warning.

During the release cycle for Firefox version 73, which goes into pre-release channels on December 3, 2019 and into release on February 11, 2020, Firefox will continue to read sideloaded files, but they will be copied over to the user’s individual profile and installed as regular add-ons. Sideloading will stop being supported in Firefox version 74, which will be released on March 10, 2020. The transitional stage in Firefox 73 will ensure that no installed add-ons will be lost, and end users will gain the ability to remove them if they chose to.

But then again why not just treat these sideloaded extensions as first-class citizen, add support for their removal, and add confirmation before enabling them the first time?

> Disabling this means that users have to approve each extension, which does indeed give them more control.

From what I read only if those extensions are declared acceptable (aka signed) by Mozilla. Pretending this gives me as user the control seems highly disingenuous. The only entity with all the power is certainly not the user anymore.

Signing has been mandatory for a while. It's unrelated to this specific change, which is giving the user more control.

Exactly. I saw where this was going a few years ago and started using Pale Moon.

The question in my mind is how this change is gonna affect the enterprise installations.

I'm aware of some installations which rely on both auto configuration and some proprietary extensions to the enterprises themselves which needs to be non-removable and always active.

Disabling installation of sideloaded extensions may make these installations harder, if not impossible.

I think the main point here is that sideloaded add-ons cannot be removed through the add-on manager. Malicious software can still install add-ons silently and without explicit consent, but now the user can view and remove those much more easily.

Title is flame-bait. It should say "Firefox to Discontinue Silently Sideloading Extensions"

Bad, bad Mozilla! For me, personally, it's what makes this model so fallible and not developer / community friendly. What if, tomorrow, some country blacklists the Firefox website, and one still needs to load some privacy extensions? This is exactly the sort of usecase Firefox should allow, if it's pro privacy.

Add-ons can still be installed from outside addons.mozilla.org, as long as they're signed (an automated process), or you're using something other than an official stable-channel Firefox build and have unsigned add-on install enabled.

The announcement in question pertains to a specific method of silently force-installing unremovable add-ons to Firefox.

Won't the "bundleware" just directly frob Firefox's state to make it think the user authorized it?

There is a rule about ensuring the original title is the same as the submission title but in this case the original title is quite badly written.

Is there some way to submit this post or edit the title to maintain compliance with the submission rule and also make it less misleading?

What would be a reasonable way to let Mozilla know that I strongly disagree with this decision (and, really, the majority of calls they have made surrounding extension security lately)? Who was responsible for making this decision on their end? I am very close to the point where I can no longer recommend Firefox to anyone (after sticking with them through some of the darkest years in terms of product quality), because they are becoming a worse enemy of the open internet than Google but harder to hold accountable for it.

I don't know the answer to your question, but why do disagree so strongly?

So, how do you now install Add-Ons on computers without internet access?

Sideloadong is automatic installation of extensions by 3rd party software. You can still install extensions manually using the extension package file and opening it with firefox. What you cant do is automate this.

Wait what? Sideloading means installing software directly, rather than from a first party distribution mechanism. If a user installs software manually they are still sideloading it, that's what the word means!!

Yeah, they just used a terrible internal name for the feature they are removing, that makes it sound way more severe than it actually is.

Seems somewhat tone-deaf with one of the big criticisms of the project being their restrictiveness regarding add-ons.

Sideloading generally means just not using an official store so this seems to be poorly communicated.

I guess you will still be able to do "Add-Ons" -> "Extensions" -> [Gear icon] -> "Install Add-On From File"

I haven't touched extension development for a while but afaik you could just open the extension package with the browser to trigger the installation process.

The side-loading they are talking about here seems to have the goal to avoid the search-bar crazyness thru adding extensions without user acknowledgement.

If an extension can't be installed silently (e.g. by a -rd party app installer once you forget to uncheck a checkbox) that's great (except for enterprise users perhaps as they need to automate such tasks). If I can't just install an extension/app manually from a file on my hard drive - I don't need such a browser/platform.

Say I wanted to provide a multi-seat computer where all users have a certain default addon experience using Firefox, like installing uBlock Origin. This seems to make provisioning such a setup impossible? Or I would have to generate Firefox profiles dynamically, on-the-fly?

It seems Chrome already does that since June 2018: https://blog.chromium.org/2018/06/improving-extension-transp...

The communication around this is completely atrocious.

Given the obvious threats that a single signing authority presents (as proven by Apple recently) Mozilla should be decentralising the signing here to a few hundred redundant parties worldwide.

> To give users more control over their extensions, support for sideloaded extensions will be discontinued.

Isn't kind of contradictory?

Sounds good for public users, sounds bad for intranet users. Is there some Firefox fork without all those restrictions?

For intranet/companies you should use Group Policies to install extensions: https://github.com/mozilla/policy-templates#extensions

Oh! Sounds like this can help with keeping the setup in Ansible.

What prevents a shitty vendor from setting up policies? It looks like all you need to do is create a file and put it in the right place.

I'm not sure about this new change, but Firefox "unbranded" builds don't require extension signing.

The timing of this event is curious. Hasn't this been an issue since almost the inception of web browsers?

To me this seems shortsighted to say the least, sounds like you now need Mozilla to validate and approve your extension for use?

Please correct me if I'm reading it wrong.

Saying "To give users more control over their extensions, support for sideloaded extensions will be discontinued." Also seems disingenuous at best...

The post clearly states that users can install extensions through the developer's website. The main difference here is that extensions cannot be silently installed — users have to explicitly install them.

Sounds good to me. No more annoying adware extensions.

I agree regarding adware, I think its just a poorly written post in terms of clarity. It could have been better summarised as

We are removing sideloading (The ability to silently install extensions from your local machine as an xpi file)

- This will not affect the ability to manually install extensions, they will need to be installed from a source code directory (Link to chrome post on same)

- This makes users safer (Malicious extensions will need to be approved and installed by a user)

- This makes it more obvious when an extension is installed (Confirmation dialog)

ETC

Thanks for making me read into it further

> Saying "To give users more control over their extensions, support for sideloaded extensions will be discontinued." Also seems disingenuous at best...

Isn't this how distributions install browser extensions from package repositories? Now I can pacman -S an extension. With this change I will not be able to.

More control, right.

Presumably pacman -S will still work, but on first run, Firefox will then ask if you really want the extension installed, listing it's permissions etc.

I think that's pretty fair. Lots of other software that interacts/loads into another bit of software requires manual configuration.

I guess distributions may be able to build a Firefox version that would load extensions installed using the package manager without prompt.

Time for a new browser introduction....

So, from now on malware will come with a minimal Firefox binary included where this functionality is patched out, and the malware will use that binary for installing extensions into the Firefox profile on your machine.

What will Mozilla do next then? Close the source so malware authors can't compile their own Firefox, for security reasons? Only allow installation on DRMed systems?

I would really like to know why people are downvoting this ... like, how is this not exactly what is going to happen next on the malware side?

It does not appear anything you said was wrong, so I don't know why you are being downvoted.

Reply on news.ycombinator.com