growse

What's the specific use case that benefits from a shorter key?

The only interaction I can ever see having with this key is putting it into and taking it out of my password manager....

Personally, I find that having orchestrate and regularly schedule the exporting of that file off my device to somewhere else, and then look after it there to be not "free".

The new offering is reasonably priced imo.

Full message content seems to be free, with the option to pay £1.59pm for all media included (45 days of media included in the free tier).

Seems pretty reasonable?

//nolint

> if it would never work, why not drop support?

Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to).

Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"?

> If you make something possible, it will be used.

Sure, but that's not without tradeoffs. I come back to:

> Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

I missed a word out from my question. Let me try again.

What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?

What makes you think that the Webauthn standards are "targeted at running services for the general public"?

> It seems like the requirements already diverged.

No, the requirements are _contextual_. This isn't a new idea.

Not all people who want to replace passwords are running services available to the general public.

There are a bunch of service provider contexts where credential storage attestation is a really useful (and sometimes legally required!) feature.

I agree that account recovery isn't the best. But just because that sucks doesn't mean there's zero value in improving credentials.

Literally no idea.

My point was that freedom is not an absolute, it's balanced against other freedoms. It's hard to tell whether you agree with that or not.

Do you think someone running a service that's under constant denial-of-service attacks would be sympathetic to the argument that "What people do on their own computer is none of the service's business".

Pretty much every service out there has "don't share credentials" in their ToU. You don't have to like it, but you also don't have to accept the ToU.

I don't know what "scare quotes" are. They're just regular quotation marks, because I'm quoting.

It is if it puts the service at risk.

No, they're just resident webauthn credentials which use asymmetric crypto.

> very obviously once Passkeys are everywhere it'll become "we're requiring attestation from approved device bootloaders/enclaves"

This is far from very obvious, especially given that Apple have gone out of their way to not provide attestation data for keychain passkeys. Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

There's a tension here between "user freedom" and a service wanting to make sure that credentials that it trusts to grant access to stuff aren't just being yolo'd around into textfiles on people's dropboxes.

People forget that one of the purposes of authentication is to protect both the end user and the service operator.

Without a lock file your transitive dependencies are.... by definition not centralised?

Or have I misunderstood?

> but I'm really good at my job

How good you think you are at your job is pretty meaningless if some manager above you wants to weaponise the company's perf policy against you.

> One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers.

But you can do this, you simply have to pay the cost of using PAGE_SIZE of memory per byte you want to protect?

I agree. But not enough people are costing out the 'do nothing' option (it's not zero!).

One of the biggest fallacies I see in this space is people looking at an observability standard like otel and thinking "I must enable all of that".

You really don't have to.

Throw away traces. Throw away logs. Sample those metrics. The standard gives you capabilities, it doesn't force you to use them. Tune based on your risk appetite, constraints, and needs.

My other favourite retort to "look how expensive the observability is" is "have you quantified how expensive not having it is". But I reserve that one for obtuse bean counters :)

Everyone knows that a donut has two sides.

Inside, and outside.

Does copyright law apply differently to humans Vs organisations?

> without any compensation,

Didn't Anthropic buy the books?

> Worse, they’re using it for massive commercial gain, without paying a dime upstream to the supply chain that made it possible. If there is any purpose of copyright at all, it’s to prevent making money from someone’s else’s intellectual work.

This makes no sense. If I buy and read a book on software engineering, and then use that knowledge to start a career, do I owe the author a percentage of my lifetime earnings?

Of course not. And yet I've made money with the help of someone else's intellectual work.

Copyright is actually pretty narrowly defined for _very good reason_.

> So is almost every other standard, but until something better comes along, DNSSEC is what we have.

I must have missed the last 40 years of the internet where DNS without DNSSEC has worked (and continues to work) just fine.

This feels like a classic example of "actions at the sharp end resolve all ambiguity" from Richard Cook's 1998 paper on complex systems.

Everyone seems to miss the "single unbreakable pki" aspect that necessarily comes along with the design. :shrug:

I've worked for these orgs on this exact problem.

It's the latter.

Apparently the way to do sane risk management is just "don't be an idiot"?