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.
The sentence you quoted says that folks who are required to comply with the law are not also required to ensure that the person currently using the device or application is the same one who entered their age or birth date into the OS's "how old are you?" database. [0]
It is true that this law is as bad as the recent Oklahoma one for small, non-corporate Linux distros... but that sentence you quoted has nothing to do with that problem.
[0] If we were speaking in person, I'd love to have you walk me through that sentence and explain to me, piece by piece, how you came to the conclusion that you did. Doing it remotely like this would be too tedious.
Yeah, seriously. It's as if people want to playact as illiterate programmers.
The "Redirections" section of the manual [0] is just seven US Letter pages. This guy's cheat sheet [1] that took me ten seconds to find is a single printed page.
> The "Redirections" section of the manual [0] is just seven US Letter pages.
"Just" seven US Letter pages? You're talking about redirections alone, right? How many such features exist in Bash? I find Python, Perl and even Lisps easier to understand. Some of those languages wouldn't have been even conceived if shell languages were good enough.
There is another shell language called 'execline' (to be precise, it's a replacement for a shell). The redirections in its commands are done using a program named 'fdmove' [1]. It doesn't leave any confusion as to what it's actually doing. fdmove doesn't mention the fact that it resorts to FD inheritance to achieve this. However, the entire 'shell' is based on chain loading of programs (fork, exec, FD inheritance, environment inheritance, etc). So fdmove's behavior doesn't really create any confusion to begin with. Despite execline needing some clever thinking from the coder, I find it easier to understand what it's actually doing, compared to bash. This is where bash and other POSIX shell languages went wrong with abstractions. They got carried away with them.
Yes. It's the syntax alongside prose explaining the behavior in detail. Go give it a read.
If you want documentation that's done up in the "modern" style, then you'll prefer that one-page cheat sheet that that guy made. I find that "modern" documentation tends to leave it up to each reader to discover the non-obvious parts of the behavior for themselves.
> I find Python ... easier to understand.
Have you read the [0] docs for Python's 'subprocess' library? The [1] docs for Python's 'multiprocess' library? Or many of the other libraries in the Python standard library that deal with nontrivial process and I/O management? Unless you want to underdocument and leave important parts of the behavior for users to incorrectly guess, such documentation is going to be much larger than a cheat sheet would be.
> Yes. It's the syntax alongside prose explaining the behavior in detail. Go give it a read.
Bold of you to assume that I or the others didn't. I made my statement in spite of reading it. Not because I didn't read it. So my opinion is unchanged here.
The point here is simple. Documentation is a very important addition. But you can't paper over other deficiencies with documentation, especially if you find yourself referring the same documentation again and again. It's an indication that you're dealing with an abstraction that can't easily be internalized. Throwing the book at everyone isn't a good solution to every problem.
> Have you read the [0] docs for Python's 'subprocess' library? The ...
Yes, I have! All of those. Their difference with bash documentation is that you get the idea in a single glance. I spend much less time wondering how to make sense of it all. Python's abstractions are well thought out, carefully selected, consistently and orthogonally implemented and stays out of the way - something I can hardly say about bash. If that's not enough for you, Python has something that bash lacks - PEPs. The documents that neatly outline the rationale behind their decisions. That's what a lot of programmers want to know and every programmer should know.
Fun fact: The Epstein files contain a copy of the bash manual! Of course they weren't involved in his crimes. It was just one of the documents found on his system. A sysadmin is believed to have downloaded it for reference. But it's telling that it wasn't the Python manual, or the Perl manual, or something else. Meanwhile, I don't really think that Epstein was running Linux on his system.
> Unless you want to underdocument and leave important parts of the behavior for users to incorrectly guess, such documentation is going to be much larger than a cheat sheet would be.
If properly designed, such expansive documentation would be unnecessary, as they would be obvious even with the abstractions. For example when you use a buffer abstraction in modern languages, you have a fairly good idea what it does and why you need it, even though you may not care about its exact implementation details. That's the sort of quality where bash and other POSIX shells fail on several counts. In fact, check how many other shells break POSIX compatibility to solve this problem. Fish and nushell, for example.
"The developer is too lazy to read the documentation" isn't the appropriate stance to assume when so many are expressing their frustration and displeasure at it. At some point, you have to concede that there are genuine problems that cannot be blamed on the developer alone.
> But you can't paper over other deficiencies with documentation, especially if you find yourself referring the same documentation again and again. It's an indication that you're dealing with an abstraction that can't easily be internalized.
> Their difference with bash documentation is that you get the idea in a single glance.
> If properly designed, such expansive documentation would be unnecessary, as they would be obvious even with the abstractions.
What is it the kids say? "Tell me you don't make use of 'multiprocessing', 'subprocess', and other such inherently-complicated modules without telling that you don't..."? Well, it's either that, or you that often use them, and rarely use bash I/O redirections... because, man, the docs for just the 'subprocess.Popen' constructor are massive and full of caveats and warnings.
You're resorting to non sequiturs, nitpicking and vague assertions to just skirt around the point here. Python syntax rarely confuses people as much as bash does. Look at this entire discussion list for example.
subprocess module isn't a reasonable example to the contrary, because it isn't Python's syntactical sugar that makes it confusing. And even in case of modules that aren't well designed, the language developers and the community strive to provide a more ergonomic alternative.
But instead of addressing the point, you decided to make it about me and my development patterns based on some wild reasoning. But that's not surprising because this started with you asserting that it's the developers' fault that bash appears so confusing to them. Just some worthless condescension instead of staying on topic. What a disgrace!
While you're still thinking about it, make sure to bookmark the "redirections" section of the manual. [0] Also useful might be the "pipelines" section [1] to remind you of the "|&" operator.
> Try introducing DPA invocation into your analogy and let's see where it goes!
When I introduce that, I see Anthropic's management getting Tiktok'ed.
It can be true that Anthropic's products are essential for national defense and also true that the management of the company are a supply chain risk.
Is any of that true? Well, so much of what has been done in the name of "national defense" & etc over the past many decades has clearly not been done for reasons that are true, so -when it comes to "national defense"- I don't think that the truth actually matters much at all.
> I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have?
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
> They're almost always relying on VLANs behind the scenes to separate the WAN and LAN ports.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
It's trivial to look up the switch port configuration of a consumer router once you put OpenWRT on it. The most common topology is the CPU has two RGMII/XGMII or similar links to an 8-port switch chip, five more ports of the switch are connected PHYs for external ports and configured for the LAN VLAN, and the last port is connected to a PHY for an external port and configured for the WAN VLAN. This does not result in any VLAN tags being emitted over the wire, but from the perspective of the switch silicon it's just one of many possible VLAN configurations. Changing which physical port is the WAN port is as simple as assigning a different switch port to that VLAN. If you did want VLAN tags emitted on a particular port, it's a single checkbox or single-character config file change.
> Buses have a long tradition of user-hostile design. "Exact change only"...
On every pay-in-cabin bus I've ever ridden, this is synonymous with "No change given". The machines are quite happy to accept more money than is needed for a single ticket, and the reason for that is pretty obvious.
> It has always baffled me why they make it so hard for first-time users in particular.
The SFMTA (the San Francisco bus/train operator) provides a document that addresses almost everything you brought up. [0] The "unhelpful and condescending and impatient drivers" thing isn't addressed, but I've never run into a Muni driver that was anything but helpful. [3] As an added bonus, the most useful information about fares is posted on the paybox inside the bus.
>> Buses have a long tradition of user-hostile design. "Exact change only"...
> On every pay-in-cabin bus I've ever ridden, this is synonymous with "No change given". The machines are quite happy to accept more money than is needed for a single ticket, and the reason for that is pretty obvious....the most useful information about fares is posted on the paybox inside the bus
That's fair, but (1) when I was a kid and starting out riding a bus, I didn't know that; and (2) as that same kid, neither my family nor I had very much money at all and paying "extra" for something is just not something you do. Consider it a cultural thing. "inside the bus" is good but insufficient when I'm deciding between walking a mile or chancing the bus that I don't understand. (I almost always walked the mile. I was cheap, and I hated looking stupid in front of unsympathetic people.)
As for Muni, I didn't live where I could use it until I was no longer that kid. But adult me fully agrees with you. My experience with Muni has been much better than with most other busses I've used.
I see. Your complaint is that in vehicles that are staffed only with a driver, the driver refuses to handle change, and that -in your youth- your parents didn't provide you with any information (whether directly from them, or published by your local transit authority) about how mass transit worked in your area.
There's not much the transit authority can do about your parents' decision to leave you ill-informed. I can tell you that obligating the solo driver to handle change would be significantly user-hostile for the passengers currently on the vehicle. The tradeoff made is the correct one.
As you're probably aware, there's also good news: for a while now, many (most?) transit systems permit payment with radio cards that are linked to a preexisting pool of money, rather than having to handle cash inside the vehicle.
Your post is a good illustration of the type of hostility I'm talking about. "If you don't already know, it's your fault, and if it's not your fault, it's your parent's fault."
I don't want the driver to handle change. I want to know what the price is before I board the bus and possibly discover that I do not have the right change (or enough money at all). Yes, I would also like the machine to give me change if I overpay. I'm demanding.
My parents do not know so cannot teach me. They live on a farm. When they visit cities, they rely on their social ties and meet someone to take them around. Plus, well, it was a farm; I had no need for buses until I moved away. There is no mass transit in the area I grew up, so there's no literature to peruse.
I apologize for not being gifted with the evidently superior parents you had.
I was not unusual. Many rural people moved to cities and ran into all this implicit knowledge that they were looked down on for not possessing. It's ok; we laughed at the city folks who came visiting or relocating to the country too. We also helped them with a straight face, or at least helped those who could be helped. The social contract is stronger in the country than in the city.
But anyway, this is veering away from the crappy UX of most buses. It is true that I could have researched bus systems before I ever encountered one and trained myself such that I could survive the bad UX. But that's kind of the point, right? UX design should require as little prior knowledge or understanding as possible (as in, as possible without harming the experience of regular riders too much or increasing cost excessively; I acknowledge the existence of tradeoffs.) You try to make it useful to country bumpkins, non-native speakers, youth, the poor, etc.
Learning that it was almost always faster to walk from 4th and King to my place in the TL in the three hour period around "rush hour", and often faster late at night -depending on how out of sync the bus and Caltrain arrival times were- was lifechanging in a couple of ways.
Because of Muni's inability to stick to schedule, [0] the Nextbus displays are absolutely essential for making the "Do I walk, or do I wait?" decision. I hate stops that don't have them.
It's a damn shame that the city didn't build many more subway lines during the boom times.
[0] Granted, it's not entirely their fault; they have to contend with SF traffic, too.
reply