I have a bunch of privacy-enhancing addons installed, which have now all been disabled. If I hadn't read HN this morning, I wouldn't even have known why. Until now, I had no idea that it was even possible to remotely disable my addons.
And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking? I'm having a hard time trusting a company that randomly & remotely disabled all my addons, regardless of the cause.
This is not entirely accurate. Nothing was done remotely to disable the add-ons. It happened locally. A certificate that's on your machine as part of the Firefox install expired. When that happened, add-ons that were signed via a cert chain that included the expired one started appearing to be invalidly signed. And that's why it requires an update to completely fix. That part is remote, because they need to push a new valid certificate to you to replace the old one.
I do think that the UX should ideally be a bit more graceful; one of my add-ons is Multi-account Containers and its being disabled suddenly caused the window I was actively browsing in to just close, among other side effects.
But that kind of UX polish for what should be an exceptional case is obviously not going to be super-high priority, unfortunately.
I enjoy a nice cup of outrage in the morning just like the next guy, but this one is really weak and lacks that fresh taste of evil conspiracy that I really crave.
You use a browser that has remote update capability, which allows them to install and run new software on your machine all the time. There is a whole separate section of the Preferences that says "Privacy" in large print that has a section that clearly identifies the Studies feature and lets you turn it off. And you use a browser that lets you install privacy-enhancing add-ons in the first place, and in fact which invented the whole concept of add-ons. When the browser discovered that it couldn't verify the add-on integrity with a valid cert, it did what it's supposed to do, it disabled them to protect you from someone backdooring these add-ons.
Someone at Mozilla fucked up, and they're trying in good faith to fix it. I don't know what else people are expecting them to do, putting on sackcloth and ashes won't resolve the problem.
Your addons have not been remotely disabled. They were marked as trustworthy by a certificate that expired and thus are no longer considered trustworthy. The effect is similar, the mechanism is different. You could also enable loading of unsigned extensions, that would “fix” the issue, too.
No one remotely disabled anything. There's a certificate deployed with Firefox. The certificate Firefox used to check addons was only valid till yesterday. So, when the browser started next time it couldn't validate the addons and disabled them. That all happened locally.
> And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking?
Can you elaborate what's your concern with "studies"? By installing Firefox that updates automatically, the user is already giving control of the software and letting Mozilla decide what's the best. How is modifying software logic using studies different than modifying logic by updating the binary?
They have not remotely disabled addons. The certificate expired and the addons did the correct thing when connection couldn’t be established. Nobody triggered a switch to disable addons.
Due to them easily being able to push code without much hastle using Studies, I think this is an elegant-ish solution to a problem that shouldn't even have happened (expired certs are something that's entirely avoidable), but errors happen.
The problem is that Firefox does not have sufficient built in privacy settings by default. Users shouldn't have to crawl the internet for lists of recommended addons, then have to trust such a variety of authors, to have basic privacy. Like I said elsewhere, I'm using Brave because of this.
> Even better would be to set things up to only do a verify on install instead on every startup.
That would defeat the purpose of verification: "Add-on signing in Firefox helps protect against browser hijackers and other malware by making it harder for them to be installed." [1]
And it's not just malware that was doing that. Microsoft force-installed the ".NET Framework Assistant" into Firefox on Windows, and you had to edit the registry to remove it. [2] If I recall correctly, AVG and Logitech were also among the list of offenders.
Verify-on-install doesn't protect you against addons that steal someone's signing certificate to push out an update, because by the time the stolen certificate is discovered, it will have been installed on a bunch of users' systems.
IMHO it seems problematic, that they can remotely push code changes, including replacement of trusted certificate, and bypass package managers.
I don't expect software to (significantly?) change during runtime, outside of what was packaged, signed, distributed and installed as part of apt/yum/pacman/etc.
I understand (not that I like or agree with) that some apps are just embedded web browsers, and load everything externally, and that Firefox extensions are in the end just some JS/CSS/HTML loaded outside of system's package manager. However, extensions have limited API they can interact with, and you need to allow permissions for each extension. Having Mozilla owned extension, that can modify core functionality, seems a bit scary.
If you didn't have browsers auto updating no-one would update them manually, meaning bad news for web developers wanting to take advantage of newer features.
I wonder if there is someone out there in the middle of the ocean with a browser extension based communication and navagation system which is dead in the water?
It sounds to me that the real headline here is that every copy of firefox out there was timebombed and we only noticed because someone forgot to elongate the fuse.
Could other code signing systems like macOS gatekeeper also be vulnerable to problems like this?
IMO this seems like just plain bad design. The Firefox addon certificate should never have had an expiry date. If they ever needed to revoke it, they could distribute an updated version of the browser with the previous intermediate explicitly marked as revoked.
That is my biggest complaint. Only the Firefox Linux team of included a about:config option to turn it off. Android, Windows and mac have no way to do so. It's still broken on my phone. Wtf were they thinking?
The browser itself continued working fine. Are you aware of any life-depending extension? Leaving this particular issue aside, your hypothetical "browser extension for people in the middle of the ocean" was doomed from its inception if it was designed to run as a browser extension (though it opens the door for an interesting discussion about similar scenarios that are happenning, like pilots relying on ipads)
I hate to say all these things because I use Firefox all the time, but...the communication around the add-ons issue has been poorly handled by Mozilla. I only learned of the problem by visiting HN. But what of the thousands of other users who don't visit HN?
If you visit the Mozilla homepage, there is nothing to acknowledge the problem (at least at the time of writing this message). Let's try the Support page. Where is it? Scroll down to the bottom of the lengthy Mozilla homepage to the page footer to find the link. (How many visitors will make it to the bottom?)
When you click through to the Support page, an easy-to-miss banner in tiny text appears at the top of the page that mentions the problem - screenshot here: https://imgur.com/a/TAHZSWa
Additionally, when the add-ons are disabled, Firefox misleading says: "These extensions do not meet current Firefox standards so they have been deactivated". This is probably a generic message but it's also an example when a generic message is misleading.
Finally, poorly-named settings like "Normandy" and "studies" that give no hint of their meaning only adds to the confusion.
The way I see it, people might have gotten used to software break from time to time. Once software breaks it is reasonable to expect it to get fix in a couple days when it is updated. At least this was probably the experience for the majority of users, those that noticed the issue.
That's sadly not the first time Mozilla fails to communicate appropriately about issues/changes that are pushed down to the end users. They should reshuffle some of their Marketing Resources to work on proper non-promotional communication instead, so that current users at least know what to deal with.
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.
I'm also interested in the postmortem to explain the processes that failed to allow the certificate to expire, but let's not overdramatize the situation by nitpicking about filling in form fields on bugzilla. The fact that the tree was closed is equivalent to DEFCON-1, which is all the priority anyone needs to understand the severity of this bug.
I'm also interested in why existing adds-ons are failing to run due to this problem. (There was a similar question in another thread about the issue here at HN.)
I understand why an add-on update or new installation would be prevented from succeeding by a certificate expiration. But why would a certificate expiration prevent an already-installed from running? Any already-installed add-ons were previously validated at installation time and should (IMO) run as-is. It seems unnecessary to continuously check the status of an add-on's certificate if it has not been changed. Am I missing something?
Looking at the changeset [1], I'm curious why the explicit check for expiry (line 644/646) didn't work. Unfortunately the mentioned bug is rather light on details; presumably they were collaborating on IRC or something instead.
I know Firefox isn't being malicious, but ugh, this seems like the worst possible PR move for this, optics wise. "Hey so uh, we accidentally broke your browser, so you need to opt-in to becoming a guinney pig. But don't worry! You probably were already opted in anyway and just didn't realize it! Also it might take six hours to work."
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 timely matter, admit a mistake was made, explain publicly how/why and apply learning moving forward. Beyond that, what's your expectation?
They only point out the opt-in instructions for the few people that voluntarily opt out of Shield studies and wish to get the fix sooner.
Most Firefox users have that checkbox enabled by default, and so most Firefox users received the fix within 0-6 hours of the blog post's publication.
HN readers often take special care to prevent Mozilla from updating Firefox, but that in no way represents the wider population of either all addons users or all Firefox users.
If Mozilla Studies are implemented the way other "push" update systems are, then probably your browser has an ID that it hashes to get a bucket ID that it builds into a URL to check for updates, plus a cron time offset for running those checks. Then, the experiments are rolled out by walking up the bucket ID list and gradually adding the addon to said buckets.
Usually, this mechanism is explained as being helpful to ensure a rollout of an experimental update can be rolled back if it's failing. That's not so much a concern in this case, I think. But this mechanism has another effect: it works as a solution to the thundering-herd problem. Every browser updating at once is bad, not just for Mozilla's servers, but for every piece of Internet infrastructure that those browsers (and their arbitrary set of addons) talk to when they update/restart. Within the time budget you have for running a rolling update, you ideally want as few machines updating concurrently as possible, just because you don't want to generate mysterious correlated traffic bursts that make NOCs paranoid.
Granted I'm using Nightly (and previously disabled extension signing in about:config), but now all my themes are disabled, even the default one apparently, though that is what it is using. Cannot be re-enabled. When do I get my dark theme back?
Also...my default search engine is now Amazon.com?? WTF is going on.
EDIT: Also my only search engine. Heck of a job Mozilla.
For 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):
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 channel update, instead of the "Studies hack".
At least for me, fiddling with the Studies settings had no effect; the about:studies page remained empty regardless of what I did. I've also seen multiple reports from people who got the Studies hack working that the fix actually failed to address the issue properly.
Very curious how the decision to use the Studies program happened. Why not just roll the version early and include the fix in the new version - isn't Firefox an evergreen browser now? Maybe there is extra bureaucracy to roll a new version, or the hotfixers didn't have permission to do it. Either of which I can understand, being that they made the fix late on a Friday night - so huge kudos to those who worked hard to get this fix started. Seems like a good case study for lessons learned here, I'm eagerly anticipating the postmortem and follow-ups.
Certificate expirations show up on causes of outage lists so frequently, yet little has been done to address the underlying issues of how PKI works to address it. The core issue of time limits on trust and no specs and requirements on how to handle the most common case of saying “yes, this is still trusted” is oddly absent.
Could we have for example a publicly verifiable ledger that can be used to verify a cert chain with not only a defined workflow to answer if a cert is still trusted but also a requirement for the workflow to be fully implemented? Seems quite doable, vs sort of hacks of auto-renew which are hit and miss depending on the CA.
In other words, when do we fix the sport rather than the players here?
Interesting. Sadly, I imagine many users will have studies disabled since the Mr. Robot incident. I've re-enabled it but there does not appear to be a way to force it to check for updates. Guess it will show up in the next 6 hours.
The most frustrating part of this for me is there is no (relatively) easy way to override this behavior. Its fine to disable the addons, but please allow me to "understand the risks" and continue against Firefox's recommendations.
The feeling of no control over my web browser was why I left Chrome in the first place.
>We rolled out a hotfix that re-enables affected add-ons. The fix will be automatically applied in the background within the next few hours. For more details, please check out the update at https://support.mozilla.org/en-US/kb/add-ons-failing-install...
Which is like "we did something we shouldn't have causing unauthorised changes to your computer, so we're going to make unauthorised changes to fix it".
Quite telling is that this is supposed to protect us from other developers. On the add-on screen "Enable" is greyed out, there's no "Enable even though Mozilla doesn't like it".
The UX is just like the "fuck you this computer isn't yours it belongs to Microsoft and we'll do what we like with it" that I thought I'd left in the past decades ago.
It's not your computer Mozilla, you fucked it up, you don't get to mess around with it without asking the owner.
My understanding is that this is literally illegal in the UK.
Mozilla barely had any trust left to burn IMO but they sure went all out.
Can we take a moment and consider the side effects?
This is a once in a lifetime chance for Google & Co. to get a glimpse of all those sly fuckers hiding behind adblockers.
This effectively uncloaked a very specific subset of Internet users and exposed them to the very companies that they've been actively trying to avoid. Not just those who avoid Chrome, but those who take extra steps to explicitly evade the tracking.
Surely Mozilla, the privacy advocate, must understand the impact of this fuck up, and yet the offered "fix" doesn't even mention a one-click .xpi install, but rather asks to enable a mechanism that, if left enabled, will grant unnecessary control to Mozilla over people installs.
Mozilla decided to make signing mandatory, then screwed up and now they're trying to fix it by making use of a feature that basically allows them to remotely execute code on all their users silently?
I checked Mozilla's main site again, and it still has this ironic statement in its description tag (it's been there for many years):
Firefox is created by a global non-
profit dedicated to putting individuals in control online.
...I guess it's more dedicated to putting Mozilla in control now. Something about this whole incident brings up a point that just feels very wrong to me --- it's not a Google or Microsoft, but the fact that Mozilla also seems to have this large amount of control over its users is unsettling.
This one will be emotional as this destroyed some of my today's work.
F you Mozilla. I lost all my tabs opened in other containers. The containers don't work too, so I cannot reopen them.
This bug has been known for 3 years, and you did nothing to fix it. You get so much money, and what you do is basically provide a pathetic software (thunderbird) and a nice browser (which you just stopped from working) and you show me banners asking for more money.
You should be ashamed. 3 years. And no, I'm not going to listen things like "this is open source, you are free to fix it". I will just go and switch to another browser. I need a browser which works, not a one which suddenly decides that my stuff should be broken because all the developers and managers have been ignoring a critical issue for a couple of years.
:( I know, this will be flagged, and removed. I don't care, I just need to get all my tabs in containers back. I have never thought that a browser can just close my tabs because a certificate expired.
[+] [-] Tharkun|6 years ago|reply
And now Mozilla are saying that the "fix" is to allow them to install & run "studies" on my machine? What are they smoking? I'm having a hard time trusting a company that randomly & remotely disabled all my addons, regardless of the cause.
[+] [-] wool_gather|6 years ago|reply
I do think that the UX should ideally be a bit more graceful; one of my add-ons is Multi-account Containers and its being disabled suddenly caused the window I was actively browsing in to just close, among other side effects.
But that kind of UX polish for what should be an exceptional case is obviously not going to be super-high priority, unfortunately.
[+] [-] yborg|6 years ago|reply
You use a browser that has remote update capability, which allows them to install and run new software on your machine all the time. There is a whole separate section of the Preferences that says "Privacy" in large print that has a section that clearly identifies the Studies feature and lets you turn it off. And you use a browser that lets you install privacy-enhancing add-ons in the first place, and in fact which invented the whole concept of add-ons. When the browser discovered that it couldn't verify the add-on integrity with a valid cert, it did what it's supposed to do, it disabled them to protect you from someone backdooring these add-ons.
Someone at Mozilla fucked up, and they're trying in good faith to fix it. I don't know what else people are expecting them to do, putting on sackcloth and ashes won't resolve the problem.
[+] [-] Xylakant|6 years ago|reply
[+] [-] sgift|6 years ago|reply
[+] [-] eh78ssxv2f|6 years ago|reply
Can you elaborate what's your concern with "studies"? By installing Firefox that updates automatically, the user is already giving control of the software and letting Mozilla decide what's the best. How is modifying software logic using studies different than modifying logic by updating the binary?
[+] [-] jeromegv|6 years ago|reply
[+] [-] lpcvoid|6 years ago|reply
Eorum est humanum.
[+] [-] zamadatix|6 years ago|reply
[+] [-] jammygit|6 years ago|reply
[+] [-] the8472|6 years ago|reply
There was a similar issue[0] a few years ago that was only caught a month in advance.
Even better would be to set things up to only do a verify on install instead on every startup.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1267318
[+] [-] Mindless2112|6 years ago|reply
That would defeat the purpose of verification: "Add-on signing in Firefox helps protect against browser hijackers and other malware by making it harder for them to be installed." [1]
And it's not just malware that was doing that. Microsoft force-installed the ".NET Framework Assistant" into Firefox on Windows, and you had to edit the registry to remove it. [2] If I recall correctly, AVG and Logitech were also among the list of offenders.
[1] https://support.mozilla.org/en-US/kb/add-on-signing-in-firef... [2] https://support.microsoft.com/en-us/help/963707/how-to-remov...
[+] [-] eridius|6 years ago|reply
[+] [-] watermelon0|6 years ago|reply
I don't expect software to (significantly?) change during runtime, outside of what was packaged, signed, distributed and installed as part of apt/yum/pacman/etc.
I understand (not that I like or agree with) that some apps are just embedded web browsers, and load everything externally, and that Firefox extensions are in the end just some JS/CSS/HTML loaded outside of system's package manager. However, extensions have limited API they can interact with, and you need to allow permissions for each extension. Having Mozilla owned extension, that can modify core functionality, seems a bit scary.
[+] [-] benbristow|6 years ago|reply
[+] [-] damnyou|6 years ago|reply
[+] [-] nullc|6 years ago|reply
It sounds to me that the real headline here is that every copy of firefox out there was timebombed and we only noticed because someone forgot to elongate the fuse.
[+] [-] javagram|6 years ago|reply
IMO this seems like just plain bad design. The Firefox addon certificate should never have had an expiry date. If they ever needed to revoke it, they could distribute an updated version of the browser with the previous intermediate explicitly marked as revoked.
[+] [-] steve19|6 years ago|reply
[+] [-] zimmund|6 years ago|reply
[+] [-] jammygit|6 years ago|reply
[+] [-] open-source-ux|6 years ago|reply
If you visit the Mozilla homepage, there is nothing to acknowledge the problem (at least at the time of writing this message). Let's try the Support page. Where is it? Scroll down to the bottom of the lengthy Mozilla homepage to the page footer to find the link. (How many visitors will make it to the bottom?)
When you click through to the Support page, an easy-to-miss banner in tiny text appears at the top of the page that mentions the problem - screenshot here: https://imgur.com/a/TAHZSWa
Additionally, when the add-ons are disabled, Firefox misleading says: "These extensions do not meet current Firefox standards so they have been deactivated". This is probably a generic message but it's also an example when a generic message is misleading.
Finally, poorly-named settings like "Normandy" and "studies" that give no hint of their meaning only adds to the confusion.
[+] [-] notimetorelax|6 years ago|reply
[+] [-] ekianjo|6 years ago|reply
[+] [-] Grollicus|6 years ago|reply
Also why it took 6 hrs to assign P1 to the bug
[+] [-] gpm|6 years ago|reply
I would assume the delay in assigning P1 is really just a result of assigning P1 not being as high priority as fixing the damn problem.
[+] [-] pcwalton|6 years ago|reply
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.
[+] [-] kibwen|6 years ago|reply
[+] [-] bhauer|6 years ago|reply
I understand why an add-on update or new installation would be prevented from succeeding by a certificate expiration. But why would a certificate expiration prevent an already-installed from running? Any already-installed add-ons were previously validated at installation time and should (IMO) run as-is. It seems unnecessary to continuously check the status of an add-on's certificate if it has not been changed. Am I missing something?
[+] [-] mook|6 years ago|reply
[1] GitHub mirror to not stress their infra: https://github.com/mozilla/gecko-dev/commit/1d1260c7615f1d9a...
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] overgard|6 years ago|reply
[+] [-] usecontainers|6 years ago|reply
Yes, it's unfortunate, I'd expect them to meet it head on, push a tested fix in a timely matter, admit a mistake was made, explain publicly how/why and apply learning moving forward. Beyond that, what's your expectation?
[+] [-] floatingatoll|6 years ago|reply
Most Firefox users have that checkbox enabled by default, and so most Firefox users received the fix within 0-6 hours of the blog post's publication.
HN readers often take special care to prevent Mozilla from updating Firefox, but that in no way represents the wider population of either all addons users or all Firefox users.
[+] [-] nsomaru|6 years ago|reply
[+] [-] tempodox|6 years ago|reply
[+] [-] derefr|6 years ago|reply
Usually, this mechanism is explained as being helpful to ensure a rollout of an experimental update can be rolled back if it's failing. That's not so much a concern in this case, I think. But this mechanism has another effect: it works as a solution to the thundering-herd problem. Every browser updating at once is bad, not just for Mozilla's servers, but for every piece of Internet infrastructure that those browsers (and their arbitrary set of addons) talk to when they update/restart. Within the time budget you have for running a rolling update, you ideally want as few machines updating concurrently as possible, just because you don't want to generate mysterious correlated traffic bursts that make NOCs paranoid.
[+] [-] furgooswft13|6 years ago|reply
Also...my default search engine is now Amazon.com?? WTF is going on.
EDIT: Also my only search engine. Heck of a job Mozilla.
[+] [-] vesinisa|6 years ago|reply
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 channel update, instead of the "Studies hack".
At least for me, fiddling with the Studies settings had no effect; the about:studies page remained empty regardless of what I did. I've also seen multiple reports from people who got the Studies hack working that the fix actually failed to address the issue properly.
[+] [-] akersten|6 years ago|reply
[+] [-] argd678|6 years ago|reply
Could we have for example a publicly verifiable ledger that can be used to verify a cert chain with not only a defined workflow to answer if a cert is still trusted but also a requirement for the workflow to be fully implemented? Seems quite doable, vs sort of hacks of auto-renew which are hit and miss depending on the CA.
In other words, when do we fix the sport rather than the players here?
[+] [-] jchw|6 years ago|reply
[+] [-] Chardok|6 years ago|reply
The feeling of no control over my web browser was why I left Chrome in the first place.
[+] [-] pbhjpbhj|6 years ago|reply
>We rolled out a hotfix that re-enables affected add-ons. The fix will be automatically applied in the background within the next few hours. For more details, please check out the update at https://support.mozilla.org/en-US/kb/add-ons-failing-install...
Which is like "we did something we shouldn't have causing unauthorised changes to your computer, so we're going to make unauthorised changes to fix it".
Quite telling is that this is supposed to protect us from other developers. On the add-on screen "Enable" is greyed out, there's no "Enable even though Mozilla doesn't like it".
The UX is just like the "fuck you this computer isn't yours it belongs to Microsoft and we'll do what we like with it" that I thought I'd left in the past decades ago.
It's not your computer Mozilla, you fucked it up, you don't get to mess around with it without asking the owner.
My understanding is that this is literally illegal in the UK.
Mozilla barely had any trust left to burn IMO but they sure went all out.
[+] [-] huhtenberg|6 years ago|reply
This is a once in a lifetime chance for Google & Co. to get a glimpse of all those sly fuckers hiding behind adblockers.
This effectively uncloaked a very specific subset of Internet users and exposed them to the very companies that they've been actively trying to avoid. Not just those who avoid Chrome, but those who take extra steps to explicitly evade the tracking.
Surely Mozilla, the privacy advocate, must understand the impact of this fuck up, and yet the offered "fix" doesn't even mention a one-click .xpi install, but rather asks to enable a mechanism that, if left enabled, will grant unnecessary control to Mozilla over people installs.
This ain't right.
[+] [-] userbinator|6 years ago|reply
I checked Mozilla's main site again, and it still has this ironic statement in its description tag (it's been there for many years):
https://www.mozilla.org/en-US/firefox/new/
Firefox is created by a global non- profit dedicated to putting individuals in control online.
...I guess it's more dedicated to putting Mozilla in control now. Something about this whole incident brings up a point that just feels very wrong to me --- it's not a Google or Microsoft, but the fact that Mozilla also seems to have this large amount of control over its users is unsettling.
[+] [-] gnud|6 years ago|reply
In the meantime I'm enjoying trying out Vivaldi[1] - really reminds me of opera 3/4, that I loved.
1: https://vivaldi.com
[+] [-] gpm|6 years ago|reply
https://storage.googleapis.com/moz-fx-normandy-prod-addons/e...
[+] [-] pleasecalllater|6 years ago|reply
F you Mozilla. I lost all my tabs opened in other containers. The containers don't work too, so I cannot reopen them.
This bug has been known for 3 years, and you did nothing to fix it. You get so much money, and what you do is basically provide a pathetic software (thunderbird) and a nice browser (which you just stopped from working) and you show me banners asking for more money.
You should be ashamed. 3 years. And no, I'm not going to listen things like "this is open source, you are free to fix it". I will just go and switch to another browser. I need a browser which works, not a one which suddenly decides that my stuff should be broken because all the developers and managers have been ignoring a critical issue for a couple of years.
:( I know, this will be flagged, and removed. I don't care, I just need to get all my tabs in containers back. I have never thought that a browser can just close my tabs because a certificate expired.