Live data from Hacker News

Update Regarding Add-Ons in Firefox

blog.mozilla.org

391–400 of 504 posts

Re: Update Regarding Add-Ons in Firefox

#391
post #307

Earlier quoted context omitted.

Cert check doesn't need to connect to any url to fail. It's just the cert's only expired 20 hours ago, so this issue is currently only affecting approximately 83% of users who happen to be checking at a time of day that has already passed, over the next 4 hours that will go up to 100% (ignoring users who receive a fix before it breaks).

ah, good point. i didn't think through beforehand how this should have worked.

i passed my `app.update.lastUpdateTime.xpi-signature-verification` time and still had no issues with addons failing, so i dug into it a bit.

turns out i had `xpinstall.signatures.required` set to `false`, which i'd done to get an older extension working in the past (and subsequently forgot to set it back to `true` later). so i don't think my install of firefox has been checking addon signatures for a while now, which is why my addons remained functional (with other security implications of course).

i didn't immediately find where the cert was stored (to check it's expiration date) however.

Re: Update Regarding Add-Ons in Firefox

#392

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…

For me at least, it was pleasantly surprising that Google either has no inventory or just no clue who I am, as when ublock got disabled by this bug, YouTube started presenting me with ads for cars in mostly Japanese, with prices in Yen and "Singapore stock also available".

I guess because I watched anime videos?

Re: Update Regarding Add-Ons in Firefox

#393
post #386
post #292

Earlier quoted context omitted.

We’re literally in this mess because Firefox requires digital signatures on this kind of thing, please don’t make FUD posts. This is much better than disabling the very same safe guard, signature checking, that prevents you from running arbitrary code in the first place.

How is this better then enabling studies, a setting that is already part of Firefox? Installing add-ons from random sources can be risky. But anyways, I'm not sure why, but the addons on my main computer remained enabled... unlike my 2 other computers.

It's cryptographically signed by Mozilla. The signature is much more important than the source.

Re: Update Regarding Add-Ons in Firefox

#394
post #41

Earlier quoted context omitted.

Hold up there. Before people start clicking and installing random add-on links, how about linking to something official (either from a FF dev, or in a soure repository) that references this URL?

So, I just got this url from this HN comment: https://news.ycombinator.com/item?id=19825921 I'm not clear if they rehosted the XPI or if that's the original mozilla url. I'm not too worried about it either. The only reason anyone is clicking on this fine link is because firefox only lets you install addons signed by Mozilla. And since the typical signing process gives addons signed by the broken intermediary we can b…

>I'm not too worried about it either. The only reason anyone is clicking on this fine link is because firefox only lets you install addons signed by Mozilla.

unzip *.xpi

nano META-INF/manifest.mf

gives me

Manifest-Version: 1.0

Name: background.js Digest-Algorithms: MD5 SHA1 MD5-Digest: pcBRGwbuhPz06VrGWmAitQ== SHA1-Digest: szDd6YcB3bpF+NusZhEHhmMDi5U=

Name: content.js Digest-Algorithms: MD5 SHA1 MD5-Digest: CGOATrflEiq+QEu1IZlFvQ== SHA1-Digest: ps2bMGGRQdb4E7VOakqQEhJ8M5c=

Name: content.js.map Digest-Algorithms: MD5 SHA1 MD5-Digest: FY98a5hwQKH3g1fKcGK04A== SHA1-Digest: bAzZBP+YQ3EDWUXpqzKcTUw35Y0=

Name: manifest.json Digest-Algorithms: MD5 SHA1 MD5-Digest: eEm4sDKemttFN7G7JeLo0g== SHA1-Digest: 5W8OY1mk3QjECHzHna00iNXo9mM=

Name: experiments/skeleton/api.js Digest-Algorithms: MD5 SHA1 MD5-Digest: 0RBtD2TRmeE30v9+4TxXYA== SHA1-Digest: 2Uq9PO2H1iks/Cb7VAkfGrrD6hA=

Name: experiments/skeleton/schema.json Digest-Algorithms: MD5 SHA1 MD5-Digest: nSzuviuP+VtUvjE4IyIVhQ== SHA1-Digest: W311W+MXcHSsHIVFP15zxGUmQS8=

===

The hashes that certify the integrity of the files are under rigorous protection of ... MD5 and SHA1 (!)

Re: Update Regarding Add-Ons in Firefox

#396

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…

I can't help but consider the tinfoil hat aspects of this matter. I would like to learn more about the sequence of events that lead to this snafu. Would an actor know that by making "an error" at a given point in time, there would be a deterministic window of time in the future where Firefox users worldwide would be affected by the consequences.

Re: Update Regarding Add-Ons in Firefox

#397

Earlier quoted context omitted.

Typing this from a new Brave install. Just switched from Firefox after their handling of this.

Have they stopped whitelisting Facebook and Twitter in their "tracking blocker" yet? The BS coming from their blog post surrounding this whitelist makes me distrust them completely: "Loading a script from an edge-cache does not track a user without third-party cookies or equivalent browser-local storage" (...) "Given that most users on the web share IP addresses with other users because of NAT, it is unlikely this ca…

Apparently not. Would there be a way via settings to just explicitly blacklist?

Re: Update Regarding Add-Ons in Firefox

#398
post #395

I am a bit salty that this reset my default search to Google of course, just an option away. Still :<

I am also extremely pissed.

Still, I was searching for alternatives on Android. It's ridiculous that no other browser allows extensions, not even Chrome itself.

Firefox is way more advanced on this. That's one more reason that is very hard to say goodbye to them...

Re: Update Regarding Add-Ons in Firefox

#399
post #369

Earlier quoted context omitted.

So a security feature that had 0 impact for decades is "crippling" the usability of a project due to one outage?

I use container tabs extensively. Today, more than half of my open tabs disappeared in an instant , and were not even an option to re-open until either I waited around ("up to six hours...") or manually installed the workaround. All of my in-progress work in any of those tabs? Gone. That absolutely qualifies as crippled usability. The mere fact of such a thing being possible is a usability defect. On what basis do I…

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 overzealous security controls is inane.

Re: Update Regarding Add-Ons in Firefox

#400
post #355
post #211

Earlier quoted context omitted.

Could you explain why verifying on every startup, instead of just on install, is necessary? The page you linked doesn't mention it. Edit: Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old?

> Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old? I asked essentially that question earlier, and received some good answers explaining why [1]. Briefly, if something is signed by an expired certificate, whether or not you can trust the signature depends on whether or not the signing took place while the certi…

I checked the hash functions for the xpi, its broken MD5 and broken SHA... which doesn't matter for a running instance if FF takes care to download it from their own servers over HTTPS... but in the attack model you describe it is retrieving the signatures from an untrusted disk.

https://news.ycombinator.com/item?id=19830228

Post reply on HN