Live data from Hacker News

Update Regarding Add-Ons in Firefox

blog.mozilla.org

481–490 of 504 posts

Re: Update Regarding Add-Ons in Firefox

#481

Earlier quoted context omitted.

Cool, yeah, noone can complain unless they can personally do it all better. Do you think that's workable? I don't think it's trivial. The critical element here appears to be "who gets the final say" and not "this is to hard to code". They manage to disable the "Enable" button for addons, and managed to consider this situation enough to provide a justification that (paraphrasing) "we do this when we don't want the add…

No, you can complain. I specifically object to “How hard is that?” which is an entire class in itself. Stuff often is inherently hard and when you don’t know internals of a project and don’t work on it, you may have no concept of how hard it is. Don’t pretend you do. Saying “How hard is that?” carries the notion that everyone working on that thing you don’t know is sloppy, malignant or stupid. “I wish it would do tha…

Are you saying you don't think that Mozilla have the capabilities; I'm not. My "how hard is that [for Mozilla]?" is specifically "I think they have the capabilities but chose differently, but if I'm mistaken and there is a technological bar to this then please correct me". That's why I didn't write "That's easy!", nor "How hard is that!", but used "how hard is that?" -- the implication is that's not hard for them to do so why did they chose to do it differently.

As it happens I've just had to flip "xpinstall.signatures.required" and it's working for me. So it seems "not at all hard [for them]" was the answer.

