I signed up kbin.social but have since decided to go all in on Lemmy. I’ve tried all day to delete my account on kbin but it won’t let me. Once I click the delete confirmation pop up it simply reloads the feed and keeps your account.
Be warned. Currently you have no control over your data there. I think that settles it for me. I won’t be using that service again.
Bit of an overreaction, it’s just that kbin is experiencing a lot of server issues and is insanely slow lately. Your request will probably go through later.
100% this. I’ll bet you’ll find a bunch of failed requests in the inspector. Things are being hugged to death right now.
I’m willing to let them slide. Kbin and Lemmy are getting power slammed right now. Requests from clients aren’t going through properly and everything is being held together with duct tape and prayers.
If you find something weird, see if there is community / magazine that makes sense to report the bug to. I don’t think there is any ill intent happening right now. Shits just cracking under the extreme traffic load.
You don’t control the data either way. Federation and deletion are in conflict. Even if you deleted the account, there is no guarantee it would be deleted from other servers that the data was copied to. (And to be clear, Lemmy has exactly the same issue.)
GDPR and CCPA lawyers when reading this comment.
https://tenor.com/view/waterboy-rubbing-nipples-gif-11600510
I mean, you can’t unsend an email either.
True, but I’ll bet money someone will file some frivolous lawsuits at some point.
The key word there bring frivolous, and like 99% of frivolous lawsuits get tossed out rapidly and/or result in a ton of wasted money by the filer. Slapp only really work when you have a lot of money already to justify it.
Gdpr is not that easy, and the right to be forgotten is certainly more complicated than people are making it out to be. Public facing forum posts have even less protection, for fairly obvious reasons. Now if Lemmy instances were sharing your account information and not deleting that, it gets murkier.
Lemmy should probably keep gdpr and ccpa in mind but public facing forum comments are early qualified under the right to be forgotten unless they meet certain criteria.
Not quite, stackoverflow doesn’t delete your content if you file a GDPR request. Not all data is personal data.
Do these regulations even apply in this case? Lemmy is non-commercial and it’s a distributed. Who would the regulators even go after?
deleted by creator
The other point is, how do you know which instances to go after to delete any content anyways? I think there is a way to see a list of federated servers, but there’s no way to know which has your data.
In theory you could send a takedown request to each of them, but that doesn’t seem helpful
Have you tried to contact the admins? Their servers are under immense load, it could be a problem related to that.
But then we couldn’t bait
There is only one admin and it is also the only kbin developer.
Kbin is not ready, I’m sad to say.
As I understand it, it’s still a prototype, the dev didn’t expect at all people would use it, that’s why it’s not ready yet for mass-adoption, tho I like how it’s made, it has great potential IMO, it just needs time to get out of prototype phase.
I can’t log in. I think it’s just a server problem. You can’t delete your account if the server can’t be reached. Give it time.
I’m sure it’d just a bug and will be fixed soon. Have you tried contacting the mods?
Bud what makes you think you have any control of your data on any instance?
@Jezebelley Kbin.social shows a small banner after requesting deletion. Whilst it is very unnoticeable, I believe it means the instance admin will have to manually remove content for now.
Thank you! I just noticed that. They have to manually delete the account as it just submits a request. Are you kidding me? What an inefficient system.
kbin is fairly new and just has one developer working on it, who’s also the sole admin of an instance that’s constantly under heavy load.
A little wait will not hurt you.
I’m imagine the servers were just overloaded. I’d give it some time and try again.
Not sure about kbin but sign-up/account management on lemmy is kinda broken as well. For example lemmy.ml doesn’t allow new users to sign up and when you try its just infinite loading with no visible response. Or on beehaw.org where you have to sign up and pray that you’re accepted cause otherwise you’re just ghosted. Edit: also there’s no way to migrate to another instance There’s a long way ahead in terms of UX
One thing that definitely worries me with federation in general is the barrier to entry to hosting an instance is low, by design. On one hand this is great, but on the other hand it means just about anyone can spin up an instance and collect usernames, passwords, emails, etc. from anyone who signs up
I know this is obviously no better than an single giant corporation who can do that. But it’s interesting to think about.
I’m definitely not suggesting kbin.social is doing this by the way. Your post just spurred this thought for me
I am once again reminded of the always relevant XKCD comic
I do see and understand the concern, and honestly, I don’t see a way around it. At some point, you have to supply some information to access services, especially if you want any sort of customization to your experience. I guess if you are really concerned about it, don’t use that email/password/username combo anywhere else.
Edit: Apologies, I am still figuring out how formatting works here.
People should be using a password manager in 2023. No password reuse if you automatically generate new 20+ character passwords for each website or service you use.
Agreed. I use 1Password and love it.
I use Bitwarden, thinking about deploying a local copy of Vaultwarden as a backup as well. I’d be in trouble if access to Bitwarden’s servers went down.
Remember folks, use a password manager and get it to create a random strong password for every site you use
I believe the passwords are stored as hashes, not sent directly to the server, at least I certainly hope so.
They’re sent directly to the server and stored as hashes. There’s nothing stopping someone from logging the plaintext password, or removing the hash mechanism, though. Make sure to follow best practices and use a unique password on every website.
Oh jeeze, I guess the hashing system can’t work locally because then we’d know how the hashing works and could crack it, darn.
edit: wait no, that’s stupid, why couldn’t it work this way?
A few years ago the plain text passwords would show up in the logs. That has been changed since then, but a malicious instance admin can easily revert this change and keep a log of plaintext passwords.
The developers explained to me that adding client-side hashing would be problematic because different clients might do the hashing in different ways, and that the desired solution is to add OAuth at some point: https://lemmy.ml/comment/97910
I lack the technical knowledge in client-side hashing to explain why this is the case, but as far as I can tell client-side hashing is not common at all. The standard is to hash the passwords server-side.
I do think that it is important to be aware of what a malicious instance admin can potentially do: they can log your plain-text password, see your e-mail and correlate it to your IP, look at what posts you like/dislike, and read your non-encrypted private messages. But these are not “Lemmy” problem, as these are general issue when it comes to trusting the servers of the sites that you create an account in.
An important benefit of Lemmy is that you can actually set up your own server or use the server of someone who you really trust, and you can use it to interact with the rest of the instances. It is also possible to create an account without providing an e-mail, a phone number is not required, and you can usually access instances via a VPN or Tor. These are not a common luxuries when it comes to other sites.
Using unsafe passwords is dangerous in a lemmy instance, but it is dangerous anywhere.
Hashing could happen client-side, but there’s not much of a difference. If you’re using HTTPS, then all traffic to the server is end-to-end encrypted anyway.
At some point you have to trust the website that you’re connecting to, but obviously don’t re-use passwords, use a password manager, etc etc
Hashing on the client side creates a “pass the hash” vulnerability. What you’ve done in that case is made the hash itself the password, because that’s all the client needs to pass to the server to authenticate. This means that if those hashes are leaked, they can be immediately used to access the server instead of being cracked first.
If passwords are hashed on the client side and sent to the server to authenticate, then all an attacker would need is the password hash and not the original password to authenticate. So it could protect your original password but not your account.
