Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Details on the Recent Firefox Add-On Outage

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 279 posts

Re: Technical Details on the Recent Firefox Add-On Outage

#91

Post by pbhjpbhj »

callahad wrote: post #58
jeffchien wrote: post #45

I would've liked to see some reflection or even just acknowledgment about the fact that they intentionally disabled the "xpinstall.signatures.required" setting on Windows and OSX. I hope it's at least in the formal postmortem.

That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte... , which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and…

So that means going forward if Mozilla don't want you to have an add-on then you won't be able to enable it?

Re: Technical Details on the Recent Firefox Add-On Outage

#92

Post by SECProto »

yellowapple wrote: post #85
SECProto wrote: post #64

Earlier quoted context omitted.

> The bug was fixed so quickly that I wouldn't even have realized it had happened if it hadn't been for the thread here on HN Maybe this is a timezone thing, but I was in East Asia, and I had to deal with the internet for close to 36 hrs (android) with no ublock. It was almost enough to look for a new browser (but browsers with adblock on Android are few and far between - so instead I just didn't use the internet as…

One option would've been to use Nightly and set xpinstall.signatures.required = false in about:config. That's exactly what I did.

I view using nightly to be as much of a barrier to entry that I might as well switch to a totally different browser. If the issue had lasted longer, I would have found (someone on the internet who had found) a solution like that.

Re: Technical Details on the Recent Firefox Add-On Outage

#93

Post by tedunangst »

Someone1234 wrote: post #74
ghostly_s wrote: post #73

If anyone's wondering if this answers the Actual Question of why the cert was allowed to expired, don't waste your time, it doesn't. I guess implicitly that's a "social detail"?

What are you after? This clearly says they screwed up and that internal procedures need to be changed so it cannot recur. If this was in fact an oversight/accident, what other kind of explanation can they give? > This was due to an error on our end: we let one of the certificates used to sign add-ons expire And: > We clearly need to adjust our processes both to make this and similar incidents it less likely to happen…

Well, they could tell us what the previous process was. Was the cert renewer on vacation, or was the wrong date entered on the calendar, or? How was it supposed to work? I think a lot of people are curious about that.

Re: Technical Details on the Recent Firefox Add-On Outage

#94

Post by keyle »

So my first thought was that a lot of ads would have been printed during that 24 hrs? Anyone notice a blip in revenues of sorts?

I mean that's the most crucial add-on to ever work: ad blockers.

When I visit a site with ad-blocker off I feel compelled to clear all caches and cookies and go have a shower.

Re: Technical Details on the Recent Firefox Add-On Outage

#95

Post by Twirrim »

lllr_finger wrote: post #68

It might not have helped here, but updating certs every several years always leads to problems from my experience - people move on, processes get lost or outdated, etc. I'll accept the yearly annoyance to avoid those issues every time.

Even with annual certificate renewal, I'd find I'd make mistakes and/or that things had changed in the intervening time.

It's also infrequent enough to often remain a manual process when it really should be automated.

That said, I still haven't automated renewal of my personal ones using LetsEncrypt, but it's also so simple I don't really need to.

At any of my previous jobs where I've had to deal with certificates, a 90 day cycle would have guaranteed I'd have it down to at least just "run this script"

Re: Technical Details on the Recent Firefox Add-On Outage

#96

Post by yellowapple »

tedunangst wrote: post #34

> For the other groups we are developing a patch to Firefox that will install the new certificate once people update. This was released as a “dot release” so people will get it — and probably have already — through the ordinary update channel. If you have a downstream build, you’ll need to wait for your build maintainer to update. Why not link to the xpi that can be installed now?

> Why not link to the xpi that can be installed now?

This is the crux of my remaining frustration with how Mozilla handled this issue. That XPI should've been front-and-center in all the articles that detailed the fix. And yet, instead of something like...

"If you have Studies enabled, a fix should apply automatically. If it hasn't yet, or if you have Studies turned off (or are using a version which does not support Studies), you can install the hotfix add-on [here](URL to XPI)."

...pretty much all the official messaging ended up like so:

"If you have Studies enabled, a fix should apply automatically. It may take up to 6 hours; please be patient and wait for it. If you don't want to (or can't) turn on Studies, you're SOL until we push out a point release (and further SOL if you're at the mercy of a Linux package maintainer or you want to use a version of Firefox that still supports XUL-based addons)."

The notion that this was a deliberate ploy to get more people to turn on Studies is surely conspiracy-theorist mumbo-jumbo, but nonsense like this makes me wonder.

Re: Technical Details on the Recent Firefox Add-On Outage

#97

Post by toyg »

> users should be able to opt-in to updates (including hot-fixes) but opt out of everything else

Finally some good news. This is what I suggested in one of the previous threads: there should be a delivery channel for important updates, and a channel for experiments/telemetry/whatnot. Some other HNer said it was an unrealistic expectation "because manpower". Guess what, it isn't. This is how things should always be.

Re: Technical Details on the Recent Firefox Add-On Outage

#98

Post by kccqzy »

Wowfunhappy wrote: post #83
callahad wrote: post #58

Earlier quoted context omitted.

That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte... , which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and…

Does Windows et al really not provide a mechinism for saving privileged settings in a tamper-resistant way? I frankly find that hard to believe. How does other software solve this problem? There are of course always workarounds on an open platform like Windows/Mac/Linux, but the threshold isn’t “impossible”, it’s just “as difficult as injecting into the browser’s code.” Edit: For example, what if the config file cont…

I frankly find that easy to believe. After all, operating systems give desktop apps a lot of trust because they trust these desktop apps to respect the users' trust. It is very recent that we now have desktop apps running potentially untrusted code that can subvert the trusted desktop app.

Of course, there are ways but just none are convenient. Generally the well established security boundaries are between the operating system and the user, and then between different users. Almost all the ways I can think of involves Firefox temporarily elevating privileges, which is undesirable.

Re: Technical Details on the Recent Firefox Add-On Outage

#99

Post by nocman »

pbhjpbhj wrote: post #91
callahad wrote: post #58

Earlier quoted context omitted.

That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte... , which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and…

So that means going forward if Mozilla don't want you to have an add-on then you won't be able to enable it?

Unless you run an unbranded builds ( https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded... ), or the Developer Edition ( https://www.mozilla.org/en-US/firefox/developer/ ), where setting xpinstall.signatures.required to false still works, then yes, Mozilla can prevent you from using an add-on.

More than "going forward", this has been the case for a while now. It's been long enough ago that they disabled that setting in stock Firefox that I don't remember exactly when it happened.

Re: Technical Details on the Recent Firefox Add-On Outage

#100

Post by callahad »

pbhjpbhj wrote: post #91
callahad wrote: post #58

Earlier quoted context omitted.

That's covered at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte... , which is linked from ekr's post. I encourage you to read the rationale as a whole, but the specific question you're asking is addressed here: > Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and…

So that means going forward if Mozilla don't want you to have an add-on then you won't be able to enable it?

We do not take an editorial stance on add-on content with regard to signing, but we do have the ability to block add-ons that are malicious or which violate user privacy and security. We hope those choices will be few and far between, and that our users will agree with them.

Our Add-on Policy is discussed further at https://blog.mozilla.org/addons/2019/05/02/add-on-policy-and...

Post reply on HN