Best chrome add there ever was.
Update Regarding Add-Ons in Firefox
131–140 of 504 posts
Re: Update Regarding Add-Ons in Firefox
#132Earlier quoted context omitted.
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…
When a certificate is no longer valid, the authority it represents expires too. Grandfathering trust in various places would make cert management even more difficult to get right, because there'd be no hard deadline when a certificate is no longer in force.
It's already a mess. I disabled the signing/recompiled Firefox, and all my extensions were still force disabled with no UI to enable them. So there's some memory/extension state there already.
I had to go thorugh profile/extensions.json and set appDisabled to false to make my extensions enableable again.
Re: Update Regarding Add-Ons in Firefox
#133I'm interested in the general writeup what went wrong that they missed this certificate expiring. That's a structural problem. Also why it took 6 hrs to assign P1 to the bug
> 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.
>This was treated as a five-alarm fire.
I don't think it bothers me personally but it's funny you said that. Presumably you mean a "'no-alarm fire' because who has time to set off an alarm when there's a fire to fight"?!
Re: Update Regarding Add-Ons in Firefox
#134Earlier quoted context omitted.
No, I totally agree with that (I just edited to expand on this point). It was a bad user experience.
Well, I disagree that it's a UX issue. The problem is they shouldn't be expiring local software at all . If it was trustworthy at the time of install, why should the calendar date matter? If users don't want to stay up to date, that may be unwise, but that's there call.
Because if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.
Re: Update Regarding Add-Ons in Firefox
#135I asked this in the other thread but I guess there's too many comments there: Is there a project for Firefox that is analogous to Chromium for Chrome? I need a Firefox build with all the Mozilla shit ripped out. I don't trust the org that decided their certificate expiration was more important than giving users the choice to run what they want.
It seems like Mozilla distributes a special version that allows this. https://wiki.mozilla.org/Add-ons/Extension_Signing
> 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 having to sign every build. To disable signature checks, you will need to set the xpinstall.signatures.required preference to "false".
Otherwise I guess there’s also IceWeasel if you’re on Linux?
Re: Update Regarding Add-Ons in Firefox
#136I asked this in the other thread but I guess there's too many comments there: Is there a project for Firefox that is analogous to Chromium for Chrome? I need a Firefox build with all the Mozilla shit ripped out. I don't trust the org that decided their certificate expiration was more important than giving users the choice to run what they want.
Waterfox?
Re: Update Regarding Add-Ons in Firefox
#137An article that mentions a timeframe of “the next few hours”, but doesn't have any timestamp besides a date without a timezone.
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.
Re: Update Regarding Add-Ons in Firefox
#138For 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…
It appears to take several minutes for the studies to be downloaded and enabled. The process worked for me on two separate Windows 10 machines.
Re: Update Regarding Add-Ons in Firefox
#139Earlier quoted context omitted.
When a certificate is no longer valid, the authority it represents expires too. Grandfathering trust in various places would make cert management even more difficult to get right, because there'd be no hard deadline when a certificate is no longer in force.
But that represents how people consider trust when choosing addons. It's trusting the code and company at the time of install, not at an arbitrary later time. Sure, if the cert expires and there's an update then the user wants to know.
[deleted]
Re: Update Regarding Add-Ons in Firefox
#140For 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…
[deleted]