Notices by Marcin Cieślak (saper@mastodon.social)

@feld @0xabad1dea Quite happy with NSS, but this is definitely something not even remotely OpenSSL-compatible

@feld what did you expect

@skinnylatte Maybe it is a feeling when living in a well-connected market garden.

I was on vacation in some rural eastern European area and decided to buy stuff directly from the peasants: "Sorry no potatoes today, it was raining yesterday".

I realized how much I was shaped by the supermarket culture.

@inthehands I wonder if the concept of documentation fades away

I realized I tend to avoid software that forces me to study the concepts and the philosophy of it first from the documentation (For example, #Lilypond didn't let me to go quickly into writing things there).

Watching some junior devs at work - they rely exclusively on prompts given by the IDE, giving at most one-line descriptions of function arguments.

When that fails, they refer to library source code, never the documentation

@feld @kravietz @PlaneSailingGames @GossiTheDog @vpz

ok, now I got to understand that the Keychain is an encrypted data structure stored somewhere (it could be Apple's key-value store). Reading this story I gather that a whole thing is encrypted with a symmetric wrapping key. This wrapping key can be either obtained by the syncing identity or derived from the recovery code.
So devices exchange the key exchange key among themselves during pairing? Could recovery code be seen as a #SPOF?

@GossiTheDog can you provide some context? I am not sure I get this...

@PlaneSailingGames @GossiTheDog

I am no expert on #Webauthn but maybe some "pure-device-based-no-backup" attestation type could be added. But then, in turn, the relying party would need to require that and only that. Unlikely to happen.

Does this mean that relying parties might need to maintain "trusted" lists of attestation CAs in the future?

Here it would be unlikely that Google, Apple and Microsoft certificates will not be included on those lists by default.

pls help @kravietz :)

@GossiTheDog @kravietz @PlaneSailingGames

got it! in short: FIDO good, passkey bad

@vpz @GossiTheDog @kravietz @PlaneSailingGames

(i)Cloud accounts have been targeted for hijack for quite a long time.

what is the point of cloud-based passkeys?

so I am going to protect myself against hijacking, say, my Github account, but my Apple account stays less protected?

But if I go ahead and buy a real hardware fido key, I can use it for all services, including Github and (probably) Apple, so why bother with the cloud-based solution?

@jond @notclacke
Looks like it is actively being worked on:

https://git.pleroma.social/pleroma/pleroma/issues/165