sdfgdfgbsdfg

https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... is a solution for that

https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Is basically that, but with infinite tickets :)

Here's how YubiCo proposes to address this: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco... Revocation is done RP side, but it essentially allows a primary authenticator to register itself and the secondary on a given RP

Agreed, and that's why I say in my original comment that I don't see it happening in the short term. If we had something that worked now or maybe tomorrow and was acceptable, it would simply be virtual authenticators; an authenticator implemented entirely in software. There's no practical reason why password managers like 1Password can't do that beyond attestation which nobody checks anyway. But in the end, I don't see the big three participating in sharing. The threat model changes so much that especially for Microsoft (in cell phones) and Google (in desktops) that means trusting an adversarial OS they have no control over

Yes but what the OP is saying is that the TPM does not store the encrypted passkey, rather, the passkey is wrapped with this TPM's public key by another TPM that already trusts this TPM, so this TPM can import a passkey that's been wrapped with its own public key and store it unencrypted. See Apple's circle of trust: https://support.apple.com/guide/security/secure-keychain-syn...

receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.

It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to start requiring TPM vendors to implement this in their drivers, but I can't see it being cross compatible with the API in the apple TPM any time soon, especially because the circle of trust is now as weak as the weakest TPM, and it's a reputation risk for apple if a credential gets compromised because some non-apple device trusted by the user in an apple circle of trust got breached

For security keys implementing FIDO (which sometimes you can see referred to as WebAuthn, although that is partially inaccurate), there is currently no good way of backing up the key. If you lose it, then you'll need to recover your account with every service you had it registed it with, meaning that you'll need at least an additional factor on each service that's most likely not as secure as a FIDO key, unless you're registering two keys for every service which is very cumbersome and still makes you re register a lost key with each service.

There are proposals to address this either by chaining trust between security keys or by sharing "passkeys" (a webauthn credential). see https://news.ycombinator.com/item?id=31272867 Only apple implements it today as far as I know so there's no good way to recover from a lost or damaged key if you're not exclusively in the apple ecosystem

I feel like this is an inevitability at this point. Kotlin is basically this, and C#/Java/Typescript are getting there, albeit with some historical baggage that might make it slightly less ergonomic.

pron talks about this on https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2....

In a library. Loom is more about adapting the JVM itself for continuations and virtual threads than adding to userspace.

FoundationDB is operationally very complex; there's a multitude of processes, no reference architectures of at-scale deployments (althought those do exist; at least at Snowflake and Apple), no docker images with helm charts, and no cloud managed solution.

It's also extremely low level, at the query layer, it's simply an ordered map of (byte[], byte[]). The sibling comment also mentions optimistic concurrency control as a built-in primitive that can scale poorly with high contention. These two issues and similar others are left for the query layer to resolve. Foundationdb is not really intended to be used directly as a general purpose key/value store but to provide a distributed transaction and storage layer for a query layer to be implemented on top of it.

I think it's interesting to think about foundationdb as a higher-layer from rocksdb which has quickly become the de-facto standard for the single node storage-layer. For building highly scalable, globally distributed ACID systems, foundationdb could very well be the clear winner like you say, although systems in this category have opted to implement their own consensus and transaction layers. At least, all the spanner and calvin derivatives I know of (cloud spanner, yugabyte, cockroach, faunadb) implement their own. But for use cases where strict serializability is not required, there's ample room for innovation and I think this is where things like Anna can potentially fit in

I am very confused by Table I, claiming Redis and HStore have a multi-key consistency of "Serializable". What meaning is it trying to convey? Serializable is a level of isolation, not of consistency, so how are they on the same category?

I agree with this overall.

It seems that C is a language/compiler/toolchain combo that lets you shoot yourself in the foot, but gives you enough access to stuff to be maximially performant in a random (i.e. not specialized) use case. (C++ is in this camp too).

Rust is a language/compiler/toolchain combo that tries its best to not let you shoot yourself in the foot by presenting those footguns for you to fix up front, without giving up much of the access to stuff (C++ tried some things in this camp like destructors and smart pointers. GC is also something that's in this camp)

Golang is a language/compiler/toolchain combo that lets you shoot yourself in the foot in some circumstances, and does not give you enough access to be maximally performant in every random case, but rather it seems to posit to give you opinions that will get you really, good performance in most random cases (if you need to tune the GC, for instance, you're probably worse off, like here: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...). Meaning it's making the tradeoffs of upfront complexity vs runtime issues, and Tim Toady vs The One True Way for you, because in the general case those are the most optimized tradeoffs. I don't disagree, especially when the closed-world ecosystem is good enough to not need to reach out to external tools whether those are via cgo or in the build toolchain.

In general, I think that if you reach the point where Golangs admittedly major warts are hindering your progress you're doing better than most companies, so its succeeded in not getting in the way of progress at least until that point.

In particular since the article keeps comparing Golang to Rust, for personal projects I do like the correctness of Rust, but some things are frustrating, like async being basically unusable without Async Drop, an uncertain future for completion apis, and apis that really want HKT but can't use them (yet?). I having to make up a lot of opinions that Go makes for you adds risk and uncertainty to a project where the most likely failure modes are not, in fact, those opinions.

I'm excited for the future of Java, with Loom and Valhalla coming to address as what I see as two core problems of Java in particular and other languages in general. I'm also excited for the present of js/node.js/maybe Deno. typescript has become good enough that I also think it's a really good competitor to Golang in the "just write code" arena, especially since there's significant synergy between the front end and the back end to help with build tooling, validation logic, and programmer expertise.