532 karma · joined January 3, 2025
The only tool I have installed currently that does %/"($& like this is Deno (required for yt-dlp now). It phones happily home even if you wrap it into a wrapper script that forces the env variable (in no way I'll pollute my default environment with stuff like this):
$ cat /usr/local/bin/deno
#!/bin/sh
exec env DENO_NO_UPDATE_CHECK=1 /usr/local/packages/deno/latest/bin/deno "$@"
I wish bad dreams to whoever puts such crap into their software! Thankfully I have Little Snitch to catch most of those kind of invasions of my privacy.I use AI, but only what is free-of-charge, and if that doesn't cut it, I just do it like in the good old times, by using my own brain.
Something like this:
try:
import requests
except ImportError:
from pip._vendor import requestsDarn…
and I thought that the JSLibCache extension was forcing every site into UTF-8 mode (even those that need to run with a legacy codepage) was a critical issue. A problem I encountered yesterday… took me a while to figure out too.
IMHO where it really needs to be protected from when iCloud suddenly starts grabbing everything w/o the user's permission to upload it to some random Apple servers.
¹) back then you paid Internet by the minute, or in case of the Deutsche Telekom it was a 4 minute tact in the evening, so you had to wait until after 21:00 to get the cheaper prices.
Generally it feels like sometimes you boot into a stable "session" that can go on forever, but often enough you boot in a "session" and something goes wrong quickly and you'll have to reboot after a week or two. But I do experience the same with my Raspberry PI. :)
/edit
And you can combine both approaches: XOR'ing the code first for good measurements. :)
Basically each email gets written as a brainf*ck program and stored in a "data-" attribute. The html only includes a more primitively obfuscated statement "Must enable Javascript to see e-mail." by default which then gets replaced by another brainf*ck interpreter (in JS) with the output of the brainf*ck code. Since we only output ASCII we can reduce the size of the brainf*ck code by always adding 32 to each value it outputs. The Javascript is loaded from what seemingly looks like a 3rd party domain. There we filter basing on heuristics and check if the "referer" matches before sending out the actual interpreter code.
Of course all this would not help if a scraper properly runs things through Javascript too.
Recently I read you soon will be able to run DOOM via CSS, so certainly it should be possible to have a brainf*ck interpreter in CSS? That would be the next step… just to get rid of the Javascript, but then I'm okay with all the downsides of using Javascript just for the e-mail obfuscation.
Anyway… I also regularly (at least once a year) rotate those public contact addresses.
Ideally the PI also should to what the extra DSL Modem does… but I guess that's where the dram must stop. :D
Of course then you got sites like gnu.org too that block you because your slightly outdated user agent.
(The interface on the website is a bit confusing to use, IMHO)
But most SPAMs are HTML, so you'll have a good default last-stage in-client filtering in place in case some SPAM actually makes it through the other setup on the server (greylisting, DNS based filtering lists, policy-based filtering, etc.) :)
I set that up in like 2014? Even back then it was known already that the quick /etc/resolver way was the deprecated way to do things. So I guess they finally killed that feature off?
The proper (more awkward) way is to use scutil directly (which then stores the settings in some binary plist somewhere, I assume).
Maybe try this and see if it still works afterwards?
Luckily I use a proper content blocker (uBlock Origin in hard mode).