241–250 of 279 posts
My heartfelt condolences to everyone who has had to browse the internet without an ad blocker. Nobody deserves that.
This is why you should have multi-tier defenses. An ad blocker in the browser, blackholed domains in your hosts file, and use DNS servers that also blackholes ad domains.
I don't understand one thing. How were they able to generate a new certificate with the same subject, a different expiration date, and the same signature. I assume I missed something in reading this.
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…
Firefox is still considered open source, correct? From what I know, open source software is meant to be altered.
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…
There's a couple of options of Android; you could use the DDG browser[0] or the Privacy Browser[1] (which I know sounds dodgy but seems legit). They don't have 'adblock' exactly but I think they implement a lot of the same lists such as EasyList. [0] https://f-droid.org/en/packages/se.johanhil.duckduckgo/ [1] https://f-droid.org/en/packages/com.stoutner.privacybrowser....
Earlier quoted context omitted.
FWIW, I was genuinely shocked that this could happen, and it has severely damaged my trust in Firefox. I am extremely wary, having been bitten more than once, about software that automatically updates itself or is otherwise subject to remote interference. I don't run Windows 10. I don't use Chrome for anything important. I avoid subscription-based or activation-required software as much as possible. And in Firefox, I…
> I find the argument that it's impossible to make this configurable because malware could then circumvent it very weak. If we're talking about that level of interference, anyone with access to the Firefox executable could in theory replace it, and given the open source nature of the Firefox codebase this wouldn't be particularly difficult technically for anyone willing to go to such lengths in the first place. As me…
Sorry, but I don't really see how. We've been using click-to-play safeguards on embedded content for years, and they have proved highly effective at stopping abusive or outright malicious content in Flash, Java applets, etc. Why couldn't a similar safeguard be used to isolate untrusted addons but still give users the option to override and run them in the current session if they really do want to? I don't see why such a mechanism would be more vulnerable than any other hard-coded browser behaviour, including refusing to run those addons at all. If you made the behaviour configurable via a persistent setting then obviously that could be subject to external modification, but you don't have to do that here.
That this happened was a risk, and they're taking active measures in the future. The other was a certainty, and this risk was the active measure they were taking against it.
I respectfully disagree with this stance. That malicious sites are actively compromising user privacy is also not a risk, it is a certainty. That addons to block unwanted content have stopped malware from exploiting browser vulnerabilities and infecting user systems is also not a risk, it is a certainty. It would take substantial evidence to convince me that the risk from greyware apps was really greater than the risk of privacy and security invasions across the entire Web.
Earlier quoted context omitted.
It could just as well been signed today with a fake date. The traditional option (used by things like Java and ActiveX since the early 2000s) is Trusted Timestamping [1], where a trusted third party provides a signature (such as via RFC 3161 Time Stamp Protocol). AFAIK every certificate authority that sells code-signing certificates also provides a free timestamping server. If you trust a CA to issue code-signing cer…
You don’t trust an authority, you trust a private key that matches a public key you know. The point is that as time marches on the key might leak or be cracked and then your trust is misplaced. So you say the key pair expires and you stop trusting it before that happens. This trusted timestamping relies on the same signing things with public and private keys process so it just adds a step, it doesn’t solve the proble…
Admittedly, CAs are held to higher standards than most certificate users in terms of keeping keys in hardware security modules and suchlike. So perhaps it's not 100% unjustified that they get longer validity periods.
Earlier quoted context omitted.
It’s funny how the mind works. We tend to accept the far greater risk of allowing automated software updates (either in-app or blindly trusting your package manager e.g. apt-get upgrade ) but the Firefox Studies mechanism which does a minuscule, strict subset of what any automatic update can do is somehow a “crazy security risk”.
In the case of apt-get, there's a release process with signed packages and open source code that the distributions adhere to, publicly visible oversight etc. End users specifically make the choice, either to run the upgrade process themselves, or set up automated upgrades on the understanding of what processes things have gone through, and the ability to verify. The Studies mechanism occurs silently, running private…
At the end of the day the question is whether you can trust Mozilla. I trust them more than most entities, including many that push changes through apt-get.
Earlier quoted context omitted.
It’s funny how the mind works. We tend to accept the far greater risk of allowing automated software updates (either in-app or blindly trusting your package manager e.g. apt-get upgrade ) but the Firefox Studies mechanism which does a minuscule, strict subset of what any automatic update can do is somehow a “crazy security risk”.
Normal update channels usually ask me (or let me set it so that they have to ask me) if I want to apply the update and I make sure to at least read the changelog if not skim through the source. In addition to that I trust the Debian team much more than I trust the Mozilla team. The studies in contrast are both for anti-user things such as telemetry and the mr robot thing, are inconvenient to disable, are not transpar…
Seriously, look at how studies operates. If you're using firefox, go to about:studies and see for yourself.
Earlier quoted context omitted.
It’s funny how the mind works. We tend to accept the far greater risk of allowing automated software updates (either in-app or blindly trusting your package manager e.g. apt-get upgrade ) but the Firefox Studies mechanism which does a minuscule, strict subset of what any automatic update can do is somehow a “crazy security risk”.
I chose to run apt-get to install packages. I have never opted-in to, nor even known about, how Firefox was running "studies" on me before this event. It's like finding out the TV you bought last year has a hidden camera and it's been recording you the whole time.
In my own browser, if I go to about:studies, I have two Studies running. One is the hotfix for the add-on signing issue. The other is:
prefflip-push-performance-1491171 • Active
This study sets dom.push.alwaysConnect to false.
Earlier quoted context omitted.
Well I've just been educated on a new mechanism by which things can be remotely broken.
Just to be clear: supported version or not, this sucks, and I hope we'll have a fix for you. I wanted to point out this wasn't remotely broken, however. Even if you had no internet connection, your addons would have stopped working when the certificate expired. (Disclosure: I work for Mozilla)
I just wanted to chime in way down deep in this comment chain because my thought only makes sense in the context of your comment right here.
I think there may be a special mode of operation of Firefox that may need to be considered here.
You said, "Even if you had no internet connection, your addons would have stopped working when the certificate expired."
This seems like an unfortunate design flaw to me. Consider a Firefox, kitted out with specific set of add-ons setup to the user's liking. Then, the network that Firefox is located on becomes permanently cutoff from the internet and can no longer make contact with the Mozilla mother ship. Maybe it's running in a VM, or maybe it's running in a country with an oppressive regime. I can think of many scenarios where a Firefox would be cutoff.
I think it is a reasonable expectation that the marooned Firefox should continue to run indefinitely without failure. Perhaps the user could be occasionally (monthly, yearly) flagged with warnings that the mother ship could not be contacted, but other than that, nothing should fail.
Please consider this and share it with your teams when the post mortem is discussed.
Thanks! I'm a loyal user since before Firefox.