add hblock by default to improve privacy, security, and web browseing experince of new and currant users

[fosslover306]

Just what it sounds like, one of the first things i install on all of my systems is to install hblock to block malware, ads, phishing, and tracking urls with no CPU overhead or RAM overhead.

The benefit is obvious, making it easier to install or having it pre-installed protects all users from tracking, malware, phishing, ads, spyware, ransomware, or being part of a DDOS botnet. improving the user experience.

Making Linux Mint more attractive overall, and actually saves electricity and is green.

Do I need to keep listing stuff to get anyone interested? It could literally be a simple bash script run in the terminal when a button is pressed, hell I will make the bash script my self if it gets any interest.

https://github.com/hectorm/hblock
https://akmatori.com/blog/hblock-guide

[AtomicRobotMan0101]

My first thoughts are that using Pihole is easy, but even easier is the free AdGuard Public DNS: https://adguard-dns.io/en/public-dns.html

My second thought goes towards a very good post I saw from @clefebvre here: linuxmint/mint22.1-beta#4 (comment) WRT new user overload.

Perhaps it would be worth considering a "Value Pack" or "28 Days Later" pack :-) where users can be introduced to the Whats Next of ideas that will help them along their journey after a reasonable settling in period.

New users have a mighty steep learning curve, one that Mint does an outstanding job of flattening out, but more tools/options always leave more to learn (and maintain). Blocking things needs to be considered carefully - for in some ways it goes against the ethos of Openness - even if we are blocking Evil.

[Fantu]

Blocking at the system level with the hosts file is not optimal and from what I've seen from experience, it is often necessary to disable this for certain sites (which block access if you use adblock software or if they have problems with "false" positives) so for single PCs and the majority of users it is better to use a browser extension instead (even if unfortunately some recent browsers are complicating things) so you can disable it for specific sites if necessary quickly and easily (doing it in a central block by whitelisting sites in many cases does not work because there are elements on other domains), furthermore it is almost only useful for browsers.
Regarding blocking access to infected websites and addresses, it's technically impossible to have complete or near-complete protection; there are too many, variable, and constantly growing threats. Blocking some of them can help, but the fact that users must be vigilant is still very important. Unfortunately, there's also the annoying fact that recently, "minimal" malware that attacks at the browser level has become increasingly common. It's impossible, or almost impossible, to block them with antivirus, antimalware, or block lists (which, in fact, can't track them all). These malware attempts to trick users, particularly by using system notifications and playing on fear (displaying messages about an infected PC). They also perform limited actions to avoid being blocked by antivirus and antimalware programs (even modern ones), such as asking users to change their search engine, installing extensions, etc. In general, most of them simply acquire data from the browser.
To mitigate this, I was recently thinking that by default notifications should be blocked in the browser (instead of asking the user, that is the more common setting), as the cases in which they are really needed are so rare that they can easily be enabled on the given site in such cases.

In cases with several devices or small companies, solutions like pihole are useful and better (for example I have been using pihole for years at my home on an old rpi2). But this too has its limits.

[Fantu]

Hblock-installer.sh This installer should the trick, just run it from the terminal and the script should: install hblock, add the systemd timer to automatically update the block lists, create the block list, and exit. Anyone can feel free to make improvements, It works fine for me, and no errors popped up so it seems go to go function wise.

It is better to have it as a Debian package and insert it into the official repository. The developer had opened an RFP in 2018, a person had offered himself but then it doesn't seem to have been completed and then there were no more news.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913027
https://salsa.debian.org/moonape1226/hblock

EDIT:
However, I don't like the overriding of /etc/hosts (it's not very good and can cause unexpected problems), and like many others, it's highly unlikely that it will be included by default.
Better methods like systemd-resolved (not active by default in Debian), which also considers additional files in /etc/systemd/resolved.conf.d, should be used.
Or use dnsmasq or unbound (hblock seems to have something set up for these alternatives).
In practice, like RAM issue ends up being a delicate issue that's difficult to deal with, something must be planned and done very well to propose adding it as a default. Neither earlyoom (with the default configuration) nor basic hblock (constantly overriding /etc/hosts) are.

[fosslover306]

Yes I know it modifies the host file, that why is works with as little resource usage as it does, the host file is always being used to filter or guide traffic anyway so if you edit that with a huge block list then it actually blocks things usefully. Unfortunately I suspect that you are right and the hblock will never be included due to various factors, but I have used a systemd resolved based solution and It caused far greater problems such as breaking dns, glitches causing general network problems, and it refusing to start up properly at times which could disable the internet connection completely without a restart, and a solid dependency on systemd which for some people or users is also a deal breaker, at least a systemd timer can be left out and replaced with a cron job instead if one desires and hblock will still work at it's best. And if downloading the block lists goes wrong then it bails out and wont rewrite anything which is probably why in 5 years it has never caused me any problems.

One option would be using hblock how the android version does with a vpn mode but that is not done on the Linux version, maybe that could be change request? or the dnsmasq or unbound thing however that works.

I would also prefer if hblock did not need to edit them main host file, I doubt the hostfile utility supports more then one host file, but it is the only reliable one I have found so far, us Linux users are not exactly drowning in choices here.

[fosslover306]

@AtomicRobotMan0101 yes I know i'm not entitled to anyone's time, hence why I have been going for ideas that should be easy, and use tools that already work and exist as is.

[Fantu]

Regarding systemd-resolved, I've never used it with DNS record lists so I don't know how it works.

I don't see any problems with systemd timers, in fact on debian-devel if I remember correctly I saw that there was a discussion about moving the crons of the main services that aren't already there from cron to systemd-timer (I didn't follow the discussion in detail).

There would therefore be the use of local DNS, such as dnsmasq which I suppose would also be much more efficient with the DNS cache rather than a large list on /etc/hosts but it still remains to manage the nameservers having the local one as the first so even here it might not be seen well as the default.

Unfortunately, I don't have time to help with this, and I'm not even interested enough in hblock.

I'd be more interested in the RAM issue, but even there, there haven't been enough OOM cases to motivate me to invest time in finding and testing an optimal configuration. My main goal is to fix the cause in almost all cases, which is the best thing to do (to avoid having to kill something due to full RAM).
I suppose maybe you could start by finding the optimal earlyoom configuration for the most common use on Debian desktops and derivatives, perhaps starting from the Fedora one (replacing specific critical processes with Debian ones) and then try to propose the improvement to the earlyoom Debian package.

@AtomicRobotMan0101 yes I know i'm not entitled to anyone's time, hence why I have been going for ideas that should be easy, and use tools that already work and exist as is.

There can be a big gap between "working" and being good enough to be used as it is by default for everything.
If they are delicate things, then this thing is even more difficult.
I'm sorry but at the moment I don't think either of the 2 things are ready and good enough to bother the Mint team (already overloaded with too many things) to evaluate it

[fosslover306]

And due to a lack of options for us linux users I will use the best free and opensource tools i can to keep my computer secure and stable, so digging furthur would also not be worth my time. Unfortaly Linux is a victim of it's own sucess right now, no one saw a reason to improve or create free, open source security tools, and people still don't for the most part.

I also suck at editing configs, and all my "modern" 64 machines are in use for specific jobs, the only ones i have free are 32 bit machines from 2006 and eairyer.

Also a safer config argument was crafted for earlyoom, but was buried under pointless paniking.