Cadende

joined 3 years ago
[–] Cadende@hexbear.net 3 points 5 hours ago

oh interesting, looks like they do work now! I don't use kemono that regularly but recall being unable to access some embedded media last time I tried. Currently both audio and video seem to work though.

Also I'm shocked that vimeo trick works lol. fantastic stuff

[–] Cadende@hexbear.net 1 points 5 hours ago* (last edited 5 hours ago)

but then I have to click on that domain name which I think might give me a horrible disease(jk thanks for the heads up. generally people I'm interested in on patreon I just cough up the change but its good to have options. ) And as always the best way to get good advice is to put out some mediocre advice and let people who know more correct the record lol

[–] Cadende@hexbear.net 11 points 13 hours ago* (last edited 13 hours ago) (4 children)

there's also https://kemono.su/ (fair warning, lots of vaguely horni anime art) which archives tons of patreons/other similar services. doesn't seem to work with patreon-hosted videos or podcasts if I recall correctly, but definitely works with other posts/images

[–] Cadende@hexbear.net 8 points 1 day ago* (last edited 1 day ago)

It may be the basic ubuntu telemetry (relatively non-invasive, but still a concern for the privacy-minded) sent by this tool unless you opted out at install:

https://github.com/ubuntu/ubuntu-report

from that page:

So it would not surprise me if it was scheduled to send, failed, and then re-triggered upon activation of a new network connection (the VPN).

Edit: Or even more likely, it is a connection from networkmanager to connectivity-check.ubuntu.com

https://ubuntu.com/core/docs/networkmanager/snap-configuration/connectivity-check

[–] Cadende@hexbear.net 2 points 1 week ago

jeez I wasn't reading very carefully. I read that as "Only the RSS reader"

[–] Cadende@hexbear.net 1 points 1 week ago (2 children)

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

and the site itself!

[–] Cadende@hexbear.net 2 points 1 week ago* (last edited 1 week ago)

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

[–] Cadende@hexbear.net 2 points 1 week ago (1 children)

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.

[–] Cadende@hexbear.net 8 points 1 week ago* (last edited 1 week ago)

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