Emily Stark

Emily Stark

@estark.bsky.social

Encryption, HTTPS, certificates, web security, security UX, software engineering and management, TMI about parenting. Opinions are my own.

3.3K followers273 following32 posts

Emily Stark reposted

I am convinced 99% of websites should use magic links + passkeys. It bypasses all (debatable) portability objections to passkeys, it’s at least as secure as email-based recovery, as fast as a password manager, it’s available to all users… and importantly, no passwords!

Ricky Mondello@rmondello.com

I wrote about how magic links (emailed one-time login links) frustrate me while explaining that they radically accept some fundamental truths. I argue that websites should layer passkeys on top of magic links to provide a seamless authentication experience for everyone. rmondello.com/2025/01/02/m...

Emily Stark reposted

Handling Cookies is a Minefield: Inconsistencies in the HTTP cookie specification and its implementations have caused a situation where countless websites (including Facebook, Netflix, Okta, WhatsApp, Apple, etc.) are one small mistake away from locking their users out. grayduck.mn/2024/11/21/h...

I caught a full vomit into my hands tonight without a single drop hitting the couch, so maybe I do qualify as a medical professional after all

Emily Stark@estark.bsky.social

I seem to have gotten added to some medical starter packs for some reason. If you're following me for medical stuff, sorry, wrong person! Feel free to stick around if you want to answer my random medical questions every time one of my children brings home some weird virus from school.

I seem to have gotten added to some medical starter packs for some reason. If you're following me for medical stuff, sorry, wrong person! Feel free to stick around if you want to answer my random medical questions every time one of my children brings home some weird virus from school.

Emily Stark reposted

We’ve now established a pattern where Go is the first non-browser stack to implement new TLS features, so we flush out all the bugs Chrome didn’t hit. Today it’s tldr.fail. PQ shares were already default in Chrome, but Go 1.23 is surfacing new broken middleboxes. Last time it was X.509 SANs.

tldr.failtldr.failThe migration to post-quantum cryptography is being held back by buggy servers that do not correctly implement TLS. Due to a bug, these servers reject connections that use post-quantum-secure cryptography, instead of negotiating classical cryptography if they do not support post-quantum cryptography.

one of these days I’m going to livetweet my night because it might be the only way to convey how ridiculous nights are in my house. I haven’t even gone to bed yet and kids have woken up a combined total of 4 times already

the (very early stage) draft is worth a read if you haven't already: https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html the idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and... (1/n)

aaron gable@aarongable.com

I'm incredibly excited about the prospect of Merkel Tree Certificates, and look forward to working with the Chrome team on experimental support in the future!

View full thread

... explore too, like being able to negotiate trust anchors -- that is, a client can signal which CAs it supports and the server can authenticate itself in a way that works with those supported CAs. In contrast today a server has to configure a single certificate to work with all clients it... (5/n)

wants to support. This part isn't fully fleshed out yet but it's exciting. It's a great time to give feedback on the draft. Would tag my colleagues David Benjamin and Devon O'Brien to give them credit but they're not on here yet! (n/n)

the (very early stage) draft is worth a read if you haven't already: https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html the idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and... (1/n)

aaron gable@aarongable.com

I'm incredibly excited about the prospect of Merkel Tree Certificates, and look forward to working with the Chrome team on experimental support in the future!

View full thread

... clients and certain types of situations, so the whole thing falls back to traditional X.509 certificate chains otherwise. You can think of it as a PKI designed from scratch, with CAs and CT smooshed into one system, as an optimization layer on top of today's web PKI. (3/n)

The main motivation is postquantum cryptography; PQ signatures are huge and this scheme allows a client to verify a domain name <-> public key association with 0 signatures. The Merkle tree proof is no bigger in a PQ world. There are lots of other interesting properties that MTCs lets us... (4/n)

the (very early stage) draft is worth a read if you haven't already: https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html the idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and... (1/n)

aaron gable@aarongable.com

I'm incredibly excited about the prospect of Merkel Tree Certificates, and look forward to working with the Chrome team on experimental support in the future!

... other interested parties. TLS servers are authenticated via a proof of membership in one of these Merkle trees, instead of via a bunch of signatures in an X.509 certificate chain -- which are huge in a postquantum world. This new form of authentication only works for certain types of... (2/n)

You are up to date.