Adapting & fixing core settings

[intika]

Following https://github.com/intika/Librefox/issues/34 many settings have to be defaulted to a different value while leaving the choice for the user... Here are some pro developer feedback for Librefox

Eloston

What do you think made ungoogled-chromium successful ?

"Success" is a pretty broad term. I will assume you define "success" based on the number of users, what users say about the project, and the kinds of bug reports this project receives. In that case, there are several points I can note (in no particular order of importance):

• Continual desire to improve the project and oneself. I think this is the most important point. I mainly gather ideas based on feedback, experiences from this and past software projects, and experimenting with software in general. I also gather ideas by reading code and docs from Google, reading technical blog posts about software, and reading about new developments in software engineering.

• Dedicating a lot of time to the project. Especially in the following areas:

• Consistent attention to overall quality of documentation, code, and user experience (building the browser, using the browser, downloading pre-built binaries, reading documentation, etc.)

  • Responding to feedback on GitHub.
  • Considering all aspects of a bug, enhancement, request, question, etc.
  • Leaving a good impression on anyone who comes by. This happens in a number of ways, but a lot of this happened via the points I made above.
  • Contributors keep the momentum going. Particularly in updating Chromium versions.
  • The Chrome/Chromium userbase is large. The number of people concerned about privacy/security and Google's role in privacy is also decently large. Having a number of people interested in a project like this helps a lot.
  • In the beginning (some time before the first spike of users), I went to a few different places to advertise this project. Then, I let other people spread the word. This works because of the number of interested users.

Also one thing, a lot of people asked me about mozilla trademark (Firefox) while i was disturbing a patched version it's curious that uc did not face this problem, i guess google folks are more permissive.

This project is not widely known, and people aren't confusing it with the trademarked Chrome and Chromium. If it becomes an issue, then I'll be fine with changing it.

Do you have any advice/comments regarding the direction of my project ?

I don't know much about Firefox, so I can't give you any specific advice. Hopefully my comments on what made this project successful will help you too. Regardless, I am glad that my project has inspired you to create Librefox. I wish you luck with it!

Moonchild

• Block third-party cookies: Can block some sites (Add it as a choice)
• Completely disable the password manager how does this improve privacy, exactly, by forcing users to type their credentials every time? ( ... )
• Completely disables IPv6 support. ( ... )
• Completely disables all parts of the blocklist, including known broken gfx driver issues. This will expose users to many issues with known graphics driver problems ( ... )
• Completely disables integration with the add-ons site. (addon can still be installed its just that there is no integration - add it as a choice ?)
• Completely disables extension updates (Add it as a choice)
• Completely disables Windows jumplists, because.... ( ... )
• Completely disables pre-loading of known HSTS domains; this opens the user up to first-time-visit spoofing. HSTS preloading is harmless, blocked because it's supplied by Mozilla? ( ... )
• Completely disables OCSP, but enables OCSP stapling, which won't work with disabled OCSP. ( ... )
• Conflicting prefs with result that at best a CRL fallback is used, and at worst no checking is performed at all and revoked certs are accepted as secure. Well done Librefox, you broke https authentication checks. ( ... )
• Not forced but default; WebGL and layers acceleration is force-enabled. This will break the browser on many more systems because of GFX issues (especially hybrid and mobile chips), especially if blocklist entries aren't checked or used. ( ... )
• Completely disables webgl2 and forces webgl minimum-capability mode. This pretty much makes webgl useless. No reason to do this, since the (already enforced) fingerprinting protection already mitigates any potential webgl leaks. Fingerprinting protection doesn't enforce minimum capability mode for a reason. ( ... )
• Disables clipboard events, breaking many sites that use JS to place data on the clipboard... ( ... copy button still works)
• Done with lockPref (Add it as a choice)
• Considering there are plenty of duplicate entries in there you may find it frustrating that it doesn't take unless you hunt down all copies of a setting ( ... There is no duplicate but related settings).
• IMHO it's just another example of copy-pasta of insane configurations ( ... Settings have been tested but any way)
• It's not even a rebuild, it's just reconfigured ( ... )
• Check wolfbeast reply

Pants

