Edit: obligatory explanation (thanks mods for squaring me away)…
What you see via the UI isn’t “all that exists”. Unlike Reddit, where everything is a black box, there are a lot more eyeballs who can see “under the hood”. Any instance admin, proper or rogue, gets a ton of information that users won’t normally see. The attached example demonstrates that while users will only see upvote/downvote tallies, admins can see who actually performed those actions.
Edit: To clarify, not just YOUR instance admin gets this info. This is ANY instance admin across the Fediverse.
Wait, is there a granular way to give access to my information? Like say I don’t mind people seeing my comment history but would like to hide what posts and comments I upvote and downvote.
Not really. It’s a side effect of federation. The information is propagated much further than one might initially think. Even if your instance doesn’t display upvotes, it doesn’t stop any other instance in the federation from doing so.
More like a side effect of sending data to third parties. Whether it’s email or messages, you can’t control what happens with that data on the other end unless you control both ends. But then you’re talking to yourself.
Fully expected to be buried since I’m late to the party.
That’s really only half of it, there is no real erasure possible when everyone’s holding a cached copy. Personally… I kind of like it, I don’t hold any value to the words I contribute here as long as they’re for everyone.
But everything and everyone is living in concentric glass houses here.
To be fair, I don’t feel comfortable with that. I believe people are so excited about ditching reddit, that they’re in denial about any possible flaw or inconvenience about lemmy.
I hope future updates bring more privacy to the users.
This is super interesting to me.
I think you’re right in that the user base has the same expectations despite a huge change in the model. But it’s going to be the same on any server, your circle of trust now has to include your instance owner everywhere on the fediverse.
In general there’s no expectation you can delete every email you ever sent either, just your local copies. Most of what you see here is similar with some new attached protocols (votes, markdown etc)
I’m sure we’ll see some evolution, but the entire infrastructure is a call back to when a single service wasn’t directly linked to a single business, and it shouldn’t be treated like one.
In other words I’m not sure the concession isn’t the price you pay to not have reddit/twitter in charge. Because any other architecture that had the convenience of having a single point to delete from is also going to be a single point of failure.
I can see where you came from. We can’t expect to be free from powerful corporations without some sort of tradeoff. However, in this particular case, I prefer my upvotes to be private, so I don’t feel like I have any incentive to hit that button again. I will only read and comment from now on, because my comments and posts are what I expect to be public.
Well, the good thing is that we have the option to refrain from voting. But this information isn’t easily available to new users.
Understandable, and yet if nobody contributes upvotes out of the same concern you end up with nothing standing out in your feed to come comment on. Kind of circular.
On the other hand having an upvote actually attached to your (and I actually mean your handle here) name would likely give it credibility in a weird sense. There’s much less incentive to blindly upvote if it essentially shows what you saw like a slug trail, but if you’re selectively giving oxygen to the best of what you see then that trail is valuable to others who value you. It’s a functional change from competing to push things for their own sake.
Im old! I come from an era where there was no such thing as OPSEC as soon as you interact with another party you cant personally name. For every consumer that was the phone company, or literally right out the door. If you transmit (login credentials, personal info, search queries) the expectation is somewhere, someone or something is logging it. Not even maliciously all the time either, sometimes I got to some of this out of boredom. The corporate Internet just kind of acts like a middle man, because that same problem never went away, just siloed into companies.
Until we get to a future like Transmetropolitan where the expectation is your online presence has some dirty laundry (and hopefully leave out the other stuff), all the bits/bytes, not just upvotes, you transmit should have a limited expectation of privacy. This is just the best/latest reminder because every hack is the same problem, only the company has incentive to keep it quiet so it doesn’t hit their bottom line.
But everything and everyone is living in concentric glass houses here. You might even call that a Glass Onion 😄
It’s not just upvotes and downvotes. Instance admin also knows your email and can store your password in plaintext if they want to. It’s up to user to decide whether to trust the instance admin
They store unencrypted passwords in the year of our lord 2023? Be this real?
They do not
How do you know that an admin has my plain text password? Typically passwords are stored hashed. Do Lemmy instances not do this?
Check this comment for details on Lemmy’s security. https://lemmy.world/comment/765991
TL;DR: Password security is fine. Server doesn’t get your plaintext password.
I didn’t read the source code too deeply, but it appears the server receives the password, and only then it is hashed. How does it work?
- POST -> HTTPS -> SERVER -> hashing
- hashing -> POST -> HTTPS -> SERVER
Is it option 1 or 2 (or other). If option 1 an evil admin can collect the password, or am I misinterpreting something?
If the threat is an evil admin who can change the code it doesn’t matter. The admin could change the server code to store unencrypted passwords, they could change the client code to send unencrypted passwords, they could make clients post plaintext passwords whenever you login. Hashing is damage control incase someone absconds with the password database.
That code may be client-side code, some of it refers to forms etc. Not familiar with the frameworks though , so can’t say for sure.
Edit: no, that makes no sense at all, now I look at it again.
They do, but since lemmy is open source they can store it before hashing it, just use basic security practices and use a password manager
I didn’t look at Lemmy’s source but I’m pretty sure it is hashed. The thing is, password is hashed in the database only to protect users in case database gets hacked. But a bad admin of the server can always just change the code and nobody would know. When it comes to websites, open source doesn’t provide any additional security, since everything that happens on the server is a black box. I’m not an expert on this though. Correct me if I’m wrong
If it’s hashed it’s impossible to see your password (hashing is a one way process, it’s not encrypted). However nothing prevents someone from running a modded instance if they want to harvest passwords.
password (unencrypted)
Seriously??? No hashing, no salting, no nothing??? WTF?
Sorry. I was misleading there. I edited it. The password is hashed and salted. I meant that admin can collect the password in plaintext only if they wanted to
I just thought the same thing. This cannot be true. I refuse to believe it
They could also track the IP address it came from and sell the data if anyone wanted it. I’m sure there are corroborating databases out there for IP address to people lookups
edit: One should also consider that Facebook and Twitter actively sell whatever data they have on you, along with the ability for people to put things in front of your face in all the places you tend to read things. At least on lemmy, you’ve got a volunteer admin that might have scruples.
I think you need to clarify how they can see the password. It’s not stored in plaintext, but when the user logs in, the server administrator can see the password in the HTTP post data if they log it in the lemmy sourcecode. All apps are subject to this and it’s why to have to trust the instance owner.
and also the reason not to reuse passwords
Jesus Christ that’s a major security risk. Luckily I just created a random string for my password but imagine how many accounts those admins can hack by simply entering the same combination everywhere.
deleted by creator
deleted by creator
and password (unencrypted)
This should definitely be mentioned when you’re creating an account. Also, how secure are usually lemmy instances?
This is not the case at all and the parent comment was not clear
What you are saying is somewhat misleading 😒
But did you know over 50k people can see your Facebook password 🤔But seriously, everything you send to a website/server can, of course, also be seen by it.
This has always been the case everywhere. I am a little surprised that this is suddenly something new…If you call someone out for lying at least address the issue.
Looking through the rest of the comments, I think there were already enough explanations.
Making the accusation towards Lemmy that admins can see passwords in clear text is misleading.
It suggests that this is different from other platforms, which it is not. All admins can get your password from/for their respective websites. Either by logging the traffic before the password gets hashed or by modifying the application so that the password gets transferred in plaintext. This applies to Lemmy, Facebook, Google and literally any other service where you enter a password.It suggests…
It doesnt. you interpret it that way. Thats fine, its your opinion. But please be a little more careful with those accusations.
What does this mean for admins regarding GDPR? Is lemmy still not GDPR complient? Are there options in place if users request their data?
An issue has already been raised: https://github.com/LemmyNet/lemmy-ui/issues/1347
Isn’t this an example of how GDPR can be morphed into an exhaustively wild over-reach that exerts control on open systems and end user internet activities despite being hailed as a privacy protector from corporations with teeth that every corp has already worked around?
Does bitcoin’s blockchain ledger violate the GDPR in the same light, where even though a blockchain address is long, it is still identifiable in the same ways a username or even a random email address can by inspecting a data set and running a search for matching entries? If not, couldn’t we just slap the Fediverse data into a blockchain style system for the whole Fediverse that each instance would act as a node on?
/throws gasoline on a fire
There is a person working on a blockchain version of Lemmy for the purpose of making the data content addressable and allowing it to be shared in a peer to peer system so that the main instance server gets less load. It seems like GDPR is getting in the way of progress or that devs need to do a lot more work on trust in the swarm to make it work.
Can’t be too difficult to script and be made automatic. But remember the nature of FED, you’d only be able to request it from the instance you joined
Federation doesn’t evade GDPR.
If federation shares data it must do so without violating GDPR.
If your data is hosted on your instance, and shared to other instances, removal must also be shared.
The nature of sharing must at least be obvious and discoverable so you can request info and deletion of updating.
The request for removal must be shared, the removal itself not so much.
If the server isn’t located in the EU, it can happily ignore it (and maybe risk getting blocked in the EU sure)
I’m pretty sure you could request it from any server. Just because it’s federated doesn’t mean the law doesn’t apply to anyone else with personal data.
And it only matters if you care about operating in the jurisdiction of GDPR. Violate it as much as you want if you’re not located there.
Every piece of information you give someone can be linked to every other piece of information.
Username + Votes is not a hard connection to make.
I’m fine with it too. Don’t think I’d be here if I wasn’t okay with sharing these sort of things. If I wanted privacy for my upvotes or downvotes (why tho?), I’d do it anonymously.
And yeah, I upvoted the beans as well. Ate beans 90% of the time as a student. Still farting from it 20 years later.
”Still farting …”. lol thanks for the laugh, I really needed that.
I’m fine with it.
I mean… you can get information accessing the database. Can anyone access the instance DBs? No. How would you know reddit doesn’t log these in its database somewhere?
On it’s own, it’s not a problem IMO. Why would you want to show all information stored on the frontend? But, if you have to investigate something, it’s not that bad you have stuff in your database that can help it.
Granted, if an admin is a shitface, they can look at these information. And then…? Make fun of downvoting people? Go to other instance and that’s it.
Why would you want to show all information stored on the frontend?
I’m gonna start out by saying that I don’t know how lemmy’s federation code works. So if I host another instance and federate do I only see the upvote count or also who upvoted? Cause if the only person that can see the count is the admin of the instance the user belongs to, then there’s no need to show it in the frontend. If however all you need to do to see upvote count of all lemmy users, is to host your own lemmy instance, then there should be an easy way to also access that information in the front end to indicate to the user that what they up/down vote is in fact not private.
So for me whether up/down voting is private is less of an issue as long as it’s clearly communicated. Again if only the instance admin the user is part of can see the count, then that’s essentially “private” as you are trusting that entity already ^^
If however all you need to do to see upvote count of all lemmy users, is to host your own lemmy instance, then there should be an easy way to also access that information
I haven’t thought of that, and you may be right on this.
However, I don’t fully understand this part:
there should be an easy way to also access that information in the front end to indicate to the user that what they up/down vote is in fact not private.
But it’s true that my brain today doesn’t really want to work. You mean by some kind of API call can reveal these information?
However, I don’t fully understand this part:
there should be an easy way to also access that information in the front end to indicate to the user that what they up/down vote is in fact not private.
But it’s true that my brain today doesn’t really want to work. You mean by some kind of API call can reveal these information?
Basically what I meant is some way for the user to see who up/down voted what. Maybe hovering the up/down vote button shows a field you can click on that say votes or something and that then redirects you to a different page that shows who upvoted and downvoted that specific post/comment. The exact details don’t really matter. My point was basically that if something is accessible but only via hidden means that are not obvious to the end-user, they may wrongly assume that information is private. So by making it easily accessible to end-user, you also clearly indicate that that information is publicly accessible ^^
Again if only the instance admin the user is part of can see the count, then that’s essentially “private” as you are trusting that entity already
Until you get rouge instances or rogue admins on seemingly reliable instances willing to fuck with vote numbers for money. A full open system does help with accountability and the ability to discover corruption/deception by admins. I’d rather have the openness than allow instances to create their own fiefdoms with no externalized accountability in an open federated system like this.
The scummier versions of old reddit power mods are probably salivating at having their own instance farms to sell upvote services to advertisers and nefarious groups to with the concept of hiding vote details from downstream instances, so it is easier to obfuscate their activities and more difficult for external analysis to discover and expose.
Keep it all open and just advocate and educate the end users to create anonymized user accounts with unique emails if they want their personal privacy.
Also. Whilst reddit mods might not get access to that information. It is definitely stored somewhere. On reddit, you can see all your upvoted and downvoted comments and posts. And lets face it. I highly doubt reddit are encrypting that information and hiding decryption keys away from every reddit employee.
I really don’t see the issue here.
I mean, remember some years ago when a Reddit admin edited a comment straight from the database?
Oh wow, I haven’t heard of it. I used Reddit a lot tho, but only for subscribed content. Maybe this slipped through my vision.
Sounds wild, tho 😆
The point here is that anyone can just spin up their own instance, federate with others, and see these information by inspecting their database.
Having a clear understanding of what is public, what’s local to your instance and what’s private is very important in this context.
yeah, you are right.
I think this is just a “side effect” of the decentralized nature. We need some pragmatical changes in our society to not to see these “side effects” as threats in any way.
In a decentralized but federated environment, sharing data is inevitable. In this case it’s important to only share what’s needed when communicating with other instances. For example, if you visit a community through your own instance while being logged in, does the other instance knows about your account being logged in ? It’s not needed, but this information could leak, and this affects your privacy directly. Because what you post is public, but what you visit should be private (or at least, limited to your instance).
Reddit would have to keep that info on downvotes stored, right? If they didn’t, it should be trivial to mass downvote something with very few users
Reddit definitely stores upvoters and downvoters of each comment, otherwise it won’t remember which comments you have downvoted.
Yeah, up/downvotes are somehow has to be tied to the user. If not, a page refresh should “reset” the state and you would be able to vote again.
I often find the feed cluttered with posts which do not interest me that much. Haven’t found a sorting method which works for me.
What does work for me: Hiding read posts (in absence of a feature to hide specific posts without reading them).
This seems to also hide posts I’ve voted on. So I vote on unread posts just to get rid of them, in lack of a better method to control my stream.
I have used voting to hide posts as well. We need a button to mark posts as read so we can avoid upvoting/downvoting when we don’t want to. I’ve read through a lot if Lemmy’s backend code and there is a way to mark posts as read, they just need to add it to the UI.
I think this is to be expected - some instances have downvotes disabled but that doesn’t seem to be the rule of thumb.
There are quite a few questions about data retention, usage, retrieval, compliance and how it is shared which will need to be addressed as the platform grows.
Countdown for this to be monetised by someone.
Of course, the internet (federated or not) is public space.
I’m safe, I upboated the beans
Big if true
For as much as I love Lemmy, its obvious that it is an early software. Mark my words, that’s not the last privacy threat it will experience.
While I think Lemmy is great, I honestly have a somewhat bad feeling about how some of it could play out in the future. As far as privacy and data-slurping, I mean.
What privacy threat? How is your privacy suddenly exposed by your like or dislike on the post as opposed to this comment?
Essentially you’re giving away a lot more info about yourself than you might realise. If someone who takes an unfriendly interest in you wants to, they can probably find out a lot more info about your habits, likes, dislikes, interests, political views, waking hours, etc than just what you’ve publicly commented!
You don’t even have to comment to get profiled by upvotes. I’ve never commented or even subbed to a local community, but in the past I had occasionally upvoted.
If it was just the home instance’s admins having access to it that would be normal. Having it be completely public empowers doxxers of both the malicious and marketing types.
deleted by creator
Not all instances require email to sing up, I’m signed up without one.
Oh whoops, I deleted my comment almost immediately but it seems like you could see it and answer anyway. Yeah makes sense that it’s not an all-instances thing, it was very weird UI-wise because it said “optional” but then the address still came back when I left it empty, saved and refreshed. Seems like they might have forgotten to remove the “optional” label (or remove the requirement, either of the two).
I never get why people are so protective about their Emailaddress. Just have a spammail account for such instances. If it isn’t a important website or service like banking or whatever -> Spammail account. only login for verification and then let the spamming do its thing in there until you need it again. If it gets hacked you lose only unimportant stuff if any.
Agreed, I use email alias services (Simplelogin, duck) whenever I sign up to a new service. Easier to control spam messages just by turning off the alias instead of having to manually add them to spam filters.
Then as a bonus, if a service the alias under in gets hacked. I just need to change passwords plus the virtual credit and debit cards. Ease of mind
It’s just that email addresses are often linked to the owner’s name and I don’t feel too comfortable knowing that it’s in cleartext and easy to access without knowing it beforehand. Your advice is good though.
I’ve been in forums where upvotes were public. It’s not something that I expect to be anonymous by design.
That being said. If something is public, it should be clear that is public (and available to everyone), if it’s not it should be protected.
I think Lemmy should go one way or the other, or upvotes are public to everyone, or they are available only for you instance admins.
This is actually a very important point: Things being hidden from public view but yet not properly anonymous creates a mismatch of privacy expectation vs. reality. Votes may or may not terribly important information, but the user should be sovereign of their own data and to implement that in practice we can’t rely on people reading the code, or a TOS, or something, it has to be there for everyone to see:
If things can be seen on the backend then they should be seen by the public, if they can’t then they shouldn’t (well, also, can’t), as a general principle, not just for votes. One other big point is private messages, afaik they aren’t currently end-to-end encrypted. Gets a bit more iffy because key storage but “only the instance admin of the recipient’s instance can see messages” is low-hanging fruit.
Wouldn’t it be pretty simple to just encrypt them with the user’s password? Or rather, create a key that’s generated from the password, so you don’t have to store the actual password in cookies, and then just decrypt it on the client side?
There will probably be issues with handling password resets, but other than that it doesn’t sound too hard to implement it, unless I’m missing something, since my knowledge of crypto isn’t anywhere near good. Should be one AES call, the way I see it.
EDIT: Oh, I’ve forgotten that you also have to somehow encrypt the messages that you send to someone, so a asymmetrical encryption is required, and that would be way harder. Or, maybe just store a public key, and encrypt the private key with your password, which is loaded into local storage and decrypted with your password once you log in? Still, that’s not as easy as I thought.
On encrypting messages, this is a solved e2e problem if users home instances generate public private key pairs for its users on sign-up ( or users can provide their own )
Then the instance admin holds the private key and can still decrypt.
If you cared that much about privacy in DMs, we should have a “profile page”. Post a PGP public key there. Then you can send PGP encrypted messages to anyone who you have a public key for.
Aye, my proposal was a trade off between privacy and convenience for non technical users ( it’s only as bad as a non federated social media site).
The best balance here would be a client on the user device that manages the keys for you, and an API in lemmy for accepting and sending encrypted messages.
As a side note, I thing PGP is more or less superseded by AGE
You log yourself into your instance using your password, using code that the instance sends you. Thus it is trivial for a sufficiently motivated instance admin to get your password in plain-text and undo any encryption that might be done on the private key stored on that instance.
To be actually secure you have to store the key separately, not use a webapp, etc. Solutions for that exists but aren’t really in the scope of a link aggregator which is why I think “send a message the recipient’s instance admin can see” is fine, ideally replaced by “send an actually secure message” if the recipient has gone through all the set-up hurdles, e.g. linked an address on an actually secure messaging service.
You are right. A solution that would keep messages secure and hidden from an instance admin will have to use a solution that’s not under the control of the said instance admin, and you might as well just use PGP for that manually. But now I’m wondering how does e2e encrypted services such as Protonmail do that, so you can be sure that they don’t have access to your data. I’m assuming there can’t be any guarantee, unless you have your keys separated from the app and do your encryption before you let the app touch it.
Tbh it would be trivial to just salt and hash the usernames (for keying the votes), no need to encrypt or involve the users password. The salting and hashing would be handled by the users home instance ( which presumably the user trusts ) so building a rainbow table would be non trivial for an attacker ( assuming the home instance keeps its salts secret ).
I like this idea. Easily solves the main issue with other instance admins getting access to it, while also being easy to implement.
Another option would be to aggregate votes per instance so programming.dev might only see “42 upvotes from lemmy.world”, but not user details. I don’t think that changes the inter-instance trust equation, at least not notably, and it even works in conjunction with non-aggregated upvotes and displaying everything publicly.