FWIW people have chipped in saying this specific issue was raised, so it's not that they hadn't conceived that such a situation could occur (indeed that's surely why the config above exists).

Re: Update Regarding Add-Ons in Firefox

#482
post #477

Earlier quoted context omitted.

I doubt google has certificates that run out automatically. Rather, the best way is with each signing to include signing the date and not allow the certificate to expire retroactively.

All signing certificates expire. They must. It's a fundamental part of the security model, because otherwise a malicious actor could take an old, comprimised cert and inject it into Firefox, allowing them to run malicious 'signed' addons. This attack would work the exact same way in Chrome, so Chrome will expire it's certificates too.

Thanks for the explanation. Can you provide me with a link to learn more about how google manages extension certs? I am interested in learning how their system differs from Firefox, if at all.

Re: Update Regarding Add-Ons in Firefox

#483
post #67

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 & re…

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.

I'm also using Brave now, though I did have a quick yearning to dust off Lynx…

Re: Update Regarding Add-Ons in Firefox

#484

Earlier quoted context omitted.

This type of reply is ludicrous. An obscure feature (Normandy modifying default settings as part of studies) that requires you to actively opt out (and even then it’s still not clear if you _also_ have to go to about:config to _really_ disable it) and which can make such large scale errors as evicting all extensions is in absolutely no way comparable to the case of a user agreeing to auto-updates and fairly easily be…

I think you're overstating it. >It is astoundingly disingenuous to act like these things are comparable. Why aren't they comparable? In both cases, it's Mozilla pushing code to the end user. There's a different process behind both but calling one a frontdoor and one a backdoor seems apt to me. >and which can make such large scale errors as evicting all extensions Normandy was not used to disable all extensions. It wa…

> “Why aren't they comparable?”

Because regular auto-updates are easy to understand and turn on/off. Normandy is clearly extremely hard for many users to understand, enabled by default, and hard to disable.

Re: Update Regarding Add-Ons in Firefox

#485

Earlier quoted context omitted.

Because if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.

But revocation is different from expiration. If you're worried about a cert being compromised long after expiration and used to back-date a signature, you can show a warning, add a second signature with a local key at time of installation, use a blockchain to prove age, have a timestamping service generate its own signature at time of generation, etc.

Sure, my point was mostly that there are reasonable cases in which one might want to evaluate the signing of an addon after the fact.

Re: Update Regarding Add-Ons in Firefox

#486
post #406

Earlier quoted context omitted.

This is absurdly overdramatic. One issue with a feature in decades and you're stating that you've lost all trust in the browser. https://bugs.chromium.org/p/chromium/issues/detail?id=952287 Chrome has bugs too. Firefox will continue to have bugs. All software will continue to have bugs. I'm so sorry that you lost some tabs in your browser but shit really does happen and acting like this is some violation due to overz…

I did not say "all trust". Please don't presume to inflate my explicitly stated position — especially while also minimizing the impact this incident had on me, and others. I did not merely "lose some tabs"; those, I could just re-open. I lost work . That data, effort, and time are gone . If you think this clownshoery hasn't cost Firefox any trust, then you're being as naïve as you accuse me of being "absurdly overdra…

Alright, I apologize for the tone. It's unnecessary to make something like this into a heated discussion.

That said, the part I was referring to is:

> The mere fact of such a thing being possible is a usability defect. On what basis do I trust that my work is not going to disappear on me like that again?

The possibility of a bug happening is hardly a usability defect in my mind. Or if you want to call it one, it seems like a perfectly reasonable one - this was a defense born out of necessity when malicious extensions were more of a problem.

And I think that the "On what basis" question definitely implies a total lack of trust, but sure, maybe not. The basis is that this is a single instance of a failure over the course of the features' lifetime, for a feature that has existed for absolutely ages.

I pointed to Chrome as an example of similar issues cropping up across codebases to show that these sorts of bugs do happen. I don't consider that whataboutism.

All bugs are foreseeable and preventable. Systems are complex. I think you're putting the issue in a very unfair light, even though it's very reasonable to be upset about time and effort that is lost because of the issue.

Re: Update Regarding Add-Ons in Firefox

#487

Earlier quoted context omitted.

Then it seems it’s a good thing they had a system in place that could deliver the quick fix in less than a day, on a Friday evening, when shipping a normal fix could have — is — taking longer to ship than that quick fix did.

Why does it take longer to ship a general fix / update? They don’t do a full regression for the studies fix? Update mechanism doesn’t check for updates as often? I couldn’t find any information on this yet but would love to know.

“How long does it take to build, unit test, performance test, and QA check a new Firefox release on every supported release of macOS, Windows, and Linux platform?” is absolutely a question that outraged users are trying not to confront. You’re right to ask it, so don’t let the downvotes get you down.

Presumably the testing burden for a preference update using Normandy is smaller, as (and I’m guessing wildly here) fewer things can be altered with Normandy and therefore testing can be simplified to exclude, for made-up example, “the code-signed binary can be executed on all platforms”.

Re: Update Regarding Add-Ons in Firefox

#488
post #474

Earlier quoted context omitted.

What you want assumes having patches for every version that was ever released in the extreme case. How do you propose not doing so when you have limited resources? Firefox offers an ESR release, you can use that if you want.

What? They produced the fix, that’s not the problem. The problem is keeping the delivery mechanism separate from the telemetry/experiments delivery mechanism. Which it clearly was in the past, since FF has been pushing security updates forever. Why it couldn’t be done this time? Is it a sign of things to come? If yes, that is very shady from a privacy perspective and unsound from an engineering perspective.

You can get the fix without telemetry. You just have to wait until the update goes through the update channels, as usual. Going via telemetry just speeds up the process. What you asked for is something different: security updates without feature updates for your chosen release. Forever.

Re: Update Regarding Add-Ons in Firefox

#489

Earlier quoted context omitted.

Why does it take longer to ship a general fix / update? They don’t do a full regression for the studies fix? Update mechanism doesn’t check for updates as often? I couldn’t find any information on this yet but would love to know.

“How long does it take to build, unit test, performance test, and QA check a new Firefox release on every supported release of macOS, Windows, and Linux platform?” is absolutely a question that outraged users are trying not to confront. You’re right to ask it, so don’t let the downvotes get you down. Presumably the testing burden for a preference update using Normandy is smaller, as (and I’m guessing wildly here) few…

Sounds reasonable to me. Would love too see that information on the official Mozilla blog for the post-mortem. I personally think it is great to have a mechanism to push fixes quickly - whatever the name is. I just don't understand why this mechanism can't be the regular update mechanism.

Re: Update Regarding Add-Ons in Firefox

#490
post #464

(disclosure: I am a Mozilla employee but not commenting in any official capacity) "Give me control over what code I run on my computer" (meaning "provide a switch to disable the requirement that extensions be signed") keeps coming up over and over. And perhaps it hasn't been clearly stated but the problem is this: if there's a switch that a user can flip, the browser has to record the state of that switch somewhere (…

My gripes with the switch paradigm are that it: a) isn't transparent b) doesn't empower the user c) isn't easily modifiable a), b) and c) are the exact opposites of what open source software is meant to stand for. Firefox is slowly losing its unique position of being an amazing open source browser in favor of what seems to me a negligible increase in user security. In my mind, Mozilla is wasting time on micromanaging…

You can choose the level of risk. If you want to run unsigned extensions, use Developer Edition or Nightly.
Post reply on HN