• Extensions update notice
• Warn and provide a checklist (because of insane niche settings)
• Provide the support for users to make changes and understand wtf just happened
• Librefox is breaking shit left right and center - it's too much mate! It's a shell of a browser and it's kinda dangerous.
• The project needs to be differentiated (Currently it's reinventing the wheel)
• The "Dangerousness" of some settings
• Added prefs from god knows where (We don't add everything for a reason, so you'll need to look at that as well)
• There's the lock pref stuff
• Stripping important things out like Safe Browsing
• Dropping recommending extensions
• New users may be put at risk.
• People can achieve what you're done with a user.js - sure, I haven't exactly followed what core FF changes you have done, but they aren't needed IMO.
• You have to assume that anyone who uses your product has no knowledge or skills :)
• Wiki full of things like important stuff to check when first getting it. recommended extensions.
• You have a lot of work in front of you, and I can't help but feel you had no idea that this will suck the life out of you, and consume all your time. I don't want you to die intika , I like ya. kiss
• Don't listen to some of the rabid commentators on your repo. Just because that's how they like it, doesn't mean it's a good default (I have read some ludicrous ideas from some of them already).

Also, already looked at, but need to re review for new version

/* ALREADY COVERED: by master pref extensions.pocket.enabled ***/
    extensions.pocket.api                                                ""
    extensions.pocket.oAuthConsumerKey                                   ""
    extensions.pocket.site                                               ""
/* INFO URLS ETC: require user interaction (e.g Help>Submit Feedback) ***/
    app.feedback.baseURL                                                 ""
    app.releaseNotesURL                                                  ""
    browser.contentblocking.reportBreakage.url                           ""
    datareporting.healthreport.infoURL                                   ""
    toolkit.crashreporter.infoURL                                        ""
    toolkit.telemetry.infoURL                                            ""
    privacy.trackingprotection.introURL                                  ""
/* DEFAULT IS SAME
   this is generally a bad idea: if FF disables something due to a security concern, the
   end user who doesn't keep up to date with changes 
   (IF you do them) is now fucked over) ***/
    browser.offline-apps.notify                                          true
    browser.safebrowsing.passwords.enabled                               false
    html5.offmainthread                                                  true
    security.sri.enable                                                  true
    security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256                         true
    security.ssl3.ecdhe_ecdsa_aes_256_sha                                true
    security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256                   true
    security.ssl3.ecdhe_rsa_aes_128_gcm_sha256                           true
    security.ssl3.ecdhe_rsa_aes_256_sha                                  true
    security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256                     true
/* NOT PRIVACY etc related ***/
[i] browser.download.animateNotifications                                false
    browser.tabs.closeTabByDblclick                                      true
/* covered by dom.enable_performance (& also RFP) ***/
    dom.enable_performance_navigation_timing                             false
/* is only exposed to chrome 
   ( https://trac.torproject.org/projects/tor/ticket/27268#comment:2 ) ***/
    dom.mozTCPSocket.enabled                                             false
/* only used in a single test ***/
    browser.formfill.expire_days                                         0
/* specifically removed because people don't understand it 
   (and we don't want to encourage Tor over FF) ***/
[i] network.dns.blockDotOnion                                            true

[Thorin-Oakenpants]

There was a lot more, but I stopped. It'll be up to you guys to sort it out. And I agree with most of what Moonchild says. I've been over most of these several times before, including rejecting many of them or proposed values when suggested (the prefs as well as some of moonchlld's observations).

But also Moonchild is coming from a perspective that things shouldn't break. The ghacks user.js he probably thinks as well is an "insane configuration". But this is a niche product (and you better TELL people that and WARN them and provide a CHECKLIST etc because IMO some of these prefs and settings are insane). Ours is also a niche, but more gentle, product - with tags built in to flip things, an updater, a full on wiki, recommended and tested extensions, and four plus years of knowledge and testing and code digging etc. You're welcome to drawn on that and keep in contact.

That's it really. Decide your target market, make it clear to users who that is, warn them of all the dangers and breakage - every single one (e.g extensions are not updated), and provide the support for users to make changes and understand wtf just happened

Good luck :)

[elypter]

That's it really. Decide your target market, make it clear to users who that is.

it's important to know what the audience is and what audience the browser is targeted at. and it is important to communicate the priorities. something like whether it is: security>privacy>usability>maintainability or maintainability>privacy>security>usability this makes the project consistent and avoids confusion what later seeds conflicts in larger projects. this all said, it should also be avoided to artificially constrain the project by the prime objective but only if a compromise is unavoidable.

[wolfbeast]

