Cadende [they/them]

jeez I wasn’t reading very carefully. I read that as “Only the RSS reader”

Only the RSS server will know the specific URL you’re visiting though.

and the site itself!

I wouldn’t go so far as to say it’s literally the same as browsing a website. Your feed reader isn’t a full web browser and as far as I know most don’t execute javascript. They will still generally fetch images, and fetching the feed itself is just an http/s request, but it may or may not always be a request to the same web server as the website of whatever publication you’re subscribing to. So IMO you’re already starting from a somewhat better position in terms of data leakage, since the feed isn’t loading analytics software or advertiser javascript or any of that stuff which feeds the vast majority of bulk data collection in the private sector.

One downside might be that if you have your feed reader set up to automatically poll for updates regularly, you may forget and it may do that polling on networks you didn’t intend to (when your VPN is off or you’re on school/work internet).

If you have a specific threat model, or a couple, that you want to guard against, it’s much easier to come up with solutions that thwart those exact threats, than just trying to be “as private as possible” all the time (very difficult, all technical solutions have tradeoffs). You could make the requests through tor. You could use a proxy to encrypt your traffic up to a server you control before going out to the various sites. You could use a VPN service.

Those all have different tradeoffs: tor exit nodes might be widely blocked from fetching content from a lot of sites, and it might be hard to connect to tor period on some locked-down networks, the server host and their ISP can still see some details about your traffic if you run your own proxy or VPN server, but it is another step removed from your local network/isp and the site both tracking you directly by IP, user-agent, etc. VPN services might be tracking you themselves, might be working with governments, but they, similarly to proxies, interrupt the tracking done by your local network or the websites in question, with the added bonus of blending in with the traffic of other users (but they are often blocked by local network admins, and occasionally by websites as well)

As an aside, RSS-based podcasts are a place where this tends to get interesting since the field is dominated by big distribution services. Assuming HTTPS is in use, most podcasts you might subscribe to can’t easily be tracked by your ISP or network admins, since they’ll blend in with all the other traffic going to say, acast, libsyn, iheart, whatever, and HTTPS blocks them from seeing the full URL or data in transit, only the domain name from SNI. They can only tell that you downloaded data from a podcast network, not what podcast it was

also sushi! (unless you count coffee and an allergy pill)

it was really good. best reasonably priced sushi I’ve had in years, place seems to be run by a single old japanese lady, just cranking out sushi to-go all day.

note that I said provider not developer. Obviously people don’t have much choice and their location isn’t a reason to cast judgment on them, but what jurisdiction a service provider operates out of is pretty impactful. I’m certainly not envious of the current political situation in the Kid Starver regime

I was going to say it’s pretty ironic that a privacy focused provider would be based in the UK what with their laws lately, but apparently email providers are exempted from the bill I was thinking of (no general carveout though, they name emails, SMS and MMS specifically. If you want to create a new protocol that does the same thing as email, or as SMS, its regulated as social media for some reason…)

Either way self hosting takes care of that problem. Neat!

Bit of trivia but I think I know why the 4 digit pin thing existed! It’s an out-of-the-box feature on freeRADIUS, I ran across it in a pfsense environment in the past. I thought it was neat (esp. in the absence of passwords, this was primary auth with public keys and then 2fa on top) but ultimately too convoluted for most users

so that’s 3/4 that you’re saying to avoid because you personally have deemed their moderation policies objectively inferior (and judging by 1 and 2 you probably think the same about hexbear?)

sounds like they’re just instances you politically disagree with, one of which does happen to also be massive. I’m not saying redditors should come to those 4 instances, they mostly shouldn’t (grad and hexbear don’t want most of them, .ml has been trying to not be “the default instance” since forever, and world is a shithole and already massive/centralizing), but your choice of list was transparently more political than it was about centralization, why not just be honest about that?

Or are you going to pull the “moderation policies are (or should be) objective and apolitical” canard?

“I hate centralization, we should do less centralization”

posts a list of instances to avoid, 3/4 of which are actually much smaller in active users than his own, presumably just all instances he politically disagrees with