Emily Stark reposted
One year from now, Chrome will enable "Always Use Secure Connections" and warn users before plaintext HTTP by default.
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
One year from now, Chrome will enable "Always Use Secure Connections" and warn users before plaintext HTTP by default.
Emily Stark reposted
Chrome has published version 1.6 of their root store policy. Notably, this includes a deadline of June 15, 2026 to get TLS Client Auth out from any intermediates under roots in Chrome's program. TLS client cert users from public CAs may need to make changes. www.chromium.org/Home/chromiu...
Emily Stark reposted
Good news, from @mozilla and @risksahead! "New ETSI draft standard on QWACs is good news for safety of European internet users"
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!
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
Safari 18.2 released 3 days ago has HTTPS-first/by-default mode: "Safari 18.2 on iOS, iPadOS, and visionOS will always try to load webpages over secure connections first, i.e. HTTPS by default. Only if the secure page load fails will Safari fall back to non-secure HTTP." webkit.org/blog/16301/w...
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...
Emily Stark reposted
Some thoughts on the quiet HTTPS revolution: medium.com/@boblord/the... 🔐
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
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.
My colleague @serena.nz gave an amazing PurpleCon talk describing the behind-the-scenes experience of removing the (in?)famous lock icon from Chrome: www.youtube.com/watch?v=iUAx... One day I aspire to get as many laughs during a talk as a 90s sitcom laugh track 🤩
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.
If you, like me, dislike when tiny icons lead to large misconceptions about security, you will be happy to hear that the lock icon in Chrome is going away. Come for the browser security UI news, stay for the perfect Simpson's reference: https://blog.chromium.org/2023/05/an-update-on-lock-icon.html
kudos to @dadrian.io for the simpsons reference and to our marketing team for not editing it out
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)
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!
... 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)
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)
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!
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)
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!
Chrome Security Q1 update! https://www.chromium.org/Home/chromium-security/quarterly-updates/
Emily Stark reposted
You are up to date.