That information is already public knowledge (aside from your IP address, I assume the Threads policy is actually talking about the instance’s IP address). I can collect all of that info about you right now myself, without even running my own instance, because kbin exposes that data. Every other instance that your posts touch gets that info too.
If the Threads instance was defederated, sure, they wouldn’t see it through that particular view. But they could be quietly running any number of other instances out there already just for the purpose of harvesting that info. Or they could be using a webcrawler or an API to get the info from some other third-party instance.
I think ultimately people need to accept that when they post something publicly - posts, comments, profiles, etc - then by the very nature of it being “public” everyone can see it. You can’t simultaneously “protect” and “publish” this information at the same time. It’s the DRM paradox, but even harder to resolve than the usual. The only way you can “protect” this information is to not publish it in the first place - ie, don’t have a profile on the Fediverse and don’t post comments on it. Because the Fediverse is designed to spread that information around.
Please read the article. The data in question, besides the IP that I don’t see how they can get since it’s coming from your instance and not the user directly, is the bare minimum that’s required for AP to even work, and it is the same data that every federated instance is already storing and propagating. The author of the article says as much.
Facebook is a shit company but the privacy of this data is not one of the issues with it. As has been said before already, all of this is already very public, very easy to scrape and it is impossible to prevent it, if you want to keep your profile picture, username and comments private then dont upload them to a federated social network… or well, any social or network at all.
💀
That information is already public knowledge (aside from your IP address, I assume the Threads policy is actually talking about the instance’s IP address). I can collect all of that info about you right now myself, without even running my own instance, because kbin exposes that data. Every other instance that your posts touch gets that info too.
If the Threads instance was defederated, sure, they wouldn’t see it through that particular view. But they could be quietly running any number of other instances out there already just for the purpose of harvesting that info. Or they could be using a webcrawler or an API to get the info from some other third-party instance.
I think ultimately people need to accept that when they post something publicly - posts, comments, profiles, etc - then by the very nature of it being “public” everyone can see it. You can’t simultaneously “protect” and “publish” this information at the same time. It’s the DRM paradox, but even harder to resolve than the usual. The only way you can “protect” this information is to not publish it in the first place - ie, don’t have a profile on the Fediverse and don’t post comments on it. Because the Fediverse is designed to spread that information around.
Please read the article. The data in question, besides the IP that I don’t see how they can get since it’s coming from your instance and not the user directly, is the bare minimum that’s required for AP to even work, and it is the same data that every federated instance is already storing and propagating. The author of the article says as much.
Facebook is a shit company but the privacy of this data is not one of the issues with it. As has been said before already, all of this is already very public, very easy to scrape and it is impossible to prevent it, if you want to keep your profile picture, username and comments private then dont upload them to a federated social network… or well, any social or network at all.
If somebody else’s federated with them and you comment on a discussion hosted by them, then meta will have your post information
You have to block all thread domains and instances.