this post was submitted on 04 Jul 2023
3367 points (96.1% liked)
You Should Know
33252 readers
5 users here now
YSK - for all the things that can make your life easier!
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must begin with YSK.
All posts must begin with YSK. If you're a Mastodon user, then include YSK after @youshouldknow. This is a community to share tips and tricks that will help you improve your life.
Rule 2- Your post body text must include the reason "Why" YSK:
**In your post's text body, you must include the reason "Why" YSK: It’s helpful for readability, and informs readers about the importance of the content.
**
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Posts and comments which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding non-YSK posts.
Provided it is about the community itself, you may post non-YSK posts using the [META] tag on your post title.
Rule 7- You can't harass or disturb other members.
If you harass or discriminate against any individual member, you will be removed.
If you are a member, sympathizer or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people and you were provably vocal about your hate, then you will be banned on sight.
For further explanation, clarification and feedback about this rule, you may follow this link.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- The majority of bots aren't allowed to participate here.
Unless included in our Whitelist for Bots, your bot will not be allowed to participate in this community. To have your bot whitelisted, please contact the moderators for a short review.
Partnered Communities:
You can view our partnered communities list by following this link. To partner with our community and be included, you are free to message the moderators or comment on a pinned post.
Community Moderation
For inquiry on becoming a moderator of this community, you may comment on the pinned post of the time, or simply shoot a message to the current moderators.
Credits
Our icon(masterpiece) was made by @clen15!
founded 1 year ago
MODERATORS
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.
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.
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
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.