Threads' New Terms & Conditions Affects the Fediverse
wedistribute.org
Threads, Meta's new microblogging platform, is updating its terms to focus on data collection from "Third Party Users".

This shouldn’t come as a huge surprise. Meta is moving forward with their plans for Theads and the Fediverse, and their adjusted terms reflect a new impending reality for Fediverse users.

  • heluecht@pirati.ca
    0·
    1 year ago

    @deadsuperhero Well, they have to collect this data to be able to federate. Question is only, what they are doing with this data. When they don’t block communication with European servers, they have to follow GDPR here. And these rules limit what they are allowed to do - and the fines for breaching the rules hurt even large companies.

    One additional point: Most (all?) AP services perform signed requests when querying the profile and the profile related endpoints. So in the current Friendica version we already added a coding, so that unsigned requests only get some basic data that is needed for the communication, but nothing more. AFAIK some other services are doing so as well.

    This coding can be extended so that signed requests from Threads will always result in only returning the basic profile data.

  • maynarkh@feddit.nl
    0·
    1 year ago

    Stupid question, couldn’t instances just say they don’t allow scraping specifically from Facebook in their ToS and then report them for GDPR violations if they do?

    As in say that have the ToS says that “we’ll give your data to other instances because that’s how the Fediverse works, we won’t give your data to Facebook” and also “Facebook is not allowed to federate, and is not allowed to pull data”.

    Then just say that your data subjects don’t consent to any data pulling by Facebook, and Facebook scraping your system even through ActivityPub is a violation of GDPR.

    • pjhenry1216@kbin.social
      0·
      1 year ago

      This wouldn’t matter. Defederating means you don’t pull their data, not the other way around.

      The article is just describing how ActivityPub works. What would be more important is how they claim to use that data. But that they collect that data is inherent to how the protocol works. They’d have to mention they collect it legally.

      • Hazelnoot [she/her]@beehaw.orgEnglish
        0·
        1 year ago

        Defederation actually does work both ways if the instance enables AUTHORIZED_FETCH. That setting requires 3rd party systems to prove their identity before they can retrieve any data, which allows an instance to block defederated domains. I don’t know if Lemmy or Kbin supports that, but practically all of the microblogging fedi software does (that being Mastodon / GlitchSoc, Pleroma / Akkoma, Misskey / FoundKey / FireFish, and GoToSocial).

        • pjhenry1216@kbin.social
          0·
          1 year ago

          Except that means you defederate from everyone but whitelisted instances in that scenario. If I recall, it doesn’t work as a blacklist, but as a whitelist.

            • pjhenry1216@kbin.social
              0·
              1 year ago

              Looking into it, aren’t both of these only Mastodon and not part of ActivityPub itself? I can’t find details on them outside of Mastodon.

              And what prevents the post from getting published to other instances from different sources?

              • Hazelnoot [she/her]@beehaw.orgEnglish
                1·
                1 year ago

                They are mastodon-specific, but most fedi software has a similar feature. Or at least, all of the mainstream microblogging software does, as well as some of the image / video sharing platforms. I’m unsure about Lemmy and Kbin. Here are the equivalent settings for FireFish: