Non Compliance to GDPR

[lollar1337]

Hello, as I have seen your Project, I wonder if you are aware that this Software (or better the hosters) do break GDPR with using it and automatically scraping Data from Twitter. Many of us do already have Crossposters or dont want Data to be spread on uncontrollable Accounts. This Project should actually be opt-in for people who want to use it. It probably also breaks Twitters TOS but who tf cares about Twitter. Me and probably many other people really dislike Data being saved on random peoples Instances with no way of deleting it. Please consider changing the system so that I dont have to write each and every Instance one of those nasty "Please dont Save my Data GDPR bla bla" mails.

[jurgenhaas]

hi @thisjade , I'm not a maintainer of BirdsiteLive, just a user, probably like you. And I'm a huge fan of GDPR as well. With that said, I'm wondering what should be breaking GDPR compliance here? From my understanding, this is not storing PID in any form and just copies publicly available tweets which is the same like a retweet, where technically the same thing happens, i.e. the tweet will be made visible to a wider audience.

[lollar1337]

Just Testing changes to my Bio does not change the outcome on the Mirror, so it is being saved/cached in some form or another. I dont want my Data to be mirrored on random servers as I do my crossposting on my own and also might sometimes consider deleting Tweets for some reasons. I dont know how long it does cache/save it but its still not okay.

[NicolasConstant]

Hi! Since the GDPR is mostly oriented toward companies, and that "personal or household activities" is a notable exception, I don't really believe BSL is breaking this legislation.

With that said. Since 0.22.0 you can migrate or delete any BSL mirror if you can provide a proof of ownership of the mirrored account, this action is automatically federated to all compatible instance listed on the-federation.info. If an instance isn't migrated yet, you can ask politely the owner to perform this upgrade using this procedure.

Another and easier way to prevent your data being acceded from Twitter API and other means (via scrapped content like Nitter or archivist websites like web.archive.org) is to switch to protected mode, this will also trigger an unfollow / blocking action on all BSL instances.

About the caching effect, there is some caching done on the BSL side, but also on the various ActivityPub server we have out there: for example, Mastodon don't fetch all their known accounts information (and refreshs it) on a regular basis, that's why some modification aren't propagated immediately (but they will at some point).

For the data itself, BSL doesn't store more than the handle and index progression, all the accounts / tweets content are only handled in memory. For the data synchronized, I am currently working on the next update that will automatically delete synchronized content after a certain period (2 weeks by default), and most ActivityPub software have a purge strategy for remote content anyway.

I hope those information will answer most of your concerns / interrogations.