This isn't even working reliably. The hotfix study is showing up completed, not active, on my Firefox at home.
No idea why, there's no information about how to reactivate it. No, re-installing it didn't help.
Update Regarding Add-Ons in Firefox
301–310 of 504 posts
Re: Update Regarding Add-Ons in Firefox
#302Earlier quoted context omitted.
So that's pretty unfair. 1) They state they are working on a fix for normal, release channel users who don't want to run studies 2) they tell you to temporarily run studies to get the fix within up to 6 six hours (could be faster; set expectation) 3) You can explicitly install nightly or 66.4 before it's pushed if you want a fix now Yes, it's unfortunate, I'd expect them to meet it head on, push a tested fix in a tim…
Not saying that their current actions are wrong , just that the optics of it are terrible for them. There was a chain of bad decisions that led them here though: 1) thinking it's ok to disable software after its installed (using cert expiration -- I'm ok if the cert was revoked but that's a totally different discussion), 2) Taking more control of people's local software than many people are comfortable with, especial…
For what it's worth, the (initial) mechanism for disabling add-ons (your 1) has been present since before Firefox 1.0. It was designed to quickly deactivate any malicious add-on as soon as it was detected, before it had a chance to do too much damage. In my books, that's a good thing.
Here, the mechanism that kicked in was the protection against add-ons that could have been signed with stolen credentials, which would make them clearly malicious.
Of course, it turns out that the problem was an expired cert, so a bug/human error. But generally speaking, I think that 1 is good.
Re: Update Regarding Add-Ons in Firefox
#303For me (repository firefox on ArchLinux), the temporary fix was setting devtools.chrome.enabled = true in about:config, and running this small JavaScript snippet in Chrome DevTools (Ctrl+Shift+J): https://wiki.archlinux.org/index.php/Firefox#Firefox_disable... AFAIK, this will enable all the disabled add-ons until the next check, which is in 24 hours. This will be hopefully enough time for Mozilla to release a stable…
On Linux you should also have the option of disabling the cert signature check. Go into about:config and set `xpinstall.signatures.required` to false. Just remember to set it back to true once this is fixed.
Re: Update Regarding Add-Ons in Firefox
#304Earlier quoted context omitted.
> Also why it took 6 hrs to assign P1 to the bug Because people were staying up until the wee hours of the morning working on fixing it instead of toggling priorities in Bugzilla. This was treated as a five-alarm fire.
The normal practice would be to have someone operating as an incident communication manager who would be taking care of status/things like this. Saying "we were too busy fixing to communicate" is actually a really bad sign, because it's not just about what you are communicating to the outside world, but also, for example, about making sure people that need to be brought in are getting consistent information.
This is an incredibly uncharitable misreading of what I said. We do have incident communication managers who were working around the clock, of course, communicating through the official channels.
The question is about why someone didn't set the priority setting in the internal Bugzilla sooner. There are a couple of reasons for this. First, that's not really what priority is for: priority is so that engineers on major projects like WebRender know what is most important to work on. It's not an effective tool for emergency responses. P1 doesn't summon on-call people. Second, everyone who was able to get it fixed was already on it. Bugzilla priorities don't make people who wouldn't otherwise be aware aware.
Unlike that of Mozilla, your issue tracker at Google for outages is private and internal-only. One of the many reasons it is private is so that people who don't know the organization's operational processes don't come in and start making incorrect assumptions based on what they find there. I think it's laudable that Mozilla works in the open so much, but comments like this one are some of the downsides of doing so.
Re: Update Regarding Add-Ons in Firefox
#305How long until heads roll? There's something really wrong with the organization. And I thought it was only their marketing/pr that was bad. > We can't afford to lose Mozilla and Firefox. https://news.ycombinator.com/item?id=18800360
nowadays they seem to make it a hobby to make negative headlines at least once every quarter. I fear there will be no negative repercussions for the leadership.
Basically, the management set their own salaries, the entire work force gets a 40% yearly bonus, and they have no one from the outside to report to.
On top of all of this, the money flows regardless of what anyone is doing. (While there is a yearly loss of 10% of their users, the past deal with Verizon made them very rich, so they can go like this for years). Revenue has been only going up, despite a loss of absolute users. So this explains why they continue to do bad things even though outside observes can not understand - during the last 5 years losing users did not impact their financials in any meaningful way. While people were complaining and users leaving the product, revenue was increasing.
They do take care of their employees with lots of benefits and other stuff, so as an employee you don't want to risk all that with speaking up against your superior.
Over the years they have created a company culture where there are endless number of small teams doing irrelevant stuff, with absurd hierarchies, with some people doing no work at all. With 16 people in the upper management, there's also fragmentetion of decision making going on. It's all a bit headless.
Due to the complicated hierarchies in the company everyone is content with doing just enough to not make life harder for anyone else - suggest to change things fundamentally and actually work on delivering a great product and you will not get very far.
Re: Update Regarding Add-Ons in Firefox
#306Earlier quoted context omitted.
First, because priority is for things like major feature work, so that engineers can find the bugs that are useful to work on. In this case, everyone in the team responsible was already spending 100% of their time addressing the issue. Second, because we care about solving problems, not being bureaucrats.
Really? Because being the bottleneck (i.e. single point of failure) responsible for approving all addons is exactly what bureaucrats would want to do ;-) The non-bureaucratic thing to do, as has been pointed out many times of course, would be to give users the power to override the cert signing check as an advanced option.
It is, in fact, an "advanced option", in about:config.
Re: Update Regarding Add-Ons in Firefox
#307Earlier quoted context omitted.
I turn on mostly all phone home functionality in Firefox, and also wasn't affected. Apparently the certificate check is only executed once every 24h, so I guess our checks only occurred after a fix was already pushed.
yes, but i also don't have the fix, since i turned off studies. i'm guessing the cert check was blocked. what url does the check attempt to connect to?
Cert check doesn't need to connect to any url to fail. It's just the cert's only expired 20 hours ago, so this issue is currently only affecting approximately 83% of users who happen to be checking at a time of day that has already passed, over the next 4 hours that will go up to 100% (ignoring users who receive a fix before it breaks).
Re: Update Regarding Add-Ons in Firefox
#308I got the update and containers are working again but, it seems like it forgot my old container configuration and I had to set them all up again.
Re: Update Regarding Add-Ons in Firefox
#309Can anybody confirm thst Mozilla is scrubbing replies on the linked page that mention about:config and toggling "xpinstall.signatures.required" ? I find it suspicious that no replies there mention it.
I found 5 replies mentioning it, the earliest on page 3. It's more likely it wasn't mentioned as often as it only works for the minority of the install base: "The Nightly and Developer Edition versions of Firefox have a preference to disable signature enforcement. There are also be special unbranded versions of Release and Beta that have this preference, so that add-on developers can work on their add-ons without hav…
ESR release in Debian also has this option available. I think the option is generally available with Firefox installed from any Linux distro.
Re: Update Regarding Add-Ons in Firefox
#310From ghacks (comment section): https://www.ghacks.net/2019/05/04/your-firefox-extensions-ar...
This should allow the extensions to work until the next check (Verified locally):
1) Shut down Firefox
2) Open extensions.json (located by about:profile -> Root Directory)
3) Replace all instances of “appDisabled”:false to “appDisabled”:true
4) Replace all instances of “signedState”:-1 to “signedState”:2
5) Save and close extensions.json
6) Start Firefox
7) Close Firefox
8) Open extensions.json
9) Replace all instances of “appDisabled”:true to “appDisabled”:false
10) Start Firefox
11) Disable and re-enable all extensions in about:addons