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.
161–170 of 504 posts
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.
>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.
Earlier quoted context omitted.
I believe it's set up this way specifically to allow revocation for addons that are initially approved but later found to be malicious.
If it is, without requesting user authorisation, then that's an illegal act under the UK Computer Misuse Act (and the USA's CFAA I think too) - modification of a computer without authorisation.
I look forward to joining your class-action lawsuit.
Earlier quoted context omitted.
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.
The main trust check is at installation time, but it's possible for problems to be discovered later, and Mozilla needs to be able to do something about it. Certificate non-renewal is the only robust avenue of revocation.
See profile/blocklist-addons.json
Not sure how not renewing a certificate and letting everything get disabled is useful. It's only useful if cert key leaks.
Earlier 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.
>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"?!
https://en.wikipedia.org/wiki/Multiple-alarm_fire
The 5th level or a five-alarm fire, is the top level where you're basically talking all hands on deck.
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 tim…
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, especially considering that their main market is tech savvy people that tend to be more sensitive to this than most 3) Making some of these things opt-out rather than opt-in, giving the perception that they may value data collection and control more than their users privacy.
Earlier quoted context omitted.
So you are saying there should be no way for an installed addon to fail an integrity check?
Yes.. the choice should be taken to the user- and the users choice should trump them all.
Earlier quoted context omitted.
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.
The main trust check is at installation time, but it's possible for problems to be discovered later, and Mozilla needs to be able to do something about it. Certificate non-renewal is the only robust avenue of revocation.
No, they do not need to. They decided that they want to. Remember that there was a time before certificate signing.
And now the decision to be able protect those who install crapware is also harming those who never had those issues.
I'm not gonna bother with 'studies' or manual workaround - I'm just going to wait for an update. In the meantime I'm enjoying trying out Vivaldi[1] - really reminds me of opera 3/4, that I loved. 1: https://vivaldi.com