# ImperialViolet Published articles for ImperialViolet. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Dependent Types and the Challenge of Automating Proofs DevFeed: [Dependent Types and the Challenge of Automating Proofs]() Original publisher: [Read original article]() Author: Adam Langley Published: 2026-07-26T00:00:00Z Content type: opinion Language: en Sources: [ImperialViolet]() Topics: [Programming language](), [Lean](), [Programming](), [Coq]() Tags: [interactive](), [language](), [machine](), [programming](), [programming-language]() ### AI overview The article discusses dependently typed languages such as Coq, Rocq, and Lean, which can encode subtle invariants in a type system. It explains that writing and checking proofs can require substantial effort, contributing to the niche status of these languages and motivating attempts to automate proof obligations. ### Source excerpt I've long had a soft spot for dependently-typed languages like Coq Rocq and Lean. They offer the possibility of a type system capable of encoding and enforcing arbitrarily subtle invariants. The sort of thing that, in regular languages, ends up (at best) as a comment, and which quickly gets lost as the size of the team grows. Then you get subtle misunderstandings and components that don't quite fit together. It's often the case that those components have grown to a sufficient size that, when the problem is noticed, aligning either of them is a wearying prospect. Perhaps, say dependent types seductively, you could write those invariants formally and have a machine check them. (p.s. Coq changed its name! I remember many years ago at a Coq conference in Princeton, I tried suggesting that, in an English-speaking world, having a programming language called Coq was an impediment. I don't think the audience agreed at the time. I also joked that many of the talks there sounded like a speech by Tyrion Lannister, there being so many Coqs and Hoares. A joke that was hilarious and timely, even though it fell completely flat, coming as it did before the final season of that show and our collective memory-holing of it.) The problem has always been that with great type-system power comes great proof effort. I can certainly attest to entire days spent proving really quite simple things. Doing proofs is actually quite fun: it's challenging, interactive, and there's a clear goal. But gosh, does it take a lot of time, especially if, like me, you don't know what you're doing. There's also the periodic, galling experience, at the end of many hours of effort, where you realise that the goal that you're trying to prove is, in fact, false. The classic result here is the retrospective from the seL4 effort that found that, even though the project was large enough for the engineers to develop considerable experience, they spent about 10 times as much time proving as they did designing and imp ## TRMNL DevFeed: [TRMNL]() Original publisher: [Read original article]() Author: Adam Langley Published: 2025-07-27T00:00:00Z Content type: opinion Language: en Sources: [ImperialViolet]() Topics: [e-ink](), [Microcontroller](), [Cloud Run](), [Go Language](), [JSON](), [HTTP]() Tags: [battery](), [e-ink](), [firmware](), [http](), [program](), [usb](), [wi-fi]() ### AI overview A review of the TRMNL, an 800x600, 1-bit e-ink display powered by a battery and microcontroller. The article describes its firmware and server customization, tile-based display service, Liquid templating, and a Go program on Cloud Run that displays family calendar events. It also notes refresh-scheduling difficulties and the device's relatively high cost. ### Source excerpt The TRMNL is an 800x600, 1-bit e-ink display connected to a battery and a microcontroller, all housed in a nice but unremarkable plastic case. Because the microcontroller spends the vast majority of the time sleeping, and because e-ink displays don't require power unless they're updating, the battery can last six or more months. It charges over USB-C. When the microcontroller wakes up, it connects to a Wi-Fi network and communicates with a pre-configured server to fetch an 800x600 image to display, and the duration of the next sleep. You can flash your own firmware on the device, or point the standard firmware at a custom server. The company provides an example server, although you can implement the (HTTP-based) protocol in whatever way you wish. I considered running my own server, but thought I would give the easy path a try first to see if it would suffice. The default service lets you split the display into several tiles, and there are a number of pre-built and community-built things that can display in each. None of them worked well for me, but that's okay because you can create your own private ones. They get data either by polling a given URL, or by having data posted to a webhook. The layout is rendered using the Liquid templating system, which I had not used before, but it's reasonably straightforward. I wrote a Go program hosted on Cloud Run which fetches the family shared calendar and converts events from the next week into a JSON format designed to make it trivial to render in the templating system. With a 3D-printed holder, super glue, and some magnets, it's now happily stuck to the fridge where it displays the current date and the family events for the next week. The most awkward part of the default service is managing the refreshes. The device has a sleep schedule, and so do the tiles, which are only updated periodically. So the combination can easily leave the wrong day showing. It would be helpful if the service told you when the device would next up ## Continuous Glucose Monitoring DevFeed: [Continuous Glucose Monitoring]() Original publisher: [Read original article]() Author: Adam Langley Published: 2025-06-29T00:00:00Z Content type: opinion Language: en Sources: [ImperialViolet]() Topics: [data](), [Monitoring](), [App](), [Android](), [iphone]() Tags: [android](), [app](), [data](), [iphone](), [monitoring](), [technology]() ### AI overview A personal review of over-the-counter continuous glucose monitoring. The author describes the sensor, its reading and transmission intervals, phone requirements, app experience, and physical application, based mainly on testing with an iPhone. ### Source excerpt Continuous glucose monitoring has been a thing for a while. It's a probe that sits just inside your body and measures blood glucose levels frequently. Obviously this is most useful for type 1 diabetics, who need to regulate their blood glucose manually. (At this point, I would be amiss not to give a nod to the book Systems Medicine, which I think most readers would find fascinating. I can't judge whether it's correct or not, but it is a delightful exploration of a bunch of maladies from the perspective of differential equations.) But CGMs have been both expensive and prescription-only. And I am not a diabetic, type 1 or otherwise. But technology and, more importantly, regulation have apparently marched on, and even in America I can now buy a CGM for $50 that lasts for two weeks, over the counter. So CGM technology is now available to the mildly curious, like me. The device itself looks like a thick guitar pick, and it comes encased inside a much larger lump of plastic that has a pretty serious-looking spring inside. It takes readings every 5 minutes but only transmits every 15 minutes. You need a phone to receive the data and, if the phone is not nearby, it will buffer some number of samples and catch up when it can. The instructions say to keep the phone nearby at all times, so I didn't test how much it will buffer beyond an hour or so. I've got both an Android and an iPhone, but for this the iPhone was a more convenient device. So everything following probably applies to both ecosystems, but I've only tested it in one. The app is well made, although you can feel the lawyers & regulators hovering over every part of it. It gives you instructions about how to "install" the sensor, which you do by holding the big lump of plastic with the spring over a suitable spot on your body and then pressing the button. It's not a large needle, but it's not trivial either. There is a soupçon of cyberpunk about applying it to yourself in the bathroom but, honestly, my first thought ## A Tour of WebAuthn DevFeed: [A Tour of WebAuthn]() Original publisher: [Read original article]() Author: Adam Langley Published: 2024-12-23T00:00:00Z Content type: article Language: en Sources: [ImperialViolet]() Topics: [WebAuthn](), [Passkeys]() Tags: [conference](), [html]() ### AI overview The author announces that a longer work about understanding and using WebAuthn is now available online in HTML. The work expands on earlier posts about WebAuthn and passkeys and was previously distributed as a printed booklet at a FIDO conference. ### Source excerpt I've done a bunch of posts about WebAuthn/passkeys over time. This year I decided to flesh them out a bit into a longer work on understanding and using WebAuthn. If you were at the FIDO conference in Carlsbad this year, you may have received a physical, printed booklet of the result. It took a while to get around to converting to HTML, but the text is now available online. ## A symmetric-key approach to post-quantum Web PKI DevFeed: [A symmetric-key approach to post-quantum Web PKI]() Original publisher: [Read original article]() Author: Adam Langley Published: 2024-04-07T00:00:00Z Content type: opinion Language: en Sources: [ImperialViolet]() Topics: [Cryptography](), [Post-Quantum](), [Encryption](), [TLS (Transport Layer Security)](), [public key](), [Security, Privacy and Abuse Prevention](), [kerberos]() Tags: [cryptography](), [dns](), [don-t](), [kerberos](), [post-quantum](), [public](), [public-key](), [tls]() ### AI overview The article proposes using DNS records and shared symmetric keys with multiple certificate authorities to help authenticate a Kyber key agreement between a client and server. It notes that initial public-key connections to the authorities would still require large post-quantum signatures and raises privacy and policy concerns because authorities could observe which servers clients contact. ### Source excerpt (I think this is worth pondering, but I don't mean it too seriously--don't panic.) Are the sizes of post-quantum signatures getting you down? Are you despairing of deploying a post-quantum Web PKI? Don't fret! Symmetric cryptography is post-quantum too! When you connect to a site, also fetch a record from DNS that contains a handful of "CA" records. Each contains: a UUID that identifies a CA ECA-key(server-CA-key, AAD=server-hostname) A key ID so that the CA can find "CA-key" from the previous field. "CA-key" is a symmetric key known only to the CA, and "server-CA-key" is a symmetric key known to the server and the CA. The client finds three of these CA records where the UUID matches a CA that the client trusts. It then sends a message to each CA containing: ECA-key'(client-CA-key) -- i.e. a key that the client and CA share, encrypted to a key that only the CA knows. We'll get to how the client has such a value later. A key ID for CA-key'. Eclient-CA-key(client-server-key) -- the client randomly generates a client-server key for each CA. The CA record from the server's DNS. The hostname that the client is connecting to. The CA can decrypt "client-CA-key" and then it can decrypt "server-CA-key" (from the DNS information that the client sent) using an AAD that's either the client's specified hostname, or else that hostname with the first label replaced with *, for wildcard records. The CA replies with Eserver-CA-key(client-server-key), i.e. the client's chosen key, encrypted to the server. The client can then start a TLS connection with the server, send it the three encrypted client-server keys, and the client and server can authenticate a Kyber key-agreement using the three shared keys concatenated. Both the client and server need symmetric keys established with each CA for this to work. To do this, they'll need to establish a public-key authenticated connection to the CA. So these connections will need large post-quantum signatures, but that cost can be amortised over ## Chrome support for passkeys in iCloud Keychain DevFeed: [Chrome support for passkeys in iCloud Keychain]() Original publisher: [Read original article]() Author: Adam Langley Published: 2023-10-18T00:00:00Z Content type: release Language: en Sources: [ImperialViolet]() Topics: [Chrome](), [Passkeys](), [WebAuthn](), [macOS](), [iOS](), [Google]() Tags: [browsers](), [chrome](), [ios](), [macos](), [settings](), [stable-channel](), [sync](), [terminal]() ### AI overview Chrome 118 adds support for creating and accessing passkeys in iCloud Keychain on macOS 13.5 or later. The article explains the required permission for autofill and account-picker access, as well as iCloud account and sync requirements. ### Source excerpt Chrome 118 (which is rolling out to the Stable channel now) contains support for creating and accessing passkeys in iCloud Keychain. Firstly, I'd like to thank Apple for creating an API for this that browsers can use: it's a bunch of work, and they didn't have to. Chrome has long had support for creating WebAuthn credentials on macOS that were protected by the macOS Keychain and stored in the local Chrome profile. If you've used WebAuthn in Chrome and it asked you for Touch ID (or your unlock password) then it was this. It has worked great for a long time. But passkeys are supposed to be durable, and something that's forever trapped in a local profile on disk is not durable. Also, if you're a macOS + iOS user then it's very convenient to have passkeys sync between your different devices, but Google Password Manager doesn't cover passkeys on those platforms yet. (We're working on it.) So having iCloud Keychain support is hopefully useful for a number of people. With Chrome 118 you'll see an "iCloud Keychain" option appear in Chrome's WebAuthn UI if you're running macOS 13.5 or later: You won't, at first, see iCloud Keychain credentials appear in autofill. That's because you need to grant Chrome permission to access the metadata of iCloud Keychain passkeys before it can display them. So the first time you select iCloud Keychain as an option, you'll see this: If you accept, then iCloud Keychain credentials will appear in autofill, and in Chrome's account picker when you click a button to use passkeys. If you decline, then you won't be asked again. You can still use iCloud Keychain, but you'll have to go though some extra clicks every time. You can change your mind in System Settings -> Passkeys Access for Web Browsers, or you can run tccutil reset WebBrowserPublicKeyCredential from a terminal to reset that permission system wide. (Restart Chrome after doing either of those things.) Saving a passkey in iCloud Keychain requires having an iCloud account and having iCloud K ## Signature counters DevFeed: [Signature counters]() Original publisher: [Read original article]() Author: Adam Langley Published: 2023-08-05T00:00:00Z Content type: article Language: en Sources: [ImperialViolet]() Topics: [WebAuthn](), [Security](), [private key]() Tags: [account](), [private-key](), [security](), [signal]() ### AI overview The article explains WebAuthn signature counters, including their optional nature, how non-zero counters should increase for future assertions from a credential, and how counter inconsistencies might indicate a cloned security key. It argues that sites using counters should lock the account, investigate, and replace the key rather than merely reject the assertion. ### Source excerpt If you look at the structure of the signed messages in WebAuthn you'll notice that one of the fields is called the "signature counter". In the previous long post I said to ignore it, which is still correct, but here's why. Signature counters are optional for the authenticator to implement: it's valid for a security key not to have a signature counter, although the vast majority of them do. In that case, the counter value is always zero. But once a website has seen a non-zero value, then the security key has to ensure that the counter, for all future assertions from a given credential, is strictly increasing. The motivation of the signature counter is that it might allow websites to detect when a security key has been cloned. Cloning a security key is supposed to be very difficult. At the very least, you should need physical access to it, and hopefully you need to spend a substantial amount of time invasively interrogating it. But, if you assume all that happened, then one could clone a security key (probably destroying it in the process), get the private key of a credential out of it, and create a working replica which could be slipped back into the possession of the legitimate user, leaving them unaware that anything has happened. At this point, the attacker can create assertions at will because they know the credential's private key. If all that has happened, then the signature counter might uncover it. Unless the attacker can know exactly when the legitimate user has created an assertion, and thus incremented the counter, then eventually either they or the real user will create an assertion where the counter didn't increase. You might be able to tell, but I consider this a rather far-fetched scenario. Nevertheless, if a website wants to use the signature counters, then it must treat any non-incrementing counter as a signal to lock the account and trigger an investigation. At a minimum, the security key in question should be replaced. Simply rejecting the assertio ## Voice recognition DevFeed: [Voice recognition]() Original publisher: [Read original article]() Author: Adam Langley Published: 2023-07-29T00:00:00Z Content type: opinion Language: en Sources: [ImperialViolet]() Topics: [Whisper](), [iOS](), [Large Language Model]() Tags: [caveat](), [ios](), [llms](), [performance](), [script](), [transcription](), [voice](), [whisper]() ### AI overview The author compares iOS 17 voice recognition with earlier results and finds that, although performance improved over iOS 16, it still produces too many errors with technical terms. The article then reports that Whisper solved the practical voice-recognition problem, while noting that it can append fabricated sentences that are removable. ### Source excerpt Update: Evan let me know that Whisper solved the voice recognition problem. He has a wrapper that records from a microphone and prints the transcription here. Whisper is very impressive and the only caveat is that it sometimes inserts whole fabricated sentences at the end. The words always sort of make sense in context, but there were no sounds that could possibly have caused it. It's always at the very end in my experience, and it's no problem to remove it so, with that noted, you should ignore everything below because Whisper is a better answer. Last week's blog post was rather long, and had a greater than normal number of typos. (Thanks to people who pointed them out. I think I've fixed all the ones that were reported.) This was because I saw in reviews that iOS 17's voice recognition was supposed to be much improved, and I figured that I'd give it a try. I've always found iOS's recognition to be superior to Google Docs and I have an old iPad Pro that's good for betas. iOS's performance remains good and, yes, I think it's better than iOS 16. But it's still hardly at the level of "magic", especially when using technical terms. Here's a paragraph taken directly from the raw output of last week's post (I've highlighted errors with italics): It is integrated into the W3C credential management specification and so it is called via navigator . credentials . create and navigator .credentials. get. This document is about understanding the deeper structures that underpin web orphan rather than being a guy as to its details. So we will leave a great many details to the numerous guides to Web Oran that already exist on the web and instead focus on how structures from UF were carried over into Web orphan and updated. While it's nice that many of the words are there, with that density of errors doing all the corrections means that it's not clearly better than typing things out. However, the world is all aflutter about LLMs these days. Can they help? I wrote a script to chunk ## From U2F to passkeys DevFeed: [From U2F to passkeys]() Original publisher: [Read original article]() Author: Adam Langley Published: 2023-07-23T00:00:00Z Content type: article Language: en Sources: [ImperialViolet]() Topics: [Passkeys](), [Authentication](), [passwords](), [Protocol (disambiguation)](), [Security](), [JavaScript]() Tags: [authentication](), [digital-signatures](), [javascript](), [passwords](), [private-key](), [protocol]() ### AI overview This article gives a chronological account of how standards developed from U2F into passkeys. It explains U2F's security-key and JavaScript API standards, the risks of bearer tokens such as passwords and cookies, and how digital signatures can authenticate users without disclosing a private key. ### Source excerpt (This post is nearing 8 000 words. If you want to throw it onto an ereader there's an EPUB version too.) Introduction Over more than a decade, a handful of standards have developed into passkeys--a plausible replacement for passwords. They picked up a lot of complexity on the way, and this post tries to give a chronological account of the development of the core of these technologies. Nothing here is secret; it's all described in various published standards. However, it can be challenging to read these standards and understand how it's meant to fit together. The beginning: U2F U2F stands for "Universal Second Factor". It was a pair of standards, one for computers to talk to small removable devices called security keys, and the second a JavaScript API for websites to use them. The first standard of the pair is also called the Client to Authenticator Protocol (CTAP1), and when the term "U2F" is used in isolation, it usually refers to that. The JavaScript API, now obsolete, was generally referred to as the "U2F API". The goal of U2F was to eliminate "bearer tokens" in user authentication. A "bearer token" is a term of art in authentication that refers to any secret that is passed around to prove identity. A password is the most common example of such a secret. It's a bearer token because you prove who you are by disclosing it, on the assumption that nobody else knows the secret. Passwords are not the only bearer tokens involved in computer security by a long way--the infamous cookies that all web users are constantly bothered about are another example. But U2F was focused on user authentication, while cookies identify computers, so U2F was primarily trying to augment passwords. The problem with bearer tokens is that to use them, you have to disclose them. And knowledge of the token is how you prove your identity. So every time you prove your identity, you are handing another entity the power to impersonate you. Hopefully, the other entity is the intended counterparty and