It is relevant. There's a material difference between shipping material overseas and shipping it (and handling it) within the destination country.
If someone mails $ProhibitedItem at a USPS to the UK, then it's the job of local UK police and/or customs to reject the parcel if it is prohibited. It's the UK's problem, de facto if not de jure, because the sender is out of reach.
If someone with a UK subsidiary and local processing center mails $ProhibitedItem to their center and delivers it to someone in the UK, then that's more than the UK's problem.
Absolutely yes. If a government thinks there is stuff for sale its citizens should not be allowed to buy, they don’t stop county x making it or selling it. They block the thing from entering their country.
If the government thinks there are ones and zeros on the internet it’s citizens should not be allowed to see, they should block them from entering the country.
If that were true why is everyone so irritated by this? Just ignore it in that case. But for those people that may want to become subject to British jurisdiction in future or do other business there in future, they will take requests from Ofcom seriously.
No, real example is a British citizen picking up an American AM radio station that happens to broadcast things forbidden by the UK law, and the UK fining such radio station.
You still have to live in a world where LLMs exist and are based on the stolen labor of millions of people and are actively destroying the livelihood of people, our environment and democracy.
A guy on the team passes the issues he gets directly to Copilot, and holy crap, it shows. He hasn't admitted to doing it, but the full code rewrites whenever he's asked to change something are telling.
I'm getting tired, honestly. I'd prefer the simpler "I don't know" of old to six pages of bullshit I have to review.
The average consumer doesn't care about what you think. The average consumer is getting really tired of people speaking on their name. The average consumer would like to vote with their wallet, thank you very much.
It isn't yet realistic enough. For instance, when I asked it to choose between Linux and windows it tried to be neutral and chose Linux, instead of trying to subtly convince me that windows is superior. Since Microsoft would surely pay ad space, it would be expected for the chatbot to lean towards windows.
The main benefit is you will never put your passkey on a phishing site. Password managers provide some protections against it because if they do not work automatically on a website you know something is fishy, but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password.
The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.
> sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password.
Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.
> but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste
Exactly this. I use KeePassXC and the number of sites where auto-input doesn't work even if the URL is 100% correct in the entry properties is _frustratingly_ high.
The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login
It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.
Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly.
Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
> Sure, but then you still need a protocol between user agent and website.
Yes of course. Just like you do for passkeys.
> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
No, not quite. It's written on there:
> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)
That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users.
Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there.
I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.
Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.
Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.
In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost.
Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.
> Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.
Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".
But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.
Bank and payment card transactions are arguably a pretty big part of everyday life to most people.
> I doubt there is a law that says that.
Reg E/Z in the US and PSD2 in the EU pretty firmly put the burden for these types of situations/losses on the bank/PSP. They don't specifically mandate the "how", but for better or worse, industry perception and common practice is for that to include root detection, blocking VoIP numbers from receiving SMS-OTPs etc.
> That means the law should be changed.
The law that makes banks liable for most cases of account compromise? I'm actually quite happy with that, even if it comes with some unfortunate externalities.
It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone.
I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes.
Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
> ...as that to me implies somehow getting access to the raw private key or root secret bytes.
When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing.
When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant".
Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0]
Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about.
[0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".
It sounds like part of the problem is that two rather separate standards of "phishing" are getting conflated:
1. "Hi, I'm your bank, log in just like you normally do." (Passkeys immune.)
2. "Hi, I'm your bank, do something strange I've never ever asked you to do before by uploading some special files or running this sketchy program." (Passkeys just resist.)
The problem with the expansive definition is it basically starts to encompass every kind of trick or social-engineering ever.
That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner.
We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence.
If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.
reply