Firefox about:config privacy settings
gist.github.com
gist.github.com
This bug tracks the proper solution: https://bugzilla.mozilla.org/show_bug.cgi?id=1429522
I made this change just to see. So far it does appear to have lowered the energy impact score a bit, but I'm not sure it's enough to matter yet. I guess we'll know in a couple hours.
Edit: 20 minutes in and I've watched my Time Remaining estimate creep up from 3 hours to 5.5 hours. Seems like a solid win so far (other than it looks like crap).
One small change I made was streaming music to my phone, and that had a big impact.
I know that streaming will use some battery life, but the amount of CPU being used by say, Pandora, was rather extreme.
I'm not the only one who experiences this either, I have a coworker who complains about the same issue with his couple year old MBP. Firefox is a battery vampire.
One issue fudging around with about:config presents could be increased fingerprintability. More battery life is cool, but will it come at the expense of an easily fingerprinted browser profile?
2) Or does it? I could envision a timing attack in Javascript that can detect rendering speed accurately enough to determine if the window is being composited with transparency.
This is a blunt tool. Some sites uses context menu events in a benign way. A better alternative is to simply bypass context handlers with shift-rightclick when necessary.
> webgl.force-enabled
This isn't really a performance improvement. If webgl is disabled it's due to troublesome drivers. Forcing it on can crash things.
> layers.offmainthreadcomposition.enabled = true > layers.offmainthreadcomposition.async-animations = true
Those are the defaults anyway on supported platforms
Applying all of the changes at this list will harm users and increase the chances of threats compromising the browser.
Don’t be shortsighted and use this blindly. Especially do not punish some poor unwary non-tech user by altering these settings on their behalf.
How so?
These instructions disable phishing lookups, rather than pointing users to a list of alternatives. This is unsafe and harmful to bury in this list.
network.cookie.alwaysAcceptSessionCookies = false
They will immediately lose the ability to login to their password manager, which requires session cookies.
browser.cache.disk.enable = false browser.cache.memory.enable = false
They will start loading every resource on a page on every visit to every page, as no resources will be cached. One hour of browsing will use a month's data quota and the glorious no-caching detail of every pageview will be closely observed by the server-side logging metrics that are so desperate these days to extract targetable marketing data.
webgl.force-enabled = true
Browsers disable WebGL in some scenarios to protect users from hardware, software, and/or driver bugs that cause crashes when WebGL is enabled. This setting overrides that which increases their risk of GPU, browser, and system crashes. Additionally all crashes are either "exploitable" or "not exploitable", so bypassing crash mitigation processes increases your risk of one such vector being used against your browser.
network.dns.disableIPv6 = true
Over the next ten years, the user will see that more and more of the web breaks down and mysteriously fails in their browser. Sites only load partially, videoconferencing never works properly, video streaming is jerky and slow. Providers shipped IPv6 to their customer endpoints years ago. Disabling it has potential downsides and no upsides either for "privacy settings" or anything else.
People making changes to user.js will have some knowledge of what they are doing, and handle the issues.
The post points some security/privacy extensions to complement. Nothing that a user changing user.js wouldn't already know.
I missed the high risk resist-fingerprinting setting and had no idea it would cause so many problems. Those problems certainly are not documented in the gist and I would have fallen prey to them if I had applied it unaware.
Advanced knowledge is not the issue. Misrepresented knowledge is the issue. A document about “privacy settings” contains non-privacy settings and does not contain any mention of the lasting harmful side effects due anyone who uses any of the settings within it.
EDIT: This is how to approach changing one of these settings with the respect and care due to such a suggestion:
You change it. Have issues. Realize it does not work for you. Change it back. If you're not sure or don't have time to deal with it, don't do it. Not difficult is it?
Ans a said previously the responsibility is in the person making the change to their browser, no one is forcing them.
This is my preferred approach: https://github.com/ghacksuserjs/ghacks-user.js https://github.com/pyllyukko/user.js
To be clearer here, lists of partial hashes are downloaded and entire links are only sent after partial match. Still worth disabling for privacy reasons if you care more about that than safe browsing protection, but worth clarifying how it works lest one thinks all links are sent.
Only part of a hash of the url is sent to get an update for all the URLs in the partial match block. The actual url is never sent.
The exception is when download malware protection is on. In that case, when downloading a file the actual URL is sent. That's a regular preference, though ("Block dangerous downloads"), doesn't need about:config changes, and is well described in the help docs.
https://support.mozilla.org/en-US/kb/how-does-phishing-and-m...
I find that these accumulated lists of security ideas are usually dangerous - in any domain, not just Firefox or browsers. They collect information and misinformation and add a veneer of legitimacy. Some settings don't behave as you think; some aren't documented; some are poorly implemented or tested by the vendor, who didn't design them for end users, and their malfunctions can create more security holes. Some are implemented for reasons you don't understand ('before you tear down a fence, know the reason it was put there'). Some are dependencies for other settings, features, and subsystems.
It would have to be work by an expert in browsers or Firefox or security, such as a Mozilla engineer or someone like Giorgio Maone, for me to trust a list like this one.
It goes like this:
Display characters that are out of range of your selected language's character set in a different colour than the characters of your language.
That way, when you go to раураӏ.com that last character shows up in red.
Homework: select two languages (e.g. Chinese and English), and use three colours. Make the colour scheme colour-blind-friendly.
(it just came to me, I haven't thought it through; I'd rather read different coloured characters than punycode)
* Identify TLD registry operators who have a sane approach that prohibits or otherwise is effective for controlling homographs, whitelist their TLDs, default to showing punycode (the A-labels used by the DNS system which are always just ASCII). This has the effect that if your name looks "wrong" that's a problem to take up with your TLD registry. Note that com doesn't have such policies at all, it's a vast sleazy market and it remains interesting to me that huge global brands would rather be in that market, trying to shout over the crowd, than leave it to rot.
* Identify cases like you've described with "confusing" mixtures of scripts and display those as punycode.
Both have problems. The former requires that you effectively police TLD registry operators. Find out what their policies are, check they actually implement those policies effectively, and take action if this changes. The latter requires you figure out how all the world's language communities use different scripts, and how that interacts with Unicode, in order to avoid penalising combinations lots of people want, while still detecting attacks.
Maybe whitelisting specific characters instead of only locale would be best.
Your color idea is neat but look at it from the perspective of people that actually use idn domains and don't speak english. What if раураӏ.com was раураӏ.fans-ùøê.com where ùøê was part of the same charset as ӏ and the user speaks both locale. Even if you color it,it would be difficult to train users to pick up on that.
All of them would show up in red, all of them are cyrillic. If all but one character was cyrillic, Firefox would detect this and render the url in punycode. As implemented now, firefox renders the URL as shown because all characters are from the same script (~character set). Chrome is more suspicious and renders it in punycode (https://xn--80aa0cbo65f.com/), though it would presumably render the confusing version if my locale was Russian.
Chesterton's Fence: Presumably Mozilla has already optimized the privacy and performance of Firefox as much as they've felt comfortable doing. If they could change each of those settings as recommended without tradeoffs to help the user, they would have done so.
Without listing the tradeoffs for each one, this list cannot be relied upon.
- and a reason they're still available for people in crowds like hacker news* readers etc.
Also, although I also think the proposed "upload" is poor wording, as many people seeing that will be confused because buttons that say that usually then request what to upload (e.g. "hmm, maybe it's asking for a local image to upload to the cloud for storage?"). You actually are saveing in both cases, in one case to the cloud, inthe other case to the disk. Thus, "Save to cloud" and "Save to disk" (or "Save locally") are much better options in my mind.
I assume they have some metric for success of the experiment tracking daily uploads to FF screenshots and they're unwilling to sacrifice that.
That doesn't really make a lot of sense though - the experiment was specifically launched with the goal of trying to solve the problem of sharing screenshots with others; a problem they identified as common through user research. So while I think there's a lot to say for changing the wording, the primary action will always be sharing it.
What you'll find, as has been the case for Mozilla in some recent decisions, is the tradeoff includes (but is not limited to) profitability and ease-of-use, two things you left off your list of what you think Mozilla optimizes for. That blind trust and invalid set of optimization metrics shouldn't be perpetuated. Granted blind trust in this list is unwise too.
Therefore manually removing all Google partner tracking features in about:config is a very sane choice.
In any case this is in my user.js:
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("privacy.trackingprotection.enabled", true);
user_pref("media.autoplay.enabled", false);
Along with ublocko and httpseverywhere, that covers a lot without breaking mostly anything.
A quite famous user.js hardening project is https://github.com/pyllyukko/user.js. But I've found that keeping such a complex configuration functional requires a lot of constant effort.
You say still, but this will be the first time in a few years that will probably be true. The details of the Google deal aren't public, but I doubt it forced them to spend the past few months secretly hiding Google tracking into the browser.
Well when you add that condition, sure.
If you understand that changing one of the defaults only affects ease-of-use, and you're a power user, more power to you! If you want to turn off analytics, cool!
But it gets trickier when it gets to the safebrowsing feature. The gist says to turn off all of those components, rather than just the ones that send hashed or partial file and address metadata to Google. That's not helping anybody.
(To be fair, I'd actually reword my original comment to change "worthless or dangerous" to something milder at this point, but HN won't let me do it. Oh well.)
Exactly.
> That's not helping anybody.
It helps the people that optimize for privacy above their own security in this case. From my understanding of the algorithm, you can't really leverage safe browsing properly without being willing to check the full hash via an internet call at some point. So might as well have it off or on. An extremely paranoid user might not want a safe-browsing download to occur at all, informing Google when their computer is on. These are paranoid stances, but it is a list of settings for that. I use a Chromium-based browser that doesn't use safe browsing lists and I accept the risks.
All of software has been around less than a century; the concept of personal computers running software that an end-user might adjust settings on is about sixty years old; thinking about Internet security is roughly thirty years old; the modern web ecosystem is no older than JavaScript, 22 years old.
You're still right that blindly changing settings is not a great idea, but the Chesterton's Fence analogy is misplaced.
MS don't have a publicly documented API, which makes it harder to know what's being sent (short of reverse-engineering it), but Google's never uploads actual addresses (it almost always only uploads the uppermost 32-bits of the SHA256 hash of the address, and it never uploads the full hash).
Side question: how many of these ought to just be standard behavior of the browser? For example, will Firefox's new tracking protection make Privacy Badger obsolete? Should the HTTPS Everywhere extension, which attempts to route any HTTP request to an equivalent HTTPS, be the default behavior?
That said, the bigger problem is that too many things that HTTPS Everywhere tries to upgrade to HTTPS are only partial versions of the site; you'd probably need something more conservative to avoid too much breakage.
In response to HTTPS Everywhere breaking things, it does, and I've done tests comparing it and DDG PE and and found sites that would break using HTTPS Everywhere did not with DDG PE. They may simply be doing more testing.
"remove_plugins-enumerable_names.patch
Bug 757726 hid most plugins from navigator.plugins enumeration to reduce fingerprinting. Plugin detection scripts could ask for a plugin or MIME type by name, but they couldn't get a list of all installed plugins. Unfortunately, the feature had to be disabled because it broke pretty much all plugin detection scripts because they naively search for the desired plugin using an O(n) loop instead of a O(1) query.
This patch removes the disabled code because it is unlikely we could ever re-enable it. In addition to removing the obsolete navigator.plugin tests for detecting hidden plugins, it adds tests for detecting click-to-play and disabled plugins."
This affected enough sites that it was a serious problem for users, not a "very tiny bug".
In any case, at this point Firefox supports exactly one plug-in, so all enumeration can tell you is whether Flash is installed or not. That's still one bit of data, of course, but that bit could be extracted even with the "no enumeration" patch by explicitly querying whether Flash is supported.
I've been using FireFox Quantum as my primary browser for 3 or 4 months now and am really trying to love it, but chrome is just so much snappier..
When you're sure you're happy with the changes, then you can just drop 'user.js' into the profile folder(s) on your other machines.
The process is detailed here. https://www.ghacks.net/2015/08/18/a-comprehensive-list-of-fi...
Edit: I haven't personally tested this past FF59.
- With right clicks I want sites to be able to supplement options but the only options are "complete replacement" or "no modification at all".
- I don't want to disable sending MIME information when I paste to prevent a site from being able to block me from copying.
- Why do I have to make the url unreadable to have special characters emphasized?
Given I have to go to this website about 1000x per day, you can see why using FF is painful...
Anyone have any advice (on config, for example) for fixing this? And if anyone on the FF team is listening... I'd like to use your browser, but this has kept me from doing so.
$ sudo python -m SimpleHTTPServer 80
Chrome doesnt do this either as far as I can tell.
Sounds like they'd visited the URL in the past and had it in their history.
What? Isn't it the opposite? I have the exact opposite experience with Firefox and Chrome, FF autofills the ports and Chrome doesn't oO
I just checked it right now to be sure I reminded correctly
To be honest, Firefox likes to mess with input too, but it can be easily tamed with few prefs, namely:
keyword.enabled=false
// no implicit searching from URL, must use explicit keyword or Searchbar
browser.fixup.alternate.enabled=false
// this prevents trying www. … .com or other configured suffixes when domain-like URL fails
browser.urlbar.trimURLs=false
// do not hide protocol and slash
browser.urlbar.filter.javascript=false
// bookmarklets FTWI don't know what is going on with your nginx setup. Most likely you've configured it differently than you think you have, or are making different requests in Firefox and Chome without realizing it. Both firefox and chrome behave the same for me when I make an http request to to a server using https (e.g. http://www.example.com:443/)
Safari, Chrome implement these APIs out-of-the-box but FF wants users to open `about:config` (and ignore the ominous warning) and set `dom.streams.enabled` and `javascript.options.streams` to `true`.
It seems a little backwards to me since this has been available since version 57 and their webpage is the first result when searching for this documentation!
https://developer.mozilla.org/en-US/docs/Web/API/ReadableStr...
https://bugzilla.mozilla.org/show_bug.cgi?id=1389628 is the tracking bug for enabling it by default.
One feature of Chrome I like a lot is the super simple per-site settings options. I use this to disable JS on a number of sites without impacting any other sites. As far as I can tell there is no option built into Firefox that allows me to do this. Does anyone know of a simple way to get per-site JS blocking?
I have looked at a few extensions which works but I was wondering (hoping) for a hidden Firefox option to do such a thing. I hacve tried to get Firefox policies to work but they appear broken?
Can anyone help?
https://github.com/pyllyukko/user.js
This does things like blocking analytics and browser fingerprinting, and it's a simple to install or revert---just drop the user.js file in your Firefox profile directory.
https://github.com/pyllyukko/user.js/issues/27#issuecomment-...
One setting I read about recently I wanted changed was to turn off URL trimming, so http:// still displays and the like: browser.urlbar.trimURLs
https://bugzilla.mozilla.org/show_bug.cgi?id=660367
// Our internal trim prevention logic is effective on 2K/XP at maintaining
// the working set when windows are minimized, but on Vista and up it has
// little to no effect. Since this feature has been the source of numerous
// bugs over the years, disable it (sTrimOnMinimize=1) on Vista and up.> network.http.sendRefererHeader = 0
WARNING: twitter.com does not work with this setting
default value is 2
Tested on FF 62, Win 10 Pro