powermaker450

Remembering (and inevitably) forgetting passwords for all your different accounts is inconvenient, frustrating, and arguably less secure than a randomly generated password unique to each account.

Additionally, it can be tempting to reuse passwords for multiple accounts, which is trouble when a less-than-reputable service that you used that password on is breached, since that password wasn't unique.

If you use an open-source, tried and true password manager (Bitwarden, Vaultwarden, KeePassXC) and keep a passphrase unique to that password manager only, you avoid the problems above which are way more likely to occur than Bitwarden passwords getting breached in plaintext, or a security vulnerability to the KeePass database.

Plus, most password managers offer support for passkeys, which are easier to register/use than passwords. They usually only require a "verify with passkey" button on a given website.

Bottom line, password managers are probably (definitely) more secure than any other reasonable solution that anyone has come up with.

I sentence you to radial blur on everything

maybe once a month if even.

only phone I've ever catastrophically broken by drop is a Galaxy S20; curved screen edges are bad for durability. glad most phone manufacturers have axed it now.

can't be heartbreaking if you don't have a heart

probably not true in most other langauges. although I'm not well versed in the way numbers are represented in code and what makes a number "NaN", something tells me the technical implications of that would be quite bad in a production environment.

the definitive way to check for NaN in JS would probably be something like

// with `num` being an unknown value

// Convert value to a number
const res = Number(num);

/*
 * First check if the number is 0, since 0 is a falsy
 * value in JS, and if it isn't, `NaN` is the only other
 * falsy number value
 */
const isNaN = res !== 0 && !res;

C, because yes.

I missed something didn't I?

other distributions should start having an option for this in the GUI installer, but it might be tricky for the average user

Arch Wiki has a guide on FDE using the TPM and it's transparent in my everyday usage

some minor issues I see are:

• Secure Boot needing to be disabled then re-enabled during install for it to work as intended
• needing to write down a long backup passphrase, but this also happens on Windows and MacOS iirc

pickles

only to the extent of what you can do on stock android. implementing changes that enable customization is unfortunately not on Graphene's radar, it's security focused changes

then don't.

it's not something your being forced to do. it's the lifting of an unnecessary restriction that in turn gives you more power on your device.