130
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Jul 2023
130 points (100.0% liked)
Selfhosted
40173 readers
558 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Under GDPR, any piece of potentially identifying information is considered personal data. I had GDPR training at work. Under the GDPR it's not even possible to count unique visitors to your website because you'd have to keep track of some identifier even if just IP address and User-Agent, even if it's entirely client side. You still have to get consent for this.
Even just community subscriptions is plenty of data to make a rather comprehensive profile of the user's interests, and if you throw in votes it quickly becomes scary.
This is everything you upvoted:
Obviously IP addresses are personal data, but those are not shared to other instances.
You could probably argue that the federated ID is personal data, but I am not sure as it might also count as only an internal identifier required for operation. IANAL but I don't think votes can be considered personal data under the GDPR.
Question boils down to where is the boundary. Does an alias of your choosing, which uniquely identifies you across the fediverse personally identifiable? I think we all would say yes. Does then actions linked to that alias constitutes as personally identifiable? Well, in absence of the correlation of the ID, it is still technically possible to map out who this user is and what their interests and preferences are, so maybe yes? That’s a hard grey area to determine IMO.
Indeed, but I think email addresses for email providers (but not everyone else) are handled differently by the GDPR as they are necessary for providing the email service. I think this is similar to how functional cookies do not require consent under the GDPR if they are only used to keep you logged into the site etc.
I think as @danieljackson@lemmy.world commented slightly higher up, this might be considered pseudonymised data? The link he provided suggested it was considered personally indentifying information - I'm (as per my question) definitely no expert in this though
The link I provided says that pseudonymous data can be used to hide personalized data.
The owner of lemmy.one can use tk338@lemmy.one to map it to an IP and/or email address. This becomes now personally identifiable data. But other instance owners can't map it to any personalized data, so it is basically "anonymized data" for them.
You just have to provide a way to either
Disclaimer, IANAL, YMMV, yaddy, yadda,...
Understood, missed that subtelty. The fact emails aren't actually shared makes it very GDPR "friendly"
How does that work? As the admin of the
lemmy.max-p.meyou have access to your server's db which contains a replica of the db of all servers you receive federation from, including detailed per-user upvotes/downvotes? Correct?Yeah pretty much, although not entirely. I only get pushed copies of the intersection between the communities my instance tracks and the victim's, and only from the time my server started federating those. I guess I could make a bot account that subscribes to every possible Lemmy communities so that I do get a copy. I could also patch up the backend to ignore any deletion requests and stash up everyone's deleted posts and even go fetch linked images and store them forever.
It's not really a secret though. Some users in another thread were shocked to learn that kbin does publicly display that information. For example, picking the first post on kbin.social: https://kbin.social/m/tech/t/124303/Bluesky-temporarily-halts-sign-ups-because-so-many-people-are-joining/votes/up
Essentially, it's extremely public, so one's gotta be careful about every single interaction on here.
I only did this for example's sake, I respect people's privacy and have no intention of running a hostile instance. But point being, anyone can rather easily.
Interesting - I had the feeling this was how the federation mechanism worked, I don't see how it could work without sacrificing privacy.
So a "bad" actor could just spin up their own instance, federate with a huge amount of other instances (I don't think other instances have a say in this, except if they explicitly, manually blacklist the "bad" instance?), and start profiling users based on their votes.
The potential for global surveillance is enormous. But I can also see it being useful to detect and fight bot farms, spam, brigading and other bad stuff that has plagued Reddit for quite some time.
Lemmy could do a better job at informing users that basically everything you do here is public (including votes). On Kbin the
/votes/uppage makes it clear at least (I like that even comments have a/votes/uppage).