I remember a little while ago a thread with someone from kbin gloating that they could see what everyone was voting, and accusing the people upvoting comments they disagreed with of being bigots in a vaguely threatening way obviously intended to produce a chilling effect, and people found this surprising because that information is not public on most instances.
I basically agree with the people saying open info is just the nature of posting on a public forum and of federation, but there could be improvements, even just in awareness of what is and isn’t private.
This is a great point because in the Lemmy UI, this information isn’t shown, and you can’t even list out all posts you’ve upvoted. As most of us coming from Reddit, we’re used to upvotes being private, and probably assume it’s the same. I understand the technical reasons for having the information public, but it is not clear from a user perspective that it’s public.
What’s extra confusing is that I’ve seen people asking about how to get this information from the API, with the answer being that you can’t (I guess to protect privacy?). It’s only accessible to federated servers, but then those can do what they want with it including publishing it to everyone.
Meh just another crappy rootkit game that doesn’t even fully prevent cheating at the cost of undermining system security. But for worse or worse, the entire playerbase doesn’t care about their data being bought and sold for immense profits they get 0% of.
If Lemmy cared about privacy, contributing source code & opening tickets would not require opening accounts with a for-profit, US-based, closed, prorietary service owned by a publicly-traded megacorporation that has shareholders to appease & a history (as well as current) record of EEE (embrace, extend, extinguish).
I mean it took the code production of from workers for the Commons, packaged it up, & sold it back to the workers—often in violation of the license if not the spirit of free, ethical, or similar software. All AI generations should be CC0 / 0BSD licensed.
Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
I personally enjoy that this sort of information is public, it keeps people honest and gives a tool to use against bad faith actors. People lie. Besides, it’s not like anyone’s forcing you to post personal information online. Some level of responsibility needs to be put on the user.
Lemmy is, like a lot of Fediverse platforms, about as private as it can be. There’s no trackers, you’re not forced to use real names or any other identifying information, no adverts follow you from site to site, no browser fingerprinting and no instance owners are trying to sell your data.
Beyond that, what you choose to say on Lemmy is your responsibility and yours alone.
Very bad, because the usability of such a scheme would be a nightmare. If you have to unzip the files every time you need a password, that’d be a huge burden. Not to mention that unzipping it all would leave the files there, unprotected, until you delete them again (if you remember deleting them in the first place). If you do leave the plaintext files around, and only encrypt & zip for backing up, that’s worse than just using the plaintext files in the backup too, because it gives you a false sense of security. You want to minimize the amount of time passwords are in the clear.
Just use a password manager like Bitwarden. Simpler, more practical, more secure.
When we wrote malware in labs in college one of the first places we looked was unemptied trash. This is almost certainly a pattern that’s going to leave your crap in trash in plaintext and even the dumbest script kiddie will find it the very first time you slip and something gets in your system.
I guess it would work, as long as you’re using an up to date zip implementation with AES-256 encryption. I guess my question would be why bother? Being compressed doesn’t add any real additional benefit, since just using text shouldn’t take up much space.
Is recommend just using an actual password manager for convenience, since you aren’t really gaining any security by only storing your passwords in a file.
Your storing in password protected zip file is better than storing it plain text in a file on your computer but the password encryption of zip is probably not that strong. A friend of mine insists on using a disk encrypted pen drive with an office document having his passwords. I hope he has a backup drive :)
If your goal is to “self-host” a password manager, you might as well use Keepass + SyncThing.
free software
master password protected
has organization and auto-fill features
can sync across multiple devices
Usually the downfall of rolling your own password manager is it’s easier to make mistakes and accidentally lock yourself out. Or if you don’t keep backups/replicas then you could easily lose your passwords.
I suppose there’s nothing wrong with it when the file is at rest, it looks like zip uses AES 128 or 256 which are adequate if you have a very strong password for the encryption. Ideally the encryption would feature a computationally intensive algorithm to slow guessing attempts when attempting to decrypt so you probably don’t want to use a weak password.
Usability won’t be great, you’ll be copy pasting constantly and that presents an opportunity for malware to spy on the paste buffer and steal your passwords but it’s a low to medium severity issue.
If you want to keep everything local I’d recommend KeePass, it’s free, open source, and very strong. It’s kinda the same thing but with the ability to insert passwords directly in some cases and can do more to keep everything organized.
If you want to use this in environments where you can’t install anything on the systems but don’t want anything online, this is probably acceptable though.
One thing to think about is the encryption quality of a zip file, which I ignore.
One danger that I see is that you have the risk of having the passwords on the clear all over the place many times. Not an expert so don’t quote me on this, but password managers are careful avoiding passwords on the clear as much as possible.
I don’t trust any online service for that, I am using keepass/syncthing for myself, with android as the only client decrypting (as I always have my phone with me). one example of advanced security measures is that while using the app I can’t take screenshots, and I hope/expect that it uses images backed by secure memory to show them to me and is careful with things like RAM and temporary files (didn’t check personally though, although being open source I could)
Having to be sure that your zip app handles that seems like a hustle honestly. On top of having random passwords without the biases I would add for each separate site.
But when Youtube shares the key with me/my client the first time, is that also encrypted?
Here’s an explanation of what happens during the initial TLS handshake.
…if ISP automated the process of gathering keys and decrypting web traffic for a certain site with them for all users, would that work for them?
Not sure this is exactly what you’re asking, but there’s the concept of forward secrecy for defending recorded encrypted traffic from future key compromises.
Okey, it’s like this: You and youtube both generate two keys, public and private. Public keys are public, anyone can see them. Doesn’t matter. When you send a message to youtube, you encrypt it with their public key. Now, the trick is, the encryption is asymmetric, which means that the message can only be decoded if you also know the private key, which you never send anyone but keep hidden. Right? This way, as long as your private key is secure, you can not realistically decode the encryption from outside just knowing the public key. Thus setting up a secure connection is just an exchange of public keys.
privacy
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.