- cross-posted to:
- fediverse@lemmy.ml
- cross-posted to:
- fediverse@lemmy.ml
You must log in or register to comment.
Here is the Threads Supplemental Privacy Policy referenced in the article. Some relevant excerpts are:
We collect information about the Third Party Services and Third Party Users who interact with Threads. If you interact with Threads through a Third Party Service (such as by following Threads users, interacting with Threads content, or by allowing Threads users to follow you or interact with your content), we collect information about your third-party account and profile (such as your username, profile picture, IP address, and the name of the Third Party Service on which you are registered), your content (such as when you allow Threads users to follow, like, reshare, or have mentions in your posts), and your interactions (such as when you follow, like, reshare, or have mentions in Threads posts).
And further down…
If you are a Third Party User, our ability to verify your request may be limited and we may be unable to process your request. Please note, however, that the interoperable protocol allows Third Party Services to automatically send Threads requests for deletion of individual posts when those posts are deleted on the Third Party Service. We make reasonable efforts to honor such requests when we receive them. Contact your Third Party Service to learn more.
First one: “we will take as much as we legally can”
Second one: “we will give as little as we legally can get away with”
Up next: “we will change the law to take even more and mask it as protecting you”
Thats a nothingburger and a half.
This just lists the info that is auto shared through federation, in legalese. The second one explains how federated deletes work, also in legalese. This is the info any instance would handle if you interacted with it.
It’s worth thinking about what you’re putting out there, but you’re right. This isn’t a Threads specific thing.
You’re putting these posts on the internet. You should expect everyone to read them, including Threads and Google and Putin and Kim Jong Un. That’s kind of the idea of public posting. They don’t even need an API to do that.
why should it be ok that Meta collects this information though?
because every other instance does the same.
this comment is content, it’s now stored on the instance I share it with, and all the instances it federates to, along with my username and so forth.
the above is just a legalese explanation of how the fediverse works.
Maybe it‘s a legalese explanation of a problematic aspect of the fediverse though. When a commercial entity comes in that deals in people‘s data, which doesn‘t just store data on its servers, but creates a product out of the data. And it seems like it can do that here without you ever agreeing or even knowing about it.
Maybe it‘s a legalese explanation of a problematic aspect of the fediverse though.
The literal foundation of federation is “a problematic aspect of the fediverse”?
Apart from the list of items being somewhat generic and IP address just being unobtainable as someone else pointed out, it’s just saying that they get data about users by means of the normal functioning of federation. It’s ok in the same way as the server that originally hosts this community we are posting to (lemmy.ml) necessarily getting user data from our “home” servers we are posting from (feddit.de, sopuli.xyz), is ok. This is how we want it to work.
Any Admin worth their salt is going to defederate anyways.
This will be the next shit storm when Lemmy.world doesn’t defederate with Threads and people get surprised. :)
This will be the next shit storm when Lemmy.world doesn’t defederate with Threads and people get surprised. :)
I wonder if those people use a mail provider that does not block GMail.
How much would that help? If even one instance doesn’t defederate, fb is still going to scrape all the data they can through that instance, negating all the other instances that did defederate. (Unless I’m misunderstanding something)
As an example: I’m from .ca and lets say they defederate. I make a comment or post (or upvote/downvote) on another instance like .world that didn’t, am I not a “third party” and opening myself up to them collecting everything they can about me and my account?
They setting themselves up for a major GDPR suit, as well other lawsuits for violating privacy policies of other services that never opted in.
I wonder if there’s a way to fuck with the info that is sent to Facebook in some way from instances, kind of like an obfuscation method. So instead of us defederating, we force them to due to spamming their fetched content with nonsense.
I wouldn’t advise it. We don’t want to set precedent that you can shovel garbage at whatever federated site you disagree with. It would be funny to append all Threads requests with Zuckerberg photoshopped as neckbeard Cesar. It’s less funny when bad actors use unsuspecting users to spread misinformation or bigotry.
Or CSAM. Didn’t that just happen?
If you look at your profile from another instance, your user history there will only contain stuff that that instance is federated with. Users looking at your profile wont see comments and posts you’ve made onto communities that aren’t federated onto the instance they are looking at your profile from.
One comment onto an instance that federates with threads would leak that one comment, not your entire user account’s worth of data.
It’s still bullshit.
Yup; you’ll have to start watching where you post and only post on servers that don’t federate with Meta.
They way it’s worded even upvoting/downvoting something would do it… you’re still interacting with it.
They already can and do scrape literally every website. If you’re putting data on the internet thousands of different companies and governments are collecting it.
Oh I’m sure they do but depending on what they’re collecting it’s a legally grey area, while this is pretty much giving them permission to do it. And I for one have no intentions of making it any easier for them to make money off me.
They would would have to scrape through a custom means like a web crawler. If you’re defederated from them, content your instances won’t be sent to them via other instances.
As far as I understand federation, you should be OK as long as you don’t interact with instances that are federated with meta garbage. Blocking an instance is one click but it’ll hide comments from their users and make you click a button to read them. Its not that big a deal though
I don’t know if interacting with users of those federated instances would be safe or not, but your exposure I assume would be limited to whatever you reply to them.
I imagine Threads is gonna defederate from a lot of instances on their own. Any instance based around NSFW content or which even allows discussion of piracy will be blocked pre-emptively.
A few months back when there was all the talk of facebook joining the fediverse I figured nothing good was going to come of it, and this doesn’t prove me wrong. Fb doesn’t do anything unless they see money in it somewhere.
They are deeply threatened by it and are desperate to capitalize off xitters failing. Mark is probably enraged that he can’t just buy up the company and snuff it out.
I think it’s inevitable that if they aren’t going to use a blocklist (which they are probably too stupid to consider doing) they will likely end up in legal hot water for having the site become a war zone of alt-fedi instances harassing celebrities and random people off threads. I do not see how them federating will go well, at all.
Genuine question here, it looks like most of the info they’re collecting here could also be collected via scraping that info from any publicly available instance (profile pic, username, etc.)
What added info would they get from federation that isn’t already something we are giving away ourselves by participating in a public protocol like ActivityPub?
Federation basically just means your instance will scrape Meta in turn and serve their content to you, whereas being defederated it will not. That means federated or no, without additional precautions by admins of particular instances, Meta will be getting the same info federated or no. Being defederated makes interacting with Meta’s service much less likely though, which makes them scraping your data less likely. This update to the ToS honestly just sort of describes how the fediverse works anyway this isn’t some special feature of Threads, all instances behave this way.
Thanks, this was the impression I got as well. It doesn’t make anything public that wasn’t already public, it just makes it easier and more likely for Meta to ingest the data more directly.
Can’t instances defederate preemptively?
Defederating doesn’t prevent them from seeing what you post. It only prevents you from seeing them
Hmm, I see. What a complex web, can nothing be done to stop thier blatant thievery?
deleted by creator
They can, if they modify activitypub for their own server
They would have to modify it for the other, “third party” server through which the user interacts with theirs, though.
Threads is the Google Plus of 2023.
Surely we need some context with this, as what we post is basically publicly visible. Even if we defederate the posts are anyway visible. Our IP addresses are probably visible to the home instance we connect to (or our VPN IP address etc) but how does our IP address then travel off with the federated post to someone following us on Threads? It’s only what travels out through the ActivityPub federation.
What would help with this post was, instead of just a link, maybe extracting the two or three issues that look problematic, and say why. That gives us something definite to actually debate.
For those who have friends stuck on Threads still, this maybe a good way for them to stay in contact. The Threads user gets their login times, IP address, location, etc tracked by Meta, and the Lemmy user with their Lemmy app, only identifies with their Lemmy instance. Threads should only be seeing the post and time that a Lemmy user posts something that is followed by a Threads user.
deleted by creator
Threads is dying. Give it time
