You still need to store those secrets. You would probably refer to a keychain but in the end it is still a password/secret manager.
And the current implementation is not really better, services like paypal still do not allow you to use a passkey on the desktop.
That is why you use an open source manager. KeePassXC for example is not owned by a for-profit company.
Losing the container due to corruption disk failure etc can be easily managed with backups.
Losing the password. Yes this is a real valid scenario. I personally have no problem with that i manage fine for years without having to write it out on paper to backup it. A solution would be to actually write that password out somewhere and hide it/ put it into a safe. An attack then needs to attack both, depending if you use disk encryption it is easy to get access to the password safe or not. There are other things to consider, like you could try to hide it in a very long string of characters like 20 pages of random characters, even if you forget it you will be able to find it cause it is very likely that you remember a few characters.
I know a lot of services that log you out regularly. Or need a password when you change settings or whatever.
Well yea people with the "I don't care. I just press the button and it always works" model do exist.
WTF no. Password managers are reasonable secure. That is no i don't care behavior.
And when you are worried about password managers you should not use cookies. Stealing a cookie is much more simple than stealing and encrypting your password safe.
Differences in the thread model. And of course convince. How to you backup your paper regulary? How do you transfer it? What if you need to access a pasdword when you are not home?
Most ppl will just reuse or use very weak passwords when they have to write every password they have to enter.
Best we have and probably will ever have on the current web. Not sure what the problem is with password managers?
I am talking about the fork. It is operated by someone else.
The syncthing fork on f-droid is still an option. An issue has been opened on the github repo. Lets see what will happen with the fork
That was a rhetorical question towards the commenter since the discussion point was not understood.
The thing is, that you only have to share public keys and never private ones. So you can only phish public keys…
How would you sync or transfer a passkey across devices without transferring the private key?
Why do you think SSH-Keys are safe against phishing? I mean it is unlikely, that someone will just send the key per mail or upload it somewhere since most ppl using SSH-Keys are more knowledgeable.
When you now get an easy one click solution to transfer Passkeys from one Cloud provider to another it will get easier to trick a user to do that. Scenario: You get a mail from Microsoft that there is a thread and that you need to transfer your keys to their cloud.
With the ability to transfer passkeys, the attack vector phishing does not sound that far fetched. Tho i have not looked into the transfer process.
We will see i guess.
You generate a second one on the other device.
Not everyone throws their E-Mail at every Text field they see.
They moved to wayland 2 years ago. https://tails.net/news/test_5.8-beta1/#index2h1
The thing is, those poor design decisions have nothing to do with those features, i claim that every feature could be implemented without "holding the compose files hostage".
Btw. dockge does support connecting to another docker dockge instance.
No, that would make no sense and is obviously not what i meant.
But you could separate the arr stack from things like pihole with a vm. For example you could pin one thread to that VM so you will not bottleneck your DNS when you are doing heavy loads on the rest of the system. This is just one example what can be done.
Just because you do not see a benefit, does not mean there is none.
Also, VMs are not "heavy" thanks to virtualization technology built into modern hardware, VMs are quite light on the system. Yes they still have overhead but its not like you are giving up big percentages of your potential performance, depending on the setup.
You talk like there is not in between containers and VMs. You can use both.
What exactly are you referring to? ZIL? ARC? L2ARC? And what docs? Have not found that call out in the official docs.
I use a consumer SSD for caching on ZFS now for over 2 years and do not have any issues with it. I have a 54 TB pool with tons of reads and writes and no issue with it.
smart reports 14% used.