Hacker News new | ask | show | jobs
by PantsyWantsy 2622 days ago
form auto-filling is disabled for a reason. It is trivial for third parties to steal form data. It's an inconvenience for some, but does not break anything - websites still work. This is a known bug/issue for at least 8 years - and yesterday I confirmed the leak can still happen in the latest Firefox Nightly - however, this is something I could possibly get addressed (or at least get some action on: I wasn't BS'ing in an earlier comment about what I do and where I have a voice: its a little voice, but it is a voice), maybe, with the Tor Uplift and apply first party isolation to (which also reduces the usefulness of it). IPv6 I addressed in an earlier comment.

I'll address automatic updates in another comment

I agree with you that 99% of these sorts of projects have questionable choices. But every single one of ours has solid reasons (and research, and validating that research, even creating our own Proof of Concepts, lots of testing, and more), and the user.js has only ever been billed as a TEMPLATE - never as a cure-all, grab it, set it & forget it. It was also started as a means to be comprehensive, and documented, and I've tried to make comments as easy for the layman to follow as possible.

I have also never recommended applying this without reading it and making changes etc. I even tell people to test it in a new profile first. And I have gone out of my way to make sure nothing is ever lost (the exception being that cookies and history are cleared: I can't bring those back) - i.e any pref can be changed back, and nothing is lost. I also encourage users to ask in the github issues. And I provide as much easy to follow comments as I can. This is not some irresponsible collection of prefs just thrown together with no thinking.

I have re-arranged the wiki page on implementation. The readme of github DOES tell everyone to read the implementation,. It's the second hyperlink. That readme is also kept very short so no-one misses anything. The readme in the user.js DOES point at the implementation and tell users to read it. And because I know human nature says a lot of people won't, I even ADDED the SAME info in super shorted form to the actual user.js - at the top, right after version, author etc. What more can I do?.

I have now added a link and message (almost at the very top) to the Overview page as even more fool-proofing. So thanks for that. Always happy to improve things.

I'm not liking the registry cleaner level of irresponsible comparison, at all. The user.js changes around 300 prefs from their default (that's not all the prefs listed, thats the ones that are actively changed if you applied it). Of these, at a rough estimate, there are only about 30 or so that people complain about. And they can change them. The vast bulk of them don't affect/break anything at all (or extremely rarely) - i.e site breakage, etc - they ONLY increase the prime objectives of increasing privacy, security, etc.

I have toyed with the idea of making the template much more relaxed & less breakage (i.e those 30 odd prefs that people complain about made inactive), and then tagging items as "harden", and/or supplying a hardened section, and or providing a hardened that users can tack on as their overrides. But that's doesn't quite fit with the original purpose of what I set out to do.

It has always been my aim, and intention, to make things as easy as possible. Hence setup tags etc. And part of that, a long time coming, has been to provide a relaxed.js or sticky issue at github, for people to apply to reduce most of the breakage. I've even taken a scientific approach and done polls on breakage, collated data from users about it, and so on. I have a basic list and should get that out, as soon as I kick myself in the backside to finish it. Once again, the user.js is a TEMPLATE, but more than happy to make things easier for end-users.