Wool2662

I have been using paperless for years now. There was the 1 issue a while back when the original maintainer stopped and they had to fork it. But otherwise it's super stable. They keep to semver religiously and all your documents are neatly organised in original format on disk if you ever need them.

Stop the ridiculous email patching already. It has kept me from contributing and will continue to do so. The infrastructure you have to set up to deal with all the email lists efficiently is just not worth it.

I will gladly invest days in fixing stuff, but if it takes me more than 20 minutes to figure out submitting my code you better pay me for it or it won't happen.

(And no, just because you set up your system 20 years ago and are used to it doesn't mean it is an acceptable system.)

Sure , supporting the evil megacorp suppressing any real alternative products seems like the ethical thing to do.

Your footer 'Get Started' link is broken.

I can only recommend addy.io (formerly annonaddy.com) I have been using it for years for aliases and it just works, is opensource and can even be self hosted if so inclined. For like 10 dollars a year you can use a custom domain, which is absolutely worth it.

The answer is duress and wasted. https://github.com/x13a/Duress The real issue is that you have to remember your duress pin. But there is no way around wiping your device in a situation like this.

And yet the likelihood of you telling someone or typing the contents of this file somewhere you shouldn't is much lower. It's more phishing resistant and is much less likely to be in some leaked password database, that's what GitHub cares about. Targeted attacks on single people don't even move the needle.

Phishing and password stuffing attacks are like 95% of 'hacking' attempts.

And frankly it is very likely that your 40 character password landed in your shell history at least once.

It is preventing password reuse and ensuring key complexity.

The implementation of the credentials manager on the device storing the passkey should also ensure 2factor auth for use of the key.

Further passkeys are highly phishing resistant since they are bound to one specific domain and the passkey manager enforces that it is only transmitted to said domain.

It is basically a phishing , credentials stuffing, brute force resistant password that should ensure 2factor authentication.

It is pretty much the spot between dedicated hardware keys and still usable for the normal guy.

The only thing I dislike is that every provider can lock you in their "passkey ecosystem" since they only sync between them etc.

Recovery is the same as with passwords. Depends on the services policies.

Passkeys and YubiKeys are different things. But generally it is recommemded to have a second YubiKey in a safe place and to register at least two keys on every service. Unfortunatly the implementations for using hardware keys are often pretty bad and require to activate alternate MFA which defeats the purpore of having a hardware token in the first place.

For backing up a yubikey. If you manage it you get a massive bugbounty. The whole purpose of a yubikey is to not be able to read the embedded key. Yubikey guarantees physical posession of the key itself if you can prove knowledge of the key within.

For passkeys: Only the authentication/creation process is specified. How passkeys are stored, shared, backedup etc is totally up to the implementing party. So Google and Apple will synchronize the keys using their existing password infrastructure.

In the end the only difference to passwords is: - It is always randomly generated - You can have multiple passkeys per service - The application managing passkey is required to verify that passkeys are only transmitted to the service they were created for (making them phishing resistant)

Passkeys are basically the point between passwords and hardware tokems like the yubikey. Safer than passwords and less safe than a yubikey but easily usabale by everyone.