@Rossana38510044 @ydeigin @MonaRahalkar @BahulikarRahul Excellently written article
Nicholson Baker
https://t.co/IZWOjdYeGL
https://t.co/0jeie0jIHO

Worth its long length, although the conclusion is muted, for acceptability I imagine.

Just published 15,000+ words on security keys. 🔐📱💻

With SIM attacks at their highest, now is a great time to take a closer look at your online security.

Removing SMS from your two-factor auth is a start, but authenticator apps have downsides too...

https://t.co/Dk0MPJHL2V

Just look at these headlines from recent SIM swap and port attacks.

It's all too established for attackers to find ways to socially engineer control of your phone number and start gaining control of your accounts.

I first talk about some general security tips.

Unfortunately not all websites let you remove your phone number from accounts.

You may consider migrating your phone carrier to @googlefi , which requires email account access to do anything (and can be locked down with security keys and even Advanced Protection)

Beyond SMS, I talk about issues that TOTP authenticator apps (the code generators) have as a form of two-factor auth. They're so, so much better than relying on SMS for your second factor but they still have issues like utilizing shared secrets and lacking phishing prevention.

Enter security keys!

Utilizing public key cryptography they don't have any shared secret between the client and the server. They prevent phishing by taking the website domain into account.

Even if you get tricked by a clone phishing website, your key won't.

@zkat__ I'm in the position that I actually find npm / yarn the best ecosystem. Whenever I use something else I always end up stubbing my toe into something thats missing / feels wrong.

Ex. Cargo seems to neither have a concept of devDependencies nor peerDependencies.

I also can't understand why it wouldn't have an "add" command to add a new dependency. And I'm no fan of Toml, json is greate (easy to parse and build tooling around), and the better option in my opinion would be json5.

C / C++ seems to just not have language package managers. The linux / bsd crowd seem to have decided that the system package manager also should be the language package manager. Which might have been fine if every Linux distro used the same system package manager.

Instead we end up with a N x M problem. Where we have a bunch of different operating systems and they all support multiple system package managers. So there's no easy way of distributing, referencing and updating C / C++ packages.

It is also my opinion that the compiler / runtime should be a package dependency. I don't like Rust's split between rustup and cargo (they should have been one tool). Similarly it would be better if you added Node as a dependency to package.json, that way we wouldn't need NVM.