Those unbranded Firefox version? Coming
Mozilla plans to release so-called unbranded versions of Firefox Stable and Beta in the near future to provide add-on developers with tools to test add-ons in those browser versions.
When Mozilla announced that it would introduce a signing requirement for add-ons, and enforce it on Stable and Beta versions of Firefox, add-on developers were left in the dark in regards to how they would be able to test their add-ons against Stable and Beta versions.
The main issue faced by add-on developers was that Mozilla decided to enforce the use of signed add-ons. This meant that add-on developers could not use Stable or Beta versions of Firefox for tests during development anymore once the signing became mandatory.
Options to test add-ons only against Developer or Nightly versions of Firefox, and getting each iteration of an add-on signed during development are not practicable.
That's why Mozilla announced that it would release unbranded versions of Firefox Stable and Beta that developers could use to test their add-ons. Unlike release versions, those would allow developers to turn off the add-on signing enforcement so that unsigned add-ons could be loaded in the browser.
Add-on signing postponed time and time again
Mozilla's initial plan was to introduce add-on signing in Firefox 40. The organization postponed add-on signing several times since then.
It seems dedicated to introduce it in Firefox 48, out August 2, 2016 though. One of the main reasons why the enforcement was pushed time and time again was that unbranded versions of Firefox were not ready.
If Mozilla would enforce the signing requirement in Stable and Beta versions of Firefox without making available unbranded versions of Firefox first, it would prevent developers from testing add-ons effectively against Stable and Beta versions of Firefox.
Tip: How to disable the Firefox 40 add-on signing requirement
Status of unbranded Firefox version
If things go as planned, unbranded editions of Firefox Stable and Beta will be made available to the development community with the release of Firefox 48 Stable.
Beta builds are already available according to the main tracking bug on Bugzilla. Those builds are not linked directly yet.
The main difference to regular builds of Firefox is that add-on signing is not enforced. It is unclear right now if they differ in other aspects as well.
Considering that these builds will be made available publicly, it seems likely that some regular users will switch to them as well. Doing so allows them to continue using add-ons that are not signed using Firefox Stable or Beta. Another option for users is to switch to Firefox ESR builds which won't enforce the signing of add-ons either.
The release of unbranded versions of Firefox marks the last chapter in the 18 months journey to enforce add-on signing in Firefox Stable and Beta.
One has to wonder whether resources spend on add-on signing, or the enforcement, would not have been more beneficial elsewhere.
Just a bit rant. I made Firefox and Chrome addon. It’s really exhausting to develop extension in Firefox.
In Chrome I can just do ‘load unpacked extension’. Everytime I change something I just need to refresh from the extension manager. And if I want to pack the extension, I just need to press the pack extension button. So easy!
In Firefox I need to reopen new Firefox everytime I change the addon, really time consuming. I need to use npm and jpm to pack the extension, in short I need to install ‘tools’ just to pack them, even though the mozilla pake said you can sign extension with jpm but in truth it’s still not available in latest jpm, you need to upload to AMO to sign the extension. Not to mention, I also can’t paste to the developer console unless I change some ‘settings’ in about:config. Last, I don’t want to install another firefox or another tools just to develop an extension.
TLDR: If Firefox can run Chrome extension later, I would rather develop Chrome extension than Firefox extension.
“can’t paste to the developer console unless I change some ‘settings’ in about:config”
I would like to know specifics. Which pref(s) must you adjust to enable pasting to developer console.
Is it the default (false) for the autocopy pref you’re referring to?
Default preference values can’t please everyone, eh.
Personally, I object to the default value set for clipboardevents
dom.event.clipboardevents.enabled = true
Thanks, but no thanks. It would be a rare occasion when a script running in a webpage EVER legitimately needs to know when I’m copying or pasting… and IIRC the user doesn’t even get the courtesy of an “informed consent” prompt (script wants to access your clipboard content).
I’m asking because I suspect the multiple prefs work in tandem and that a “sane default” behavior regarding clipboard events could probably be achieved (so that an informed consent prompt would de displayed). In the past, i seem to recall seeing such a prompt; I just haven’t figured out how to achieve that in recent firefox versions.
I’d expect the behavior of the developer console regarding clipboard would involve separate prefs (different from dom.event.*)
ESR or Unbranded… it all depends which has the better taskbar icon.
“Considering that these builds will be made available publicly, it seems likely that some regular users will switch to them as well.”. Count me among those.
If these unbranded builds follow the regular builds then I’ll switch immediately. But hard to understand mandatory signed add-ons with, at the corner, the same version free of sig requirement.
I think the rationale is that 99% of users will use the main website and your mom and pop users and non-tech savvy users will have enforced add-on signing. Any users who deliberately seek out the unbranded versions (and the links will not be on the main mozilla website etc), well, then it’s on their head if they get burnt, so to speak.
Yeah, perhaps, but modifying a setting in about:config (like “xpinstall.signatures.required”) is not, IMO, more obvious for a non-tech savvy than getting an unbranded version of Firefox. I still don’t understand the scenario, I mean its pertinence. Unless the truth is that Mozilla has abandoned the idea of mandatory signed add-ons and is trying to find an honorable exit. As I said, I don’t get it.
I think we can all agree on that using a hidden preference would have been a lot easier for Mozilla than what is done right now. Probably, and that is just my estimation, it would result in about the same number of users bypassing it.
Exactly, Martin. Not to mention that these unbranded versions will require extra work for the developers. If the unbranded version differs from the other by the only addition of a switch (or no switch and signatures off by default), you have to have missed something in the pertinence (I love that word, use it regularly in this mad world) of such a decision. Now, if it appears that unbranded versions would require a form of legitimacy to be installed then it’s a totally different story. But as it appears now reminds me of “why making it simple when it can be complicated?”
The problem with a hidden preference is that there have been instances of malware disabling the signature requirement through about:config.
Glad to hear that the unbranded version will be available. Otherwise I would have stayed with Firefox 47 in order not to lose the one extension that I can’t find a replacement for.
I may still stay with an older version of FF if other planned changes disable any of my important extensions.
If the addon isn’t signed and doesn’t have serious security problems, you can just take a copy of it and get it signed for yourself. If you select “not publicly listed”, you’ll get the extension signed immediately.
Martin, the unbranded build(s) will likely contain multiple significant differences compared to release channel build, and I don’t hear/read anyone mentioning (reiterating) the cautionary disclaimer stated in the early dev.mozilla blog post:
The activated dev-centric features and default prefs are intended for testing and are unsuitable for (unsafe for) surfing the open web.
Off-the-cuff I can’t cite a reference (edit: for this post, I did lookup some refs. See below), but my understanding is that even in current/recent firefox versions, several of the dev console components which are activated by default in alpha/dev builds are disabled (or are not built, period) for release channel builds.
One of the inbuilt dev tools actually launches an inbuilt mini-webserver, yes? Another component among the devtools (perhaps in conjunction with the mini-webserver) grants “SpecialPowers” remote-control access to the browser ~~ listens for connection requests on a TCP port and blindly (no login/auth challenge) accepts command-n-control instructions via that port.
Users naively opting to install “unbranded” due to their desire to install unsigned addons… gonna get hella lot more than they bargained for and will be exposing themselves to SIGNIFICANT new vulnerability vectors.
click the navlink at left side, labeled “EXTENDING THE DEVTOOLS”
and choose the link lableled “Remote Debugging Protocol” wiki.mozilla.org/Remote_Debugging_Protocol
I’ll leave it to you to investigate the details.
IIRC, one of the worrisome (ripe for abuse) addons pre-installed in dev build is named “Valence”
Thanks for pointing that out. So what is more of a problem? Letting users install unsigned add-ons, or users installing an unbranded version of Firefox?
Unsigned add-ons is a security risk while unbranded versions would be rather a privacy risk, as I understand gh’s comment.
At scale, “Letting users install unsigned add-ons” is the more problematic scenario.
Across my comments posted to ghacks, I’ve repeatedly criticized mozilla’s changes/decisions, including the decision to disempower users by removing choice to install unsigned addons. Nonetheless, I do respect mozilla’s need to “protect the brand”. Many firefox users have been exploited via (early years) drive-by installs of malicious extensions as well as (recent years) via installs of malicious extensions via socially-engineered coercion. Gullible and/or “rationally ignorant” users comprise the lion’s share of the current userbase, and they “blame” firefox (rather than their own gullibility, or the developer of an installed malicious extension) for not keeping them safe. Mozilla expending resources toward maintaining an “extension blacklist” has (predictably) been an exercise in futility…
…as would adoption of a “locked pref” or whatever mechanism (user must edit, or create, “iamsure.txt” containing a keystring, while browser is not running) due to both the gullibility and the social engineering factors. “Ah wants ta be able ta lookit dem pornz vids NOW 1!!01”
The “extension signing required in release channel build, but unbranded builds available” scenario is a reasonable compromise. Frankly, from the outset I seriously doubted that Mozilla would follow through with their promise to deliver unbranded builds. Due to their decision-making track record, I suspected they were just “shining us on”, in order to deflect/defer our complaints. Maybe they would have, maybe we arrived at this juncture, this compromise, only because so many of us who are NOT mainstream “rationally ignorant” users loudly protested the prospect of our disempowerment.
Will installation of the “unbranded” releases present a sufficiently detailed warning/explanation? In advance, I’m saying “I doubt that will be the case”. If such a detailed explanatory warning is presented, how many (few) users will actually read, digest, and understand the potential consequences (consequences in addition to allowing unsigned addons)?
I’m entrusting you (or challenging you, shades of meaning) to examine those potential consequences and to thoroughly convey them within future ghacks articles.
I love you, but I’m a relentless critic nonetheless. What set me off, motivated my earlier comment was this tripe: “The main difference to regular builds of Firefox is that add-on signing is not enforced. It is unclear right now if they differ in other aspects as well.”
That changes everything. Calms my enthusiasm but corroborates my quest of logic.
Bye unbranded and hello Firefox 48 (Aug. 2nd) and its mandatory-mandatory add-on signing. We’ll have to do with it until a no side-effect work-around appears. I like Firefox but again I have to state a heavy Mozilla infrastructure, bureaucratic-like. Mostly the company seems to start, change, forget, adopt another policy, change again, abandon… no one knows where it’s leading to but worse: many wonder if the company knows it itself.
You could use ESR if you don’t need the latest features
As the time for every release approaches we see the ‘where are unbranded versions’ and ‘how do I defeat unsigned’ arguments. In tons.
Did I miss where Mozilla changed their minds and decided not to replace XUL? That, by itself, will kill many, many, extensions and, I would guess, most of the unsigned ones anyway.
Please correct me if I am wrong.
I have some 65 addons, all are signed, have been for a long time. To be honest, I’ve hardly had to lose anything or replace it for at least a year (except nosquint). I’ve removed a few through no longer needing them (eg I run zero plugins so a couple went, I use uMatrix’s referrer spoof, so RefControl went, etc). But of course, I’m only one person. Pretty sure for a lot of people, a large number of addons in the AMO have become deprecated/broken. And losing XUL is so far off at this stage, it’s not funny. Before that we will have a ton of dead addons from the various e10s stages. If anything significant is left at the end of that, that still works in FF, that is unsigned – then I’ll eat my cat. (miaou ^^)
The XUL drop was announced in August of 2015 and at that time they said 12 to 18 months. Things do slip and time schedules do change but, IMHO, 6 months is not a long time off.
I have no unsigned extensions. I only have 5 anyway. The only one from that group that I would really miss, if it is not modified, would be uBlock Origin.
You’d eat a cat, Pants, when Martin loves them? :)
Otherwise, yeps, 2016 starts what will be in 2017 Firefox’s big shift. It may and will be annoying for many but as always we’ll overcome the “improvements”. I did it with add-ons signature requirement (set it back to default that is ON because not worth for one add-on only after having previously already removed un-signed add-ons that never would be signed), I’ll have to do it with Electrolysis but I really fear the big one : losing XUL.
Oh yeah, almost forgot : it’s only a browser, it’s only an OS, it’s only a computing device, it’s only a machine. I ain’t gonna break my head for that.
If an addon isn’t signed and doesn’t have serious security problems, you can just take a copy of it and get it signed for yourself. If you select “not publicly listed”, you’ll get the extension signed immediately.
If it’s not asking you too much could you resume the steps in order to proceed as you mention? This “npt publicly listed” add-on quick signing seems interesting.
Sure, no problem. Read till the end before you start!
1. Search and download the unsigned addon from https://addons.mozilla.org/ using “save as” so as to not trigger the FF ‘Install extension’ prompt. Or use the xpi file from your profile’s extensions directory.
2. Open the xpi file using 7zip f.e. and verify that there’s no META-INF folder.
3. Register an account on https://addons.mozilla.org/ and once logged in, select the xpi file to upload but make sure you select ‘not publicly listed’ (or something like that) before uploading it. The file gets checked and then automatically signed and it’ll give you a link where you can download the now signed extension.
If it doesn’t work because the ID of the addon is already used (idk if mozilla allows existing IDs for non-publicly-listed, private extensions), or if you want to change something in an existing signed addon and get it re-signed for private use, you’ll need to …
1. extract the xpi file with 7zip or similar into an empty folder.
2. delete the META-INF folder
3. edit the em:id field in install.rdf to something that doesn’t exist yet.
It’s now recommended to use a non-existing email address. f.e. [email protected]. You can also change the name and/or other fields if you like, but the id is the extensions unique identifier.
4. Select all files and folders and create a zip-file with them. install.rdf needs to be top-level, so don’t zip the folder itself where you extracted it to in step 1.
5. rename the newly created .zip to .xpi and upload it (non-publicly-listed!!!) to get it signed.
Maybe it’s mandatory anyways, but it’s probably best if you always change the ID, so you don’t ‘steal’ the devs ID and prevent them from getting it signed later on. Please be careful!! A lot of people could be prevented from getting an updated signed version of an extension if the devs need to use a fresh ID!
That’s it, I hope it helps, and just ask if something is unclear or doesn’t work as described.
Many thanks, earthling :)
I do — or did — have small add-ons built around a bookmarklet thanks to Codefisher (the site) and I’m also looking forwards to modifying one or two old add-ons from AMO, not to mention a cosmetic change on 1 or 2 add-ons as well. Your detailed information provides the path to all situations. I really appreciate it. When you think that I have 70 add-ons, a tweak-lover and that I totally ignored the possibilities to get an add-on signed quickly provided the signature choice over at AMO is ‘not publicly listed’ (or something like that).
This makes my day, thanks again :)
You’re welcome mate!
I forgot to mention that the email format of the ID is not optional! Either that or you’ll need to get a unique ID from mozilla somehow, but Idk how that works exactly.
Oh and some addons will unpack when installed, so either download the xpi file using “save as” as described or just copy the already unpacked folder from your profile’s extensions directory and skip the extracting (step 1)
And of course you shouldn’t use the original and your new signed copy at the same time.
Glad to have made your day :-)
OK, earthling, email and package formats noted. I’ll start with an easy add-on (not on AMO, no META-INF) to see how things turn up, as soon as i get some free time (one eye on the computer now, the other on documents). It’ll work out fine. I copied both of your posts (Guide & appendix) – Have a nice day or evening (01:20PM in NY, 07:20PM here)!
Ok, damn, one more thing. Don’t change the em:id’s in any em:targetApplication blocks, those are ID’s marking either Firefox, Seamonkey or others and never change.
Look up install.rdf on mozilla dev pages if you want to know more about what you can change and/or add/remove.
Thank you, have a nice evening too!
Roger! We copy you on the ground (as they say at the Houston Space Center!).
Kind of you, earthling, to commit yourself in sharing, not only the basic method but those extra details as well which, if unknown and not properly handled can make an operation fail.
We’re bound for take-off!