@Thorin-Oakenpants I actually only lifted out the ones that are severely breaking - I didn't comment on any that would be a good choice for this product with some breakage, but as you said yourself it breaks left right and center, as well as a number of things that aren't directly exposed to the user but do break under the hood (e.g. OCSP and blocklisting). I don't think most of what is done is insane, but some things that are done are clearly wrong either out of ignorance or because things haven't really been thought through before changing the settings. Some things should simply not be forced differently because all they do is break stuff with no benefit.

@intika : I understand you want to prevent calling home as much as possible, so from my own experience and the same desire for Pale Moon, here are some things to consider to improve without adding more exposure to mozilla:

• Re-enable HSTS preloading. This list is hard-coded in the build and won't download anything from Mozilla. It does have a validity period as well so even if your builds fall behind there is no danger as the internal preload list will be discarded.
• Re-enable the blocklist to prevent known dangerous and broken combinations in the graphics and plugins sections.
• Either disable Kinto blocklist updates or host them yourself. Disabling the updates will have it fall back to the binary-supplied list which is still better than no list at all.
• Enable OCSP and OCSP stapling. Most web servers with https support stapling, so there won't be the perceived privacy issue of contacting OCSP servers in that case. Where OCSP direct requests are used, it's generally not enough data to profile anything (since it will verify a certificate only once per https session), and to be fair OCSP servers are already too loaded to have tracking added to them (often so much that OCSP server connections prove unreliable from end-user machines in a lot of cases)
• Enable IPv6. Or give the user a clear choice when installing it which protocols to enable. While IPv4 is still much more prevalent for home connections, there is a slow but steady adoption of IPv6, so Librefox should be ready to accept it when it becomes available.
• Enable the password manager, but strongly suggest a sufficiently-long master password to be used. (10 or more characters)
• Enable Windows jumplists. At most this would be a local privacy concern, which is in the ream of user choice (they can use Private Browsing to ensure local privacy if needed), and it's a long-standing OS-integration feature that many people use to varying degrees.

Other things are entirely at your discretion and a balance between functionality and privacy. It'll be up to you to determine where you want Librefox to stand in that case.

[Thorin-Oakenpants]

@wolfbeast

I understand you want to prevent calling home as much as possible

since the post was @ me, I just want to clarify that this is not what I or the ghacks user.js aims for. If it doesn't impact security or privacy then I leave it alone (but may provide options). Some people don't understand what privacy actually means

[Thorin-Oakenpants]

Enable Windows jumplists

you (librefox) need to distinguish between different threat levels. There's shoulder surfers vs persistent local storage (you would need to be compromised locally) vs external etc

I actually only lifted out the ones that are severely breaking

I know. There's way more. One of my initial quick checks revealed a load of deprecated prefs (this is FF60+base) and overall, as intika has said to me elsewhere, it was more of a personal project with his settings .. but enough on that .. I think everyone can agree that the ship needs a little steering :)

[Thorin-Oakenpants]

an example

Enable IPv6

After 3.5 years of NOT disabling ip6 .. I did (in the ghacks user.js). I did this after user feedback. I also including setup tags, etc ... and we weighed up the pros and cons - it doesn't break anything AFAIK, and most people worldwide can;t even use it ... and it something that should be handled on a network level ...

but it is a privacy/tracking risk, and it can compromise VPNs (when not set up correctly), etyc .. but that information is in our single point of reference .. the user.js itself .. knowledge is power

so we flipped it, after *really** thinking about it, after consulting users, and built in fallbacks for end users

^^ this is what the llibrefox project faces. Its not easy throwing 200 or 300 changes to prefs (a lot are enforcing defaults) ... I have about 90 odd (out of 450+ in FF60+) that break something - whether that be UI behavior or web sites or performance ... and the permutations of 90 items is astronomical .. which is why its so important to outlay expectations, provide info and an easy way to get to it and decipher it, etc

I'll stop now .. time for something else

[wolfbeast]

@Thorin-Oakenpants Apologies for not being clear. only the first paragraph was directed at you, the rest was directed at the Librefox project maintainer(s).

[elypter]

so one question that has to be answered is "what priority does local privacy have?" imo it's on a whole other level. once an intruder already has control over the system he can do basically anything. there are endless threat models and every counter measure can theoretically be reversed by an adversary. once an attacker is in the system there is no such thing as real scurity. al you can do is make low hanging fruits less low hanging. protecting against this is a sisyphus task. so i personally think it should have lower priority and it's mostly other softwares job anyway.