I don’t think they mean scrapers necessarily driven by LLMs, but scrapers collecting data to train LLMs.

We had as many people come test as we could, and we found that 90% of them didn’t get a sense of depth, likely because it lacked stereo-vision cues. It only worked for folks with some form of monocular vision, incl myself, who were used to relying primarily on other cues like parallax.

However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.

That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.

Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...

The important point being made in this discussion is that this is already a common thing with OAuth, but mostly unheard of with web sessions and cookies.

In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections.

A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally.

In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.

Another good way to get started is to find crewing opportunities for casual racing on https://www.latitude38.com/crew-list-home/. Many skippers will take no-experience folks out for fun. (It may take a couple of attempts to find a skipper/crew you enjoy hanging out with)

But as sibling comment says, that’s been dropped.

For surnames, anyone (including Icelanders) is allowed to use a family name if they have a claim to one, which is defined as having a parent or a grandparent carrying that name as a surname. So foreigners with family names can pass those to their children if they like and skip the patronym.

“Enthusiasts” might have legitimate reasons for preferring hardcover (durability, aesthetics, etc) and are willingly and knowingly paying extra for that.

How much it cost to manufacture is mostly irrelevant.

That is not quite true, the sub field will be different.

We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users.

I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader.

> hoping the other keys with timeout before the use actually have to use them

Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.

So when the signal frequency changes, you’ll still see that change, but the light might get brighter or dimmer at the same time due to the stained glass. But you don’t care about the brightness to begin with.