Other people in that thread have pointed out that it isn’t showing posts being delivered to Threads despite the block. That should be testable with other instances, but not Threads since it’s not receiving any content from Mastodon at the moment. The concerning thing there is the user still being able to view content from people they’ve blocked, but that seems to be a bug if it’s reproducible.

In the EU companies can’t scrape personally identifiable information without consent, even if it’s already publicly available. IANAL, and there’s probably ways they can sneak around the GDPR, but at least it’s not a free for all. It’s unclear though how it works for federation. It’s definitely not the same legally though.

The reason for not directly federating content to Threads isn’t so nobody there can ever see my amazing posts, it’s so Meta can’t easily profile me. Scraping public posts on a different platform would probably be illegal, at least in the EU, and reposts don’t give them a lot of data about me. Federating content, however, would give them most of the same data that Mastodon has on me without even having to ask.

This post from Eugen Rochko mentions that blocking Threads at the user level “stops your posts from being delivered to or fetched by Threads”. Basically, the user-level instance block is bidirectional.

Limited federation mode is a different feature, at the admin level. It doesn’t really affect the delivery of posts in either direction, it just hides the blocked instance’s content from the global feed. Defederation on the other hand is indeed bidirectional, but again it’s on the admin level rather than users’.

Mastodon instance blocks are already bidirectional AFAIK: if you block an instance your content does not get federated with them. I was actually surprised that this does not seem to be the case for Lemmy. I don’t think this break any core abstraction of AP…

Oh yeah, you’re right on that. If I’m looking for privacy from the subscription manager signing up with a service like this is a terrible choice, because it is fully a financial institution.

I wish they were all on the same day of the month…

Dates aren’t a big concern though. What I was hoping for is something that would update automatically to some extent if (say) some amounts change, or a payment is missed. But I guess indeed that’s basically impossible without access to my payment data.

Given that I have to update it manually though, I would at least like it to be synced remotely. So that I can, say, check it from my laptop on a webpage or desktop app without redoing all the manual data input.

I thought I heard they were rolling out some material you theming in beta a while ago. Did they revert it?

For my use case yes, that would defeat the purpose, but for what it’s trying to do it kinda makes sense… At least, they have to do it to comply with payment regulations. And you’re still only exposing your identity to one service with a decent reputation, rather than plenty of possibly shadier ones. It seems like a fair tradeoff if what you’re looking for is privacy from services you want to pay for.

I’m not American, it seems to be available in the US only…

I guess you’re right, yeah. I was hoping someone had figured out a different solution, perhaps integrating directly with the individual subscription providers. But I guess that’s way too broad of a scope, integrating with countless individual services.

At least a cross-platform, cloud backed “spreadsheet” would be nice to have though.

[…] I set up a cloud service where my VPN service would be located on Amazon’s web services, a reputable and widely trusted cloud provider. […] After about an hour, I set up a VPN that worked flawlessly. The best part? Not only is it free to use […]

Sorry, what? Last time I checked AWS VPSs were very much NOT free to use, and I’m pretty sure the lowest tier is still more expensive than your average VPN.

Also, this article seems to be arguing against its own points: “you probably don’t need a VPN, but I have one anyway”…

Backed by who?

Andreessen Horowitz (a16z), a Silicon Valley venture capital firm with a recent history of questionable investments…

God I hope this is a bit

Interesting demo! Does this use the user agent string for identifying clients?

Oh I mean, sure, but I don’t think IP logging is the main privacy concern with spy pixels.

I’m assuming this trick uses the user agent string and other request metadata to identify clients. Even if it didn’t recognize Jerboa as a client, it did guess that I was on mobile. That’s not possible just by tracking IPs, unless they’re cross-referencing it with other datasets. Also, I was on VPN anyway, so the IP would have been useless.

It should be possible for clients to obfuscate/fake the metadata of image requests to make tracking with spy pixels less effective.

Can countermeasures be implemented in the clients to mitigate privacy risks, while not having to proxy images?

Got it, thank you!

I’m seeing the same bug, and I don’t see a github issue for it. Wanna create one?

Oh cool, didn’t know about the plugins.