Feeling safer online with Firefox
blog.astithas.com
blog.astithas.com
One suggestion: In the Control Center™, I would recommend using the past-tense for the current state. E.g.,
Receive Notifications Allowed X
Access Your Location Allowed X
Maintain Offline Storage Allowed X
Receive Notifications Allowed [Disallow]I agree. An X usually means "close" or "hide this thing," whereas here they're using it to change a setting. It really looks like there should be a toggle switch there.
But I personally would feel far more secure if there was a firefox-lite where no sensitive stuff (access camera, share screen) were included to start with. And I don't mean turned off by default, I want it removed at compile time.
You can test it here: https://browserleaks.com/webrtc
I tried that test page with the mentioned setting 1) enabled and 2) disabled. I did not see my local IP on 1), I did get see it reported with 2) - so it seems the block works. NOTE: Whether uBlock Origin was enabled for the specific page did not matter, the WebRTC block setting seems to be global and independent of whether the extension blocks anything else on the site.
They aren't suggesting using compile flags requires code changes...
Then you make a custom mozconfig file to disable or enable features, or to add your own extensions (ie: windows): https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-installer
ac_add_options --disable-crashreporter
But I agree, I can't find any documentation what exactly every feature is and why you would not want to disable/enable them. The Chromium build process is much more straight forward, or you could just use 3rd party sandbox and regular release FF.
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
On Linux I clone the source and run "./mach build".
sudo apt update && sudo apt install python build-essential -y
wget -O bootstrap.py https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py && python bootstrap.py
cd mozilla-unified/
./mach buildhttps://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
mozilla-central is just such a big repository that it pushes the usual cloning process to its limits.
The Rust dependency was added to Firefox very recently, so I guess with the holidays it hasn't made it into the bootstrap script and docs yet.
I have no use for WebRTC, so I would not install the addon/plugin. You may want it, so you would. When there was a problem with Mozilla's implementation, I wouldn't have to care, and neither would anyone else who didn't use or want it. Only those that chose to have the functionality would need to be concerned, and even then it could be updated without a full browser update.
So if your threat model includes targeted attacks, where an attacker might invest some (even a small) level of effort to find a 0-day vulnerability, I don't think I'd use it.
So you probably don't need to do effort to find a 0-day, just browse old Mozilla CVE disclosures.
edit: I'd reply to your response below normally but apparently I don't get to reply to any comments on HN anymore. The reply button has disappeared. When I log out of my 5 year old/458 karma account it's back. I guess my opinion isn't wanted here.
You have a good point there. I bet a least a couple of those are present. But you've also completely missed my point. When looking through the FF known vuln list the vast majority are for things like WebRTC, WebGl, and other attack surfaces that Pale Moon intentionally avoids.
This isn't FUD. You can literally go read the list:
https://www.mozilla.org/en-US/security/known-vulnerabilities...
I count over 174 fixed vulnerabilities and stopped at version 48. Yes, some of these might not apply to Pale Moon because they're new vulnerabilities or it has the relevant feature disabled. You think anyone did the work to go through them all? Let alone backport the ones that are relevant?
Mozilla used to do this work for Pale Moon by virtue of still backporting the most important ones (i.e. not all) to ESR38. Not any more. Good luck!
the vast majority are for things like WebRTC, WebGl, and other attack surfaces that Pale Moon intentionally avoids
Pale Moon supports WebGL nowadays. It's needed for a few things like Google Maps to not suck. Of course, the implementation is outdated, which is perhaps what made you think it's not there...
And I'm betting most of the time they succeed. There may be a few weird ones with edge cases that they've screwed up though and some subset of the vulnerability is still possible.
I have pointed out many of these and argued with Pale Moon devs about it. "Moon Child" believes they don't need to apply patches if they can't replicate the PoC from Mozilla's bugzilla.
These are things that are obviously vulnerable and need to be fixed (such as missing bound checks in the XML parser).
If someone ever cared enough to target Pale Moon users they would have an absolute field day with all the known Firefox vulnerabilities they could use.
HN delays the visibility of the reply link on threads that seem to be getting too deep too quickly.
The real reason is that they are based off of an old ESR and their code wouldn't be able to inter-operate with anything else. Aside from the issue that they're not getting security patches for it, either...
The recommendation to use an external PDF reader is also not quite something I can stand behind. (Unless that external reader is Chrome...)
As for external PDF readers I'd argue that avoiding the push for integrating or redeveloping more and more external applications into a browser is very sane.
This is a bit like saying "Firefox 4 has HTML5". The WebRTC stack in Firefox evolved significantly from Firefox 38 to 50, as did the WebRTC standards themselves. That's why I pointed to interoperability issues.
You're going to have to dig up a browser whose authors don't subscribe to this vision, or browsers that may intend to do this down the road but haven't caught up yet. For the time being, out of graphical browsers, Dillo and Netsurf are in this category.
Many features can be turned off globally in about:config in a way that will not result in an opt-in prompt and will also reduce the javascript API surface.
Is that not good enough?
When using the UI it's a bit more clear: you can't click "Allow". But just looking at the screenshot, I had the impression this was a request dialog somehow. I thought Allow was clickable to give permission, and the X was to dismiss being told the site wanted to know about the permission request.
The little X doesn't seem like a common UI element to indicate "block", but it's probably ugly to say "Allowed - [Block]".
Another idea might be to write "Currently allowed" or "This site has access to" under the word "Permissions".
It has no information on CA, whenever it's first time you saw this exact certificate or not, whenever a "weak" or "strong" ciphers are used (and if PFS is enabled), etc - things one'd really want to see if they care about their connection encryption and authentication. It's all still available, but hidden after long sequence of button clicks. Heck, it would be useful to have client certificate and HTTP auth status there as well - it would actually make those nice things closer to being usable.
I really fail to understand why it can't be displayed in a sanely concise manner - and why things that were there before were removed. Surely there's a plenty of screen space and it's not like it would scare Joe Sixpack off to Chrome, or confuse anyone. Or analytics show it otherwise?
Three, actually. One on the i+lock icon pair, one on the right-pointing arrow, then one on "more info". If I'd need more details (like issue and expiry dates, which is pretty common thing to be interested in), then it's 1 more button "view certificate". And if I'd happen to be interested in certificate public key properties (algorithm and key size) it's a really long story, 6 clicks away from the address bar.
It certainly makes sense to not show something right away, on the first click. But the current UI hides quite essential information (to those who can understand it) way too deep. I'm really not persuaded it would hurt usability and confuse users if such information would be 2 clicks away, rather than 4-6.
(And, really, it mustn't hurt to show at least "have I visited this page prior to today? yep, 234 times" on the very first click. And probably won't confuse anyone much to also see something like "TLS1.2, modern ciphers" or "TLS1.0, legacy ciphers".)
> Ctrl/Cmd-I
Toggles bookmarks sidebar for me. I'm unaware of any shortcut to open page info.
Feeling safe, and being safe are two different things.
Same goes for self signed (or expired) certificates and 'not secure' connections, they are not per definition 'not secure'.
Ironically, as far as "privacy-oriented browsers" go, Chrome has domain whitelisting of Cookies/JS/Plugins easily accessible from address bar and it works as expected.
I think this is going to be a nice improvement. It was way to easy to "loose" the permissions dialog in the older flow.
Also, I got kind of annoyed when one of their leaders came begging for donations by email, but are getting paid FAR beyond normal wage.
I'm quite glad that Firefox implements sandboxing of its own.
Given that 95% of what I do on my personal computer is in the browser, sandboxing the rest of my computer from the browser is sort of a https://xkcd.com/1200/ situation.
No. Reasons not aside. Reasons are very important.
If the guys had said, "We didn't bother with Firefox because they weren't willing to pay us as much as Google or Microsoft", okay. But they didn't. What they said was:
'We wanted to focus on the browsers that have made serious security improvements in the last year,' Brian Gorenc, manager of Vulnerability Research at HPE said."
And now Firefox looks weak by comparison.
Why would they have said that, even if it were true? What's the upside for them?
I agree the net result is the same whether they were honest or not, of course, which is again why there was no upside for them to say that if it were true.
https://blog.mozilla.org/futurereleases/2016/12/21/update-on...
The statement quoted in Slashdot is really unfair.
I don't think you understand how PWN2OWN works. And the poster you replied to was right, at the time of PWN2OWN 2016 Firefox was the only browser without a working sandbox. It would have been very easy to compromise it.