qqq

joined 3 years ago
[–] qqq@lemmy.world 2 points 1 week ago

It's actually kinda cool to see people focusing on topological quantum computing in industry. It's such a wild concept!

[–] qqq@lemmy.world 5 points 1 week ago
[–] qqq@lemmy.world 15 points 2 weeks ago

Jesus, I thought this comment was a joke before reading the article

[–] qqq@lemmy.world 4 points 1 month ago

I'm with you: the experiences people have with these tools are just dramatically different from mine. They are quite good. By no means even close to perfect, but they're just so much faster than me at pulling up some random information that would be hard to find with an Internet search myself and very good at going from nothing to something that works with code. I don't particularly enjoy using them because I find the whole industry abhorrent, but their usefulness isn't in question to me.

[–] qqq@lemmy.world 6 points 1 month ago (1 children)

I imagine the low level form of each model being free indefinitely, possibly ad supported. It's already probably becoming the most consistent "we're pretty sure this is from a human" training data they have.

[–] qqq@lemmy.world 1 points 1 month ago* (last edited 1 month ago)

"Difficult to recover from" was referencing setting all of your accounts back up. I should have also included "lost" and "broken" to make that more obvious. Many hardware (most? all?) passkeys do not allow for backup and restore.

But I do see an issue with stolen hardware passkeys being used for access too if they're a primary factor. With the mitigations you mentioned hopefully holding up.

[–] qqq@lemmy.world 6 points 1 month ago* (last edited 1 month ago)

They will almost certainly lead to vendor lock in. Why do you think they won't? Apple's password manager is definitely an example of vendor lock in. Many others have a simple to use export feature to CSV or something that others can understand

Edit: it could be that you don't know what the WebAuthn/FIDO2 specification says or we understand it differently? Do you know how the attestation mechanism works? That ties the key to a device or software authenticator (the software authenticator is likely going to tie it to the device somehow, possibly even via a TEE).

[–] qqq@lemmy.world 3 points 1 month ago (3 children)

There is no full stop there... A password that is sufficiently long will never be cracked no matter the hashing algorithm in use. Passwords are easily transferrable and can be communicated to a third party in the event of an emergency. They also provide tunable security, where you can trade off security for convenience if you want.

Some (not all, I know) passkeys are tied to a device. Stolen device means stolen passkey, and it's potentially very difficult to recover from that. Passkeys are also locked to a certain standard, passwords have no such restrictions.

Tbh I don't understand the move for passkeys replacing passwords. They should become the second factor when a user wants additional security. They're perfect for that niche.

[–] qqq@lemmy.world 1 points 1 month ago* (last edited 1 month ago)

I once again cannot disagree more strongly. This is the BS that has been pushed by the mobile phone world. It couldn't be more wrong. Well designed root access to your own device would dramatically increase its security for those who chose to use it.

Here are a few things you simply cannot do on a phone and would be considered terrible in any other context:

  • Control system, root level services running on your device. The idea that you can't do this is a security nightmare. It is the single most basic security tenant I can think of that is grossly violated. You have no control over your device's attack surface
  • Control privileged non-root applications
  • Control network traffic. You have no low level control over your device's firewall without root. You want egress rules? Sorry.
  • Linux namespaces. You literally are banned from accessing the single greatest Linux security feature since UIDs and GIDs. Network namespace isolation? You can't do it. UID remapping? Nah. Mount namespaces? Nope.
  • SELinux policy. Android relies heavily on SELinux and you have no control over it at all.
  • Device handling. There was a great root exploit a long time ago with just a plugged in USB that would have never existed on devices that sanely disabled automounting.

There is so much more. I can't even imagine calling a device I had no root access to "secure" in a personal threat model. Business? Sure. Personal? God no. Not even close.

This is in addition to the privacy benefits.

[–] qqq@lemmy.world 3 points 1 month ago (1 children)
[–] qqq@lemmy.world 2 points 1 month ago (1 children)

Are you using those in the US? When I needed to get a new phone they still weren't available here, but I'm hoping that has changed or changes by the time I need a new one again

[–] qqq@lemmy.world 3 points 1 month ago* (last edited 1 month ago) (2 children)

But “give up a bit on security” doesnt preserve privacy that’s the whole thing.

I gotta disagree with this. GrapheneOS has bought into the crappy smart phone threat model, but the most obvious way to preserve my privacy is to give me complete control over my device and let me tailor it as I see fit. This means root. GrapheneOS doesn't allow root access and that's horrible for privacy.

Sent from my GrapheneOS phone

 

Seems like a ton (over 1k) of people were affected because of an auto updating VS Code extension. Check your bashrc/zshrc and GitHub account if you use nx

view more: next ›