Installed Antennapod, and have been successfully downloading and listening to podcasts, recently though it has stopped downloading any episode from newly Subscribed Podcasts, throwing any number of download errors, inparticular 403s, (forbidden, blocked access).
Using gnirehtet and reverse tethering, I can connect to newly subscribed podcasts without any problem:
Not sure why, but can only think weak wireless signal is to blame, despite being able to see the podcast series, and still browse, Antennapod throws errors when trying to download.
weak wireless signal doesnāt play into this. A http 403 comes up due to the remote limiting your IP or user-agent. Browsing podcasts might speak to different remote (the one with the rss feed) than the download links for audio files - and those got issues. Does it happen on all podcasts or only specific ones? able to disclose them?
I assume it is temporarily due to ratelimiting. More exotic reasons could be the dns in reverse-tethering giving you another host than you get on the handheld and this one isnāt misconfigured to serve the paths you request in Antennapod. After all, if you donāt use the mobile data connection, both handheld and PC/Laptop do have the same network exit. Then my rate limit theory makes less sense.
It only happens on certain podcasts, and I donāt use mobile data at all.
I did try to download one of the podcasts via the weblink in Antennapod, and in a browser on a laptop (although the address of the feed could have been different), but they both failed, but did download when reverse tethered.
could also just be some rss / mp3 url that is now outdated. Host sees request on path that is not allowed anymore, returns 403. So I think any report needs to name the Podcast to poke the rss feed.
all too likely. But as podcast urls nowadays go through many redirects (for ā¦ analytics) any one host in that redirect chain hosted at cloudflare or similar can hiccup on Tor.
In Antennapod, if you long-press an episode entry and go to āshareā for āmedia-addressā, a url is shown. Thatās the one to debug. If you contact the sites that just enable cloudflare for other reasons but never gave the Tor usecase a thought, they might disable the Tor check. If they just serve static files thereās little reason to make life hard for Tor users.
there is a real upside for the provider shunning Tor for anything that takes computational effort and presents an attack surface (their tracking). Tor will skew their country numbers and invite probing.
The plain static file hosting is less susceptible to abuse, only to bandwidth. As there are ~2000 Tor Exits, a sane rate and bandwidth limit per IP can protect a static file serving host. This part can be solved.
As analytics are bread and butter for podcasts - to back its media data for advertisers - podcast hosters donāt include the deeplink to static files mostly.
If the tracking layer is very efficient and the operator doesnāt mind probing, than categorizing Tor Exits into an extra group in analytics is a way to allow for them. There is an argument for Tor here, as countries under censorship are in need of multiple info sources.
