So, check this little idea that I have - I want to browse the internet without all sorts of unscrupulous actors collecting every little bit of metadata on me and my family they can possibly get their…
So, check this little idea that I have - I want to browse the internet without all sorts of unscrupulous actors collecting every little bit of metadata on me and my family they can possibly get their hands on. Radical, I know. Who would’ve thought that I don’t wont every single website I visit syphon metadata about my computer, my browser, and other signals that can help them build a profile without my consent.
Unfortunately, the experience of browsing the web or using software in 2024 boils down to fielding a barrage of ads, malicious scripts, analytics widgets, chatbot widgets, massive “take over your page” banners asking you to consent to cookies, software that won’t shut up and just phones home with every click, and other things that you probably didn’t want to have to deal with. Not that any of these things didn’t exist in some capacity in 2004 (or even 1994), but the sheer amount of privacy-abusing techniques was much smaller.
The whole concept of “ad tech” became “figure out how to abuse the living hell out of every visitor” which is, let’s say, suboptimal. I even alluded to it in some of my previous writing.
Which brings me to my main point - you should absolutely use a Pi-hole in your home network. It’s not exactly news that this project exists - folks like Jeff Atwood, Troy Hunt, Scott Hanselman, and Scott Helme talked about it for years. I am just adding another datapoint to the camp of “Get this on your network ASAP.”
If you’ve never heard about it, Pi-hole is software that runs on a Raspberry Pi (can technically run even outside a Pi) that acts as the Domain Name Service (DNS) proxy within your own network. That is, if you go to https://example.com, it first hits the Pi-hole before going out and asking authoritative DNS servers for domain information. Its main purpose is blocking requests to domains that you don’t want to hit from your network. Those can be trackers, ad-serving content delivery networks (CDNs), or just any domain that you deem not worthy of receiving data from within your house or place of business.
To give you an idea of how much completely unnecessary network traffic there is, on my own network a whopping 66.6% of all traffic is blocked with no functional impact on anything that I do. This tells you just how much various devices, sites, and apps like to either phone home or load things that I do not want.
The kit #
Setting Pi-hole up doesn’t take a significant investment. This is a list of recommendations, but of course you can fly solo and come up with your own configuration that suits your needs better. On the surface, you will need:
- A Raspberry Pi. If you’re in the US, you can get a CanaKit starter kit for roughly $155, which also includes a microSD card you will need for the setup.
- A monitor, mouse, and keyboard that you can plug into the Raspberry Pi as you set it up.
- Minimal time to follow instructions on Pi-hole setup.
- Some time to make sure that you set up your network to route DNS requests through the Pi-hole.
And that’s about it. Frankly, the biggest investment here is time - getting everything set up and validated. Worry not, though - the Pi-hole team have done a marvelous job in making sure that the installation process is as simple as possible.
Domain lists #
Once you set up the Pi-hole hardware and software, as well as configure your router to point to the Pi-hole device as the target for DNS requests, you will also need to configure which domains to block. You can do that yourself, for example by seeing what flows through your network and then deciding whether you want it or not, or you can use community blocklists. I highly recommend looking at Firebog as the starting point for your explorations as the community has done extensive research and collected a myriad of domains that you likely haven’t heard about.
Oooofff... There are quite a few lists there. Do I need to use every single one when I configure my own Pi-hole instance?
Absolutely not, but it’s a great reference point. What I found is that as you start setting things up you will notice that certain things will break or not work. Conveniently, you can look at the live query log that I mentioned earlier, that will tell you what clients are trying to access specific domains. You can use that view to dynamically block or unblock domains as you see fit.
Not only that, but you can also set up rules to block domains that fit a certain criteria via regular expressions. For example, and because I see a lot of malicious traffic sourced from Russia, China, and Hong Kong, I can easily block those TLDs:
Now, anything that tries to talk to any server with those TLDs will not escape your network if the requests are routed through the Pi-hole. Now, of course, a country TLD is not necessarily the only attack vector for malware, but blocking them is another small step in terms of improving the overall network security posture.
Preventing devices bypassing DNS settings #
As you set things up and configure the network-wide DNS provider to be your Pi-hole, you might also not realize that quite a few devices bypass your DNS settings to make sure that they can still serve you ads or collect analytics. To solve this you need to use a trick that is dependent on what hardware you’re using for your router. In my case, because I am within the UniFi ecosystem and using a UDM Pro, I can run the following set of commands when I SSH into the UDM itself:
iptables -t nat -A PREROUTING ! -s YOUR_PI_HOLE_IP -p tcp --dport 53 -j DNAT --to YOUR_PI_HOLE_IP
iptables -t nat -A PREROUTING ! -s YOUR_PI_HOLE_IP -p udp --dport 53 -j DNAT --to YOUR_PI_HOLE_IP
# Make sure that we skip 192.168.1.1 since that seems to break UniFi Protect
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.1.2-192.168.254.254 -j MASQUERADE
The Bash script above configures the iptables rules to redirect all DNS traffic (port 53) to my Pi-hole and applies Network Address Translation (NAT) rules to allow for network address masquerading, which is a technique that allows to abstract away the internal network from the public internet by replacing the source IP address with the address of the gateway (your router).
Let’s dissect these commands a bit more in-depth:
iptables -t nat -A PREROUTING ! -s YOUR_PI_HOLE_IP -p tcp --dport 53 -j DNAT --to YOUR_PI_HOLE_IP
Here is what each argument does:
| Argument | Description |
|---|---|
-t nat |
Specifies that the rule is for the NAT table. |
-A PREROUTING |
Adds a rule to the PREROUTING chain, which processes inbound packets before routing. |
! -s YOUR_PIHOLE_IP |
Excludes packets that are originating from the Pi-hole itself. |
-p tcp |
Specifies that the rule applies to TCP packets. |
--dport 53 |
Matches packets destined for port 53 (DNS). |
-j DNAT |
Jumps to the destination NAT (DNAT) target, modifying the destination IP address. |
--to YOUR_PIHOLE_IP |
Finally, redirects the packets to the Pi-hole IP address. |
The second line does the exact same thing but for UDP packets:
iptables -t nat -A PREROUTING ! -s YOUR_PI_HOLE_IP -p udp --dport 53 -j DNAT --to YOUR_PI_HOLE_IP
For the third command, we do the following:
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.1.2-192.168.254.254 -j MASQUERADE
The arguments are somewhat similar to what we saw above, but let’s break them down too:
| Argument | Description |
|---|---|
-t nat |
Specifies that the rule is for the NAT table. |
-A POSTROUTING |
Adds a rule to the POSTROUTING chain, which processes inbound packets after routing. |
-m iprange --src-range 192.168.1.2-192.168.254.254 |
Matches packets with source IP addresses in the range 192.168.1.2 to 192.168.254.254. You can adjust the ranges fro your own network. |
-j MASQUERADE |
Jumps to the MASQUERADE target, which replaces the source IP address with the router’s IP address for outgoing packets. |
Long story longer - the script ensures that all DNS requests (both TCP and UDP) from devices on the network are redirected to the Pi-hole, except for requests originating from the Pi-hole itself.
The MASQUERADE rule ensures that the source IP addresses in the specified range are masked with the router’s IP address, ensuring proper routing and response handling. In my special case, the IP range excludes 192.168.1.1 to avoid breaking UniFi Protect.
Combo with ad-blockers #
Despite having Pi-hole sitting between all the devices on my network and the rest of the internet, there is still a lot of value in having a trusted ad-blocker like uBlock Origin. That’s mainly because you will still run into domains that you can’t block (e.g., for YouTube) but still want to use the service ad-free (e.g., again - YouTube). I treat the Pi-hole as another layer in blocking unwanted content and requests in addition to an ad-blocker in the browser, which can also helpfully block specific UI elements, such as passive ads or sponsored content that loads from the primary website domain.
Conclusion #
Once I set up the Pi-hole on my network, there is no going back. I did the same thing for my parents and in-laws, and will continue advocating it to everyone that wants to hear about it. It makes that big of a difference in the online quality of life.
Read the original article
Comments
By h4kunamata 2025-05-062:553 reply I run PiHole for years in my home network, I cannot live without it. With the years, I have made small changes to increase my control over it.
I have a recursive DNS setup, PiHole filters everything, and what is left is processed locally via Unbound which in turn, contacts the 13 root nameservers for DNS resolution. I don't use any third party DNS.
Add PiHole/Unbound caching capabilities, surfing on the internet is bloody fast.
Now, they alone cannot block everything like smartTV with hardcoded DNS, DNS-Over-TLS, DNS-Over-HTTPS, etc.
That is where OPNSense comes to play...
I have firewall rules in place that nobody but PiHoles can request name resolution. My Samsung smarTV trying to use Google DNS?? Blocked, PiHole takes over.
Devices trying to use DoT or DoH??? Blocked, PiHoles take over.
You can create dynamic firewall rule with OPNSense so it will only block 443 and 853 if the host match the list which is updated diary.
To make everything even better, OPNSense firewall makes sure no IoT can access the local network but I can access them like wireless printer, etc, and if I need to access anything while on road like my cat's cam or my Voron 3D printer camera, WireGuard VPN makes sure of that. No VPN equals no network access.
It is just me and my devices, at the time of this writing:
* Domains on List: 500k
* Total queries: 43k
* Queries Blocked: 17k
* Percentage Blocked: 39%
I run GrapheneOS on my Pixel phone and very limited apps, I prefer web version. The apps themselves are fully controller and 99% of the access blocked. That is why I have a fairly low numbers after purging all the logs a few days ago.
By vladvasiliu 2025-05-066:171 reply > Devices trying to use DoT or DoH??? Blocked, PiHoles take over.
How? I can see you only allowing some ports through the firewall, but presumably TCP 443 is one of those. According to Cloudflare [0] DoH uses that. What if Samsung uses that, or figures DoT on port 443 works better? Do you only allow specific destinations for these devices?
I actually use a similar setup, only I removed pihole and just use some lists in my opnsense's unbound (didn't notice much difference).
My "smart" TV is pretty awful, so it's just unplugged (which makes it dumb, so now I love it). I've tried putting it on a dedicated VLAN with no internet access so I could try using the built-in Chromecast functionality – didn't have much luck. I've set up the mDNS repeater and allowed ports through, but that doesn't seem enough.
[0] https://developers.cloudflare.com/1.1.1.1/encryption/dns-ove...
By h4kunamata 2025-05-066:512 reply I followed this blog to get the firewall dynamic firewall in place: https://labzilla.io/blog/force-dns-pihole
Like you said, you cannot just block 443, the dynamic firewall uses a public list, which contains all the public DNS known to man ( the last bit was just to sound a little dramatic haha )
So OPNSense will block anything within that list in both 443 and 853.
So my Samsung QLED TV can no longer use Google:443 for DNS resolution. OPNSense blocks it and redirect it to PiHole, a NAT is also required to avoid devices getting mad.
I didn't pay a kidney for that smartTV back in 2019 to make it dumb, when it is on, PiHole logs goes brrrrrrrr
It is also one of the reason why my whole network was going down, it was making too much request exhausting PiHole 150 concurrent DNS requests, there is a flag to increase that and no more issues.
Google:443: DNS request only, not actual 443 request gets blocked
Cloudflare:443: DNS request only, no actual 443 request gets blocked
etc etc Read that blog I shared to understand it.
If I run a dig google.com @8.8.8.8, PiHole terminal shows the request
If I run 8.8.8.8:443 on the browser, OPNSense firewall log shows access denied, the same msg when my TV turns on or my Home Assistant goes on.
DoT on 853 is simple to block on its own, no much secret there.
I have similar setup with adguard and opnsense, and here is another list for public known DoH servers (including IPv6):
https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/r... https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/r...
By h4kunamata 2025-05-0723:26 That is cool, but the list looks too small, the list https://public-dns.info/nameservers-all.txt is a lot bigger.
Good stuff.
As an alternative, has someone tried running http/s proxy on the firewall and blocking the rest of client HTTPS (except maybe for whitelist devices)?
By illiac786 2025-05-077:29 Not all devices support proxies and it means you are blocking all UDP traffic (RTP, QUIC…) traffic, this will definitely not make your internet experience better…
While there is absolutely value in doing what you are doing and I commend you for fighting the good fight, the fact that 61% of your queries are still going through means your data is still getting out there. Maybe to a lesser degree but that doesn't mean the marketing target isn't being painted it just means you are an impressionistic painting rather than a modernist with straight, accurate lines.
I want to know how to become a Pollack painting.
By h4kunamata 2025-05-067:03 I see your point, I have no need to block 99% of everything. For instance, many apps like bank apps use Google to delivery notification (there is a name for it), so if you start blocking everything, you won't use anything.
To your credit, I can block more stuff but I haven't bothered. I have spent many nights blocking stuff haha
Reddit doesn't work atm home because I blocked static.reddit.com Since the API drama, I never used it again, I used to waste hours of my life everyday there. Couldn't be happier to be honest haha
The only fight I gave up is YouTube, I do see value into YouTube Premium. Spotify is dogshit, YouTube Music allows to me listen to music available nowhere else like DJ remix, old music and the the offline music works which Spotify gave me the finger.
I watch YT only, TV News are complete useless nowadays. There are solid news channels so anyway, I do pay for it over trying to block its ADs from the free version. I mean, try listening music with ADs, nah thanks haha
Is there an updated set of instructions/great guide on how to set up unbound and pihole together along with forced DNS redirection (so all dns requests are forced through unbound/pihole)? I tried to do this a couple of years ago and gave up because of how complicated it was to setup.
By h4kunamata 2025-05-0723:22 I shared the link before, we do need to have firewall rules in place to enforce that. I had done it before but was wrong, I could still bypass PiHole.
I had to recreate all my firewall rules because of a system crash, the order and place I had the rules created earlier were wrong.
I shared the blog link yesterday, that is all you need to follow.
In case you’re like a lot of folks in HN, read the title, and say to yourself “already have one”, read TFA for the iptables config that fixes those apps and devices that bypass local DNS. For example, the New York Times app seems to now use its own hard-coded DNS servers. Without having tried it, it looks like TFA has the fix for that.
EDIT: replies indicate that I, a person who is barely competent at many network tasks, might be off-base on this one. Grain of salt, and all.
An increasing number of them also rely on hard coded DoH servers which is harder to block/redirect. You will need to will Pi-Hole/Adguard Home on router to block them based on some curtailed lists (i.e [1])
In this arms race you are saying a current "move" is a curated list of IPs that correspond to known DoH servers ... and that's fine ..
However, if the adversary decides to just query - and answer - DoH requests on the same hostname that you are trying to talk to ... isn't that a winning move ?
For instance:
If one had an application - or an appliance - that spoke https to endpoint.samsung.com, how would one block DoH requests addressed to the same endpoint.samsung.com ?
By baby_souffle 2025-05-0519:46 That might work but if your Samsung example is behind cloudflare, you're basically going to have to block any and all access to cloudflare's Network.
And if telemetry.example-iot.com belongs to an AWS IP, it could change to another IP in their space at any time so your only recourse would be to limit connectivity to all of AWS which would effectively prevent you from accessing most things on the internet
If you're really serious about DNS interception, you'd setup something where
a) you stop accepting A lookups, because it's 2025 and IPv4 only is dead (let's pretend anyway)
b) for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts). Then only let clients connect to these IPv6 addresses you setup.
If someone smuggles address resolution through, outside of DNS, their clients can't connect.
(this is going to be a big PITA, but that's how these things go)
By ignoramous 2025-05-0523:541 reply > for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts)
We employ exactly this technique for our Android firewall app. It can do IPv4 (by mapping hash(domain) name onto RFC6598 reserved subnet [0]) as number of unique AAAA/A requests on a client seldom exceeds 35k/mo!
Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.
> (this is going to be a big PITA, but that's how these things go)
You don't say.
[0] https://github.com/celzero/firestack/blob/2191381f/intra/dns...
By vladvasiliu 2025-05-066:22 > Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.
This sounds good, and I've wondered how I could implement such a thing.
However, with the clearly hostile approach all IoT appliances are taking, I wonder if they'll actually fall back to a "degraded" (for them) config with the network-provided DNS, or whether they'll just fail and complain the network is broken or something.
By dullcrisp 2025-05-0523:06 I guess at that point they’d have to establish a tunnel and route ads through the same HTTPS connection as legitimate traffic.
I run Zenarmor in addition to Adguard at home, which can detect DoH traffic and intercept it. You have to pay for this enterprise level tool, but if you are worried about DoH, Zenarmor is so far the easiest tool to block it.
In our house the only device that tries to use DoH is my partner's iPhone. It tries a few times, fails, then uses the Adguard DNS, which blocks the trackers.
By illiac786 2025-05-0713:40 Do you have documentation of this? My understanding was always that Zenarmor simply maintains a list of known DoH servers.
By jeroenhd 2025-05-0519:46 And before DoH was a thing, several Chinese apps I've used also used to do plain HTTP for DNS resolution (I only caught them by chanbecause they were doing HTTP). PiHoles only work for apps that stick to the standards and don't mind being caught.
By TacticalCoder 2025-05-061:18 Browsers allows corporations to prevent DoH and force DNS through company-owned DNS servers:
https://support.mozilla.org/en-US/kb/dns-over-https
I use these settings on all my browsers to prevent DoH and make sure traffic goes through my Pi (I run unbound directly on the Pi though, not Pi-Hole: in my experience unbound is a bit harder to set up initially but it's also more powerful than Pi-Hole... For example unbound accepts wildcards in blocklists).
It's not incompatible with also blocking, at the firewall level, all known DoH servers of course.
Nor is it incompatible with forcing your router to also use your Pi as a DNS.
> read TFA for the iptables config that fixes those apps and devices that bypass local DNS. For example,
Don't worry. All the browsers and stuff are bypassing this level of control by moving to DNS-over-HTTPS. You'll either have to deploy a TLS terminating proxy on your network, or give up on this arms race.
Would certificate pinning also remove the first option? I wonder if we are moving to a system where inspecting your own traffic isn't a viable option anymore, am I missing a workaround?
By jcalvinowens 2025-05-0616:56 If you control the machine you can always defeat pinning, given enough effort. But for an IoT device, yeah, we're already there.
To be fair, if you are geeky enough to run a PiHole you will have no trouble finding the config option to turn off DoH in your browser.
Don't turn it off in your browser. If you have control of that setting just install an ad blocker. The point of DNS block lists is to get rid of ads on phones, TVs, and other non configurable things.
By nobody9999 2025-05-0521:03 >Don't turn it off in your browser. If you have control of that setting just install an ad blocker. The point of DNS block lists is to get rid of ads on phones, TVs, and other non configurable things.
Yes, and...It's not just to block ads. It's also to block various trackers and unwanted/surreptitious "telemetry" and "updates" to those devices you can't control/configure.
By hnuser123456 2025-05-0520:111 reply Except, now you don't really control your web browser either, and ad blockers are getting crippled. It is an uphill battle.
By Larrikin 2025-05-060:39 AdBlockers are not crippled on Firefox
By woleium 2025-05-0518:52 And then there is amazon sidewalk, which can only be evaded by unplugging the wifi board on your tv
By freedomben 2025-05-0517:58 True, but I want all the devices on my home network to have DoH disabled too. Most of them I can't change directly.
The arms race will continue. I think the next gen will be a self hosted archive.ph style host that lets all the garbage load and distills it into a PDF or Web 1.0 style file ready for consumption. I would be fine with a browser extension that learns what I watch the most and preloads it for me, and/or an on demand service that shares prerendered sites bundled into torrents that group together common interests.
Edit: as much as I dislike AI, I concede it would be lovely to tell it to replace all ads with pictures of flowers.
By DrillShopper 2025-05-062:00 That's what The Internet Junkbusters Proxy / Privoxy excelled so good at.
Yeah DoH was a solution to a really niche US-only problem where their laws provided the ability for providers to sell their users' DNS logs. In normal countries with privacy protections this isn't a thing anyway.
In this model, DoH is only a bad thing because it evades local DNS control.
I know that apps can always roll their own or even hardcode servers, but I hate the way that DoH was seen as some kind of saviour even though it adds zero benefit to European users and only adds negatives.
Your comment makes no sense. The DoH providers can still log requests and sell them.
DoH protects against intermediaries spying on your requests and potentially forging responses. Exactly the same as HTTPS.
Sending anything in clear text over the internet in 2025 is criminally negligent.
HTTPS is not necessary to encrypt DNS traffic. DNS-over-TLS exists, but it has much less traction compared to DNS-over-HTTPS. I am guessing the reason is that HTTPS traffic all goes through port 443, so "censorship" of DNS becomes tricky, since DNS traffic becomes a bit harder to distinguish from ordinary web traffic.
Encapsulating DNS packets in HTTP payloads still feels a bit strange to me. Reminds me a bit of DOCSIS, which encapsulates ethernet frames in MPEG-2 Transport Stream packets (this is not a joke).
Everything other than 80 and 443 is blocked by default, anything-over-https is just a matter of time. With a properly configured TLS MITM proxy only certificate pinning will prevent snooping, but it’ll also prevent connectivity, so you might call it a win for security/privacy, or a loss for the open internet if it’s you who needs to VPN to a safe network from within such an environment…
A port number does not force a certain protocol. You can run everything you want over port 443.
And yeah I also think it's a really bad idea to run everything over https. But I don't think it'll happen.
By wkat4242 2025-05-063:00 Yes but in the US the ISPs are the intermediary. And the big DoH providers like Cloudflare have better privacy protection.
Here the ISPs are intermediairs too, but we have laws to prevent them from using our data using DPI etc. And even if you use their DNS.
I agree encryption is important but DoT is much better then. DoH mainly took off because of this in the US.
By notarealllama 2025-05-0516:291 reply Jokes on you, I do have a fortinet which does this.... Oh wait, only up to TLS 1.1 or something and it's slow.
I forgot the name of the software but there used to be a few tools to terminate and reencrypt. But yeah dnssec is it's own challenge
By gbuk2013 2025-05-0516:36 You need to get an F5 box instead. :)
By bongodongobob 2025-05-0517:321 reply No, that's not a fix and those iptables settings are on the router. It will only catch DNS requests on port 53. Doesn't catch DoH which you can't do on a router, you need a firewall for that.
By tenacious_tuna 2025-05-063:401 reply Also, doesn't that break the network if the pihole is offline? Before I'd just override DNS on my workstation, but that iptables config would block any "unsanctioned" DNS traffic
By bongodongobob 2025-05-0615:34 It would, yes
By ignoramous 2025-05-0516:021 reply > For example, the New York Times app seems to now use its own hard-coded DNS servers. Without having tried it, it looks like TFA has the fix for that.
Those commands in TFA simply reroute traffic on port 53 to Pi-Hole, which isn't enough to prevent apps from doing their own name resolution. For instance, the Telegram app has built-in DNS-over-HTTPS, which those iptables chains could do nothing about.
By shaky-carrousel 2025-05-0519:41 You can block known DoH servers.
By iugtmkbdfil834 2025-05-0516:46 I was going to say, as a person who used pihole pretty extensively at one point, it may not be enough anymore. I am by no means a network expert, but I do recognize those shortcomings and try to compensate for them. Blanket pihole recommendation may be disservice at this point.
By RachelF 2025-05-064:27 I've seen Windows 11 ignoring DNS settings too, for Microsoft telemetry, ads and updates.
By silverwind 2025-05-0516:112 reply Apps that open arbritrary UDP/TCP ports? Isn't that something the app store policies should reject?
By 01HNNWZ0MV43FF 2025-05-0516:28 They're not opening listening ports on the local system, they're just ignoring the system's DNS and saying "Take me to this IP and this port" and then doing a DNS lookup themselves
By epcoa 2025-05-0516:24 What is an arbitrary TCP port? Ports in isolation from an IP address aren't inherently arbitrary, they're nothing, and the IP:port pair is arbitrary. Once you allow connections to any host on the internet the port doesn't really matter - you can do whatever nefarious shit over port 80. And not allowing apps to connect to external internet servers seems pretty limiting.
My router just ate itself after the breaker on the house got cycled a few times in rapid succession. The router is almost a decade old, so perhaps it's not surprising. As a consequence, my pihole is temporarily out of commission. When we first set it up, we had IOT, android, chromebook, etc. Currently the whole household is on Linux and we just have a couple of smartphones. (plus a steamdeck) My wife has a few ugly apps (facebook, instagram, etc) but outside of that we're in much better shape network-wise.
I used to spend a lot of time on my pihole trying to "fight the internet," but with this recent breakage, it just feels like what I need to be doing is just visiting fewer websites, owning less connected tech, and doing other things such as working outside or reading books. Blocking javascript goes a long way, but just avoiding bad websites, web apps, etc seems to be the only long-term solution.
By mberlove 2025-05-0617:16 I know I'm not alone in maintaining a strong feeling that we've "gone the wrong way" with tech in a lot of ways, as the meme goes, and forgotten (societally) that tech is there for us rather than the other way around. I like your approach - take a light touch using technology; use tech where it helps and ignore it where it doesn't.
(The challenge of course is when you can't or aren't allowed to ignore it, its own challenge).
