This is a long-standing security/usability tradeoff in the Webauthn spec. Various solutions have been proposed, but as far as I know most of them are still just drafts, e.g. [1]. The best practice has been and, as far as I know, continues to be to register multiple authenticators, e.g. a primary and a backup authenticator. This practice has a variety of benefits:

1. Avoids lockout if an authenticator is lost.

2. If you use multiple authenticators from different vendors (e.g. Yubico and Google) you:

1. Avoid vendor lock-in

2. Can rapidly respond in case a security vulnerability is discovered in one of your authenticators, as has occurred for both Yubico [2] and Google [3].

One could use Apple's Passkeys as one's day-to-day "personal" authenticator, and use an authenticator from a different vendor (e.g. Yubico Yubikey or Google Titan Security Key) as their backup key. I don't see how Apple's implementation increases the risk of lock-in beyond that of any of the other major Webauthn authenticator providers.

[0]: https://github.com/w3c/webauthn/issues/865#issuecomment-3804...

[1]: https://github.com/Yubico/webauthn-recovery-extension

[2]: https://www.yubico.com/support/issue-rating-system/security-...

[3]: https://security.googleblog.com/2019/05/titan-keys-update.ht...

[0]: https://www.macrumors.com/2022/06/06/macos-ventura-system-se...

They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid.

Source: https://developer.mozilla.org/en-US/docs/Web/Security/Certif....

My reasoning behind this exercise was:

- I checked in with their teacher ahead of time and confirmed that all of these kids had a least some experience using a web browser. Generally it seems like a likely "lowest common denominator" of tech experience for kids.

- Most web browsers have powerful developer tools that can be used to inspect and modify source and will display the results of many types of changes in real time. It is easy to get kids to understand the relationship between HTML/CSS code and the webpage that results from rendering it when you can make live changes to the code and see it immediately reflected in the rendered page.

- Web browsers are freely available. I gave them a handout with instructions on how to access the developer tools in web browsers that are either free (Chrome, Firefox) or readily available to them (Safari, since their school computer lab had a few Macs). I specifically wanted them to be inspired and continue experimenting after I left.

I concluded by spending 10 minutes taking student's requests for the modifications to nytimes.com. It ended up with a bizarro color scheme, comic sans on all the things, and pictures of dinosaurs and Pixar characters at the top of every article. Everyone had a blast, myself included!

I think the demonstration tickled the kid's innate predisposition towards mischief. An immediate question was "can everyone in the world see this changes? are you hacking right now?," which allowed me to naturally give a high-level explanation of the server-client architecture of the web. A few kids came up to me afterwards and asked me to specifically walk them through finding and opening the developer tools so they could continue experimenting at home, and that was the best outcome I could've hoped for!

While Apple only started posting transcripts of WWDC presentations last year, https://asciiwwdc.com has been around for a while and is a great searchable archive of WWDC transcripts. Here's the transcript for the presentation you referenced: https://asciiwwdc.com/2014/sessions/715?q=user%20privacy%20i....

Since there was no mention of it in the post, this is called “randomized response,” and is a building block for modern privacy-preserving protocols e.g. RAPPOR, which is used in Google Chrome: https://security.googleblog.com/2014/10/learning-statistics-...

1. Use a preheated pizza stone or similar (e.g. cast iron pan) to get as much radiant heat into the crust as possible.

2. Position the pizza stone close to the upper heating element and/or switch to broil for the last few minutes of cooking.

This is a great example of why I'm generally skeptical of these scattershot approaches to making users more secure by changing default settings in mainstream browsers. Security and privacy features always entail tradeoffs and should be designed and implemented holistically for best results.

On platforms that have a decent OS-level keychain API (not Windows), this technique does not actually bypass password encryption and may trigger a password prompt/require the user to enter their password. This depends on whether the user previously granted permanent access to a given secret by a given application (e.g. by clicking “Always Allow” in the macOS keychain prompt). The author of the exploit probably did this at some point and forgot about it, which is why this appears to be a bypass of Chrome’s cookie db encryption.

Ultimately, encrypting the cookie DB provides limited protection anyway and if you have user privileges then you’ll eventually be able to access their data. This is not news, although it was the topic of some controversy back when Chrome resisted making changes to support this specific threat model, which is impossible to completely defend in the general case from the POV of a typical application developer on a modern desktop OS.

Update: they recently tweeted confirming they were not at risk, https://twitter.com/GitHubSecurity/status/105231733337972326...