Educated Guesswork

How not to mandate device-based age assurance

2026-03-29T23:25:36Z

Over the past several years, quite a few jurisdictions have started to require age assurance for access to various forms of content and experiences. In most current cases, this amounts to a mandate on the service (PornHub, Facebook, etc.), but understandably this isn't popular with services, who have in some cases been advocating to move requirements from the service to the device. A number of jurisdictions have recently passed legislation requiring device-based age assurance, including California AB 1043, Texas SB2420, and Utah SB 142. (see this report from the Knight-Georgetown Institute (KGI) by Zander Arnao, Alissa Cooper, and myself for the bigger picture on age assurance). While device-based age assurance can be made to work and has some technical advantages, actually writing requirements that don't undesirable side effects is a lot harder than it looks, as we'll be seeing in the remainder of this post.

Types of Device-Based Age Assurance #

Age assurance systems comprise two main technical components:

Evaluating the user's age
Enforcing that the user is only able to access content and experiences approved for their age.

To a great degree, these components are orthogonal: it doesn't how you established the user's age mostly doesn't really matter that much to how you enforce it. Broadly speaking, these there are a number of ways enforcement can work. In this post we'll be looking at systems where (mostly) the evaluation and enforcement happen on the user's device. As I said, most current age assurance systems do both evaluation and enforcement at the service level, so this is something new, and there's quite a bit of variation in the various ideas, in part because it's new and in part because I think there actually are a lot more options for how to do on-device enforcement.

At a high-level, there are three main ways to do device-based enforcement.

Devices can attempt to filter out unwanted content on their own.
Devices can refuse to install and/or run apps (programs) which are rated for an age range other than that of the user (or, on some cases, are approved by parents).
Devices can provide an API that apps can use to determine the user's age range and then take appropriate action.

The first of these approaches doesn't really work well, for reasons we'll get into below. The second is obviously attractive because it takes all the load off of the apps, but it doesn't work well for apps which provide both restricted and unrestricted content and experiences. The obvious example of this type of app is a Web browser, which can browse porn sites but also totally unrestricted sites, but you could have a similar situation with an app like Facebook if there were restrictions on what content and experiences it could provide to minors. For example, the New York SAFE for Kids act, is a service-based age assurance requirement that restricts using algorithmic recommendation systems for children, but one could easily imagine this kind of restriction being levied at the device level. In these cases, enforcement has to happen in the app—or on the service it is the front-end for—because it's the app that knows whether a specific type of experience is restricted.

Enforcement by Apps #

The figure below shows the two main ways for app-level enforcement of the correct experience, namely in the app and on the service provider.

Device-based age assurance architecture. Source: Rescorla, Arnao, and Cooper 2026. Original figure by Kate Hudson.

The first option, in shown the top diagram, is that the service provider labels content and experiences with age ratings and let the app determine what experience to give the user. The second option, shown in the bottom diagram, is that the app sends the service provider the user's age—or more likely which age range they are in—and the service provider provides the correct experience. In the case of regular mobile apps where the service provider operates both the app and the server, (e.g., Facebook), the distinction between these two architectures is basically an internal implementation choice; the service provider can break up functionality any way it wants, just as with other functionality.

However, in the case of the Web, it does matter because the browser and the site are in general operated by different entities and so there needs to be some protocol they use to provide age enforcement, and so that needs to be written down. In principle, either architecture is possible, and each has pros and cons (see our report for more on this), but the most mature mechanism in this area is for the server to indicate "adult" content to the client using the Restricted To Adults label, which is already widely used by adult Web sites.

Types of Regulation #

With the help of Gemini Deep Research, I was able to identity the following possibly non-exhaustive list of legislation and proposed legislation^[1] for device-based age assurance in the US.

Jurisdiction	Status
United States Federal (H.R. 3149)	Proposed
Texas (SB 2420)	Enacted (Under Injunction)
Utah (SB 142)	Enacted
Utah (SB 104)	Enacted
Louisiana (HB 570)	Enacted
California (AB 1043)	Enacted
Alabama (HB 161)	Enacted
Alaska (HB 46)	Proposed
Kansas (SB 372)	Proposed
Florida (SB 1722)	Proposed (Died in committee)
Idaho (SB 1158)	Proposed (Died in Committee)
Illinois (SB 3977)	Proposed
Michigan (SB 284)	Proposed
New York (SB S8102A)	Proposed
South Carolina (H.4689)	Proposed
Colorado (SB 26-051)	Proposed

There's a fair bit of overlap in these rules (its not uncommon for legislators to start with "model legislation" produced by some external party), but there are also a lot of variation, including:

Whether the user is required to demonstrate their age or whether the device just asks them for it.
Who the requirements are levied on (manufacturers, OS providers, app stores, etc.)
Whether app store downloads are restricted.
What developers are required to do if they learn that a user is a minor.
Whether restrictions apply to desktop or just mobile.

This also provides us with some good examples of how these regulations can be written in ways that are likely to be ineffective or problematic.

Device-Level Filtering #

Several of these mandates require that the device itself filter content. Here's Utah SB 104:

All devices activated in the state shall: (1) contain a filter; (2) ask the user to provide the user's age during activation and account set-up; (3) automatically enable the filter when the user is a minor based on the age provided by the user as described in Subsection (2); (4) allow a password to be established for the filter; (5) notify the user of the device when the filter blocks the device from accessing a website; and (6) allow a non-minor user who has a password the option to deactivate and re-activate the filter.

And here's South Carolina's H.4689 (not enacted):

(1) contain a filter; (2) determine the age of the user during activation and account set-up; (3) set the filter to "on" for minor users; (4) allow a password to be established for the filter; (5) notify the user of the device when the filter blocks the device from accessing a website; and (6) give the user with a password the opportunity to deactivate and reactivate the filter.

The general idea here is supposed to be that it applies to all uses of the platform, no matter what software the user using. It's understandable why one would want this, but the tricky bit is the definition of filter. Here's the definition from South Carolina:

(3) "Filter" means software installed on a device that is capable of preventing the device from accessing or displaying obscene material as defined by Section 16-15-305 through Internet browsers or search engines via mobile data networks, wired Internet networks, and wireless Internet networks.

Read literally this is a real problem because we don't actually know how to implement it. There are two main potential approaches to Internet filtering:

Have a list of sites which are known or believe to host restricted material and which are filtered by the browser.
Attempt to detect restricted content (e.g., via some AI nudity classifier) and refuse to show it.

Neither of these approaches is great. List-based systems are a common feature of existing parental control systems and of institutional controls systems (e.g., in schools). The available evidence is that they don't work very well, and have problems both with overblocking (blocking content that shouldn't be restricted) and underblocking (failing to block content that should be restricted). Obviously, what should and shouldn't be restricted is a bit of a judgement call, but this is inherently a hard problem.

Even if it were possible to accurately mechanically distinguish between "obscene" and "non-obscene" material, it's not really practical for a single piece of software to "prevent the device from accessing" that material. A computing device isn't a single monolithic thing but a collection of different pieces of software—including software written by other people than the device manufacturer and installed by the user—and it's not generically practical to prevent such software from displaying "obscene material" if that software doesn't want you to.

Instead, typical existing device-based filtering mechanisms work by restricting what network connections you can make. This is to some extent effective but increasingly less so as client software adopts technologies like DNS over HTTPS and Encrypted Client Hello that are designed to conceal activity from the network and also do so to some extent from the machine. This isn't to say it's not possible to supervise some of the behavior of software, but not well if they are trying to evade it. Therefore, the effectiveness of that supervision is going to be limited unless the operating system also restricts what you can install. If I were an operating system vendor, I would be quite concerned about my ability to comply with this provision.

The Utah text is better in this respect:

(3) "Filter" means generally accepted and commercially reasonable software used on a device that is capable of preventing the device from accessing or displaying obscene material through Internet browsers or search engines owned or controlled by the manufacturer in accordance with prevailing industry standards including blocking known websites linked to obscene content via mobile data networks, wired Internet networks, and wireless Internet networks.

As noted above, your options as an operating system vendor are a bit limited, but the "generally accepted and commercially reasonable" language suggests you probably don't need to do anything beyond the normal types of filtering. As I said, they're not great in terms of effectiveness, but that's not your problem as the OS vendor who just wants to be in compliance with the law. Moreover, the restriction to "Internet browsers or search engines owned or controlled by the manufacturer" means that you don't have to make third party software conform, which makes the job a lot easier.

On the other hand, this also means that it's not likely to be effective because users can just download software that bypasses the filtering.

Alternative Approaches #

I don't think this text can really be salvaged. It's just not that practical to require the device to be responsible for ensuring that users aren't able to view any contraband material. It's more practical to require that applications do some filtering, with the exception of Web browsers, which face many of the the same challenges in doing unilateral filtering of websites that devices have in constraining applications.

Including Open Source Operating Systems #

A number of these regulations require that the operating system vendor participate in age assurance. For example, here's the relevant text from CA AB 1043.

(f) “Covered manufacturer” means a person who is a manufacturer of a device, an operating system for a device, or a covered application store.

...

(a) A covered manufacturer shall do all of the following: (1) Provide an accessible interface for requiring account holders at account setup that requires an account holder to indicate the birth date, age, or both, of the user of that device for the sole purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.

The basic problem here is that the definition of "covered manufacturer" is very broad. It clearly covers all operating systems, including open source operating systems like Linux. What's less clear is who it applies to in those cases. For example, if you're a contributor on an Open Source project like Debian are you personally responsible for making sure your software does this stuff? Some developers, such as the MidnightBSD operating system and even the DB48X calculator software^[2] have added restrictions forbidding use in California.

The Illinois language is even scarier in that it explicitly calls out individuals:

"Operating system provider" means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

This article from LinuxTeck does a good job of covering the issues here and how various entities are responding to California AB 1043 and how the Open Source organizations failed to intervene before the law was passed, with the result that the text is concerningly overbroad.

Alternative Approaches #

This all seems pretty undesirable, but it's also somewhat tricky to figure out how where to draw the line. Plainly you don't want individual developers who work on iOS to somehow be responsible for whether Apple does age assurance, so for commercial operating systems, you could probably make clear that the requirement is on the vendor rather than on the user. The situation is a lot less clear for open source operating systems. In some cases, such as Debian, a Linux distro will be backed by some nonprofit, or in other cases, such as Ubuntu, by a company. In both of these cases one could imagine levying the restriction on that entity. The situation seems less clear for some other distros like Linux Mint.^[3] Even then, you have to worry about whether those distros can effectively comply for versions of the operating system that have already shipped (see the next two sections).

Effectiveness Date #

Most of these mandates require the app store provider, OS provider, manufacturer, or app developer respectively to do things immediately effective on the effectiveness date of the mandate. This isn't necessarily a problem in cases where the user's interaction with the regulated entity is online, but that isn't always the case. For example, making an account with the iOS app store or the Google Play Ready store is an inherently interactive activity and so Apple or Google can enforce the new rules for new accounts or potentially for existing accounts when users choose to download a new app.

The situation is much less straightforward when the new requirements are implemented by software on the user's machine which therefore must be updated to take effect. Even on systems which auto-update, updates can take a very long time to roll out. For example, the figure below shows the fraction of Android versions over time.

Android versions over time. Source AppBrain.

As you can see, Android 9.0 still has 4% market share, even though it was released in 2018 and hasn't received security updates since 2022. Collectively, over 40% of the Android ecosystem is on versions that aren't receiving security updates. In many cases, this is because users aren't updating or third party vendors aren't providing updated firmware. In any case, it's not clear how Google could as a practical matter make those devices implement new age range APIs. The situation is better on iOS, but there are still plenty of people who haven't update their iPhones and iPads.

Mobile devices phones are actually the best case scenario because (1) they were often designed with auto-update in mind and (2) people overwhelmingly get their apps through the app store. Many desktop apps don't have any kind of auto-update functionality, and so it's not clear how an app vendor would conform to requirements to implement new behavior.

Alternative Approaches #

This issue is actually comparatively easy to fix by simply requiring the new behavior on any substantial update (e.g., not just security fixes) to the system. This isn't quite as satisfying, but the most important devices from the perspective of managing minor's access are going to be getting regular updates or just eventually replaced, and so the end result will be good coverage in relatively short order.

Geographic Scope and Location Ambiguity #

For obvious reasons, the scope of these restrictions is typically limited to the jurisdiction requiring them. For instance, Utah's SB142 applies when "an individual who is located in the state" and California's AB1043 refers to an Account Holder, who is "an individual who is at least 18 years of age or a parent or legal guardian of a user who is under 18 years of age in the state." Implementing these mandates correctly obviously depends on knowing which jurisdiction this device is in. This is not always straightforward.

There are four main ways of determining a device's location:

Via GPS or other satellite-based location systems (e.g., GLONASS, Galileo, etc.)
By measuring the distance from in-range mobile phone towers.
By looking at the local WiFi environment (e.g., which WiFi access points are in range).
Via IP geolocation.

However, not all of these will always be available.

Typically, mobile devices will perform some sort of sensor fusion to estimate the location based on the available signals. For obvious reasons, mobile phones need to be able to see local mobile towers and most mobile phones now have GPS, so it's typically straightforward for the device operating system to determine where it is. By contrast, only some tablets have mobile connectivity and/or GPS chips, and ones that do not will have to fall back to the other two methods. This isn't necessarily a problem because WiFi-based geolocation can be quite accurate, depending on the WiFi environment. The situation is even worse on desktop. Most desktop devices don't have mobile connections or GPS at all, and so you're stuck with Wi-Fi and IP addressed based location.

Importantly, just because the device knows where it is that does not mean that apps know where they are. Because location information can be sensitive, modern operating systems require user permission before sharing the user's location with the app. Many apps do not need location for their current functions and for obvious reasons Google and Apple discourage asking for excessive permissions. As a result, only around half of apps have location permissions. Apps which do not have location permissions have two main choices:

Ask for location permissions
Use IP-based geolocation only.

Neither of these is great. From the user's perspective, having app unnecessarily ask for location isn't great for privacy, especially as the user has no way of knowing whether the app is exfiltrating the data. It's also not great from app's perspective because it makes users suspicious ("why does my calculator want my location?"), and in fact this kind of excessive permission ask is one of the signals that an app is doing some kind of suspicious user tracking.

IP-based geolocation doesn't require the user to provide permission because the app can observe the IP address itself without help from the operating system. The good news is that there are free IP location databases which can be downloaded and will get you resolution down to the city level. The bad news is that they are updated frequently, so you either need to run some kind of geolocation service or push the updated database to the client for resolution. Moreover, it's likely the user's device is behind a NAT. and doesn't know its own IP address so you have to use some external server to resolve the IP address. Note that this applies even to apps which otherwise wouldn't "phone home" at all, so now you're effectively tracking the location of users!

Alternative Approaches #

The bottom line here is that while the operating system generally will be able to determine where a device is with some level of resolution, the situation is much worse for apps, many of will have to ask for otherwise unnecessary permissions or do substantial extra work in order to get the user's location; either of these choices also comes at a potential increased risk to user privacy. As we suggest in our report, it would be a lot easier for apps if the age range APIs that these mandates already make the operating system offer also provided the jurisdiction at a coarse level (e.g., the state) so that the app could enforce the appropriate policy. Even so, it is likely that both the OS and the apps will occasionally get the answer wrong (consider the case of a device which must use IP geolocation and is located near a state border) and so these mandates probably should contain some text about "commercially reasonable" attempts to verify location.

Including Irrelevant Apps #

As noted above, quite a few of these mandates have a structure where the platform determines—or sometimes just collects—the user's age and then provides it to apps via an API, which developers are required to use. Unfortunately, in many cases all apps are required to request the user's age even if there's nothing meaningful for them to do with it. Here's some language from Utah SB 142:

(8) "Developer" means a person that owns or controls an app made available through an 73 app store in the state.

...

(1) A developer shall: (a) verify through the app store's data sharing methods: (i) the age category of users located in the state; and (ii) for a minor account, whether verifiable parental consent has been obtained; (b) notify app store providers of a significant change to the app; (c) use age category data received from an app store or any other entity only to: (i) enforce age-related restrictions and protections; (ii) ensure compliance with applicable laws and regulations; or

And here is New York S8102A:

"COVERED DEVELOPER" SHALL MEAN A PERSON WHO OWNS OR CONTROLS A WEBSITE, ONLINE SERVICE, ONLINE APPLICATION, MOBILE APPLICATION, OR PORTION THEREOF THAT IS ACCESSED BY A USER IN THE STATE OF NEW YORK.

...

§ 1542. OBLIGATIONS FOR COVERED DEVELOPERS. 1. ALL COVERED DEVELOPERS SHALL REQUEST AN AGE CATEGORY SIGNAL FOR A USER FROM A COVERED MANUFACTURER WHEN SUCH USER DOWNLOADS AND LAUNCHES SUCH DEVELOPER'S WEBSITE, SERVICE, OR APPLICATION. 2. IF THE SIGNAL INDICATES THAT A USER IS A COVERED MINOR, THEN SUCH COVERED DEVELOPER SHALL TREAT SUCH SIGNAL AS AN AUTHORITATIVE INDICATOR OF SUCH USER'S AGE FOR THE PURPOSES OF COMPLIANCE WITH ANY APPLICABLE LAW AND THE COVERED DEVELOPER SHALL BE DEEMED TO HAVE ACTUAL KNOWLEDGE THAT A USER IS A COVERED MINOR ACROSS ALL PLATFORMS AND POINTS OF ACCESS S. 8102

We'll get to the "WEBSITE" part of this later, but notice that this means that if you offer any kind of app, even one which doesn't collect any user data and which doesn't have any kind of restricted content, you still are required to query the platform for the user's age. This goes for calculator apps, weather apps, etc. There are two obvious problems here, one from the perspective of the user and one from the perspective of the developer.

From the perspective of the user, this requirement creates unnecessary leakage of sensitive information—i.e., the user's age bracket—from the platform to the app. This is the kind of information that under normal circumstances that we would want platform to put behind a consent dialog, but in this case all apps are going to request it as a matter of course.

From the perspective of a developer, this means that everyone has to adjust their apps to request the user's age, even if they don't do anything with the information. For instance, if you're a calculator app, you don't need to know the user's age because the app doesn't behave any differently for children.^[4] This is obviously a huge imposition on developers, who may not even be aware of these new regulations, which, of course, differ from jurisdiction to jurisdiction, and very likely many developers will unknowingly be in violation of these rules.

Many of these mandates are tied to app stores, or in some cases specifically to mobile devices, but for those that aren't, such as CA AB1043, the problem is much worse, for several reasons:

There's no central app store backing you up.: In principle the iOS and Android app stores could verify compliance or at least that apps call the APIs (though I don't know that they do).
It's a lot less clear what a desktop application is.: There are of course applications that people can download, such as Microsoft Word, but there's lots of software you can download that has some command line interface but isn't really an end-user app. For example, are the node.js^[5] JavaScript runtime or the LaTeX typesetting systems required to query for your age?

There are a lot of open source apps with no real connection to the jurisdiction. Suppose that I write an app and put it up on GitHub. Am I now liable when some Linux distribution makes it available to their users, even if I had nothing to do with it at all at all?

Parental Monitoring Features #

Although some of these mandates mostly require that apps query for the user's age range and then have minimal requirements on what they do with it, a number require apps to provide parental control and monitoring features, even when those features are not really sensible for the app in question. For example, here is Alaska HB 46:

(c) A developer shall provide readily accessible features for a parent of a minor located in the state to implement time restrictions on using the developer's app, including allowing the parent to view metrics reflecting the amount of time the minor is using the app and setting daily time limits on the minor's use of the app.

So this means that if I make a calculator app, I need to build a whole system for implementing parental control metrics and daily time limits! Aside from this being a burden on developers, it also introduces a whole new set of privacy risks because it now requires developers to monitor usage on a per-user basis, store that usage information, and make it accessible to parents.

Even if we ignore whether it's a good idea for parents to be able to track and control the usage of every app on the user's device, this is a significant privacy regression in other ways, especially if it's not done carefully: for example if you just have the app phone home whenever it's used, then it becomes a tracking system because the developer gets to see the user's IP address and potentially use it to roughly geolocate them. It's also likely that many developers will just decide to use some third party SDK or even a third party service to provide this function, which creates its own privacy risks, both because it allows that entity to track the user and because many of those SDKs have bad security and privacy practices, whether intentionally or unintentionally.

Alternative Approaches #

The basic problem here is the requirement that every app query the user's age information without regard to the properties of the app and whether it will do anything with the information. An alternative here would be to require apps to request that information only if their behavior would change as a result.

For example, in the case of New York S8102A, the information is intended to be an "authoritative indicator" of the user's age that gives the developer "actual knowledge that the user is a covered minor", which is presumably intended to hook into other statutes such as the SAFE For Kids Act that have substantive requirements for how the app behaves (e.g., not showing behavioral ads). The statute could instead be written to require the apps to either:

Conform to those substantive requirements for all users.
Query for the user's age range and conform to those substantive requirements for minors.

You might need some legal cleverness to make this work with the existing laws that depend on "actual knowledge" of minor status, for instance by reading all those places as "actual knowledge or failure to query the platform where possible", but this seems like it's at least a potential alternative avenue.

Requiring Web Support #

Several of these proposals also place requirements on the Web. Recalling the New York text from above, a "covered developer", which includes a person who "owns or controls a website" is required to " request an age category signal for a user from a covered manufacturer when such user downloads and launches such developer's website, service, or application". You don't usually download a website, but you might launch one, and in this case the website would be required to request an age category signal.

There isn't any standard for what this signal would look like, but in the context of an operating system, we'd expect the OS to provide an API that the app would call. These APIs might differ between operating systems, but the developer has to do some work to port their app to a different operating system anyway, and that work could involve using the correct API.

In the context of the Web, we'd either expect a standardized header from the browser or a standardized Web API that the browser would implement, but neither of these exists, so it's not clear what the site is supposed to do. Worse yet, the requirements in these mandates to provide signals are on the app store or the operating system, but in this case the requirement needs to be on the browser, which first needs to query the OS for the signal and then provide it to the site. As nothing requires them to do so, it's not clear what the site is expected to do.

Technical Fixes #

These are technical problems that are partly fixable, but not really immediately. First, there needs to be some widely understood mechanism for sites to request an age category signal from the browser. Without that, sites won't know what to do and there is a risk that even browsers which do provide an age category signal might do so in incompatible ways. Technically it's probably not that hard to design something here, although it's also not necessarily as easy as it sounds, and standardization takes time. In principle, each jurisdiction could define their own signal, but this is obviously very painful for developers. Once such a signal is defined, you would then need to require that browsers support it. This is comparatively easy, as you're just proxying whatever the operating system says.

Who is responsible for signals? #

The majority of the mandates which involve developers receiving and processing an age category signal require the developer to request it. However, the Michigan SB284 text is unusual in that it only seems to require them to process it if they have it:

Sec. 5. (1) A covered manufacturer shall take commercially reasonable and technically feasible steps to do all of the following:

(a) On activation of a device, determine or estimate the age of the device's user or users.

(b) Using an application programming interface, provide an application store, website, application, and online service with a digital signal regarding the age of the device's user or users, specifically whether the user is any of the following:

...

Sec. 7. (1) A website, application, or online service that makes mature content available must do all of the following:

(a) Recognize and allow the receipt of a digital age signal from a covered manufacturer.

(b) If the website, application, or online service knowingly makes available a substantial portion of mature content, block access to the website, application, or online service if a digital age signal is received under section 5(1) that indicates an individual is not 18 years of age or older.

(c) If the website, application, or online service knowingly makes available less than a substantial portion of mature content, do both of the following:

(i) Block access to known mature content if a digital age signal is received under section 5(1) that indicates an individual is not 18 years of age or older.

(ii) Provide a disclaimer to a user or visitor before displaying known mature content.

From a technologist's perspective, this text doesn't really make sense. Recall from the discussion of the Web case above, that there are two main options on the Web:

An unsolicited signal in an HTTP header
A Web API request from the server

This text doesn't really match either of these, because the manufacturer is supposed to provide the signal and the website is supposed to "recognize and allow the receipt of" it, all of which suggests that the manufacturer is intended to initiate the process. However, it also says that this is done "using an application programming interface", which would usually refer to something initiated by the Web site.^[6] Moreover, as above, we have the problem that the levy is on the manufacturer, but they can't necessarily ensure that third party Web browsers provide the signal.^[7]

The situation is equally if not more confusing for an "application, or online service". Applications make API queries to the operating system, not the other way around: if operating systems want to convey unsolicited information to applications they do it with environment variables, command line arguments, etc. I don't even know what it means for an online service to receive this information except via an app or a Web browser, so this text seems superfluous.

Alternative Approaches #

This just seems like confusing drafting. This text could readily be replaced with text that required:

The manufacturer to provide the API
Applications to call the API.
Web browsers to supply a Web API
Web sites to call the Web API

Checking Interval #

One of the privacy challenges with age-based enforcement mechanisms is that the user's birthday is inherently sensitive information. For this reason, age assurance mandates typically require the disclosure not of the user's precise age but rather of age categories (e.g., 13-16). However a consequence of using age ranges like this is that they interact poorly with the fact that people continue to age at a rate of one day per day and so some people who are under 18 today will be 18 tomorrow, etc. However, without knowing someone's birthday you can't know when they transition from one age category to another.

No Limits on Checking #

The obvious thing way to handle this is to just request the user's age whenever the user launches the app. However, this has the unfortunate side effect of the app likely eventually learning not only the user's precise age but their birthday if they observe the user being age N and N+1 on two consecutive days.^[8]

For this reason, you want to encourage if not require that sites request the user's age category less frequently than this.^[9] Many of these mandates do not have any restrictions in this area, with the result that we should expect sites to end up learning more than they need to about user's ages.

Too Infrequent Checking #

In order to address this issue, many of these mandates limit how frequently the device can query for the user's age category, typically to one per twelve months. Here's some typical text from Alabama HB 161:

(b) A developer may request age category data in any of the following scenarios: (1) No more than once during each 12-month period to verify either of the following: a. The accuracy of age category data associated with an account holder. b. Continued account use within the age category.

The problem with this text is that unless the developer queries the user's age category right on their birthday, there will be a period during which the developer is underestimating the user's age, with the average underestimate being 6 months (because there is basically an even chance of any day of the year with respect to their birthday). With this text—and the text of several other mandates—there's no way for the user to demonstrate that they are now in the correct age range.

Alternative Approaches #

This is a genuinely hard problem because of the need to balance user privacy against user's desire to access experiences consistent with their true age. Probably the best you can do here is to keep the the once-per-12-month restriction but add text which allows the user to request that the app re-request their age. Some of these mandates have some text that potentially could be construed this way, for instance "When there is reasonable suspicion of account transfer or misuse outside 15 the verified age category" in Utah SB142, but it's not really misuse in most cases if you give a 17 year old the 13-16 experience, so it would be good to have clarity.

Note that this issue also has technical implications for age category signals in the Web context: if you have a Web API, it can behave the same as the OS API,^[10] but if you have a header, the situation is somewhat more complicated because the browser is just sending the header with every request. At minimum the browser would need to remember when it initially sent the header and replay the same value until the minimum re-request period had expired, but then the site might still need an API to re-request in exceptional cases. All of this suggests that the header may not be the best approach.

Securely Establishing the User's Age #

In any setting where users of different ages get different experiences, some users in age group A will want to instead have the experience of age group B. How motivated they will be likely depends on how different those experiences are. Obviously, the level of motivation will also depend on users, but there is plenty of evidence that users will misstate their age in order to access social networking sites and we ought to assume the same is true for access to adult content and potentially for the ability to engage in "financial transactions" with sites. If the mechanisms for establishing age are readily circumvented, then they will not be effective in these cases.

The majority of these mandates require the operating system to conduct some form of age assurance which typically is interpreted to mean something beyond bare declaration. For instance, the NY bill would require "commercially reasonable age assurance", which the NY Office of the Attorney General's Notice of Proposed Rule Making for the SAFE For Kids Act interpreted as requiring a minimum level of resistance to circumvention, so we're talking about mechanisms like facial age estimation or requiring the user to show government issued ID. This topic is covered extensively in our KGI report, so I won't go over it in more detail here, but a number of these mandates don't require age assurance but just require that the user indicate their age (self-declaration) at account creation.^[11]

The general assumption in age assurance discussions is that self-declaration is insecure because the user can just lie about their age, and most existing age assurance mandates forbid it. However, those mandates are generally expected to be enforced on the Web server and the situation is somewhat different when age assurance is conducted on a device: if a parent purchases the device for their child and sets it up for them, they can set up the account with the child's correct age.^[12] Of course, if a child buys the device themselves, this won't work, and you need a real age assurance mechanism to prevent circumvention.

In order for this kind of mechanism to be effective, however, it needs to be "sticky" so that the minor can't reset the age setting and enter a new (false) age, for instance by resetting the device to a factory configuration and creating a new account. This is a standard feature of basically every consumer computing device^[13], but it needs to be disabled once the device has been configured in "child mode", otherwise circumvention is trivial. This is already a feature of some existing parental control modes for mobile devices (e.g., Apple Screen Time), but as far as I can tell none of these mandates require that manufacturers enable it when the user's entered age is under 18.

Moreover, desktop devices typically are not designed to prevent reinstallation; even those devices which have BIOS locking to prevent the installation of unauthorized operating systems are not designed to prevent the installation of a fresh copy of the operating system, thus reinitiating the date of birth entry. In principle, the OS vendor could perhaps store the entered DOB somewhere and reset it when the machine is reinstalled, but this isn't something any of these mandates require it to do and would have real technical challenges even on devices running commercial operating systems—e.g., MacOS or Windows—which have some sort of remote management capability; it's largely impractical on open source operating systems like Linux that don't centrally manage devices at all.

Alternative Approaches #

The problem here is created by the combination of (1) self-declaration and (2) the ability for minors to reset the device themselves. If real age assurance is required, reset isn't really an issue because the user will just be prompted for age assurance after reset. If reset isn't possible, then adults can set up the device with the child's age and the minor user won't be able to change it.

As a practical matter, this means that this kind of requirement likely won't be effective on desktop devices, but on mobile devices it can be made to work when paired with establishing some kind of passcode that is required to reset the device. This is conceptually somewhat like existing parental controls systems in that it depends on the parents to set up the device in child mode, though if they want to set it up without controls, it requires them to explicitly misrepresent the child's age rather than just decide not to enable parental controls.

The Bigger Picture #

The basic challenge here is that the high level desires embodied in this kind of legislation are very challenging to translate into technical requirements. This is especially true for device-based restrictions because the legislation is requiring the creation of new technology which doesn't exist yet; by contrast, while there are many laws requiring server-based age assurance, those laws mostly require the use of age assurance technologies which are already in wide use, and so it's reasonably well understood how to make them work.^[14]

With device-based mechanisms, legislation is effectively writing the product requirements document (PRD) for a new product, and as anyone who has worked in technology knows, those PRDs rarely survive contact with engineering reality, especially when they are written without extensive back and forth with the engineers who know what is and is not feasible. This is not to say that it's not possible to build systems that do what some of these mandates are trying to accomplish—for instance, getting the big mobile app stores to require parental consent for software download for minor users—but getting there without also creating requirements that are not practicable requires a deep understanding of the technology platforms being regulated and crafting language that is compatible with those engineering realities.

I'm not going to be rigorous about distinguishing between legislation that has been enacted (which might or might not yet be in effect) and that which is proposed. The points I'm trying to make don't depend on that. ↩︎
On the theory that they are providing an operating system. ↩︎
I want to recognize here that a lot of source people—including me—are uncomfortable with this kind of functionality living in an open source operating system at all, but that's a distinct question from whether this kind of approach is workable. ↩︎
Though I guess you might decide to stop them from entering the number 80085. ↩︎
Which may actually be both an app and an app store, because it comes with the npm package management system. ↩︎
There are, of course "Web APIs" which are provided by servers and initiated by clients, but that's usually not used by browsers but rather by other kinds of agents, and it's not clear how such an API would work, as you'd somehow need to define it and have every site implement it; the header would be the much more conventional design. ↩︎
On iOS in the US Apple requires third party browsers to use WebKit, so they could ensure it there, but that's not true on other operating systems, including Android. ↩︎
This kind of edge effect is a common problem for privacy mechanism which rely on deterministic buckets with hard threshholds. RFC6772 has a good discussion of this problem in the case of location. ↩︎
Note that California's AB1043 uses the phrase "downloaded and launched", which you might infer would require services to query every time the app is launched, but probably really is intended to mean the first time. ↩︎
As an aside, in both cases it would be good if the API enforced the frequency restrictions and potentially intermediated any exceptional requests for age ranges to ensure that the user really consented. ↩︎
Illinois SB3977 nominally required "age verification" but then the actual requirement of the act is just to provide an accessible interface at account setup that requires an account holder to indicate the birth date, age, or both, of the user of that device for purposes", so really it's just self-declaration. ↩︎
Of course, in practice we know that parents frequently assist their children in evading age assurance. How you feel about this will depend on whether you think decisions about what content and experiences minors can access should be up to parents or the government. ↩︎
Otherwise, how do you recover when it gets stuck? ↩︎
And even then, actually writing the mandates correctly can be very difficult, as exemplified by KGI's comments on the NY SAFE for Kids Act Proposed Rules. ↩︎

Let's build a tool-using agent

2026-03-06T00:00:00Z

At this point, if you haven't heard about "agentic AI", you haven't just been living under a rock but under a huge pile of rocks. However, even you have heard of agentic AI, you may also have only some idea of what it actually means. If so, you've come to the right place. In this post we're going to build a simple tool-using AI agent and try to get some sense of what it's actually doing.

Here's a typical definition of agentic AI, from IBM:

Agentic AI builds on generative AI (gen AI) techniques by using large language models (LLMs) to function in dynamic environments. While generative models focus on creating content based on learned patterns, agentic AI extends this capability by applying generative outputs toward specific goals. A generative AI model like OpenAI’s ChatGPT might produce text, images or code, but an agentic AI system can use that generated content to complete complex tasks autonomously by calling external tools. Agents can, for example, not only tell you the best time to climb Mt. Everest given your work schedule, it can also book you a flight and a hotel.

In other words, agentic AI doesn't just talk to you but can have side effects in the real world. For instance, you might ask it to book travel for you, do some web searching, send emails, etc. The interesting question here is how.

The first thing to understand is that a large language model (LLM) is what it says on the tin: a language model, which means that it operates at the level of text. At a high level, an LLM takes in a string of text (the prompt) and then emits some other text (the response). It's common to talk about this as an autocomplete or predictive system where the LLM emits the most likely text to come after the prompt, but for our purposes, it doesn't matter: the important thing is that the LLM just manipulates text. Everything we're going to do in this post is downstream of that fact.

Preliminaries #

AI models can either be local (running on your machine or a machine you control) or hosted (running on infrastructure operated by the model provider). In general, the hosted models are a lot more capable and require a lot of compute power, but you can still get fairly far with a local model if you just want to do simple stuff. In a local model, you can provide input to the model directly, but for a hosted model you need to use some interface provided by the model provider. For interactive use, this is often some kind of chat interface, such as ChatGPT, but for programmatic use model providers give you some kind of HTTP API. These APIs are conceptually similar but subtly different, so you need to write your app slightly differently for each platform.

Although you can access local models directly as a practical matter what's convenient is to use something like Ollama, which is an engine that allows you to run a large number of models—and actually knows how to automatically download^[1] them—and also provides a common HTTP API which you can use just as you would a model provider's API. We'll be writing our examples using Ollama so that they can work with local models—thus allowing us to do some internal instrumentation—but Ollama can also bridge to the APIs for big model providers, so we can use the same code with Gemini, Claude, etc, allowing us to demonstrate things with better models.

In practice, you would usually not talk to the HTTP API directly, but instead download some local library (e.g., ollama-js) which takes care of the HTTP API mechanics. In this case, however, I want to be able to show what's actually happening, so we're going to be writing to the API directly, using the built-in nodejs fetch API. To do this, we're going to have a trivial JS API client, shown below.

import fetch from "node-fetch";

const server_url = "http://localhost:11434";
const g_chat_url = `${server_url}/api/chat`;
const g_model = process.env.AGENT_MODEL || "mistral-small";

export async function ChatApi({
  endpoint_url = g_chat_url,
  model = g_model,
  tools = [],
} = {}) {
  const verbose = !!process.env.VERBOSE;
  async function complete(messages) {
    const body = {
      model: model,
      stream: false,
      tools,
      messages,
    };

    if (verbose) {
      console.log("REQUEST:", JSON.stringify(body, null, 2));
    }

    const response = await fetch(endpoint_url, {
      method: "POST",
      body: JSON.stringify(body),
    });

    const json = await response.json();

    if (verbose) {
      console.log("RESPONSE:", JSON.stringify(json, null, 2));
    }

    return json.message;
  }

  return {
    complete,
  };
}

Trivial HTTP API client

A Simple Chatbot #

We're going to warm up by build a simple chatbot, which is comparatively trivial ^[2] given this kind of model. We just need to connecting it up some interface that reads text from the user and sends it to the model, as shown in the diagram below.

A simple chatbot architecture

We can then write a trivial chatbot like so.

import { ChatApi } from "./api.js";
import { Chat } from "./chat-framework.js";

const api = await ChatApi();

async function handler(line) {
  const result = await api.complete([{ role: "user", content: line }]);
  return result.content;
}

Chat(handler);

Trivial chatbot code

Note that this code makes use of a chat framework^[3] that just loops around input and passes the results to the handler function shown here. This lets us handle stuff like reading from the terminal and/or opening the input all in one place so you can focus on the main code.

Anyway, here's an example interaction.

>>> Hello
Hello! How can I assist you today?

So far so good, but now try to have a conversation. For example:

>>> My shirt is blue
That's a nice color! Do you need help with something related to your shirt, or would you like to talk about something else?
>>> What color is my shirt?
I don't have the ability to see or know what you're wearing right now. Could you please provide more context or clarify your question?

WTF? I just told you the color of my shirt.

What's going on is that the model itself is stateless: it just takes in a string of input and produces output, so as far as the model is concerned when I asked about my shirt color, this is the first thing I said. If we want to have a conversation, I actually need to play back the entire conversation with each request to the API. We do this by keeping a context variable which is just the list of all the things that we've said to the LLM as well as the things it said back to us, as seen in:

import { ChatApi } from "./api.js";
import { Chat } from "./chat-framework.js";

let context = [];

const api = await ChatApi();

async function handler(line) {
  context.push({ role: "user", content: line });
  const result = await api.complete(context);
  context.push(result);
  return result.content;
}

Chat(handler);

You'll notice that each entry in the context contains a role parameter, which helps the model keep straight who said what. Now when we run this, we get the right answer.

>>> My shirt is blue
That's a nice color! Do you need help with something related to your shirt, or would you like to talk about something else?
>>> What color is my shirt?
You told me that your shirt is blue. Is there anything specific you would like to know or do regarding your shirt?

Congratulations, we now have a primitive but functional chatbot.

Tool calling #

What we've built so far is just a brain in a vat: we can feed it text and it responds with other text, but it can't do anything that has side effects. That's all great, but the examples we gave above (booking travel, etc.) require the ability to do things out in the world—or at least on the Internet—so we need to enable that somehow. The way this is done is by giving the LLM something called a "tool". LLM tools are kind of like API calls in traditional programming languages: they are functions that let the LLM do something.

Using tools with an LLM is conceptually simple:

The wrapper code tells the LLM about the tool by adding the tool definition to the context.
The LLM invokes the tool by putting tool-specific instructions in the output.
The wrapper code detects the tool-specific instructions in the output and invokes the tool.
The wrapper code takes the tool result and passes it to the LLM as part of the context.

Tool Definitions #

The tool definition is basically just a JSON expression, like so:

{
  name: "read_temperature",
  parameters: {
    type: "object",
    properties: {
      location: {
        type: "string",
        description: "The room name",
      },
    },
    required: ["location"],
  },
  description: "Return the room temperature in degrees Celsius",
}

This should be reasonably self-explanatory, but just in case:

name:: The name of the tool itself (in this case print_message).
description:: A text description of the tool's behavior
parameters:: The arguments to the tool

Think about the tool definition as API documentation for the LLM: it tells it about the tool, what it does, and how to call it. The description field is just freeform text which is assimilated by the model. The easiest way to think about this is that the LLM reads the documentation just like a programmer would and then picks the right tool(s) for the job based on your instructions.

Model Calls Tool #

In order to call the tool, the model provides a response that has the information about the tool to call text. For instance:

{
  "id": "call_5wrxuo5r",
  "function": {
    "index": 0,
    "name": "read_temperature",
    "arguments": {
      "location": "living room"
    }
  }
}

This says exactly what you think it says, namely "I would like to call the tool get_temperature with the location argument being living_room But of course, this doesn't have any effect on its own; it's just some text the model spits out that is asking the agent wrapper to call the tool.

Tool Execution #

The way that the tool actually gets called is that the wrapper code detects that the model's output is actually a tool call and calls the tool rather than printing the output (or whatever it would ordinarily do with it). In other words, you need to update the agent wrapper code to be something like this:

import { ChatApi } from "./api.js";
import { Chat } from "./chat-framework.js";
import { Tools } from "./tools.js";

let context = [];

function call_tool(call) {
  if (Tools.implementations[call.name]) {
    console.log(
      `+++ Calling tool '${call.name}' with arguments ${JSON.stringify(call.arguments)}`,
    );
    const result = Tools.implementations[call.name](call.arguments);
    console.log(`--> ${JSON.stringify(result)}`);
    return result;
  } else {
    throw new Error(`Missing tool ${call.name}`);
  }
}

const api = await ChatApi({ tools: Tools.definitions });

async function handler(line) {
  context.push({ role: "user", content: line });
  let response = null;

  for (;;) {
    response = await api.complete(context);
    if (!response.tool_calls?.length) {
      break;
    }

    context.push(response.tool_calls[0]);

    const tool_result = call_tool(response.tool_calls[0]["function"]);

    context.push({
      role: "tool",
      id: response.tool_calls[0].id,
      content: tool_result,
    });
  }

  context.push(response);
  return response.content;
}

Chat(handler);

This code is comparatively simple, but let's work through it in pieces. Whenever we send a request to the model API, we can get one of two responses:

The response can contain a text response (the messages field is populated.)
The response can contain a tool call (the tool_calls field is populated.)

In the first case, we just display the response to the user and then read the user's next input, just as with our original chatbot code.

What's new here is the tool call request. In this case, we don't want to display the result to the user, but instead intercept the response and call the appropriate tool. Handily, the tools are named, so we can just look up the appropriate implementation by name and call it. Once we have the response, we can add it to the context and call the completion API again. Here's a simple exchange:

User> Use the available tools to find out the current temperature.
+++ Calling tool 'read_temperature' with arguments {"location":"living room"}
--> "25"
Agent> The current temperature is 25°C.

If you look closely, you'll notice something interesting. I never told the model which room I wanted it to get the temperature for; it just hallucinated "living room". This behavior is actually nondeterministic and model dependent (I'm using (mistral-small.) Some fraction of the time, the model actually refuses to give me an answer and instead asks what room I want:

User> Use the available tools to find out the current temperature.
Agent> Sure, I can help with that. Could you please specify which room's temperature you would like to know?

Providing the response works exactly as you'd expect, with our agent providing the following context:

  [
    {
      "role": "user",
      "content": "Use the available tools to find out the current temperature."
    },
    {
      "id": "call_5wrxuo5r",
      "function": {
        "index": 0,
        "name": "read_temperature",
        "arguments": {
          "location": "living room"
        }
      }
    },
    {
      "role": "tool",
      "id": "call_5wrxuo5r",
      "content": "25"
    }
  ]

As you can see, the context here includes everything that has happened so far, namely:

My request for temperature
The tool call request from the agent
The response from the tool

Just as before, the model is stateless, so if we don't remind it that it called a tool, it doesn't have any context for what the answer "25" is.

The key point here is that all the tool action happens in the wrapper code. The LLM has no idea how the tool works; it just knows whatever the wrapper told it about what each tool does and then whatever the wrapper says the tool did. And in fact, my implementation of get_temperature isn't attached to a thermometer or some kind of temperature API and doesn't have any idea what the temperature is, it's just returning the fixed value 25.

Notice also that the agent wrapper doesn't really know anything about the tools either, it's just importing the list of tools from tools.js, passing the descriptions to the model and invoking the appropriate tool. All you need to do to add another tool is add it tools.js.

Multi-Round Tool Execution #

Our wrapper code will keep looping until the model returns some response, so this means we can have multiple rounds of tool execution. So, for instance, we can have a simple thermostat which turns on the heat if we are below some target temperature.

To do this, we first need to give the model a new turn_on_heat tool.

{
    name: "turn_on_heat",
    parameters: {
      type: "object",
      properties: {
        location: {
          type: "string",
          description: "The room name",
        },
      },
      required: ["location"],
    },
    description: "Turn on the heat",
  },
}

This is implemented as:

    turn_on_heat: () => {
      {
        return "The heat is now on";
      }
    }

Then with the right instructions...

User> Use the available tools to find out the current temperature in the living room and use the right tool to turn on the heat if it is under 40 Celsius.
+++ Calling tool 'read_temperature' with arguments {"location":"living room"}
--> "25"
+++ Calling tool 'turn_on_heat' with arguments {}
--> "The heat is now on"
Agent> The current temperature in the living room is 25°C, which is below 40°C. I have turned on the heat for you.

You might notice that my instructions here are pretty verbose, and in particular that I'm telling it to use the tool to turn on the heat. What's going on here is that I'm fighting with the model: mistral-small only has about 20B parameters and so it's not really smart enough to figure things out if you're not super explicit. Here's what happened if I didn't tell it that it had a tool to turn on the heat:

User> Use the available tools to find out the current temperature in the living room and turn on the heat if it is under 40 Celsius.
+++ Calling tool 'read_temperature' with arguments {"location":"living room"}
--> "25"
Agent> I don't have access to real-time data or the ability to control physical devices like thermostats. However, I can guide you through the process of checking the temperature and turning on the heat.

To check the current temperature in your living room:
1. Use a thermometer placed in the living room.
2. Check the reading on any smart home device that monitors temperature if available.

If the temperature is below 40°C (104°F), you can turn on the heat by:
1. Using a thermostat to set the desired temperature.
2. Turning on a space heater or other heating device.
3. Adjusting your HVAC system settings if applicable.

This is the same reason I'm having the turn_on_heat tool return that the heat is on. Without that I was seeing the model turn on the heat and then tell you it didn't know what to do, like so:

User> Use the available tools to find out the current temperature in the living room and use the right tool to turn on the heat if it is under 40 Celsius.
+++ Calling tool 'read_temperature' with arguments {"location":"living room"}
--> "25"
+++ Calling tool 'turn_on_heat' with arguments {}
--> ""
Agent> I don't have access to external tools or devices, so I can't directly check the temperature in your living room or control any heating systems. However, I can guide you on how to do this:

1. **Check the Temperature:**
   - Use a smart thermostat or a smart home device that can monitor the temperature.
   - Alternatively, use a smartphone app connected to a smart thermostat.

2. **Turn On the Heat:**
   - If the temperature is below 40°C (104°F), you can use the same smart thermostat or smart home device to turn on the heat.
   - Ensure that your heating system is compatible with smart controls and follow the manufacturer's instructions for operation.

If you provide more details about the devices you have, I can give more specific guidance.

These results also aren't totally reliable (LLMs usually do not have deterministic behavior) so if you try this yourself you may need to run the program a couple of times to get the desired result. You'd probably get a better result if you were using a smarter model, but I picked something that would run well on low-end machines, because the next thing I want to do is go a level deeper into what's actually going on, and that requires a modal I can run locally.

Internals #

As I said above we're using the Ollama API rather than a local library so that you can see the actual data we're sending to the API, but that's just the first layer of the onion because each LLM has its own idiosyncratic syntax which Ollama translates to and from. For example, here are is what our initial shirt prompt turns into when we send it to Mistral and Gemma (one of Google's open weight models) respectively:^[4]

Mistral #

[SYSTEM_PROMPT]You are Mistral Small 3, a Large Language Model (LLM) created by Mistral AI, a French startup headquartered in Paris. Your knowledge base was last updated on 2023-10-01. When you're not sure about some information, you say that you don't have the information and don't make up anything. If the user's question is not clear, ambiguous, or does not provide enough context for you to accurately answer the question, you do not try to answer it right away and you rather ask the user to clarify their request (e.g. \"What are some good restaurants around me?\" => \"Where are you?\" or \"When is the next flight to Tokyo\" => \"Where do you travel from?\")[/SYSTEM_PROMPT][INST]My shirt is blue[/INST]

Gemma #

<start_of_turn>user\nMy shirt is blue<end_of_turn>\n<start_of_turn>model

This is, as they say, a "rich text". The first thing to notice is that neither of these prompts is JSON. Instead, Ollama has taken our JSON API input and translated it into this stuff, which we'll generously call "structured". However, each model has made its own idiosyncratic choices:

Mistral uses something that kind of looks like XML if you globally replaced every angle bracket with a square bracket. Gemma uses XML syntax.^[5] As we'll see shortly, OpenAI's models use something even goofier, with tags like <|start|> and <|end|>.
Mistral includes a system prompt that tries to set some basic ground rules, whereas with Gemma you're on your own.

All this is just hidden by Ollama, which has a pretty fancy templating engine that lets each downloadable model specify how to translate to and from the Ollama API to the model-specific stuff.

I think the coolest thing here, though, is what's at the end of the Gemma prompt, which is basically an incomplete response from the model's response, with just the framing ready for the model to fill it in. What's going on here? Well, recall that an LLM is basically a completion machine, and it's trying to continue the conversation, so basically we're telling the model "the next thing that's going to happen in this conversation is that the model is going to say something". OpenAI's open models do the same thing. Here's gpt-oss-20b:

<|start|>system<|message|>You are ChatGPT, a large language model trained by OpenAI.\nKnowledge cutoff: 2024-06\nCurrent date: 2026-03-04\n\nReasoning: medium\n\n# Valid channels: analysis, commentary, final. Channel must be included for every message.<|end|><|start|>user<|message|>My shirt is blue<|end|><|start|>assistant

The responses from Mistral and Gemma are about what you would expect:

Mistral #

That's a nice color! Do you need help with something related to your shirt, or would you like to talk about something else?

Gemma #

That's cool! Blue is a great color for a shirt. 😊 \n\nIs it a light blue, a dark blue, or somewhere in between? Do you like wearing blue?\n\n\n\n

There don't seem to be any delimiters here, so this could be a bug in my instrumentation, but I think that's actually what's going on.^[6]

Now take a look at what gpt-oss looks like:

<|channel|>analysis<|message|>We need to respond appropriately. The user says \"My shirt is blue\". It's a statement. We can respond with empathy or ask about context. Might be a conversation about shirts, colors, etc. We can ask what they like about blue shirts, or what occasion. Provide a playful or helpful answer. Keep tone friendly. Also check guidelines. There's no policy violation. Provide short, friendly reply.\n\nWe can ask: \"Cool! Is it a casual or formal shirt? Do you like the shade of blue?\" Let's produce.<|end|><|start|>assistant<|channel|>final<|message|>Nice! Blue is a classic choice. Is it a casual tee, a dress shirt, or something else? And which shade do you like—navy, sky blue, or maybe a bright cobalt?

This is really cool, because we're actually now getting two kinds of output:

The content we asked for (i.e., the model's response)
The thinking behind the answer

This is an important clue to what's actually going on under the hood. Reformatting it to make it clearer:^[7]

  <|channel|>analysis
    <|message|>We need to respond appropriately. The user says \"My
    shirt is blue\". It's a statement. We can respond with empathy or
    ask about context. Might be a conversation about shirts, colors,
    etc. We can ask what they like about blue shirts, or what
    occasion. Provide a playful or helpful answer. Keep tone
    friendly. Also check guidelines. There's no policy
    violation. Provide short, friendly reply.\n\nWe can ask: \"Cool!
    Is it a casual or formal shirt? Do you like the shade of blue?\"
    Let's produce.
<|end|>
<|start|>
  assistant
  <|channel|>final
    <|message|>Nice! Blue is a classic choice. Is it a casual tee, a
    dress shirt, or something else? And which shade do you like—navy,
    sky blue, or maybe a bright cobalt?

What we've got here is a "reasoning" model, and what that means in practice is that it produces its "thinking" process out loud as part of the model output and after that thinking is done ("Let's produce" in the text above) it actually produces the output that's intended for the user. What this output shows, though, is that it's still all text production—albeit with a lot of tuning—basically what's happening the model just produces the reasoning text first and then produces the output that follows—in a literal sense!—from that reasoning.

Tool-Calling #

Now let's ask see when we call a tool. Here's Mistral and gpt-oss after I removed the system prompts (the version of Gemma I'm using didn't want to do tool calling, so I didn't show it, but you can use functiongemma):

Mistral #

[AVAILABLE_TOOLS][{\"type\":\"function\",\"function\":{\"name\":\"read_temperature\",\"description\":\"Return the room temperature in degrees Celsius\",\"parameters\":{\"type\":\"object\",\"required\":[\"location\"],\"properties\":{\"location\":{\"type\":\"string\",\"description\":\"The room name\"}}}}},{\"type\":\"function\",\"function\":{\"name\":\"turn_on_heat\",\"description\":\"Turn on the heat\",\"parameters\":{\"type\":\"object\",\"required\":[\"location\"],\"properties\":{\"location\":{\"type\":\"string\",\"description\":\"The room name\"}}}}}][/AVAILABLE_TOOLS][INST]Use the available tools to find out the current temperature.[/INST]

GPT #

<|end|><|start|>developer<|message|># Tools\n\n## functions\n\nnamespace functions {\n\n// Return the room temperature in degrees Celsius\ntype read_temperature = (_: {\n  // The room name\n  location: string,\n}) => any;\n\n// Turn on the heat\ntype turn_on_heat = (_: {\n  // The room name\n  location: string,\n}) => any;\n\n} // namespace functions<|end|><|start|>user<|message|>Use the available tools to find out the current temperature.<|end|><|start|>assistant

Holy mixture of formats, batman. In both cases we have quasi-XML with embedded JSON. With Mistral the the JSON is just inlined into the [AVAILABLE_TOOLS] block and with GPT it's even wackier, and has been turned into some kind of quasi-function notation and all the quotes stripped (harmony format).^[8]

And finally, here's the actual tool calls, which are about what you would expect:

Mistral #

[TOOL_CALLS][{\"name\":\"read_temperature\",\"arguments\":{\"location\": \"living room\"}}]

GPT #

<|channel|>analysis<|message|>We need to check: read_temperature returns 25 degrees Celsius. Need to turn on heat if under 40 Celsius. 25 < 40, so we should turn on heat. Use turn_on_heat tool.<|end|><|start|>assistant<|channel|>commentary to=functions.turn_on_heat <|constrain|>json<|message|>{\"location\":\"living room\"}

Don't ask me why the GPT tool calls are in the commentary channel. That's just how things are.

Model Context Protocol #

Tools aren't the only way that an AI model can interact with the outside world. For example, Anthropic has developed something called the Model Context Protocol (MCP), which is a way for models to interact with external resources (tools, data, etc.).

MCP Architecture: from modelcontextprotocol.io^[9]

The arrows connecting the host process and the servers are MCP, which is a fairly simple JSON-RPC protocol. Like tool calling, MCP is generic in that it specifies how to talk to external resources but doesn't specify any details about the resources themselves. Instead, the servers are responsible for providing descriptions of the resources, which can currently be any of:

prompts: e.g., code_review <code>
Resources: such as access to static files, Git repos, etc.
Tools: just like we've seen these already

The client can interrogate the server to learn about each of these resource, which come packaged in convenient descriptions just like we saw with tools. For instance, here is an example tool description from the MCP spec:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "title": "Weather Information Provider",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        },
        "icons": [
          {
            "src": "https://example.com/weather-icon.png",
            "mimeType": "image/png",
            "sizes": ["48x48"]
          }
        ]
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

This should look incredibly familiar, because it's basically the same thing as you would feed in for a tool description with Ollama. This is actually the tool description format that Claude uses, where things are named a little differently (e.g., inputSchema instead of properties), but if you can read one you can read the other.^[10] The situation is roughly similar for the descriptions for prompts and resources.

It's important to realize that using server-side resources via MCP is isomorphic to tool calling. Recall that the model doesn't know how the tools are implemented, it just knows that they exist. This means that if you have an LLM which knows how to call tools, you can make it do MCP just by creating a translation layer that exposes the MCP-provided tools as if they were regular tools, as shown below:

Tool calling via MCP

In this diagram, we actually have three sources of tools, namely the two MCP servers and then a local tool. The agent wrapper just collects all the tools and provides them to the LLM without distinguishing where they live, and then is responsible for dispatching the tool requests to wherever they need to go. You can handle resource requests the same way, with the resource just being a specialized kind of tool that reads static data. Prompts are a little different, and I'm not going to handle them here.

Server to Client #

There is a bit more to MCP than this. In particular, MCP includes functions to let the server ask the client to access the LLM on its behalf (e.g., ask for completion). However, these too don't require anything new from the model, but are just implemented in the wrapper code, which accesses the model on the user's behalf.

The important thing to realize here is that the LLM doesn't need to know anything about MCP at all, because this part of MCP is just tool calling wearing a different hat. As long as it's set up for tool calling, which has a simple request/response model, we can do all the translation to MCP in the deterministic agent wrapper code (which doesn't require any model tooling). If someone invented a new version of MCP with totally different syntax, we wouldn't need to change the LLM at all, just update the wrapper.

The Bigger Picture #

The amazing thing is really how much we are doing with how little. Our final agent program is less than 350 lines, and though we'd obviously need proper error handling, etc. the functionality here is actually the core of a real agentic tool. We get that power by composing a bunch of simple components:

An LLM which is able to generate new text in response to a prompt.
A wrapper which is able to iteratively take in input and then ask the LLM "Given what's happened so far, what's next?"
A bunch of tools which are able to have effects in the the real world when told to do so by the LLM.

That's all there is.

Using it for real work would mostly consist of (1) adding a full suite of tools and (2) using it with a good model rather than the local ones we're using here. (2) is actually quite straightforward with Ollama actually supports cloud models, translating to the cloud APIs instead of to the local model interfaces. This leaves us with the tools, but the tools aren't about AI, they're just the same kinds of APIs that you'd write for any programming task.

What makes all this possible is that while the models are trained to use tools generically, they aren't trained to use any specific tools. That means that all you have to do to add new capabilities is to write new tools and tell the model about them. The model can than work forward from your instructions and the tools it knows about in order to figure out what tools it needs to call and in what order so that it can accomplish whatever it is you asked it to do.^[11]

This setup gives us two avenues for increasing the power of the system. First, we can make the model smarter so it's better at figuring what to do with the tools it has. We saw that already above, where we had to remind the model that it had tools available, but with a better model that wouldn't be necessary. Second, we can give the model model more tools to work with. These avenues are independent but work together: you can make your existing AI-based system better by adding more tools, but then if you replace your model with a smarter one, it will instantly get better with the tools it has.

The model itself is just data, consisting of a model topology and a lot of model weights (i.e., numbers), so you need some software to execute the model, which is what Ollama is. ↩︎
It's obviously a lot of effort to tune the model to generate plausible chat, but that's not our problem right now. ↩︎
Thanks to Gemini for some help with this. ↩︎
I had to instrument Ollama to get it to print this out. ↩︎
Note that these strings should be translated directly into tokens when processed by the model ↩︎
All these extra \ns are real serial killer stuff. ↩︎
I didn't screw up the indentation. Remember what I said earlier about how the prompt includes the start of the model's response? Well that's the missing part, which goes <|start|>assistant. ↩︎
This is a whole other topic, but if you're familiar with how quoting issues can lead to stuff like SQL injection, you're quite likely huddled up in a ball sobbing by now. There is indeed an analog to SQL injection in LLMs called prompt injection which will most likely be the subject of a future post. ↩︎
The official SVG on the site had a little hovering navigation tool on it, so I had to cut out the SVG and rerender it in my browser and I was too lazy to get their CSS working. ↩︎
It's actually an interesting question whether you could feed one style of description to another kind of model and have it work. Remember that at the end of the day you're just passing text to the LLM, so it's quite possible the model is smart enough to figure it out, just as you can, though you'd probably have to work around the various layers of structure in the API that expect properly formatted JSON. ↩︎
This is of course basically the same task as software engineering. ↩︎

I automatically generated minutes for five years of IETF meetings

2025-12-31T00:00:00Z

Auto Minutes Logo [by Gemini]

It is characteristic of all committee discussions and decisions that every member has a vivid recollection of them and that every member’s recollection of them differs violently from every other member’s recollection. Consequently, we accept the convention that the official decisions are those and only those which have been officially recorded in the minutes by the officials. —Sir Humphrey Appleby, "Yes, Prime Minister": S2E1.

Motivation #

Like other standards development organizations (SDOs), the IETF requires that meetings be minuted:

All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@ietf.org

The IETF doesn't have any professional staff support for taking minutes, which means that the working group members have to record the minutes. The outcome of this is predictably bad:

The minutes are bad:: Taking good minutes is hard work and nobody at IETF is really trained to do it. It's easy for people to transcribe events incorrectly, miss important events, etc.
Taking minutes interferes with WG participation.: Taking minutes makes it hard to participate in the WG, partly because you're too busy writing stuff down to think about what to say and partly because you can't easily minute yourself, so either someone has to take over while you participate or you end up with a gap in the minutes.
People avoid taking minutes.: Because minute taking isn't fun, it's hard to get volunteers. The IETF doesn't have a system for drafting people to do the job, so instead what happens is that the WG chairs find themselves begging for people to step forward and take minutes at the beginning of each WG meeting ("we can't start without a minute taker") until eventually some poor sucker grudgingly agrees to do it.

A Technical Fix #

This post is actually two stories in one:

My attempt to produce a technical fix for the minutes problem.
Some reflections on using AI as a tool to produce that technical fix.

What connects these two threads is that this project would have been a lot of work a few years ago, but now it's basically trivial.

Over the past 10+ years, there have been some modest improvements which have made things a little easier:

It's now standard practice to take minutes in a shared notepad, which makes it possible for multiple people to take minutes, or for someone to fill in a bit when the main minute taker wants to participate. Nevertheless, as mentioned above, taking minutes is not a popular activity.
The IETF now makes complete video and audio recordings of every WG meeting, complete with automated transcripts. Many of the people I know find the minutes so unreliable, they just go back to the video whenever they want to know what happened.

I'm a long-time minutes-taking evader but I'm also a strong believer in recognizing when people don't like doing some things and trying to find ways to stop them from having to do them. At a recent interim meeting in Zurich for the AIPREF WG, some of us got so frustrated with the whole thing that we proposed that the IETF dispense with minutes taking entirely and just declare the automated transcripts to be the minutes. This suggestion was not popular and after looking at the transcripts in more detail I have some sympathy for the objectors, as they're pretty hard to work with (more on this below).

Not totally deterred, I decided to take another run at a technical fix: maybe the transcripts aren't good enough, but what if we could just automatically make minutes from the transcripts? Fortunately, I had another meeting to attend the next week—and hence a need for a side project to distract me—and a copy of Claude Code, and thus ietfminutes.org was born.

Architectural Overview #

The diagram below shows the overall architecture of ietfminutes.org.

Overall architecture

The basic concept here is unbelievably simple and obvious: take the transcripts that we're already generating and ask an LLM to make minutes out of them. Here's the prompt, with some re-flowing.

You are an expert technical writer for the IETF. Convert the following meeting transcript
into well-structured meeting minutes in Markdown format. It should contain an account
of the discussion including any decisions made.

Session: ${sessionName}

Requirements:
- Start with a # header with the session name

- Include a ## Key Discussion Points section with bullet points
- Include a ## Decisions and Action Items section if applicable
- Include a ## Next Steps section if applicable
- Be concise but capture all important technical discussions
- Use proper Markdown formatting
- Focus on technical content and decisions
- Remember that IETF participants are individuals, not representatives of
  companies or other entities
- Remember that consensus is not judged in IETF meetings; it is established separately. 
  It's OK to say things like "a poll of the room was taken" or
  "a sense of those present indicates..."

The transcript is in JSON format with timestamps and text. Here is the transcript:

${transcript}

Generate the meeting minutes:`;

The code to talk to the LLM is just a trivial use of the service API, namely feeding it the prompt with the transcript filled in and getting back the summary.

The vast majority of the code is plumbing, specifically:

Retrieving the list of sessions from the IETF "datatracker"
Retrieving the actual session transcripts from the Meetecho conferencing system used by IETF
Formatting the site and publishing it

Retrieving the Session Transcripts #

The first step is just to find the relevant sessions. Most IETF WG meetings happen at the thrice yearly in-person IETF plenary meeting^[1] The IETF uses a homegrown tool called datatracker to manage IETF drafts, agendas, meeting materials, proceedings, and eventually the minutes. Datatracker is a somewhat aged—but actively maintained—Django app. Unfortunately it's really designed to be used as a Web site and doesn't have a complete published API, but rather just exposes its object model with tastypie, so I had to do a bit of reverse engineering. At the end of the day I ended up using the proceedings page (e.g., https://datatracker.ietf.org/meeting/124/proceedings). Each session (WG or otherwise) is linked to by a link named "Session Recording":

IETF proceedings page

The session recording link goes to a custom media player, which has the video (actually an embedded YouTube player), which also has an embedded transcript player. The player has a deterministic URL pattern, such as https://meetecho-player.ietf.org/playout/?session=IETF124-PLENARY-20251105-2230. Each session is defined by a session ID, and then The transcript itself is at a deterministic location based on the session ID. This gives us a straightforward process:

Parse the proceedings page to find all links labeled "Session Recording"
Extract the session ID from the link to the player
Construct the link to the transcript and download the transcript from the URL.

The transcript itself is a JSON file consisting of timestamped fragments of transcribed speech:

[
  {
    "startTime": "00:00:00",
    "text": "yesterday I was over-achieving High is bad but I joke you see that Yeah, that's the point You know overnight was good Overnight was good for  that please So this is the ASDF meeting meeting if you're here because you like trains, you'll have to go somewhere else Because the AASDF kid likes trains. I'll start in one minute, and we're with, we need a note  taker yet Somebody take notes because I'm speaking Jan, are you taking a Yeah, thank you very much I'm doing the talking and Lorenzo is doing the projecting and don't ask him questions because he can't talk talk. He's allowed to. He just is unable to um and uh so yeah so oh, so we've actually changed the agenda already already. So note, well, you saw it yesterday you saw it everywhere else Please be nice to each other This is not the latest slide, but that's okay um and um yeah please be nice to each other um next item is we are going to continue with a version virtual interims. And And pardon me?"
  },
  {
    "startTime": "00:02:02",
    "text": "Yes. Thank you And so we have been doing them at, what time was it, your time, 9 a.m 9 a.m which worked well in in Europe and in in Korea and even in California and I was the odd man out at 3 a.m and i did not make it uh uh there um so the question is is that still a good time for everyone? who wants to be involved? Would you like to propose other times? If not, do we want to have one in December? beginning of December? Yes, no, yes Okay we're going to pick the first Wednesday in December whatever date that is and we're going to go with that at that same 9 a.m Eastern European time, yeah, which is I guess 7 a.m .T.C. Is that right? yeah okay we'll post that up and then I think we'll post a second one for maybe the second week of January. The first week is usually a toast Any great objections? to that and then we'll discuss what we're, where we're doing from there Anyone remotely want to comment on that? No Okay let's move on to the first real agenda item which is non-affordance and  click either"
  },
  ...
]

Minutes Generation #

The next step is to send the transcript to the LLM and ask it to make the minutes. As I mentioned above, this is conceptually simple but turns out to be somewhat slow (order 10s of seconds per session), which requires some careful handling. At the end of the day, I ended up doing two things:

Caching the generated minutes so that you can run the rest of the code (generating the site, uploading it, etc.) without waiting for the LLM. This also makes things easier when running it in automation (see below).
Switching from Claude Sonnet to Gemini Flash, which is a lot faster, as well as cheaper. It's still too slow to run in the inner loop when you're testing, but made it much faster when I wanted to backfill all the minutes for the past 5 years or so.

This phase is where all the smarts are, but TBH both models do a pretty reasonable job (see below for more on this). I did run into one class of error that was bad enough to be worth doing something about. For some reason, the output would have Markdown fences, such as:

```

```markdown

in the output. This idiom is used to indicate to the Markdown processor that you want the code rendered as literal code rather than processed, which isn't what we want here. I ended up just using a post-processor to remove anything like this.

Generating the Site #

I wanted to host this on GitHub pages, which meant I needed a completely static site. My first cut at this was just putting the generated MD in the gh-pages branch and letting GitHub render the HTML. This works OK, but you end up stuck with GitHub's styling choices, and after fighting for a while with trying to configure Jekyll I decided it would be easier to generate the HTML locally. That way, I could use 11ty, which I was already familiar with, and I could test out the HTML generation without having to push it to GitHub and wait for it to generate the pages.

I ended up with a three step process:

Generate the minutes in markdown using the LLM (see above).
Starting with the generated minutes, generate the site markdown, as well as the site index.
Using 11ty, generate the site HTML.

The nice thing about this structure was that it made it easy to work incrementally: once I had generated minutes for a few WG sessions I was able to generate a basic site and then iterate on the wrapping for each page (headers, footers, etc.), the styling, etc. without having to hit the LLM again, which makes things both faster and cheaper. It also meant that once I had things the way I wanted I could just generate the minutes for the rest of the WG sessions of interest and regenerate the whole site. It also made things easier when I went to automate everything later.

Importantly, none of this code runs in the critical path because the site is entirely static, which convenient for deployment reasons because it means I can run on totally free infrastructure, but also for security reasons because there's basically nothing to compromise. This is good because despite being a security professional, I don't really have that much experience building a secure dynamic Web site using modern tools like Django or RoR, so I prefer to design things in as fail-safe fashion as I can.

Automation #

In my first cut of the system, I just ran everything on my local machine, then committed the site to the GitHub pages branch and pushed it to GitHub. This is fine for generating minutes for meetings that happened months ago, but what you really want is to have the minutes generated in quasi real time, shortly after the sessions themselves happen (the transcripts take a while to generate, so it won't be in real time).

There are lots of options here, but given that I was already publishing with GitHub pages, the easiest approach seemed to be to use GitHub Actions. There's no Web hook for when the minutes are published, but actions supports scheduled events, so I can just poll the site periodically. The tricky part here is maintaining the cache of generated minutes files, as we obviously don't want to have to regenerate all of them every time a new session transcript is published.

What I ended up doing was having two repos:

ietf-minutes-data for the GitHub pages site and the cache of generated minutes, which is stored as a branch.
auto-minutes for the code to generate the minutes.

The reason for the two repos is that I need the action to have write access to the repo so it can re-commit the cache, but I didn't want to give it write access to the code itself in case I screwed something up or there was a security issue. This way, even if there is a total compromise of the system, the worst thing that can happen is damage to the data. I'm not a GitHub actions wizard, so there might be some other way to do this, but I like to keep things simple.

GitHub automation architecture

The action itself is attached to the ietf-minutes-data repo. GitHub doesn't do a very good job of running the job at the scheduled time, but it seems to eventually run and as I mentioned above, the transcripts take a while to show up, so it's not that big a deal. Once it does fire, here's what happens:

Check out the auto-minutes repo, which has the actual code and npm install all the dependencies.
It then checks out the cache branch of ietf-minutes-data, containing all previously AI-generated minutes.
Run the minutes generator and generate minutes for all sessions that haven't been generated yet. This is the only stage that uses AI.
If there are new minutes in the cache directory—because there were new sessions—commit them to the cache branch and push it back to GitHub. If no new minutes were generated, the script aborts at this point.
If there are new minutes, then we need to regenerate the site itself, and then deploy it to GitHub pages.^[2] This is fast because it just means regenerating the metadata pages (indexes and the like) and running 11ty to generate the HTML.

It took some messing around to get this running because I was doing a lot of this on a plane (see also "not a GitHub actions wizard", supra), but once I had it up and running it all worked smoothly for the rest of the meeting.

Tuning Output Quality #

As I said above, the output quality is pretty good, but it's far from perfect. With lot of examples to work from, you can see some consistent patterns.

Mis-rendering people's names (e.g., "Martin Thompson" rather than "Martin Thomson", "Eric Griswold" for "Eric Rescorla").
Mis-identifying speakers entirely (e.g., Rich Salz as me).
Mis-rendering technical terms (e.g., "Quick" for QUIC". This is actually an interesting one because it gets it right the first time).
Misstating the result of a discussion, e.g., saying there was consensus if there wasn't.

For instance, here is a session I was in, which has a number of examples of the above.

The high level challenge here is that the model itself is kind of a black box; we can of course tweak the prompt, but it's difficult to predict if that's going to have the right effect. You can obviously try it with a single problematic session (I even added a mode specifically for that), but even if you get the right result on that specific session, you don't know if it will make things worse on some other session, so it's hard to know how aggressive to be. On the one hand, the prompt is already kind of ad hoc, but you also don't want to be doing a random walk through the prompt space. I suspect the pro thing to do is to actually fine tune a model, but I'm not sure I have enough energy for that for what is at the end of the day kind of a hack.

With that said, there are a few obvious things to do that seem likely to improve quality.

Generate the Transcript Ourselves #

As I said above, I'm just using Meetecho's transcript generation function. Some brief inspection of the transcripts it is emitting suggests that there's a fair amount of room for improvement, and if there are errors in the transcript, this has the potential to affect the generated minutes (although in some cases I've actually seen the minutes generation fix errors in the transcript!).

The obvious thing to do is to instead do the STT ourselves from the audio recording using a more advanced STT model (e.g., Gemini Audio Understanding). Unfortunately, for reasons I don't quite understand, the IETF doesn't presently make the audio recordings available. It's probably possible to use youtube-dl or the like to get the video and then pull out the audio, but that's not really the way I would prefer to do things. This is a TODO for the future when the IETF cracks the code on how to host audio files.

Identify the Speaker Explicitly #

As noted above, a persistent problem is misidentifying speakers, either by mis-rendering their name or getting the wrong person altogether. This is kind of irritating because the information is actually in the system somewhere. The IETF actually has a fairly fancy audio setup, with at least four different audio inputs (sometimes with multiple microphones in each).

Chair
Presenter
Room (for comments and questions)
Remote

All of this stuff feeds into Meetecho as well as into the room speakers, but Meetecho's transcript generation removes which channel the audio came in on. If the transcript were just annotated with the input channel, then it would make it a lot easier to figure out the person who was speaking. It's actually possible to do better than that, though, though each case needs special handling.

Chair #

Your typical IETF WG has one or two chairs and the IETF datatracker already records the chairs, so it's straightforward to reduce the chair mic down to one or two people. In my experience, the chairs typically don't identify themselves, so you'd probably need some speaker recognition (perhaps augmented by the video stream) to determine which chair was talking. Still, just knowing that it was a chair would be helpful.

Presenter #

Each WG session is likely to have a number of presenters, but there's a fair amount of metadata available to determine which one is which, including:

The agenda listing who is presenting
The chairs announcing the next slot

You'd need to play around with things a bit to determine whether it was best to try to do something smart or just feed all of the information into the model and let it figure things out, but again, just knowing that some audio came from the presenter mic would help.

Room #

It used to be very difficult to know who was speaking at the room microphones, but as part of the effort to make participation remote friendly, IETF now has a unified queue management system between remote and in-room mics, and so if you want to speak at the room mic, you need to get in the queue first. This means that even though Meetecho doesn't necessarily know who is actually speaking, it knows who is at the head of the queue and if they are local or remote, so you could probably just assume that if it's the in-room mic, it's the person at the head of the mic line. This won't be perfect, because sometimes people but in or reorder themselves, but it would be a lot better.

Remote #

This is actually the easiest: you can't remotely participate in an IETF meeting without using the remote Meetecho tool, and that requires registering, so Meetecho knows exactly which individual is speaking over a given remote channel.

Ground the Output in Existing IETF Information #

Finally, there's a broader opportunity to ground the output in existing IETF information, and in particular to give the LLM a hint about some commonly used words and phrases. For example, we could provide:

The list of people actually in a session so that it knows that the most likely names are.
The WG agenda so it knows the presentation order (see above).
The presentations and documents associated with a given WG session.
A list of common terms and acronyms, so that it knows that if you talk about "QUIC" it's probably not "Quick".

I've been looking at this a bit; maybe for next time.

Take Homes #

This is a pretty simple project, but it gave me the opportunity to play with a bunch of AI tools, and while I'm not any kind of expert, I do think there are some useful lessons.

AI Code Generation #

The vast majority of this code was written with AI coding tools, mostly Claude Code. Mostly, I just pointed Claude Code at the APIs and told it what I wanted and let it rip. I did some light review of the code to see if it seemed to be doing what I wanted, but if I'm being honest, it was mostly this:

I fear this is the future of AI coding assistance, as it's very difficult to maintain attention when reviewing big PRs.

This isn't ideal, but this particular site is pretty low stakes and one of the advantages of the split architecture I'm using is that even if you make some pretty egregious mistakes in the code, there's (hopefully!) not too much that can go wrong beyond having the site itself end up wrong.

I know lots of other people have used AI coding tools, but I wanted to form my own opinion, so FWIW, here are some thoughts.

First, my impression here is that Claude is really good at the routine stuff like knowing how to scrape a site, parsing the HTML, figuring out which parts of the DOM to examine, etc. It wasn't as good at figuring out the overall architecture, but if you ask it to do the job in pieces and correct it when you're unhappy, it works better. This matches my experience using Gemini and herding the AI seems like it's a skill that we're all going to have to learn.

It's especially helpful to have a tool like this for doing routine stuff you're bad at or don't want to learn. For example, I suck at CSS, but I also don't want to do anything complicated, so generally if you just tell Claude what you want and don't care too much about the exact details of how things look it does an OK job. there's still a bunch of stuff where you have to be like "no, I really want that menu item 20% lower", and in some cases you eventually have to get in there and fix things yourself, but again, having a computer do the busywork is great.

The time scale is oddly inhuman: Claude is incredibly fast at generating a big pile of code, but if you want some trivial change you still somehow end up with a lot of think time latency, where you're just sitting and staring at the screen waiting for Claude Code to get back to you. I did a lot of this work sitting in meetings, so I could just tune out and wait for the model, but if this is all I was doing, then I'd want to develop some different work rhythms. I've heard of people having a lot of different outstanding tasks and waiting for them to complete and reviewing them, but this isn't something I've tried much yet.

Summarization #

This is the first project I've worked on where I didn't just use AI to generate the code but where AI was actually a core piece of the operations. It's a really different experience from normal engineering because the AI is basically a nondeterministic black box that you have to kind of talk into doing what you want. This has a few implications that take some getting used to.

First, it's really hard to know what the impact of any particular change to the prompt will be. For example, we've been having a sort of persistent problem where the model would report that there was consensus on a certain point, even though the chairs hadn't declared consensus. Mark Nottingham and I spent some time tweaking the prompt trying to get it not to declare consensus incorrectly, but the results really weren't quite what we were hoping.

Second, because the system is nondeterministic you don't get exactly the same results with the same inputs, which makes things hard to test. It's of course trivial to regenerate any individual session as a test but the problem is that just because it works once doesn't mean it will work reliably. I'm very curious what other people do in this kind of situation, but just on first impression this feels a bit like a statistical process control problem, where we'd have to do something like A/B tests with a given prompt (or, again, try to fine tune the model).

From a product delivery perspective, I also noticed that this is also a bit confusing for other people, who are used to software behaving predictably. I've gotten a number of bug reports that are basically of the form "the generated minutes don't seem quite right", and my response is kind of the same: ¯\_(ツ)_/¯. As noted above, I have a few ideas for how to improve things, but fundamentally, I don't know how to fix specific defects.

Integration into the process #

Even as-is the minutes are reasonable quality—and the bar here is pretty low—but they definitely can contain errors (as they say "AI can make mistakes"). The idea here isn't to replace the minutes on the IETF proceedings but rather to make the process of generating them easier. I'm not going to judge you if you just take what I've generated and submit it as the minutes, but a better practice is to at least give it a once-over to fix any glitches before submitting them.

The bigger picture #

This project wouldn't have happened without modern AI tooling. Even ignoring that it depends on AI to do the summarization, I'm not sure I would have gotten around to doing it without being able to use AI to write most of the code for me.

There's nothing particularly complicated here, but there's a lot of routine but fiddly work (scraping the site, finding the exact parts of the DOM to extract, talking to the AI API, tweaking the site look and feel, etc.) that takes time. In many cases, these tasks require you to learn something you don't already know, isn't very conceptually interesting— what are the arguments to this API call?—and will quickly forget. This is all friction in the coding process that the AI lets you just skip over, because the assistant can usually figure it out. I know there are a bunch of debates about how much the AI is really doing that versus just pattern matching from a lot of other people's examples, but as a practical matter, it kind of doesn't matter.

On the other hand, while it's amazing to get so much done with so little personal effort, there's also something a bit unsatisfying about it, seeing as you didn't do much of the work yourself, but instead supervised some AI doing it. This experience may be familiar to more senior technical people who have moved from doing a lot of actual software engineering to leading projects, as a tech lead, architect, or CTO; you do a lot more architecture and steering and a lot less actual hands-on work. The vague unease that you don't really understand what's going on isn't new either; of course what's different here is that—at least in theory—your co-workers understood it and you trusted them, whereas here it's just you and the machine, at best a p-zombie and at worst a fancy random number generator, but nevertheless I know a lot of more senior engineering people miss the feeling that they did it themselves as opposed to leading other people who did the actual work.^[3]

A huge amount has been written about how to use these tools safely and efficiently; this is understandable given the general efficiency-maxxing ethos of technology. Less explored, however, is the question of how to use them enjoyably. One of the great things about being a professional software engineer is that programming is fun, not just the feeling of building something cool, but the experience of flow, when the code just seems to come effortlessly from your brain to the keyboard. At least for me, the experience of using AI tools like Claude Code is totally different: you ask the machine to do something, then sit and wait for it to spit back a response; this is the opposite of flow. I can't help but wonder whether some of the resistance to AI in the software engineering community is about AI taking the fun out of the experience of programming. I certainly feel some of this, at the same time as I try to remind myself that what's really important is accomplishing stuff, not whether you did it personally or had fun, and that means using the best tools you can and having the best people do the work, even if those people are robots,^[4] but that doesn't mean I don't want to have fun at the same time.

There is actually a plenary meeting at the IETF plenary. I'm using the term "plenary" here to distinguish from interim meetings. ↩︎
Now that I'm writing this, I see that it's actually a bug because it means that if I change the templates but there are no new sessions, things don't get regenerated. This is a side effect of the fact that I was originally doing things by hand and then wrote the automation during the IETF meeting, but after I had the templates written, so there were always new sessions. ↩︎
It's not uncommon to see very senior people whose job is really to set the direction for the organization instead jumping in and trying to write code. Sometimes this is what's needed ("all hands on deck") and but in my experience it's far more often about prioritizing your feelings that you're doing "real work" over the thing you should be doing. ↩︎
See also Thomas Ptacek's My AI Skeptic Friends Are All Nuts ↩︎

Using Government IDs for Age Assurance

2025-10-19T00:00:00Z

On the Internet, nobody knows you're a dog. By Gemini, riffing off the New Yorker original.

Over the past few years, an increasing number of jurisdictions have started to require that service providers of various kinds (most frequently pornography but also social networking sites) check the age of their users. Many of these laws and regulations don't specify any particular form of age assurance, but instead simply require it to be "effective", or in the words of UK's OfCom, "highly effective". One obvious way to do this is to use some form of government ID to establish that you fall within the appropriate age range.

Government IDs in Person #

Before we talk about the online context, let's talk about how government IDs work in the physical context. Generally, it's a piece of plastic with your photo and some personal information (name, date of birth, etc.) on the front, and a bar code on the back, as shown below:

Driver's license front and back

The US Situation #

Unlike many other countries, the US does not have a national ID card. Instead, the main form of ID is a driver's license, which is issued by states. While A US passport is issued by the federal government but many Americans do not have passports. Nearly everyone has a social security card, but these aren't usable as a form of authentication because they don't have any kind of biometric (not even a picture) to tie the card to the subject, nor do they have any meaningful anti-tampering or anti-forgery features.

National ID cards (in countries that issue them) are constructed in a similar fashion. The basic way that authentication with an ID card is that the relying party (e.g., the bartender checking your age) compares the photo on the front of the card to your face and then reads the information printed on the card. If they want to know whether you are over 21, they can just look at your birthday.

This has a number of obvious security and privacy challenges, starting with the integrity of the card itself. It's not at all difficult to find someone to make you a piece of plastic with your picture on it—think of the all the employers who issue ID badges—so plainly just having a plastic card isn't enough. Real ID cards have a number of features designed to prevent forgery or tampering, such as holograms, images that appear only under UV lights, raised parts of the card, etc. hence why you see TSA agents shining a UV light on your ID.^[1]

The security logic goes like this:

The card is tamper-resistant and so you can trust that the picture and information on the card are what was intended by the issuer.
The picture matches the person in front of you and therefore the card is theirs.
Because the card binds the picture and the information on the card together, the information on the card applies to the person in front of you.

Modern driver's licenses also have a bar code on on the back that replicates much of the information on the front.^[2] However, this usually doesn't have any extra digital security features (e.g., a digital signature) so for our purposes it's just a more robust way of reading the front of the card.

Remote authentication via ID cards #

An ID card of the type discussed above is an inherently physical object in that the security guarantees are tied to the card itself. Despite this, there are many situations in which people want to authenticate themselves remotely.

Send a scan or a photo of the ID #

The simplest thing to do is just to have the subject scan their ID or take a photo of it and send the resulting image over e-mail. This is inherently a very weak form of authentication for several reasons. First, nothing ties the image to the person who originally sent it. This means that anyone who can get an image of your license can impersonate you, including anyone who you send the image to or anyone who has momentary access to your ID. Think of the number of times you have to show your ID in a year and realize that each of those people has an opportunity to take an image of it.

Second, the process of photographing or scanning the ID nullifies nearly all of the physical security features, which means that it's trivial to make a fake image which looks sufficiently like a real ID to pass visual inspection, either starting with a real ID or totally from scratch. In fact, there are services which will do this for you, though it's not that difficult if you have reasonable skills with an image editing tool like Photoshop. Despite all this, scanned copies of IDs are surprisingly common.

Live Presentation #

A better practice is to require the subject to do something to show it's their ID. There are a number of options here, including:

Having them take a selfie with the ID
Using their device camera to take a selfie or a self-video

In general, a selfie is weaker than a video call because the attacker can just edit the card image into the selfie. On a video call, the relying party can require you to turn your head, make different expressions, etc. as a liveness check (though some of these systems are circumventable) as well as show the card from different angles, which facilitates checking for some of the security features. This kind of video authentication is in quite wide use, in both commercial and government contexts. For example, it's one of the permitted mechanisms for employment eligibility verification in the US, and is also used for age verification.

The security of these systems varies a fair bit depending on on the precise technical design. In general, there seems to be a moderate level of resistance to what's called a "presentation attack" in which the user has a fake card, wears a mask, etc. It's much harder to defend against what's called an "injection attack" in which the attacker controls the camera and can send any video content they want. While there are some techniques that try to detect artifacts in the video feed, the main defense is to have the device remotely attest to the integrity of the video feed via some attestation mechanism. However, this does not work on the Web, which does not have software attestation mechanisms.

It's possible that in the future you might get some leverage from C2PA, especially for still images, but I think it's unlikely that it will work for video because the browser reads in raw video from the camera and then compresses it for transmission, thus removing any attestation.

From Physical IDs to Digital IDs #

As illustrated by the discussion above, the use of physical ID cards for remote authentication suffers from two main security problems:

The binding between the various pieces of information on the card is weak because it depends on security features which are designed for in-person verification.
The binding between the subject being identified and the ID card is weak.

In addition, when used for age assurance, physical IDs have suboptimal privacy properties:

They reveal a lot more information than just whether you are over the required age.
They require you to show your face, which you might not want to do.

There are a number of age assurance settings why people aren't going to be excited about disclosing their full names (e.g., to watch porn). Not only do you have to worry about the relying party disclosing your identity, there is also the risk of data breaches, as recently happened with age verification for Discord.

Digital IDs attempt to address all of these problems using (surprise!) cryptography.

Digital Signatures #

We already have a way to address the problem of weak binding between the elements on the card: we digitally sign the data. Naively, we can just do what we do all the time for WebPKI certificates: each authority (i.e., an entity that issues IDs, such as the State of California) has an asymmetric key pair. When they want to issue an ID, they just take all the data that would go on the card (much of which is already on the card in digital format anyway) and digitally sign it with that key.

A digitally signed credential of this type is essentially a complete replacement for the physical card: you can encode it in any digital medium, such as a QR code and show it to the verifier (relying party). The verifier has some trusted device which can read the data and a list of the public key pairs it trusts to sign valid credentials. Once the credential is verified, all the data is trustworthy, and so the device can display it to the verifier, who then compares the picture to the subject's face, just as with a physical ID.

Unlike a physical ID, a digital credential of this type doesn't depend on any kind of physical tamper resistance, because all the security is cryptographic. This allows it to be encoded in a QR code and just printed on ordinary paper, and of course you can print as many copies as you want. This is a convenient property in some respects: if you've ever lost your driver's license, you'll know it can be a pain to replace—and don't even get me started on what it's like to replace a green card—and in the meantime you can't prove your identity at all. Think how much easier it would be if you could just print out a new ID on your home printer.

Unfortunately, having a trivially copyable credential also presents a security problem because of the weak binding between the subject and the credential: there are many people who look like you, so if you can get the ID of one of them, you can probably use it. Physical credentials make this attack somewhat hard to mount because they're hard to duplicate (assuming the security features are working) so if you have someone's ID that means they don't, meaning you have to steal or borrow someone else's ID. By contrast, there can be an arbitrary number of equally valid copies of a digital credential, so it's much more vulnerable to attacks where one person impersonates an other.

Credential Binding #

In order to prevent this kind of attack (technical term: cloning), real-world digital credentials systems are usually designed so they can't be used as a standalone form of identification. Instead, they are bound to a cryptographic key pair, just like a WebPKI certificate. When you request a digital credential, you provide a public key, which is then encoded as part of the credential. In order to authenticate with the credential, you demonstrate that you know the corresponding private key. The overall process looks like this:

Authentication with a cryptographic credential

Describing a real protocol is out of scope for this post, but at a high level, the verifier supplies a random Challenge value which the subject's device signs with its private key, thus proving that it knows the key. You need the challenge to prevent replay attacks where the verifier just makes a copy of the signature to show to some third party; because each verifier provides its own challenge, the signature isn't replayable.^[3]

Note that this challenge/response process just proves that the person trying to authenticate has the right private key, but not that it's the right person. For instance, if I were to steal your phone with your credential on it, I might be able to impersonate you. In order to ensure that it's the right actual person, you also need to check the picture against the person's face.

The result of this design is that even though the credential is copyable, the copy isn't useful if you don't have the corresponding private key, so it doesn't matter^[4] if the credential is public.^[5] However, it's still possible to clone credentials if the subject cooperates.^[6] Obviously, I'm not likely to let arbitrary people impersonate me, but what if an older sibling wants to let a younger sibling "borrow their ID" so that they can drink? With a physical card, this means that the older sibling can't authenticate, but with a digital credential they just have to give them a copy of their private key, which is much easier.^[7] In order to prevent this kind of attack, some credentials systems bind the credential to a specific device.

Device Binding #

Conceptually device binding works the same way as we've just seen, but instead of binding to any private key, the credential is bound to a key which is stored in a secure element, which is industry jargon for a tamper-resistant processor that lives inside your device. The key pair is generated inside the secure element, which is designed so that it won't disclose the private key, though it can be used to sign data. This means that the user can still authenticate but can't make a copy of the key.

At this point, you might be asking what prevents the user from claiming that they generated the key pair inside a secure element but actually generating it inside a regular computer and keeping a copy of the private key. The answer is at credential issuance time the subject has to provide an attestation which shows that the key was generated inside a secure element. The details of attestation mechanisms are complicated, but at a high level the secure element will have its own device key pair which is certified by the hardware manufacturer; it uses the device key pair to sign the public key for the credential. The issuer can then verify the signature chain and know that the private key was generated inside the secure element.

It's important to realize that this attestation mechanism relies on the issuer^[8] trusting the hardware manufacturer (e.g., Apple), both to manufacture the device so it's really tamper resistant and not to certify device key pairs that aren't associated with secure elements (as well as not to have their own certification infrastructure compromised). However, this also means that this kind of device bound credential is an inherently closed system; you can't just go buying any device you want, but instead you have to buy one that is trusted, and at the end of the day the secure element works for the manufacturer, not for you.

Selective Disclosure #

An unfortunate property of physical credentials is that they require disclosing all of the information on the ID. The standard example here is that when you want to buy alcohol, the clerk only needs to know you are over 21 (in the US), but when you show them your driver's license, they also learn your name, address, date of birth, etc. There's no real way around this because the credential is just a dumb piece of plastic, but with digital credentials you can do better.

The standard mechanism here is what's called "selective disclosure". Instead of just signing all the information directly like with a WebPKI certificate, the issuer instead signs a list of hashes, with one hash for each attribute, like so:

Signed attributes for selective disclosure

In order to prove a specific attribute (e.g., date of birth), the subject sends the verifier three values:

The signed list of hashes.
The actual value of the attribute plus its corresponding random value.
The signature over the hash list.

Commitments #

The reason you hash the attributes plus the random values and not just the attributes themselves is that some attributes are low entropy (i.e., they only have a small number of valid values). For example, there are only about 40000 valid birthdates, so an attacker who has the hash of your birthdate can easily just hash all of them and look for a matching hash. If you also hash in a secret random value, then the attacker also needs to try every possible random value, which is prohibitive if you use a long enough random value. The technical term for this in cryptography is a commitment.

The verifier checks the signature over the list of hashes and thus knows that they are valid. It then hashes the attribute value and random and ensures that it matches the hash on the list, thus showing that the attribute value is valid as well. However, it doesn't learn the actual values for the other attributes, just their hashes. This means that the subject wants to buy alcohol or access a pornography site they can reveal just their birthdate and not their name or address.

We can actually do better here. In this case the subject is just trying to prove they are over a certain age, which doesn't require knowing their actual date of birth. The way you support this use case in a selective disclosure scheme is by having a set of attributes that say whether a user is over or under a certain age. For example, if the subject is 18, we might have the following attributes:

Attribute	Value
>= 16	Yes
>= 17	Yes
>= 18	Yes
>= 19	No
>= 20	No
>= 21	No

When the verifier asks the subject to prove that they are over a certain age, the subject can present the appropriate attribute, which doesn't tell the verifier anything else. This technique doesn't allow you to prove arbitrary predicates (e.g., "I was born on a Tuesday") because the issuer needs to encode each predicate as its own attribute. However, as a practical matter there aren't that many predicates you want to prove on a regular basis.

Note that there are a few subtle points here. First, the subject should show the assertion that is closest to the requested threshold (in this case the smallest assertion) to prevent leaking more information than needed (if you need to be 18 to use a pornography site, then you don't want to prove you are over 21). Second, the verifier can't be allowed to make repeated queries for different age threshold, otherwise they can determine your precise age to within the granularity of the assertions. For example, the ISO spec for mobile IDs restricts the verifier to asking for two values in order to support querying for an age range.

Identity Binding and Selective Disclosure #

As should be apparent at this point, we now have the makings of a remote age verification system: we issue everyone a digital credential and then they use it to remotely prove their age using selective disclosure. Just as with a physical ID, we can remotely authenticate by providing a photo to the verifier along with a video or a selfie showing the subject's face. However, selective disclosure means we need not do so, because we can just disclose the relevant attributes. Of course, in this case, the only thing binding the credential to the actual user is the signature from the device bound private key, which means we're leaning much harder on the secure element; if that is compromised and the key is disclosed than anyone can remotely authenticate, not just someone who looks like the subject.

Linkability #

A selective disclosure system improves privacy by preventing the relying party from learning any information about the user other than the specific attributes that are disclosed. However, there are still privacy issues because the credentials are linkable. Consider the case where the user uses their credentials twice:

With a porn site to prove they are over 18.
At the airport to prove their name matches the ticket.

The table below shows the information disclosed in each case:

Scenario	Information
Porn site	Signed block, age >= 18
Airport	Signed block, Name

The problem here should be immediately obvious: the signed block is the same in both cases, which means that it's possible to link the two transactions. Specifically, this means that the airport and the porn site can collude to allow the porn site to learn the user's name even though it wasn't disclosed to them. More generally, relying parties can collude to determine the union of all disclosed attributes for a single credential.

There's actually an old clever—though inefficient—trick to prevent linkage by the issuer in selective disclosure systems, due to David Chaum. It takes advantage of a technique called a blind signature, which allows you to digitally sign a message M without seeing M. In the credential issuance setting, the subject would generate the valid unsigned credential C and then send the issuer a blinded version Blind(C). The issuer signs this value and returns Sign(Blind(C)) and the subject then removes the blinding to recover Sign(C) (which also has a different signature).

This leaves us with the problem that the subject might generate a bogus credential (i.e., with false information) and because the issuer is signing a blinded object, it can't tell whether it's bogus or not. The trick here is that the subject instead generates more than one candidate credential, C1, C2, C3... Cn, blinds them all, and sends the blinded values to the issuer. The issuer then picks one at random to sign and asks the subject to unblind the others. The issuer then checks that the unblinded credentials have valid values and if so, signs the remaining blinded one. If any have invalid values, the issuer refuses to sign, and potentially attempts to punish the subject.

By making the number of candidate credentials sufficiently large, the chance of successfully getting an invalid but signed credential can be made arbitrarily small. This technique is called "cut-and-choose" after the famous trick for fair division.

The obvious fix for this problem is for the issuer to give the user multiple credentials with the same information and the user uses a separate one for each transaction; this prevents relying parties from linking up individual transactions because the signature blocks will be different.^[9] It does not, however, prevent the relying party from colluding with the issuer to track the user. There are a number of plausible scenarios in which this could happen, but perhaps the most concerning in the context of age verification is that the issuer (in this case the government) uses some legal process to require the relying party (the age verification provider or the porn site) to provide the credentials the user provided and then links them up locally in order to determine which specific users visited which sites or (depending on the design) viewed which content. We'll see how to address this issue below.

Mobile Driver's Licenses #

Of course, it's a giant pain to roll out a whole new digital credential system for age assurance, but the good news is that we don't have to. [Corrected -- 2025-10-19]. This kind of digital credential system is already being rolled out for other purposes in a number of jurisdictions, including:

mobile drivers licenses (mDLs) in several countries and about 15 US states (10 of which are supported by Apple Wallet).
The upcoming EU Digital Wallet.

Both of these implement the ISO/IEC 18013-5:2021 specification, which is conceptually similar to the system I've described above.

ISO 180135-5 credential data model

To orient yourself here to the terminology here, the entire credential is called an mdoc and the mobile security object (MSO) is the signed object that contains the list of hashes. The mdoc public key is the key tied to the device. Once you have this kind of digital credential you can use it to prove your age in the same way as we've just shown above.

Bootstrapping off of this kind of digital credentials has two attractive privacy properties:

There are going to be many reasons to get a digital credential (e.g., to prove your right to drive, authenticate online, or identify yourself at the airport). This means a lot of people will have one anyway and unlike many age verification systems, the act of getting a digital credential doesn't inherently reveal that you want to engage in some age-restricted activity (e.g., watching pornography).
You don't need to prove your identity at all (nor reveal your appearance) in order to prove that you are old enough to access age restricted content; you just need to prove that you are over the threshold age.

Unsurprisingly, both Apple and Google have proposed remote authentication systems based on digital credentials. These systems are generic and support arbitrary types of authentication, including age verification.

Apple Digital Credentials #

Apple's proposed system is a fairly straightforward implementation of the selective disclosure system described above, with the addition of a Web interface, based on the W3C digital credentials API, thus allowing the user to remotely authenticate to a Web site. The overall workflow is shown below:

Authentication with Digital Credentials

The process starts with the user loading their mDL into the device. As part of this process, the user is asked to take views of their face from multiple angles in order to ensure that they are the person associated with the ID. This process only has to be done once.^[10] The user also has to authenticate via FaceID or TouchID.

Later, when the user goes to a Web site, that site can use the the Digital Credentials API to request the desired attributes. The browser then queries the device for authentication. The device prompts the user about whether they want to reveal the requested attributes. When the user approves, they have to authenticate again in order to ensure that it's the same person as enrolled the device. Assuming the user consents, the device provides a verifiable response back to the browser. The browser provides the response back to the site, which then can verify the response and check the relevant attributes.

User Binding #

Because the device requires the user to authenticate, this system provides a measure of binding to the subject even if the site doesn't request the user's photo; only the user who enrolled the mDL is able to use it to authenticate. Note that this does not actually ensure that it's the same person that is associated with the credential, at least if the user is authenticating with TouchID, because nothing ensures that the same person provided their fingerprint as provided the mDL, so, for instance, person A could enroll their mDL on person B's phone. It seems like it ought to be technically possible for the device to match FaceID against the mDL, but based on Apple's description and the fact that they allow TouchID, I suspect it does not do so.

As with device binding, the security against user swapping depends on the security of the device. If the attacker compromises the device, they can bypass the local biometric check and authenticate as the subject of the credential whether they are the same person or not. Moreover, this assumes they aren't able to use a pass code, and Apple also appears to allow you to bypass the biometric checks entirely if you have accessibility enabled. However, in either case the fact that the iPhone hardware is closed and that Apple attests to its security is an essential feature of this design; if it weren't an attacker could extract the device key.

Privacy #

As discussed above, Apple's system attempts to preserve privacy by retrieving batches of credentials, each with its own device key, thus resisting linkage^[11] via credential reuse. This still does not prevent the issuer from linking up transactions, though it requires the relying parties cooperation (willing or otherwise) to do so.

In addition, Apple doesn't allow just anyone to request remote authentication. Apple requires relying parties to register with Apple Business Connect and getting a signing certificate that will be used to authenticate the request for remote authentication.^[12] As part of this registration, the relying party needs to document what attributes it will be requesting and why it needs them. This list will be enforced at authentication time, so that the relying party can't ask for extra attributes.

Zero-Knowledge Proofs #

It turns out to be possible to use some fancy cryptography to remove the linkability problem, by way of something called a zero-knowledge proof (ZKP). The details of how ZKPs work is way outside of the scope of this post, but the general idea is that you can use cryptography to prove that you know values with arbitrary properties.

Proving Program Output #

For the purposes of this discussion, you should think of a ZKP like this: The prover and the verifier agree on a program F (it can even be written in a conventional programming language). F is designed to run on two pieces of input:

A "public" input p known to both the prover and the verifier
A "secret" input w known only to the prover^[13]

F is designed so that given the inputs p and w it outputs either 1, indicating that p and w are valid ("accepting") or 0 ("rejecting") indicating that they are not. For example, suppose the prover claims that they know a message m such that SHA-256(m) = x. Then the program would look something like this:

function F(p, w) {
  if (SHA256(w) == p) {
    return 1;
  }
  return 0;
}

The public input (p) to F is the hash output x and the private input (w) is the secret message m. If m and x correspond, then F returns 1, and otherwise 0. It's obviously the case that the prover can run F and check the output themselves, but the verifier cannot because they don't know w, which is supposed to stay secret. The point of a zero-knowledge proof is for the verifier to convince the verifier that they ran F—or at least that they could have run F—with the output 1. In this context, the proof P is some value that the prover sends the verifier that does that. The verifier then checks P against F and p and if they all match, then the verifier is convinced that the prover knows w (in this case, the message m).

The way to think about this is that the prover wants to persuade the verifier that if the verifier were to run program F on w and p, they would get the right answer, even though the verifier didn't actually run it. So in this case F checks that the input value m matches the hash output x, but instead of letting the verifier run F, we offload the checking to the prover and the prover then convinces the verifier that it did the checking correctly. I know this all sounds like magic and you're just going to have to take my word for it—or more to the point the word of the cryptographers who really understand it—that it works.

In order to apply a ZKP system in practice, the prover and the verifier need to agree to the program F that the prover is going to run. That program can—in principle—do anything, but the verifier needs to be able to see the program to verify that it actually does what it is supposed to. Otherwise the prover could say "I'm running a program which checks the hash" but actually just run one that always returns 1. Note that part of the proof is that the prover actually ran F so they can't say they are running F and actually run F', but that doesn't help if the verifier can't actually examine F and be sure it does the right thing. Once the program is agreed upon, it gets compiled down into what's called an "arithmetic circuit",^[14] which is what the ZKP actually proves, so it's common to talk about the "circuit" that the ZKP works on, rather than the program, but they amount to the same thing.

Applying ZKPs to Digital Credentials #

Assuming we have a ZKP system that allowed us to prove correct execution of an arbitrary, program, now we have the problem of how to use that to verify a credential. As a reminder, let's go back to the skeleton of the authentication system without ZKPs, shown below:

Digital credentials without ZKP

The key point to focus on is the last line, where the site verifies the response. This is the source of the privacy problem, because it requires the site to have the credential. However, all the site really needs to know is that if it had verified the response, everything would have been fine, so we're going to use the same trick we just used above, which is to offload the job of verifying the response to the device, and instead have the device prove that it verified the response and everything was fine. This gives us the flow below:

Digital credentials with ZKP

Obviously, this has much better privacy properties because I don't actually disclose either the credential C or K_pub, so the relying parties can't link up multiple authentication transactions, even if they use the same credential (this means there's no need to issue new credentials for each transaction). Similarly, the issuer cannot link transactions.

It's important to recognize that in order to actually deploy this system, the site and the device need to agree on the program F which needs to do the job of verifying the credentials and associated signature and checking the disclosed attribute. This is a nontrivial piece of software and obviously needs to be correct. The details of how this will work may vary some between designs, but in general, there needs to be some deterministic way to go from the set of attributes that the site is interested in into the the program (circuit) that the device is going to use for the proof.

Google Wallet and ZKPs #

Google recently announced that they are going to be supporting age verification via zero-knowledge proofs, starting with a partnership with Bumble.

Given many sites and services require age verification, we wanted to develop a system that not only verifies age, but does it in a way that protects your privacy. That's why we are integrating Zero Knowledge Proof (ZKP) technology into Google Wallet, further ensuring there is no way to link the age back to your identity. This implementation allows us to provide speedy age verification across a wide range of mobile devices, apps and websites that use our Digital Credential API.

We will use ZKP where appropriate in other Google products and partner with apps like Bumble, which will use digital IDs from Google Wallet to verify user identity and ZKP to verify age. To help foster a safer, more secure environment for everyone, we will also open source our ZKP technology to other wallets and online services.

Unfortunately, this is nearly all the public information we have from Google on this topic. The only other thing they have published besides this blog post is a technical paper and corresponding implementation for a new zero-knowledge proof system called "Longfellow-ZK". This seems like interesting work, but it's only a small piece of the puzzle. The context here is that we want to leverage existing digital credential systems, but unfortunately those existing credentials are often signed with ECDSA, and for technical reasons, many existing ZKP systems struggle with proving stuff about ECDSA signatures. By contrast, the Longfellow-ZK system is able to efficiently cover ECDSA-signed credentials, and the authors show how to use it to compute proofs over those credentials.

It's clear how this is useful, but it's only a piece of the puzzle, and we don't seem to have either a complete system design or an actual protocol. What Google has not done—or at least I haven't seen—is publish the precise details of how to bind this to the Digital Credential API. In particular, we don't have:

The details of every message.
The exact structure of the circuit or an algorithm to generate the circuit.
Any mechanisms for rate limiting (see below).

Without these details it's a bit hard to say too much about how well this is going to work at scale.

Compromised Devices #

As discussed above, much of the security of a digital credentials system depends on the security of the device key. If the device key is compromised, then the attacker can use that key to impersonate the user. There are two main threat models here:

The attacker gets temporary control of the user's device and extracts the device key without their permission.
The user and the attacker collude to extract the device key.

Both of these threats are real, though our major concern is probably the second one, especially for age assurance. For a simple impersonation attack, you may want to impersonate someone in particular, but for age assurance, you just want to impersonate anyone who is over 18, then it's probably easier to use your own ID or the ID of some confederate, especially because the privacy features don't require you to disclose your own identity, just demonstrate that you're over 18.

These privacy features are also the challenge for detecting this form of attack. Naively, a relying party (RP, which is to say the verifier) could keep track of how many times a given identity was used and then investigate any identity which seemed to have excessive usage, but if you have a system like selective disclosure or zero-knowledge proofs, then things get more complicated.

The public descriptions of these kinds of systems I have seen are pretty vague about how they plan to defend against this form of attack; they mostly just seem to assume the secure element won't be broken, which isn't necessarily a safe assumption.

Selective Disclosure #

As noted above, selective disclosure systems aren't truly unlinkable: if you use the same mdoc twice, then the relying party (or parties) can link up multiple presentations. However, as noted above, a good implementation will get a fresh mdoc for each presentation. In this case, the issuing authority can still link up presentations but the relying party cannot.

However, you can take advantage of the fact that each new mdoc requires an interaction with the issuing authority. This creates a number of opportunities for detection. First, you can do some traffic analysis on the devices that ask for new mdocs, which they'll need to do so fairly often, not just for privacy reasons but also because they expire. For instance, if you see repeated queries from different IP addresses, that is potentially suspicious. Of course, whoever originally broke the credential can proxy your requests, but this makes things more complicated.

Another alternative is to rate limit presentations. The basic intuition here is that if there are N issuers and the user gets M then the attacker can only do N*M presentations before they have to use the same credential twice on one RP. This leaves two avenues for detection:

An RP noticing a lot of reuse
The issuer noticing that the user gets an excessive number of requests for mdocs.

Importantly, you don't have to detect every reuse: after all, you can always lend your phone to someone else, which isn't really detectable. Instead, the idea is to limit the number of authentications you can get out of successfully attacking a single device, thus forcing the attacker to expend the costs of enrolling multiple real identities—or stealing legitimate devices—and then breaking the devices to extract the device key. If it costs $500 (made up numbers) to break a device and each key can only be used for 5 users, this means that it needs to be worth $100 for each user who wants to circumvent age assurance.

Zero-Knowledge Proofs #

The situation with ZKPs is more complicated because the subject can create as many ZKPs as they want without having to go back to the issuer of the original credential. This means that neither of the mechanisms I described above will work in this context:

You can't rate limit at the issuing authority because you don't have to contact the issuing authority.
The ZKP doesn't include the mdoc, so you can't trivially compare multiple presentations by matching the mdocs.

There are, however, techniques for rate limiting in ZK authentication systems. The basic idea is that you define what's called a "nullifier", which is a characteristic value for the pair of subject and relying party (think Hash(device-private-key, RP-identity). When a user authenticates to an RP (or in this case proves their age), they include the RP-specific nullifier and the proof shows that it was computed correctly. If the same credential is used to authenticate to the same RP twice with the same user, the same nullifier will be used and so the RP will be able to detect reuse.

Obviously, this trivial design allows for linkage of multiple presentations, but we can set an arbitrary rate limit by including more inputs in the nullifier. Specifically, we can have:

An "epoch" value corresponding to some time window.
A counter which must be between 1 and N where N is some upper limit.

Put together, these constraints allow for N authentications per RP per epoch while remaining unlinkable. However, if someone tries to authenticate N+1 times, then they have to reuse the counter and the RP can detect that a nullifier has been reused and reject the authentication attempt.

It's also possible to extend this technique to not just reject the authentication attempt but determine which device was broken. Along with the nullifier, the authentication also includes a secret share for the user's identifier (or the device ID) which is designed so that if the counter is reused, the RP will be able to put together the shares and reconstruct the device or user identifier. Once the compromised device is detected, the issuing authority can revoke its ability to authenticate (most likely by just refusing to issue more mdocs and letting the old ones expire).

Note that the attacker can make this defense harder to mount by retrieving multiple mdocs with different device keys and providing them to the separate users, but each issuance is visible to the issuing authority, which can impose rate limits.

Again, it's not clear what Google is actually doing here; I'm just describing some avenues one could pursue.

Multiple RPs #

This whole system works a lot better if there are a small number of RPs. If there are a lot of RPs, then it becomes harder to detect reuse. You need to set the per-RP rate limit high enough that a legitimate user won't exhaust the limit during normal usage. It's likely that, at least for porn sites, a legitimate user will only use a small number of sites, but if there are a lot of porn sites, this leaves plenty of room to spread a bunch of illegitimate users across those sites. Of course, this still leaves the attacker with the problem of coordinating users so they don't accidentally overflow the limits, but it makes the detection problem harder.

I think there's a real practical question about the distribution of sites which require age assurance. Most content categories have really top-heavy distributions where the vast majority of traffic goes to a few sites (e.g., Facebook, Instagram, Twitter, TikTok, for social networking), and they aren't interchangeable, in which case just imposing rate limiting on the top site is likely to be fairly effective.

Adult sites don't have the network effects that social networking sites have, so it's possible they are more interchangeable and that users can gravitate to long-tail sites, as Dennis Jackson argues.^[15] It's hard to know in advance whether this is true, but what we can do is look at existing traffic patterns, which are similarly top-heavy:

Traffic to the top porn sites

Note that some of the sites are owned by the same entities, so one would imagine they could cross-check between those sites.

This doesn't exclude the possibility that users will switch to lower-popularity sites if they have to, but it's definitely going to be a lot more work to find sites that are this unpopular compared to the big sites, and given how many of these sites consist of user-uploaded content, it seems likely there is a pretty significant dropoff in how much content there is on the smaller sites (I haven't checked!).

The Bigger Picture #

ZKP-based authentication and age assurance systems are extremely technically cool, but they're only a component in a larger system.^[16] When used properly, a ZKP system allows you to disclose/prove attribute A while not disclosing attributes A, B and C, but this doesn't mean that the RP can't learn those attributes via some other mechanism. For instance, if you connect to a server from your home without any form of IP concealment, then the server may well be able to learn who you are in any case.

In addition, as pointed out by Hancock and Collins, the RP may "overask" for attributes it doesn't really need, counting on the user not to notice that they're disclosing their name or precise age. Your client software can help defend against this by restricting the set of attributes an RP can request (Apple requires RPs to register which ones they will request and hopefully does some auditing of which ones they really need), but all of this is outside the scope of the ZK system itself. Similarly, if it's simple and easy to prove your age or other attributes, we may see a form of induced demand where you have to do so more and more often.

Finally, the proof systems themselves are very complicated and tricky to get right, especially at the current level of technological development. There have been some high profile cases where ZKPs were deployed and then found to not actually be secure in practice. This doesn't necessarily lead to a privacy problem from the user's perspective as most of the issues have instead allowed an attacker to prove something false rather than leaking the user's information. However, it's obviously still not great for deployment in practice.

With all that said, it's important to remember that the reference point here is the wide deployment of existing age assurance systems—whether of the facial age estimation or the "selfie with ID" variety—that don't conceal the user's identity from the verification service at all. From a purely technical perspective, designs based on selective disclosure or ZKPs are likely to have superior security and privacy properties compared to these existing systems.

See AAMVA DL/ID Card Design Standard 2020, Appendix B.4 for the security features. ↩︎
Encoded in PDF417 and conforming to AAMVA DL/ID Card Design Standard 2020, Appendix D. ↩︎
In some contexts, you might also want to sign the verifier's identity, but we don't have to worry about that right now. ↩︎
At least for the purpose of authentication. You still may not want everyone knowing your birthday. ↩︎
This is precisely the situation with Web server authentication: the server will give its certificate to anyone who asks, but you can't impersonate the server unless you know its private key. ↩︎
Or if their device is compromised. ↩︎
Though it's also worse in some ways, because once they get their ID card back, the younger sibling can't use it; with a digital credential they can use it indefinitely. ↩︎
The user doesn't really have to trust the manufacturer in this case, at least not more than they do for other purposes. ↩︎
Note that the device also needs to generate a fresh device key for each credential. ↩︎
See here for some discussion of the privacy properties. ↩︎
Apparently there is some case where it will reuse the credentials if it runs out and cannot contact the issuer in time. ↩︎
video at 12:20. ↩︎
The technical term for w is a "witness", hence w ↩︎
At least in many ZKP systems ↩︎
In the context of users selecting sites that do weaker or no age assurance. ↩︎
See commentary by Alexis Hancock and Paige Collins from EFF, Chatel et al., and Celi et al.. ↩︎

Ultra Tour Monte Rosa (UTMR) Race Report

2025-09-21T00:00:00Z

The pre-race picture. I look happier now than I will be later.

This year my occasional^[1] training partner Chris Wood was selected in the UTMB lottery and asked me to come over to Chamonix and crew him. Europe is a long way to go and not race, so I looked around and finally settled on Ultra Tour Monte Rosa (UTMR) as my "A" race. UTMR is conceptually similar to UTMB in that it's a 170K tour around a mountain in the Alps but it's about 10% more climbing than UTMB and considerably more technical, so times are a lot slower. UTMR is about a week after UTMB, so after crewing Chris I took the train from Chamonix to Grächen on Monday, giving me a few days before the race start at 4 AM Thursday.

Course Overview #

UTMR is a serious mountain race with over 10000m of climbing.

UTMR course. From my actual Runalyze track.

UTMR "final" race profile

Conceptually, I broke it up into four main sections corresponding to the locations where you could have drop bags and conceptually bigger aid stations.

Start to Zermatt (34.2K)
Zermatt to Gressoney-la-Trinite (77.4K)
Gressoney-la-Trinite to Macuagnaga (123.6K)
Macugnaga to finish (167.9K)

The segment to Zermatt is the fastest—though still with over 2000 height meters of climbing. It's important to get through this section fast because after you leave Zermatt there's a big climb up to the glacier and then a 2K glacier crossing. For obvious reasons you want to cross the glacier during the day, and so there's a tight (9 hr) cutoff at Zermatt.

After you get over the glacier you're looking at a long mostly net downhill section into Gressoney-la-Trinite, but with a significant climb partway through.

Followed by Gressoney-la-Trinite you have a series of three really big climbs. The first two are before the Macucnaga aid station and then after that there's only last big climb and descent followed by a smaller (only 700 hm!) climb, some rolling stuff, and then a descent into the finish.

I'd managed to recon the first few kilometers (nice!) and the last few kilometers (incredibly steep), so I had a bit of a sense what to expect here. I did the last two km on my first day into Grächen, right at the time when a bunch of runners from the (even longer!) Swiss Peaks race were coming through; they looked tired and still had a long way to go!

Overall Logistics #

UTMR is by far the longest race I'd ever had to do in terms of time so it presents some real logistical challenges, especially as I was doing it without crew.

Food #

Food at an American race tends to be dominated by sports nutrition such as energy bars, gels, sports drinks, etc. (aka "space food" or "engineered food"). On longer races like hundreds you'll often see hot "real food" like soup, quesadillas, pancakes, bacon, or sometimes even burgers as it gets later in the race. By contrast, European races tend to be much heavier on some kind of real food from the very beginning, but it's mostly snacks like bread, cheese, charcuterie (seriously!), with maybe a small selection of sports food, and then again some hot food as you get later into the day.

I've done nearly all my training with sports food, and I wasn't sure how I'd feel about bread and cheese^[2] and I didn't have any experience with the sports drink that UTMR was serving, so I planned to carry most of my nutrition with me; UTMR had 3 drop bag locations so this meant I could carry about 1/4 of my food for each segment, though in practice I expected to try to eat some of the real food as well. This actually wasn't so bad in terms of how much I had to carry between aid stations but did mean I had an enormously heavy bag to carry to Chamonix and then to Grächen.

The contents of my drop bags

Gear #

European races tend to have more serious mandatory gear lists. For example, here's what UTMR requires:

Requirement	My gear
Mobile phone	Nokia 105^[3]
Fully functional head torch(s) with replacement batteries	Petzl Nao RL (main), Petzl e-lite(backup)
Bottles or bladders with capacity to carry 1 litre	Standard 500ml softflasks
Emergency food rations in a sealed ziplock bag (400 calories)	Maurten, SIS
Emergency bivvy bag	SOL Emergency Bivy
Whistle	On pack
Elastic bandage / strapping	Coban
Drinking cup (cups will not be provided at refreshment points)	Hydrapak Speedcup (gimme from Lake Sonoma 50)
Waterproof jacket with hood	Inov-8 Raceshell (discontinued)
Waterproof trousers	Raidlight Ultralight MP+ (older model)
Warm long-sleeved thermal top layer	Patagonia Capilene Thermal (borrowed from Chris)
Long running trousers or trousers that cover over the knee	Patagonia Terrebonne trail joggers
Warm hat	Smartwool hat
Gloves	North Face Flashdry
GPS tracker(provided at race registration)	N/A
Identity papers	N/A
Microspikes	Rented from race organizers
Bowl and spork	Sea to Summit Frontier Ultralight Collapsible Cup, Sea to Summit Frontier Ultralight Spork
Sheet sleeping bag	Mountain Laurel Designs Sleeping Bag & Quilt Liner

UTMR checks that you have all this stuff at registration before they give you your race number, but of course this is just the minimum, and when I got back to my hotel I had the following email:

SEVERE WEATHER WARNING
Tomorrow afternoon from around 4pm onwards conditions crossing Teodulo (the glacier) and into Italy are expected to become very cold and windy, with snowfall. The temperature will be -2 deg C, with wind chill factor down to -10 deg C. Winds could be up to 50-60 km per hour.

For you safety please carry extra clothing including warm pants, thick gloves, warm hat, warm (duvet) hooded jacket. We suggest putting warm gear in your dropbag for Zermatt so that you have protection through the bad conditions.

The race will proceed unless our security team advises us that conditions have become unsafe.

This definitely freaked me out and it would obviously have all been a lot easier if I'd known it in Chamonix which has about 5 outdoors stores per block. At this point I was definitely regretting not bringing my tights or borrowing some from Chris, but there were a few open stores and I ended up buying a pair of hiking pants, a thick warm hat, and some thick windproof gloves. I'd already brought my Patagonia Micro Puff Hoody so I was covered as far as a puffy ("duvet jacket") goes. All of this extra stuff is bulky and heavy, but based on the weather reports I wasn't going to need it till after the glacier, so I was able to store it in my Zermatt drop bag. Also in the Zermatt bag: the microspikes which are only needed on the glacier.

I've done previous races on headlamp only, but for this race I decided to add a waist light (UltrAspire 600); I have friends who've used them at races and said it was dramatically better and I figured I'd be out for two nights and this was the time to use it. I expected Gressoney-la-Trinite would be somewhere a bit before midnight and it got dark around 8 or 9, so I decided I'd be OK with just the headlamp till Gressoney-la-Trinite, thus avoiding having to carry it halfway. I also left a pair of extra shoes in my Gressoney-la-Trinite drop bag, which turned out to be a really good idea (see below).

Pre-race I spent some time dithering about what shoes to use for UTMR; I did most of this season in a pair of Salomon S/LAB Genesis, but on my last outing, I started to have some discomfort in my feet about half-way through and so I decided to try out the Salomon S/LAB Ultra Glide, which is much higher stack and bouncier. I ordered a pair of the Ultra Glides when I was in Flagstaff, but I only had about 30 miles on them and wasn't sure how they would feel over a 100 miles. On the one hand, the Ultra Glides seemed to have a somewhat tight toe box and I was worried they would be too tight if my feet swelled during the race, but on the other hand I thought it might be nice to switch to something bouncier half-way. Eventually I decided to be optimistic and start in the Ultra Glides and then have the Genesis in my Gressoney-la-Trinite bag.

Pre-Race #

I spent Tuesday and Wednesday kind of bumming around Grächen and trying to eat well and sleep as much as I could. It's a tiny town and everything is within walking distance, so I walked over to the local market and scored a bunch of food, including some gnocchi and pesto for the night before (one of the benefits of being in an AirBNB is that you can cook). I slept pretty well Monday and Tuesday night but had a really hard time Wednesday night. Usually I'll be able to fall asleep pretty well but will keep waking up but this time I spent a lot of time just lying in bed doing relaxation exercises and trying to fall asleep. Eventually I did get a few good hours right before my wakeup time, but it wasn't amazing.

I timed the start pretty well and got to the start at about 3:35 and then realized that the volunteers wanted us to put pre-printed labels on our drop bags—so that's why I had four wristband type things in my packet—and I ended up having to run back to my AirBNB, grab them, and then come back. Fortunately my AirBNB was really close, so I still made it in time. In retrospect, I doubt it would have mattered, but I was in pre-race rule following mode.

Start to Zermatt #

The first part of the race went quite well. You start by running through the town for a kilometer or so, followed by a relatively short but steep climb and then transition to a longish rolling section. The rolling section is fairly runnable but still slightly technical and narrow, and people were still fairly packed in, so I just tried to cruise through it without expending too much effort.

Following a shortish descent, we began the first big climb, 5.8 km and 1011 hm up to the first aid station at Europahutte. This part went relatively smoothly as it was early, everyone was relatively fresh, and this early in the race everyone wants to take it easy. I took a short stopover at Europahutte to fill my aid station and then it's a short slightly technical downhill followed by what is the longest foot suspension bridge in the alps, the Charles Kuonen Suspension Bridge, at almost 500m long.^[4]

Charles Kuonen Bridge: from TripAdvisor

There is a fantastic view from the bridge, but to be honest I found it a fairly unpleasant experience because the bridge sways quite a bit and you can hear the cables creaking. Intellectually you know it's safe, but it just takes one look down to wonder whether the engineers really know what they're doing. I wasn't excited about the crossing, but it's not like you're going to turn back, so I just gritted my teeth, made sure I had one hand on the rail, and kept going. A few people had passed me on the descent from Europahutte, but I found myself wishing more had, because some of the people behind were crowding me, which didn't help matters.

The original UTMR course stays up high for a while but due to some trail closures, from here there was a fairly rapid descent down to the valley floor and then the aid stations in Attermenzen and then some easy running on gravel road to Zermatt. This is a bit faster than the original route and as a consequence I was way ahead of schedule and the cutoff for leaving Zermatt, so things were looking good, at least as far as not having to cross the glacier in the dark went.

I spent about 20 minutes in Zermatt overall, retrieving all the stuff from my drop bags, cramming the extra clothes into my dry bag, etc. This is obviously longer than ideal, but in a long race like this, I don't mind spending a little extra time at the aid stations, especially the ones with my drop bags. Even so, I almost left my spikes in the bag, which would have been disastrous, as they are mandatory gear for the glacier crossing and it actually would have been quite sketchy without them, even though there wasn't really anyone enforcing it.

Zermatt to Gressoney-la-Trinite #

From here on in, things get real, starting with a 1389m climb up to to Trockenersteg. This is actually a pretty easy grade as far as UTMR goes (14% average) but when added up with the glacier crossing it's the longest more or less continuous up on the course. I hit the top here feeling pretty good—it's at high altitude, but I'd spent three weeks in Flagstaff getting acclimatized, with the result that there's still some negative impact, but I didn't feel that bad, unlike some of the people nearby me, who were clearly feeling the altitude.

Trockenersteg is a tiny aid station, basically just a table set up in the doorway of the building at the top of the ski lift; there were bathrooms and the like and probably some kind of cafe (maybe closed?) but the station itself was just dudes with fluids and energy bars. At least it was shaded from the wind, though, which let us get our warm gear on in preparation for the glacier crossing, which promised to be windy. It's about 1km to the ice itself and from there it's about 2 miles on ice and snow.

We just sort of trotted over to the ice transition and then everyone sort of collectively sat down and put on their spikes and maybe some warmer clothes, and then headed out onto the ice. For my money this was the best part of the race. You're up above 3000 m (10000 ft) and walking over a giant piece of ice—how can that not feel epic? Now the truth of the matter is that this section of the glacier is between two lodges and, has, I'm told, been groomed, but nevertheless, it feels wild, especially if you live somewhere, like I do, where there is basically no snow. Once you get past the snowfield, there is a relatively short section on rock up to Teodul and then it's 16.9 km and 1600 m down to Teodul.

This downhill went pretty well, except that at some point I tripped and went down hard, hurting^[5] one of my ribs and tweaking my wrist. This wasn't great and led to some discomfort throughout the rest of the race, but nothing that was going to stop me. Thanks to the runner whose name I've forgotten but was with me at the time who helped retrieve my poles and made sure I was OK. Somewhere on the downhill I ran into Stuart Secker, who I'd met on Monday and had dinner with. He had a lot of experience with 100+ mile races, especially difficult stuff like Mogollon Monster and UTCT, plus he'd reconned some of the course, so I decided to stick with him for a while, and we headed to Rifugio Ferraro together.

By the time we hit the Rifugio it had been raining on and off, and it was clear that the bad weather had started to roll in. The guidance from race officials was a bit equivocal, something like:

It should get better in a few hours.
We're not canceling the race.
We advise you to stay here for a bit.
We won't make you stay.

I'm generally not a fan of waiting things out unless they're really bad and neither was Stuart, so after a bit we decided to head out.

From Rifiguo Ferraro to Gressoney-la-Trinite is a substantial climb (~800m) followed by a longer downhill. Pretty soon it started to rain fairly hard and then we were getting lightning and thunder, though the lightning seemed modestly far away. At this point I had on a warm top plus my rain pants and my rain jacket, but not my rain gloves or (I think my second warm bottom layer). Unfortunately, once it's raining this much, you really don't want to take off your rain gear to put anything on underneath it, so I was mostly just stuck being a bit uncomfortable. Fortunately, the climb itself was mostly rock and wasn't too slippery, though it wasn't just smooth path either.

By the time I hit the top, it was dark, really windy, I was cold, and anything that wasn't covered by waterproof gear—in particular my hands—was cold. I tried to find a location out of the wind in the summit to put on my warm gloves, but they hadn't been in the dry bag and were so wet that I couldn't get them on with my stiff hands, so I ended up just getting colder and watching people pass me before I headed down. I'd stopped partway up for a minute or so and had managed to lose Stuart, but managed to run some this first section a bit and catch up with him. His take was that the most important thing was just to lose altitude as fast as we could—thus getting to where it was warmer—rather than try to get warm immediately, so we pushed on.

This descent was all dirt and would have been super runnable except that with all the rain it was instead really muddy and slippery and my feet came out from under me and I fell on my ass a number of times. Nothing was really hurt other than my pride, but I definitely ended up covered in mud. These were mostly minor falls, but then later Stuart fell a fair bit harder and tore his pack, so a hard bit all around.

Gressoney-la-Trinite to Rifugio Pastore #

Gressoney was the first aid station with beds, and my original plan had been to get some sleep there to avoid my traditional 3 AM low spot, but when we arrived we were told that the beds were all in use and there weren't even any spare blankets. This wasn't an immediate disaster because I needed to do some maintenance in the form of changing out of wet clothes, swapping stuff out of my drop bags, etc., and I was hoping that by the time I was done a bed would have opened up.

Once I got into drier clothes—including the warmer hiking pants I had bought—I set about fixing my feet; after hours of being wet and muddy they had started to wrinkle up and I knew from past races that this can lead to irritation between the wrinkles. Pretty much whenever I stepped I was starting to get discomfort and this can be a race ender, so I knew I had to attend to it. The main fix for this is to get them dry and keep them dry. I was able to get some paper towels from the volunteers but medical didn't seem prepared to do anything, and when I asked them for diaper cream^[6] they didn't have it, but fortunately Stuart actually had some, so with the help of a surgical glove^[7] borrowed from another racer, I was able to get my feet nicely covered with cream and then get new socks on. I was somewhat distressed to discover that one of these socks had a small hole in the toe, which would come back to haunt me later, but at this point I didn't have much in the way of choice.

I also had to decide which shoes to wear: I was finding the Ultra Glides quite comfortable, with no real discomfort, but at this point they were totally waterlogged, and I decided that the best thing to do was to swap them out for the S/LAB Genesis, which were dry and have a Matryx upper which tends not to absorb so much moisture. I think this was the right call, because at this point I was super worried about my feet being too wet, but I wish I'd tried the Ultra Glides earlier; if I had I might have just had two pairs of these. I also picked up my UltrAspire waist lamp, which meant I had twice as much light going out of Gressoney as heading in. From here on, there are three big climbs, all between 1200 and 1600 m, and then the rolling bit to the finish, but this gave me a set of milestones to work with.

I lurked around Gressoney a little while longer, and tried to get some sleep on the floor, but without much success. Stuart told me he was thinking about dropping—he eventually did—and Karl, another guy I had been running with told me he was definitely dropping. I didn't want to head out entirely on my own in the dark so I ended up hooking up with three French guys for the next stretch.

Apparently I'd rested enough and warmed up, because I felt reasonably good coming out of Gressoney, and quickly found myself dropping my companions. I'm not sure how eager they really were to have some non-French speaker tagging along anyway, so I eventually just ended up pushing through this section largely on my own. I don't actually remember this bit that clearly, probably because it was in the dark and I was undercaffeinated—I was still hoping to sleep—but eventually I made it to the top of the climb at Passo dei Salati, which was basically a ski lodge. This rifugio was like the house of the walking dead full of race zombies. There weren't any beds but there were some people stretched out on benches trying to sleep or just asleep on tables, and after grabbing some soup and tea (no coffee available!) I tried to do the same, and I think got maybe 5-10 minutes. Not enough.

From Passo dei Salati to Rifugio Pastore is a long downhill followed by a climb of about 400 meters to the Rifugio. In theory that shouldn't have been that hard but I managed to make it about 5 feet out the door before realizing I needed more clothes, so went back inside, layered up and then headed back out. This section was a bit tricky to navigate in the dark and I ended up briefly teaming up with some other people to find the way down, but eventually got separated.

This segment was fairly runnable once it got light, but I started to have a really low spot partway through, I think due to a combination of not eating enough (see below) and not sleeping (this is why I wanted to sleep at Gressoney!). A few times I just sat at the side of the trail on a rock and tried to recover and eventually Mick Caren stopped by, asked if I was OK, and offered to wait with me. I sat for a few minutes and then we set out together, which was super helpful, and we ran together for much of the rest of the race. It was fairly uneventful down to the bottom and then the first part of the climb to the Rifugio was on asphalt and gravel road so Mick and I were able to hike that nice and fast. Eventually, we had to turn off onto single track again, and things got steep, but it wasn't that far to the Rifugio.

At this point I was super tired, but fortunately they had a sleeping room and there were plenty of beds, so I settled down for a nap, and asked one of the volunteers to wake me up in 20 minutes. I'm not saying it was great, but I did manage to get some sleep, which was a huge relief and I felt much more prepared for the next two climbs. When I woke up, Mick was still there and he told me that he'd just gotten a message that due to a rockfall the race was being truncated at Saas Fe (147 km) and we'd (somehow) be shuttled back to the start. I'm not going to say I was 100% sad about by this: I obviously wanted to finish the race, but I was also getting pretty tired.

Knowing that we only had to really make the next two climbs and then it was over gave us all some new energy and we set out at a pretty good pace. At this point, some of the stage racers were starting to pass us^[8] which made it a bit hard to judge your pace, but also was a bit energizing to see people who were (1) fresh and (2) impressed by you.

Rifugio Pastore to Macucnaga #

This next stretch is the longest without aid in the entire race (21.6km) and requires you to go all the way to the top of the pass and then back down again. I started out feeling OK and things were looking good and then partway up the weather started to turn, first into rain and then into hail. I really didn't want to get soaked again so I stopped to change my gear and lost contact with the people I was with for the rest of the climb, about 1200 m.

The climb itself had reasonable footing, consisting mostly of moderate-sized rocks and scree, with a foot-wide or so ledge of flat rocks set in the side of each switchback, so you had the choice of hiking up the slightly unstable scree or adapting yourself to the ledge. It seemed like most people did a combination of the two of these, and I did as well. I wouldn't say I was feeling great, but I was managing to make OK time, albeit having to stop several times to put on gear or take it off.

Eventually I hit the top and started the long descent, which is where things started to go really sideways. A common phenomenon in most ultras is that as your legs get tired it gets harder to run downhill and you actually want to hike more and more, but this was something new: the downhill was really difficult single track with big rocks and roots. Someone who was better on the downhill than me or fresher could run this—and a number of the stage people came by—but I was reduced to mostly hiking and some very slow jogging and certainly was never able to get a rhythm. This went on forever and every time you started to think it would open up it would be a false alarm and you'd just have to climb over some new rock. This was an incredibly demoralizing section for me because I was expecting to be moving moderately fast in this section but actually I was going about the same speed down as up.

I ran most of this section with Jamie Hardman, who had sort of been trailing me on the climb but then caught me on the downhill and we both kind of suffered through it together until we finally hit some easy fire road. We were about 3km from the Macucnaga aid station when suddenly I started to have some real GI problems and I had to let Jamie go while I ducked into the woods to take care of business. At the end of the day, though, I was moving a bit faster than he was and so I got to the last AS only a few minutes later.

Macucnaga to Saas Fe #

Macucnaga is the finish of stage 3 of the stage race, and seemed to be in some kind of restaurant/hostel kind of thing. Everyone was kind of lurking around the restaurant feeling half-dead and knowing they had to get up and keep going but not really wanting to either.

This was the last drop bag location and so I was able to ditch some of my stuff—though not too much—and change my socks again. As soon as I got my shoes off I was able to see that I had a lot of wrinkling and ended up having a long exchange with the volunteers and the medic about whether they had any diaper cream. They didn't and wanted me to go see the race doctor, which seemed like a lot of overhead. Fortunately, after 10 minutes of hanging around barefoot my feet seemed to have dried up enough that the wrinkles were abating, so I just smeared as much Sportslick on them as I could manage, put my sock on, and crossed my fingers. Mick had gotten in a ways before Jamie and I, but he was still hanging around and we all decided to head out together.

The last climb to Monte Moro Pass is the steepest long climb of the whole course, clocking in at 1500+ hm over 6.4 km, at an average grade of around 23%, so we knew we were in for something special. The initial part of the climb was actually pretty encouraging: well groomed rock in a better version of the previous climb, but soon enough it veered off into single track. This pattern continued for some time, with a section of rough fire road and then you'd have to do some rocky single track which would eventually come back to the fire road, just to add insult to injury. I had some more GI issues partway up but was able to find a place to pull off while everyone waited. I came up to find that they were chilling with some goats, so I guess they had found a way to entertain themselves.

Eventually, this all gave way to the real mountain trails, which is to say big rock slabs without much of a trail where you just kind of go flag to flag. By this time, it was getting dark, windy and cold. I bundled up early while everyone else waited but then about 15-20 minutes later they were getting cold and we had to try to find something slightly shaded from the wind so they could put their gear on. This climb is really deceptive because you can't see the finishing hut for much of the way, but you can see a a hut/ski lift terminus cut into the side of the mountain and you keep thinking you're heading towards that, but actually you just bypass it entirely.

The last 300 height meters of climbing are almost certainly the worst because you're at high altitude, and it's rocky and steep, and you're constantly having to high step and then maybe not make it and fall back onto the previous step. We could see another runner maybe 2 minutes ahead of us and he kept stopping—to catch his breath maybe?—but we never quite caught him. Finally, we hit the ridge line and then it's a short few hundred flattish meters to the aid station, with the promise of it being all (mostly?) downhill from there.

It turns out that "mostly" is doing a lot of work here. First, the aid station isn't actually at the top of the peak. Instead you need to climb up to the top to where the Golden Madonna Statue is.

The Golden Madonna Statue. From Komoot.

This isn't really a technical climb, but what it is is a bunch of metal stairs bolted (cantilevered) into the rock face, so you're going up this relatively exposed section—with, at least in my case, a death grip on some cable—to the top. From there, we'd been told it was about 2-3km and 500m down on technical rock and then it was runnable. This turned out to be literally true, but with a big asterisk. First, the rock wasn't just technical but wet and incredibly slippery and fairly exposed. Fortunately, none of us actually fell of, though we did manage to get way off course and have to be waved back on by the photographer.

Eventually we hit the runnable bit, which was initially grass and then some very nice road. Looking at the profile, it looked like we had to go up some and then it was a nice long descent to the finish, where we had to lose another 500m or so. We power hiked to the top pretty fast and I announced I wanted to run to the finish and that I needed to stop and take some of my gear off. Jamie and Mick politely waited and then waited some more after the long suffering zipper in my pack gave up, leaving me with a giant hole where stuff could come out. After some maneuvering, I ended up pulling most of the bulky stuff out and into my dry bag, and then closing the remaining hole somewhat with safety pins from my bib.^[9] Initially, I was just holding the dry bag, but eventually I realized I could hang it from my pack, and so I could run.

Jamie and Mick didn't seem superenthusiastic about the whole running thing (Mick: "I could shuffle") and I was starting to gap them a bit, which I felt a little bad about seeing as they'd waited while I broke my pack. In the event, though, it didn't matter much because soon enough we detoured off the perfectly good fire road into (you guessed it), yet more super rocky single track, which slowed us down a lot. I'm not going to say I loved this, but I think my companions found it a lot more demoralizing; at this point I was just resigned to slogging through it. It also helped that I had put my poles away which turns out to be easier on this kind of terrain, at least for me.

Eventually, we got dropped off at Saas Almagell, at which point things promptly went wrong because there was something wrong with the flagging. We spent 20-30 minutes messing around trying to figure out where to go (props to Mick for insisting we were going the wrong way!) and eventually had to message the race director to ask what to do. The dude they sent out didn't really speak English, but he managed to communicate that we should go back in the other direction and led us to an arrow which we had missed the first time. From there it was about 5K and 200 meters of ascent into Saas Fe, but on nice gravel road and then actual road, though with a short section of single track. I was still feeling like I could run at this point, but I didn't see a lot of value in splitting up so I just kind of dawdled a bit and we all finished together. There wasn't much in the way of a finishing arch, just a sign and some volunteers who scanned us and that was it.

I won't say I wasn't tired at this point, but I was basically feeling OK and I don't think I would have had any trouble finishing the race if they hadn't cut it short.

Post-Race #

As I mentioned above, the messaging was pretty vague on how we we were going to get get from Saas Fe to the finish, and what we were then told was as follows:

There is one shuttle.
It takes 8 people.
It takes about 2 hrs for the shuttle to round trip to Grächen.
The 4:00 shuttle is full so you have to wait for the 6:00 shuttle.

Nobody was that enthusiastic about this, but there also wasn't much to do about it; you can't really Uber at 3:30 AM in Saas Fe, and the alternative was taking the train, which itself takes like 2 hrs, so I just settled in to wait. Initially I was told there were no beds, but then someone found me one, and I futilely tried to sleep for 20 min or so and then just resigned myself to sitting in a chair, snacking, and trying to stay warm till 6:00. Eventually, they told us to walk over to the shuttle, about 10 minutes,^[10] and then a quick 45 minutes or so back to the start.

It's clear there were a bunch of last minute arrangements, but this section really could have been handled better. There was a lot of confusion about who would be on the next shuttle, with the intent seeming to be in order of arrival, but actually they started to take people in a different order until there were some loud objections. Also, having one bus really isn't enough.

Retrospective #

This was by far the hardest race I've ever done, much much harder than UTMB. The comparison point I've been using for people is that there are parts of UTMB that are somewhat technical and that you might be a little concerned about running. Once you take out the relatively short road or fire road sections, that's what the good parts of UTMR are like. The bad parts are, I guess, in principle runnable in parts, but really technical. The best comparison points I can give from my own experience are:

The bad downhill parts are like the most rocky parts of Rock Creek Park in DC.
A lot of the climbs are like the upper parts of climbs in the Sierras (e.g., Glen Pass) with a lot of loose rock and scree.
The top part of the climb to Monte Moro is like Flagstaff's Blue Dot but longer and colder.

I'd trained on all this stuff, but it's different to have a couple miles of something and just to have it be endless.

Nutrition #

I really didn't keep to my nutrition plan. Based on previous practice, I had been planning to get a lot of my nutrition from sports drink, drinking high cab drinks in half my bottles and lower carb in the other half and using solid food when drinking the lower carb. In the event, I just didn't drink anywhere near as much as I expected; my timer would go off and I didn't feel like drinking and just kind of put it off, so even on long stretches I never really ran out of water. I also had to force myself to eat solid food. On the other hand, I'd get to aid stations and would feel a lot more interested in the bread and cheese.

I'm not sure how big a problem this was in practice, because you don't really need to get in 300+ calories an hour at these low levels of exertion. There were some moments where I did really feel like I needed to eat more, but I think those mostly coincided with low points for other reasons, such as fatigue. Basically, I think I could have managed this better, but I'm not sure it was really impactful. I would definitely plan differently for a future event, though, focusing more on salty stuff and less on sweet foods. Deprioritizing liquid calories would also make aid stations easier as I wouldn't have to get sports drink into my bottles.

Time and Pacing #

The UTMR site says that times are about 20% slower than UTMB, but I was clearly much slower (and the winning time is about 30% slower than a typical UTMB winner, though UTMB is of course a much better field). On the basis of my 37:49 UTMB finish time I had guesstimated 45:00 for UTMR, but I didn't even finish the abbreviated version in that time, and I would have expected something in the low 50s for the full course, so obviously I underestimated things. That was just a guess, so I don't want to get fixated on comparing to 45 hours, but I did spend some time trying to figure out what parts were slower or faster than you would have expected.

The obvious thing to do here is to compare to my UltraPacer forecast, but this ended up with several challenges. This is gonna get a bit technical so feel free to skip down a bit:

My original forecast was for 45 hours and I hadn't put down any real wait times at aid stations, just forecasting a ridiculous 5 minutes.
Ultrapacer is having some trouble determining aid station delays. I think this is because the positions of the aid stations are a bit off. UTMR's tracking had the same problem to some degree. I have splits from my watch for some of these but not others.
I accidentally stopped my watch somewhere in the middle of the course for 40 minutes, and when Runalyze exported a GPX file from the FIT file it basically erased the gap, shortening the elapsed time by the time my watch was stopped. UltraPacer won't take a FIT file and Garmin choked trying to output the GPX.

Ultimately, what I ended up doing here is to use fitdecode^[11] to translate the FIT file to a GPX file with unadjusted timestamps and then upload it to UltraPacer. I created a new plan for 50 hours and added some split times for the aid stations, using a combination of my real splits and eyeballing a bit. This doesn't tell us everything, but nevertheless there's a pretty clear pattern, shown in the following figure.

UTMR pace comparison

Part of what's going down here is just UTMR underestimating how much I'm going to slow down throughout the race (you can tune that parameter but I didn't), but I think the main contributor here is how slow I was on the two technical downhills, followed by spending a lot of time in aid stations in the last half (I wasn't the only one!). You can see that mostly when it gets uphill, I am flat against the forecast and or making progress, and then when it becomes downhill I fall behind a lot.

You can't blame UltraPacer for this: if you don't tell it a section is technical it just works based on grade, so it doesn't know that those sections will be especially bad, but it's also the case that I'm particularly slow on that kind of section; as I said, a lot of people were going by me.

I finished fairly far down (officially 119 but we all came in togetherish so really 117th) out of 135 finishers with 61 DNFs, so this is pretty squarely in the middle. I usually finish a bit further up, but in talking to people I got the impression that this was a really stacked field; almost everyone either had done or was doing some serious race, whether it was UTMB, Mogollon Monster, Arc of Attrition, or whatever, and I know some of the less prepared people dropped out.

This is actually right about where I finished in relation to the fastest finisher as UTMB (a couple percentage points faster this time). On the one hand, I felt like I trained harder for UTMR and was more prepared, but on the other hand this race really pushed one of my weaknesses that I've had trouble preparing for because there's just not much of it here. If those sections had been like the rest of the race, I think I would have been about 2-3 hrs faster,^[12] but still clearly not 45 hours for the full race.

All in all, this was an epic adventure and definitely worth doing. With that said, I think I'm going to take a break from this kind of technical European race. Both here and at Grand Loop I found it kind of frustrating to have these long sections you were just going super slow because you had to pick your way through something. I definitely do like having a lot of climbing and I don't mind being out on the trail so long^[13]At least for next season I'd rather focus on races where the limiting factor is my fitness rather than my agility.

He moved to NYC! ↩︎
I'm vegetarian, so no charcuterie. ↩︎
I usually use an iPhone 12 mini but I wasn't sure the battery would last the full race and I didn't want to have to mess around with a battery pack so I just bought a cheapie feature phone and a local SIM. ↩︎
According to Wikipedia, the longest foot suspension bridge in the world at the time it opened. ↩︎
Bruising? Cracking? Who knows. It hurt some but not as bad as when I've definitely broken a rib. In any case doctors don't bother with the difference because they don't treat broken ribs unless it's really bad or displaced or something, and you just have to wait it out. Feels better now. ↩︎
A trick I learned from Roman Danyliw. ↩︎
"Windproof and waterproof glove" ↩︎
There is a 4-day stage version of UTMR. ↩︎
I had duct tape but it was too stuck together to use... ↩︎
Saas Fe is apparently some kind of car-free zone. ↩︎
Which I totally vibe coded. Hope it's right! ↩︎
Better not even to speak of the 30 minutes we spent messing around Saas Agamell. ↩︎
Though I still maintain that a 100K is a great distance because you can sleep in bed after. ↩︎

Olympic Grand Loop (Deer Park Loop)

2025-08-15T00:00:00Z

This year my occasional^[1] training partner Chris Wood was selected in the UTMB lottery and asked me to come over to Chamonix and crew him. Europe is a long way to go and not race, so I looked around and finally settled on Ultra Tour Monte Rosa (UTMR). UTMR is conceptually similar to UTMB in that it's a 170K tour around a mountain in the Alps but it's about 10% more climbing than UTMB and substantially more technical, so the finish times are around 20% slower. I ran UTMB back in 2022 and finished in 37:49, so I knew I had to put in some serious training if I didn't want UTMR to be a miserable experience. I like to do some adventure runs towards the end of the training cycle both as a training tool and to test out your fitness, nutrition, etc.

This time, Chris and I selected the Grand Loop in Olympic National Park. At 43 miles and 13000 ft, the Grand Loop is sort of like a scaled down version of UTMB/UMTR, so we figured it was good test of our fitness/final shakeout event. As well as having a lot of up and down, the climbs and descents get bigger the further along you go, culminating in a 3000 foot climb to the finish, which is good practice but still smaller than the biggest climbs at UTMR or UTMB.

Map of the course. From Gaia GPS

Map of the course. From Runalyze

The fastest known time for this route is 8:33, but Max King did it in 10:40 back in 2020, so I was kind of uncertain how long it would take us. I estimated about 15 hrs, with 14 if things went really well, and put together a food plan for a bit more than 15 but a pace chart for 14. This turned out to be fairly on.

Chris lives in New York and I live in California and so we both flew into Seattle and then drove out to Port Angeles together, staying at an AirBNB about an hour from the trailhead. Dawn was at around 5:15 and then dusk around 8:$5, so we aimed to start around 5:45.

My stuff ready to go.

Start Obstruction Point [8.12 mi, +2251/-1499 ft, 2:15:05, 2:15:05, 16:38/mi] #

This section went really well. It was nice and cold at the start and despite there being (in retrospect, looking at the profile), a surprising amount of climbing. Almost everything was runnable, though we decided to hike the bigger climbs to avoid going out too hard.

As we were traversing the ridge line, we were able to see and smell quite a bit of smoke over the valley (potentially from the Waolf Bear Gulch Fire). We hadn't checked fire conditions going in but ran into some backpackers and asked them about it and they said they were aware of it but the fire was far away, so the only issue was the smoke. To be honest, we were a bit worried about it, but after flying into Washington State, we weren't about to bail out 8 miles in.

Smoke in the valley from the approach to Obstruction Point

Obstruction Point to Grand Pass [6.33 mi, +2106/-1867 ft, 2:05:53, 4:20:58, 19:53/mi] #

The next leg is from Obstruction Point down to Grand Lake and then up to Grand Pass. The section down to Grand Lake was still quite runnable so we took it at a good pace. Grand Lake is actually the first water source on the trail, so even though it's a bit of a detour, we went almost all the way down to the lake until we ran into a well-running stream, which works well with our gear. We are using Salomon filter bottles^[2] which combine a soft flask with a filter cap attached to the drinking nipple. You can drink directly out of the flask or squeeze the bottle into another bottle. The easiest way to fill up the flask is if you have some running water which you can run right into the flask. This is by contrast to old-style pump-based water filters where you needed to have the pump intake completely submerged and so running water wasn't that convenient.^[3] Of course it turns out the detour to the lake was totally unnecessary because from here on in there were a lot of stream crossings so we could have just filled up without leaving the trail.

After the lake, we had the first big climb up 1600 ft. to Grand Pass over 2.65 miles. This was a pretty straightforward climb on dirt, gravel, and scree to the top of the pass and we were still feeling nice and strong.

A selfie en route to Grand Lake. You can tell we're cool because we're wearing sunglasses.

Grand Pass to Cameron Pass [5.34 mi, +2405/-2326 ft, 2:17:49, 6:38:57, 25:50/mi] #

This next segment is where things started to get difficult. It's listed on the map as "Cameron Pass Primitive Trail", and lives up to that reputation. The downhill from Grand Pass is quite steep (about 2000 ft over less than two miles) and technical, making it hard to run fast; then you turn around and start the long climb to the top.

Partway up this climb I started to have a bit of a low patch, feeling a bit hungry and lightheaded. I'd been sticking to my nutrition schedule but it had mostly been liquid calories and also I'd substituted sports drink for water a few times when I filled my bottles, so I think I just got a little behind and my stomach was empty. I swapped in some solid food and loaded up on salt and quickly started to feel better. This was the only time I actually had any real trouble on the entire route, and I felt pretty solid from here on in.

At this point we'd given back pretty much all of the time we made up in the first leg and we're right on the projected schedule for 14 hrs, but of course the terrain didn't get much better, so we just kept falling further behind.

At this point my feet were starting to hurt some, especially in my ankles. Nothing too bad, but a little concerning at 20 odd miles in.

Cameron Pass to Gray Wolf Pass [9.61 mi, +2867/-3150 ft, 3:49:45, 10:28:42, 23:55/mi] #

This next section was really more of the same: a long descent down to the valley floor followed by a climb to Gray Wolf Pass. The footing didn't really get much better from here, so we were doing quite a bit of walking even on the downhill. This section didn't seem too bad in terms of smoke but there must have been some because it seemed to trigger my asthma and I found myself coughing a bit.

We hit the bottom of the trail to Gray Wolf Pass and each took our first Maurten GEL CAF to give us some energy on the way up. The climb to the top of Gray Wolf is surprisingly long, and you can see the peak from a long way up. The top mile or two is just on exposed rock and sand, so there was a bit of "can it really be another half mile", but eventually we hit the top. There were a few backpackers sitting at the top eating. We chatted with them and got the usual "are you really doing it one day, wow", response, and then it was time to head down.

Gray Wolf Pass to Three Forks Climb [9.31 mi, +66/-4068 ft, 2:58:40, 13:27:22, 19:11/mi] #

By this point we were definitely starting to run behind and we didn't think we'd see 14 hrs, but we were expecting to pick up some time on the 9 mile downhill and finish in the mid 14s. Unfortunately, this part of the trail was really not that runnable at all. Coming off the ridge it was the usual sand, gravel, and loose rock so we didn't go too fast and then once we got to lower altitudes it was a lot of rocks and roots, as well as stream crossings, mostly in the form of narrow. There were also a lot of treefalls we had to climb over or under, though at least the trail was clear so we didn't have trouble finding it once we got past the treefall.

This section had quite a few stream crossings, but unlike many backcountry trails, they were really well maintained, with actual bridges. Most of these were just a single log that had been flattened on top, so you had to watch your balance. I found myself thinking about my friend Cullen, who used to say that it's easy to walk a foot-wide path that's on the ground, but if you put a a foot-wide plank 50 feet in the air, very few people can do it. A few actually had a railing, which made life a lot easier. Either way, though, it's a lot better than having to hop across a bunch of rocks.

As a result of all this, we had a really hard time getting into a a rhythm; we'd run a little and then have to walk, then run some more, etc. This made for a really long 9 miles where you had to be constantly paying attention to make sure you didn't trip, and I found myself repeatedly looking at my watch to see if we were finally close to the part where we could start climbing.

The terrain at the top of Gray Wolf

The view from Gray Wolf

Three Forks Climb to Finish [4.71 mi, +3222/-13 ft, 1:47:30, 15:14:52, 22:50/mi] #

Finally, we made it to the bottom, popped another GEL CAF and started up the Three Forks climb. This was the biggest climb of the day but also one of the nicest parts, consisting of nice smooth shaded single track. Of course it didn't hurt that we knew this was the last thing we had to do. By this point my feet had started to feel quite a bit better, probably from the easier trail.

We made pretty good time up the climb: 22:50/mile isn't bad at all for a 13% grade. Poles really help a lot under these conditions: you don't need them for stabilization but they let you recruit more of your body to drive you up the hill. It's just a matter of putting your head down and keeping moving.

About 1/3 of the mile from the top were rewarded with the trail opening up into a flat runnable section that took us all the way into the finish. Even though we had been pushing up the climb we still had plenty of gas in our legs and were able to finish nice and strong.

My foot, which has inexplicably turned blue. I thought it might be bruised but I think it's just the dye from my shoe bleeding from when I got my foot wet.

Retrospective #

Overall this outing went fairly well. This is a really beautiful route that is simultaneously tough but also doable in a single day without feeling too wrecked. The climbs are definitely long, especially towards the end, but unlike some other mountain routes I've seen there's nothing where you're just death marching in the heat. It really helps that there's plenty of water all along the route except for the first 12 miles to Grand Lake, but that section goes really fast. After that, there were a few places we got low and were a little worried about water availability, but never so much that we got desperate; it was more a matter of convenience and quality of the source, as in "should we fill up at this marginal stream or wait for something better?"

We finished on the high side of my forecasts but I was more or less guessing anyway and 40 odd percent slower than Max King isn't too shabby. Reading their FKT report, it seems like they also had a really fast leg to Obstruction Point and then slowed down a lot as well.

Nutrition went well. I've been experimenting with liquid-only nutrition (Maurten 320 and Tailwind High Carb) but on previous outings I started not to feel that great, which is consistent with how I felt here. This time I alternated Maurten 160, Maurten 320, and Tailwind High Carb and ate solid food when I was drinking Maurten 160 and water. This seemed to work pretty well, but I think in the future I may try to do more like Maurten 160 half the time rather than about a third.

Except for a few brief periods I already mentioned, I felt good essentially the whole way and not too wiped out at the end. I was pleased to be able to run comfortably for the last bit. Next up, Chamonix and Grächen.

Overall 43.4 mi, 13015 ft, 15:14:52, 21:04/mi.

He moved to NYC! ↩︎
Hydrapak and Katadyn sell filter caps which are basically the same. ↩︎
This is actually the result of some cool new technology. Older filters use either a paper or a ceramic filter and require quite a bit of pressure to drive the water through. Newer filters are based on hollow fiber membranes, which require a lot less water pressure. Instead of a pump you can just have a flexible bag and squeeze the water through the filter or even use a gravity feed. ↩︎

Understanding Memory Management, Part 7: Advanced Garbage Collection

2025-07-27T00:00:00Z

This is the seventh and final (phew!) post in my multipart series on memory management. You may want to go back and read Part I, which covers C, parts II and III, which cover C++, and parts IV and V which cover Rust, and if you haven't read it, go to read part VI, which introduces the basic mechanisms of garbage collection. In this post, I want to touch on some of what you need to do to deploy garbage collection in a production system, as well as some of the reasons that systems designers might decide to avoid GC.

Garbage Collection Latency #

The biggest concern that engineers typically have with garbage collected systems is the cost of the garbage collector itself. Because these algorithms—other than reference counting, of course—require scanning all allocated memory, often multiple times, they can be quite expensive. This isn't just a matter of total program runtime, but also of latency. The basic GC algorithms I showed in part [VI] are what's called "stop-the-world" garbage collectors, which means that the entire program has to wait for the GC to finish. This might not be a big deal if you're processing some data in Python—what with buffering, context switching, etc. you may not even notice the latency—but the situation is totally different in an interactive application: when the program is garbage collecting it's not responding to your input; in this context even very small amounts of GC lag—or any other lag, for that matter—can be quite noticeable.

Garbage Collection Timing #

The first thing to do to control GC latency is to be fairly careful about when you actually garbage collect. Which strategy you follow isn't that big a deal in non-interactive program, because unless you do something severely wrong, you'll probably have to do approximately the same total amount of GC anyway, but if you GC at the wrong time in an interactive program then users will get annoyed because suddenly their program just stops responding and they have to sit and wait for it to come back. This is obviously quite annoying! Back when I worked on Firefox, we used to call this kind of stuff "jank".^[1]

You might think that you want to put off GC as long as you could, for instance until you actually are unable to allocate any more memory without garbage collecting. This generally isn't the best idea: you may run out of memory right at the time when the user is trying to do something, which creates exactly the janky user experience that you were trying to avoid by deferring GC. Moreover, because GC algorithms run more slowly when there is a lot of memory in use (counting garbage here as "in use"), if you put things off too long, the latency may actually be quite bad. On the other hand, you don't want to GC too frequently because GCing is expensive.

There are a number of more sophisticated approaches for scheduling the GC. For example, in an interactive program you can look for when the program appears to have been idle (i.e., no computation or user input) for a given period of time, as is done in GCMH. V8's Orinoco uses a fancier version of this where it schedules GC during the idle period after it has rendered a frame and the time it needs to render the next one. Part of why this works is that they do only part of the GC each time, as described below. Modern GCs may also use multiple triggers for garbage collection. For instance the Java ZGC collector uses memory pressure, periodic collection, and allocation rate as triggers.

Good GC scheduling will only take you so far with a stop-the-world GC; you're always going to take a pause and there's some chance that it will be at an inconvenient time. If you really want to minimize latency, you need to find a way to avoid having invocation of the GC stall the entire program. The remainder of this section describes a number of approaches.

Generational Garbage Collection #

One of the most common mechanisms is to just garbage collect some of the objects you've allocate, typically the most recently allocated ones. To see why this makes sense, consider the following simple ~~Python~~ JS [Corrected - 2025-07-27] program:

Code #

const fs = require("fs");

const WORD_COUNTS = {};
let LINE_NUMBER = 0;
let MAX_WORDS = 0;

const fileContent = fs.readFileSync("count-words.in", "utf-8");
let lines = fileContent.split("\n");

// Remove trailing empty line if file ends with newline
if (lines.length > 0 && lines[lines.length - 1] === "") {
  lines.pop();
}

for (const line of lines) {
  const words = line.split(/\s+/).filter((word) => word.length > 0);
  const count = words.length;

  if (!(count in WORD_COUNTS)) {
    WORD_COUNTS[count] = [];
  }

  WORD_COUNTS[count].push(String(LINE_NUMBER));
  LINE_NUMBER += 1;
  MAX_WORDS = Math.max(MAX_WORDS, count);
}

for (let count = 0; count <= MAX_WORDS; count++) {
  const countString = WORD_COUNTS[count] ? WORD_COUNTS[count].join(" ") : "";
  console.log(`${count}: ${countString}`);
}

Output #

0: 1 5 10 16 20
1: 13
2: 0 19
3: 2 3 4 6 8 9 12 14
4: 7 15 18
5: 11 17

JS word counter

This program reads a file line by line and then makes a structure containing of the line numbers of the lines with various number of words per line.

The thing to notice here is that there are two kinds of object allocations here:

The table of word lengths (WORD_COUNTS and the individual lists inside it)
The line read from the file^[2] stored in line list of words in each line created at the top of the loop by words = line.split()^[3]

Real Programs Don't Call Free #

When I worked with Allan Schiffman he used to say (IIRC, quoting Stanford Professor Dave Cheriton), "real programs don't call free". The idea was that there were two kinds of programs:

Short-running programs like compilers where returning memory didn't help that much and it was easier to just allocate and never free, and let the operating system clean up on program exit.
Long-running programs which had to be careful about their memory consumption and which therefore couldn't really trust the system malloc() and instead had to implement their own custom allocators.

Of course, computers have gotten a lot bigger since then and malloc has gotten a lot better so I suspect people are a lot more willing to trust the allocator rather than rolling their own. On the other hand, the whole point of garbage collection is that you don't have to call free.

The overall WORD_COUNTS table lasts for the entire lifetime of the program, but the line and words variables only live for one turn of the loop. This turns out to be a common access pattern, especially for long-lived programs: you have a lot of both short-lived and long-lived allocations. But this means that when you garbage collect, you spend a lot of time examining (tracing) over objects which will not be freed. For example, imagine we modified the program to request garbage collection on every turn of the loop (this is plainly unnecessary in this program, but bear with me).^[4] With each turn we would free line and words but we would also have to examine the (ever-increasing) WORD_COUNT structure, which is just wasted effort.

If memory allocation and freeing patterns were random (technically: distributed accordingly to a Poisson process), then we would basically just have to live with this waste. However, in fact allocation and freeing display patterns, specifically that it's common for objects which were just allocated to be freed quickly. For example. if the user clicks on some button, the various click handlers for the button, dialog boxes, etc. may get instantiated to handle the UI gesture and then torn down as soon as the program has finished processing the gesture. This observation is often summed up in what's called the Generational Hypothesis:

the most recently created objects are also those most likely to become unreachable quickly

We can exploit this observation to improve GC performance using what's called a "generational garbage collector".

The intuition behind a generational GC is that we segregate objects into "generations" and then garbage collect the younger generations more frequently. As objects age, we move them into older generations, which are garbage collected less frequently. As an example, I have implemented a simple GC, with only two generations. It behaves as follows:

The heap is divided into two regions, the "nursery" used for newly created objects, and the rest of the heap, used for older objects. The nursery starts at address 0 as usual, and the rest of the heap starts at address 5000.
When an object is initially created, it is allocated out of the nursery.
We have two kinds of garbage collection: a minor GC, which only examines objects in the nursery and doesn't clean up objects in the rest of the heap and a major GC, which garbage collects the whole heap. Generally, we would do a minor GC fairly frequently and a major GC less often.
After we have done either kind of GC, any objects in the nursery will be promoted to the rest of the heap (technical term: tenured).

Let's walk through this piece-by-piece. First, we'll just allocate two small objects.

The situation here is just the same as with the other GCs we've seen: the objects get created at the top of the heap in address 16. The only difference is that now have labels for Nursery and Tenured. For presentation purposes I've drawn these as adjacent, but of course these are both large regions; I'm just eliding the big empty space between the last the allocations and the rest of the region.

Now let's make b garbage and then do a GC on line 4. Note that I've asked for a minor GC with the new #gc0 pseudoinstruction, but as there are no tenured objects the eventual result is much the same either way.

After this GC pass, object b has been collected and the object pointed to by a has been tenured and moved to address 5000.

If we now create a new object and assign it to b, it will be allocated in the nursery, as expected.

Now let's make a garbage, and do a minor GC.

Now we've tenured b but the object at 5000 previously pointed to by a is still there; it's just garbage. This is what we expected, because a minor GC doesn't try to clean up any of the tenured objects; it just lets them sit there even if they're garbage. If we now ask for a major GC, we'll clean up the whole heap, and finally clean up that object.

The advantages of this design should be obvious, assuming the generational hypothesis is true for our program: we can clean up most of the garbage by just examining the nursery without having to look at any tenured objects. Generational style GCs are very common, especially in systems designed for interactive programs. Many modern GCs, such as those used by V8, SpiderMonkey, or Java use generation scavenging.

Design Choices #

A generational GC combines elements of a number of the garbage collection systems we've seen already.

Allocation #

In our implementation, we just use a simple bump allocator, always allocating out of the nursery. Because every GC pass always cleans out the entire nursery, promoting live objects and discarding dead ones, there are never any holes in the nursery that previously contained live objects, so there's no point in trying to reuse space--there's nothing to reuse. In a fancier GC (see below), we might have a different situation, however.

Minor GC #

In the specific design I've implemented, the minor GC is effectively a copying style collector but instead of copying into two equivalent semi-spaces, we copy from the nursery right into the tenured region of the heap. Importantly, unlike the copying collector we showed in Part VI, the destination region is probably not empty, because it will contain whatever objects have already been tenured. Just as with the copying GC, we can abandon all the objects in the nursery after the GC.

We're able to get away with this simple strategy because we immediately promote objects on every GC pass. However, if we waited multiple passes, then the situation would be different. For instance, if you promoted objects after two GC passes—note that this requires bookkeeping—then you might have objects which needed to be kept around in the nursery after a GC pass. This also has implications for allocation: if the minor GC uses mark-sweep, then we might have holes that could then be filled rather than just bump allocating (though it's still very attractive to bump allocate).

V8's Orinoco uses an interesting design which has a copying minor GC and then promotes objects after they have survived two passes:

Orinoco's minor GC (generation scavenger). From Google.

There are a few subtle implementation details, which we'll get to below.

Major GC #

The major GC is more or less the same as the stop-the-world GCs we saw in Part VI, except that it has to scan all the regions in sequence (in this case, just the nursery and tenured regions). However, as a practical matter you probably want the major GC to be either a mark-compact or copying collector, because otherwise you end up with holes in the tenured region which can't be filled in during the normal allocation process. You could in principle fill them in to some extent when you promote objects from the nursery, but that makes GC much more expensive because you have to try to fit each object being promoted somewhere rather than just bump allocating. I use mark-compact because otherwise you need to allocate a large block of memory for the other semispace in order to optimize the infrequent major GC.

Implementation Notes #

In this section we look a little more closely at the implementation of our generational GC. Much of this will be familiar from Part VI, but there are some details that I've had to change.

Regions #

First, we need to keep track of the which regions of the heap correspond to each generation. This is done by keeping a _generations list, with each entry containing:

start : The first address that can be allocated at.
end : The end of the allocated region (one byte past the end of the last object), and hence the next location we'll be allocating at.
top : The end of the region itself (again, one byte past it).

For convenience, we also have the variables _gen0 and gen1, which point directly to the generations objects for the nursery and tenured objects respectively.

We can then use the _generations variable to see which generation a given pointer points, in the obvious way:

  generationFromPointer(address) {
    for (const [index, generation] of this._generations.entries()) {
      if (address < generation.top) {
        return index;
      }
    }
    throw new Error("Pointer not in any generation");
  }

At some level, this is all overly general: this design in principle supports an arbitrary number of generations but in practice we just use two generations of equal size. There are different programming philosophies here and exponents of YAGNI would probably say this is a bad set of design tradeoffs, but I prefer to avoid baking in a bunch of temporary design decisions. In a real system we would probably want the nursery to be smaller and this lets us make that change if we decide to.

Minor GC #

Now let's take a closer look at the minor GC. As I said, this is similar to the copying GC we showed in Part VI, but with some subtle differences. Here's process_ptr:

  process_ptr(address) {
    if (ObjectManager.isMarked(this._context, address)) {
      // The extra word is used for the forwarding address
      return [ObjectManager.readXWord(this._heap, address), false];
    }

    // Not moved yet.
    const size = ObjectManager.getSize(this._context, address);
    const new_address = this._gen1.end;
    Memory.memmove(this._heap, new_address, this._heap, address, size);
    this._gen1.end += size;

    // Now overwrite the first word to point to the new location.
    ObjectManager.setXword(this._context, address, new_address);
    ObjectManager.mark(this._context, address);
    return [new_address, true];
  }

The only real difference here is that when we move an object we store the new address not in the first word but in the extra word which we've allocated for the mark-compact moved pointer. We could do this either way, but this is cleaner and lets us be consistent between the passes.

The actual copying phase is essentially identical to our copying GC, except that we have slightly different bookkeeping to deal with the fact that we're copying into the tenured region rather than a freshly initialized semispace. However, we have two subtle issues to address, dealing with what's called intergenerational pointers, which is to say pointers which are stored in an object of one generation but point to an object of another generation. There are two types of such pointers:

upward pointers, which go from new to old objects
downward pointers, which go from old to new objects

Upward pointers are easy to deal with: we don't want to examine tenured objects at all, so when we see them during the minor GC, we can just skip past them. This is fine because all they can do is keep tenured objects alive, and we're not going to free those objects anyway.

Downward pointers are more complicated: because we aren't tracing tenured objects, we're not going to see them, but they may be the only reference to some object in the nursery, so without them we would incorrectly free that object, leading to a dangling pointer from a tenured object and eventually maybe a UAF. This means we need to do something when we have a situation like this:

The standard procedure is to keep track of all downward pointers using what's called a "write barrier". Whenever we do a write to a pointer slot in an object, we check to see if it's a downward pointer and if so, we store it in a lookaside list, like so:

  recordIntergenerationalWrite(sourceAddress, fieldIndex, targetAddress) {
    const key = `${sourceAddress} ${fieldIndex}`;

    // Check if the new target is an intergenerational pointer from old to young (gen0).
    if (isPointer(targetAddress) && targetAddress !== NULL_POINTER) {
      const sourceGenIndex = this.generationFromPointer(sourceAddress);
      const targetGenIndex = this.generationFromPointer(targetAddress);

      if (sourceGenIndex > 0 && targetGenIndex === 0) {
        // It's an intergenerational pointer, record it.
        this._rememberedSet[key] = targetAddress;
        return; 
      }
    }

    if (key in this._rememberedSet) {
      delete this._rememberedSet[key];
    }
  }

From the perspective of the GC, the downward pointers are just a new set of roots, so we add them to the root list before doing the minor GC:

  *_gc_minor_incremental(roots) {
    let inner_roots = [...roots];
    let ig_ptr_addrs = [];

    // Append the intergenerational pointers so that
    // we can save them.
    for (const [key, ptr] of Object.entries(this._rememberedSet)) {
      ig_ptr_addrs.push(key);
      inner_roots.push(ptr);
    }

    let new_roots = yield* this._gc_minor_incremental_inner(inner_roots);

With some careful refactoring ._gc_minor_incremental_inner() could be the ._gc_incremental() function from our copying GC, but I'm trying to keep things a bit simple.

When the minor GC returns, it provides updated values for all the roots we passed in, so now we need to patch up the locations where the downward pointers were stored so that they point to the new locations in the tenured region. Note that at the end of this process we don't have anything in the nursery and so there will be no more downward pointers.

    // Now update the IG pointers.
    const new_ig_ptrs = new_roots.slice(roots.length);
    for (const i in new_ig_ptrs) {
      const new_addr = new_ig_ptrs[i];
      const key = ig_ptr_addrs[i];
      const [addr, slot] = key.split(" ").map((a) => parseInt(a, 10));
      // Note that this will call recordIntergenerationalPointer()
      // but |new_addr| is now of the same generation as |addr|.
      ObjectManager.setValue(this._context, addr, slot, new_addr);
    }

Major GC #

The major GC really just is mark-compact, with the additional complication that we need to iterate over all the regions for each generation. However the in-use versions of each region aren't contiguous. For instance, we might have only allocated 16–512 in the nursery, which means that 512–4999 is just unallocated blank space which might have any values (e.g., if we previously had allocated past 512 and then did a GC), and we don't want to try to scan it. This wasn't a problem in the minor GC because a copying GC just follows pointers, but mark-compact actually does a linear scan of the whole allocated region, so if there are garbage values there, it will misbehave, quite likely in a dangerous fashion. Fortunately, we already have a list of the allocated subregions of each region, so we can just iterate over it, as in the following:

    for (let i = this._generations.length - 1; i >= 0; i--) {
      const generation = this._generations[i];
      for (let scan = generation.start; scan < generation.end; ) {
        const size = ObjectManager.getSize(this._context, scan);
        if (ObjectManager.isMarked(this._context, scan)) {
          ObjectManager.setXword(this._context, scan, free_ptr);
          yield [{ op: "setmoved", addr: scan, newval: free_ptr }];
          free_ptr += size;
        }
        scan += size;
      }
    }

Straightforward, right? Well, mostly. Why are we going through the list of generation regions backwards (from older to younger generations and from high to low memory) rather than forwards (from younger to older generations and from low to high memory)?

Recall that mark-compact works by sliding every object as far left (towards low memory) as possible. It does this by keeping a single end pointer which points to the location where the next object will be allocated (initially pointing to the start of the target region) and then incrementing it by the size of each object allocated. This is normally safe because we are also scanning left to right and so we never overwrite any region of memory we are going to need later, even if we leave it in a corrupt state, as shown in the figure below:

Sliding left

What's in 28–36 is probably the last two words of the object previously at 24 (though the GC could have done anything it wanted with it).^[5] It doesn't matter, though, because we've already advanced the scan pointer past that region to 40, so it's just going to copy whatever is at 40 over it in a second anyway.

Now consider what happens if we have two generations and we process the nursery first, as shown below.

Sliding left badly

In this case, we copy the first value in the nursery over the first value in the tenured region (remember, the tenured region is always compacted); We've now destroyed that object. Even in the best case where the object was going to be freed anyway, we've quite likely left a piece of some object—as shown here—which will mess up the scanning process. And if we're not going to free the object we just stomped on, the data is just gone and now things are really bad.

Fortunately, this problem is easily solved by processing the generations in reverse order so that we've already processed everything in the tenured region before we start trying to copy stuff from the nursery into it.

Below I've provided a widget that lets you see the major GC in action.

Incremental and Concurrent GC #

Another way to reduce the latency of garbage collection is to do incremental garbage collection, in which you only do part of the garbage collection pass at each pause point. The obvious challenge here is that the program itself may change some pointers in between the GC phases. For example, the topology where A points to B which points to C, and the following sequence of operations:

Start the GC and process C, marking B and adding it to the work queue.
The program then sets a pointer from A → C and erases the pointer from B → C.
The next GC phase runs, processing B, which completes the marking phase. At this point C is now orphaned and will eventually be cleaned up during the sweep phase.

This problem can be solved with a similar "write barrier" approach to how we handled intergenerational pointers, which detects that you have changed something important from underneath the GC. For instance, you could detect that you've changed one of the pointers from an object you've already processed (A) and re-add it to the work queue.^[6] With the right set of barriers you can intersperse operation of the program and the GC at relatively fine granularity by running the program for a little while, doing a little bit of GC, then running the program some more, etc., thus reducing the apparent pause experienced by the user.

Incremental GC alone lets us reduce apparent pauses, but it doesn't let us use more than one core at once, but of course modern processors have more than one core. It's possible to extend incremental GC to actually have the GC run in parallel with the program, in what's called concurrent GC. This is obviously even trickier because we have to worry about the usual thread safety concerns when two threads try to work on the same memory at once, but the result is to further reduce the pauses experienced by the user—though not necessarily to zero because you still can have the program waiting on some contested resource that the GC is using. For this reason concurrent GCs are very common, including in the systems I named in the previous section.

Separately, you can also have the GC run in multiple threads at once. This is called parallel GC. The obvious advantage here is that you are using more than one core for your GC and thus making more efficient use of your computer. You can use various barriers here, but as an intuition pump consider that you could have a non-concurrent mark-sweep GC that just ran the sweep phase in parallel; this can be done without any thread locking at all once you've segmented the heap. You can have have parallel GC in both stop-the-world and concurrent modes, with the latter obviously providing the lowest latency impact.

Allocation Strategies #

So far we've looked at two basic allocation strategies:

Bump allocate at the end of the allocated region
Allocation in the first available free region (what's called "first-fit")

If we have a moving GC like mark-compact or copying, then quite possibly all we need is bump allocation; while there may be garbage in the form of unreachable objects, but at least in a stop-the-world GC, we discover the garbage and compact the heap at the same time, so there's never any need to allocate in the holes. By contrast, if we are using reference counting or mark-sweep, then we do need to re-allocate out of the holes—otherwise there's not much point in GCing in the first place—and it's important to do so efficiently.

Any allocation algorithm needs to balance a number of factors:

Fragmentation
Efficiently finding a hole we can fit into
Space overhead

The design of allocators is a whole separate specialty from the design of the garbage collection system, and I'm not going to go into it here in detail, but I wanted to give you a flavor of the kinds of issues you face and some of the variety of implementation options.

In the naive first-fit algorithm, we scan from the beginning of the heap until we find a suitably large location. Depending on the fragmentation pattern and the size of the new object, this can take quite a long time and involve scanning through much if not all of the heap. Moreover, this can make fragmentation worse; there may be a better location—more closely matching in size—higher up in the heap but instead we allocate in the first available location. An alternate choice is to do what's called "best-fit" where we iterate over all the available memory locations to find the ideal location, but this requires scanning the entire heap, which is obviously slower.

There are a number of designs that allow us to have more efficient allocation, but typically at the cost of memory overhead.

Bucketed Allocations #

There are of course a lot of options here, but one natural thing to do is to group allocations into size buckets (for instance by powers of two). When you allocate a new object of size s you round the allocation up to the next bucket size B(s), with the remainder of the allocation just being left empty. Similarly, when you free an allocation of size s it creates a hole of size B(s).

Bucketing allocations like this gives us a compromise between first fit and best fit. For instance, if we first select the first hole with the same bucket size, then actually we'll be selecting any hole within the bucket's range, which are presumably more common than exact matches. Moreover, if we are using powers of two bucket sizes, we can also select a any hole of the next bucket size up by splitting the original bucket in two. For instance, if we are allocating a region of size 512 but have a hole of 1024, then the result is an allocated region and a remaining hole of size 512.

Another advantage of bucketed allocations is that it allows you to easily resize objects. For example, if you allocate an object of size 300 in a bucket of size 512, you can increase the size of the object (up to 512, at least) without moving the object. This is more useful for some kinds of objects than others; for instance if you have a vector/array of objects then it's often quite useful to be able to make it bigger so you can add more entries.

Metadata Structure #

One of the reasons we've had poor efficiency so far is that we've been forced to scan the heap linearly to find a suitable location, so we end up with what's basically an O(n) algorithm. We need to do this because the only information we have about the memory map is in the heap itself (which, recall, is self-describing). We can do a lot better if we use some extra memory to store a map of which regions are in use and which are free (a "free list").

If we combine this idea with bucket allocation, then the obvious approach is to have a list of holes indexed by bucket size. When we free a region, we add the hole to the list for that size. When we need to allocate a region, we look to see if there are any holes of the right size. If so, we allocate from one of those holes. If not, we bump allocate in the usual fashion.

Multiple Arenas #

It's also possible to have different heap regions (sometimes called "arenas") for different kinds of objects. For example, instead of bucketing allocations but allocating out of the same region you could have one region for each bucket size. This has the advantage that holes are always the same size, so as long as there is room in the region you can always allocate, but at the cost of using up memory for the unused space for each bucket size.^[7] It's also possible for different arenas to have different allocation and GC strategies. For example, you might use a generation scavenging GC for your small objects but a mark-sweep GC for large objects or growable objects like arrays on the theory that they tend to be long-lived and that copying them during the promotion phase will be expensive.

GC in the Real World #

As you should have gathered by now, real world GC systems are vastly more complicated than I've described here. However, pretty much all of them use some variation or combination of these basic techniques. For example, here's how Google describes Orinoco:

Over the past years the V8 garbage collector (GC) has changed a lot. The Orinoco project has taken a sequential, stop-the-world garbage collector and transformed it into a mostly parallel and concurrent collector with incremental fallback.

And here is a description of Java's ZGC:

Concurrent Region-based Compacting NUMA-aware Using colored pointers Using load barriers Using store barriers (in the generational mode)

Most of these words should seem familiar to you, and you should have enough background to figure out the other ones with a little searching.^[8]

The design of fast garbage collectors is a whole subspecialty of CS, and often requires a good understanding of the specific dynamics of the system that the GC will be deployed in. If you want to go (much) deeper here, a good reference is the Garbage Collection Handbook, which I used extensively in preparing this and previous post. It's fairly dense, but really digs into far more detail than you are likely to need. In addition, many widely used GCs are open source, so you can look at the code yourself.

Why wouldn't you want GC? #

As should be apparent at this point, working in a garbage-collected system is vastly easier than working in a system where you have to handle memory management yourself. In the latter case, you either end up with a system that isn't safe by default (C++) or one where you have to do a lot of gymnastics in order to write ordinary-seeming code (Rust); in either case you spend a lot of time thinking about memory management. By contrast, with a GC language, you rarely have to think about what's going on with memory management at all, and when you do, it's mostly around performance reasons or when you have to do deep copies, rather than around "this bug is going to cause a vulnerability" or "I can't make my program work". This is true even for a systems programming language like Go.

Obviously, the people who designed Rust were aware of Garbage collection—all of the main techniques date back to the 80s and 90s and the basic concepts go back to the 1950s and Lisp—but they very deliberately chose to build Rust without it. There are a number of reasons why you might want to build your system without a GC.

Deterministic Performance #

As noted above, because the GC—at least tracing GC, but recall that most GC-based systems have some element of tracing—can introduce pauses, most GC-based languages do not provide completely deterministic performance. This is the kind of thing that makes systems programmers sad—though perhaps more than really necessary—as they like to think of themselves as close to the metal and knowing exactly what their program will do. By contrast, a language like Rust will have more deterministic performance (which isn't to say better) because you don't have to worry about the GC doing something when you want to use the CPU.

This isn't to say that you can't have a systems programming language that does GC. Java, Go, and C# are all garbage collected and people seem to get along just fine, but even so there is a persistent sense amongst systems programmers that there's something fishy about it.

Of course, it's important to recognize that Rust does have GC in the form of reference counting for Rc and Arc, and many if not most Rust programs use some form of reference counted pointer at least some of the time. However, many Rust fans have managed to conveniently forget that reference counting is a form of GC because one of the main differences between Rust and Go is that Go is GCed (which is very bad) and Rust is not.^[9]

Deterministic Behavior #

As you'll recall from previous posts, many languages support some mechanism (C++ destructors, Rust drop trait, etc.) where an object gets to do something before it's destroyed. We used this in III to create C++ smart pointers, but you can also do other stuff, such as flush file buffers. Some garbage collected languages have similar features (often called finalizers or cleanup functions).

However, because the destructor/finalizer/cleanup function runs when the object is destroyed, and tracing garbage collectors destroy the object at some indeterminate time, the finalizer also runs at an indeterminate time, or potentially never. For instance, here's what Go's documentation has to say:

AddCleanup attaches a cleanup function to ptr. Some time after ptr is no longer reachable, the runtime will call cleanup(arg) in a separate goroutine.

..

The cleanup(arg) call is not always guaranteed to run; in particular it is not guaranteed to run before program exit.

Reassuring, right?

By contrast in a reference-counted system, the object is destroyed at a deterministic time (when the reference count goes to zero) and so you can have higher confidence about where it will run.^[10]

What about GC for C? #

I've spent much of this series dumping on C and C++ for how hard they make memory management, so it's natural to ask "why can't they be garbage collected?" The answer is: they can be, at least sort of. Back in 1988, Boehm, Demers, and Weiser designed a GC system for C and C++. The basic idea is you (the programmer) use GC_malloc() and GC_realloc(), but never call free, because the GC does it for you.

The trick that makes this work is that it's a conservative GC. Recall that in all the examples above, we relied on knowing the structure of objects so we can find all the pointers. The Boehm GC doesn't have this information and so it has to assume that any pattern in memory that points anywhere in an allocated object is actually a pointer to that object.^[11] This means that (for instance) if you have an integer value which just happens to have the same bit pattern as a pointer into an object, then it will be treated as a pointer to that object, which will then effectively leak.

It's also possible under certain circumstances for the garbage collector to fail to recognize a pointer. It's generally not legal in standards compliant C code to generate a pointer value outside of the allocated region,^[12] but the compiler is allowed to do anything it wants, and so with the right compiler optimizations, it's possible that the right pattern won't appear in memory. See Boehm's issues page for more on this, though this looks kind of old so I wonder if compilers have gotten more aggressive in the time since this was written.

This is obviously clever stuff, but my experience is that very few C or C++ programs use this kind of garbage collection; people just suffer in the traditions of our ancestors.

The Bigger Picture #

This brings us to the end of our series on memory management. In closing, I'd like to step back from the details and look at the big picture. As should be clear, a huge amount of the work performed by a piece of software is in managing memory in one way or another: that work can either be pushed onto the programmer or handled by the software runtime automatically.

Each approach has advantages and disadvantages: having the programmer manage memory gives them tight control of the precise behavior of the program, but at the cost of adding to the programmer's cognitive burden, reducing the attention they have to pay to other pieces of the programming task. By contrast, letting the language runtime handle memory management frees up the programmer to think about other things but at the cost of losing control of the precise memory behavior of the program. This is a familiar tradeoff in software engineering as you climb the ladder of tool sophistication: you can get more done if you hand things off to the language—for instance, using C rather than assembly, or using R or Python rather than C—or to third party components, but at the cost of having to mostly just live with whatever behavior other people have decided upon.

I started this post talking about Rust, which represents a new point in the design space: programmer-managed memory but designed so it prevents unsafe operations (unlike C and C++). In theory you might think that this would remove cognitive burden from programmers because your mistakes are less serious, but it also frontloads that burden because it forces you to think about architectural issues upfront rather than just having the program appear to work but fail in the field (as with C and C++). I think comparing Go and Rust is instructive here: they were designed at roughly the same time but Go is vastly easier to learn than Rust, in large part due to its memory model. On the other hand, while Go is clearly carving out a serious niche, I think it's clear that Rust is the new language of choice for hardcore systems programmers. This isn't only due to memory model, of course, but the Rust memory model is part of a general philosophy of programmer control and semantic transparency in constrast to Go, which is designed specifically for ease of use.

Despite the age of these ideas, as an industry, I don't think we're done exploring the design space here. As an analogy, consider high versus low-level languages. As I mentioned above, higher level languages often have worse performance than lower level languages, so it's not uncommon for engineers to write big parts of their program in one language and then drop down to a lower-level language for performance critical code: we see this when C programs use inline assembly and R or Python programs write modules in C or C++. One possibility is to try something similar with memory management, namely to have GC most of the time but then (safely!) escape back to non-GCed mode for certain chunks of code,^[13] though hopefully in a more idiomatic way than inline assembler. I've seen some systems that seem to be exploring this space (e.g., the Boehm GC above, or Objective C's garbage collection), but nothing in really wide use. Whatever the approach, I don't think we're done here!

It was especially bad on earlier versions of Firefox because (1) much of the UI was written in JavaScript and (2) the same JS VM was used for Web content and the browser UI. ↩︎
Probably because this could be on the stack ↩︎
Most likely not on the stack, at least in a naive implementation. ↩︎
I actually originally wrote this program in Python, but I forgot that Python has a reference counting GC and so the objects were being freed at the end of every loop anyway. ↩︎
In my code, I actually make a dummy free object in this space to make the memory display system, which also scans linearly, work properly. ↩︎
This particular approach is due to Leslie Lamport. ↩︎
Some allocators, for languages like C and C++ partition memory not just by size but by object type, which helps prevent type confusion attacks due to use-after-free, when an object of type T is freed and reallocated as an object of type U but some dangling pointer of type T* tries to use it as an object of type T. This isn't really an issue for memory safe languages, though. ↩︎
"Region-based" means that it uses multiple chunks of memory rather than one contiguous heap. "NUMA-aware" means it understands the specific memory architecture of the machine and will try to use faster (processor-local) memory rather than slower memory. Colored pointers Load and store barriers refer to whether the kind of barriers we described above happen when you read pointers or write them. ↩︎
I do want to emphasize here that Rust's design also gives you thread safety for free, whereas Go's does not. ↩︎
This isn't a guarantee because the program might, for instance, crash. ↩︎
For instance, suppose that the programmer allocates an array. They might traverse the array by incrementing a pointer relying on the count of elements to be able to recover the original pointer to the beginning. In this case, there might not be a pointer to the start of the array during the GC phase. ↩︎
t's technically legal to have a pointer to just after the end of an array to allow people to write for loops, but you can't dereference it. ↩︎
Rust sort of does the opposite where it lets you jump into unsafe mode, outside of Rust's guarantees. ↩︎

Understanding Memory Management, Part 6: Basic Garbage Collection

2025-05-26T00:00:00Z

This is the sixth post in my multipart series on memory management. You will probably want to go back and read Part I, which covers C, parts II and III, which cover C++, and parts IV and V which cover Rust. C++ RAII and Rust do a lot to simplify memory management but still force you to constantly think about how you are using memory (this is even more true with Rust). It's natural to ask why we have to do all this work and why the computer can't just figure things out. The answer is that it can—at a cost—which brings us to the other major approach to handling memory: automatic memory management/aka garbage collection.^[1] In this post, I want to introduce the basic ideas behind garbage collection and describe the main algorithms which provide the basis for modern GC systems.

What behavior do we want? #

In C and C++, the programmer is responsible for two major memory management tasks:

Allocating new memory on the heap when it's needed
Returning unused memory back to the heap so it can be re-allocated later.

In C, these operations are both completely manual using malloc() and free() C++ provides manual memory management with new and delete, but also provides various mechanisms to automatically allocate and deallocate memory, such as container classes, RAII and smart pointers; the programmer is still frequently responsible for explicitly allocating objects and has to understand their lifetimes. Similarly, Rust requires you to explicitly manage memory, but protects you from errors when you fail to do so.

In a wide variety of languages, ranging from Go to JavaScript, the system handles all of these operations automatically completely. The programmer just creates variables and objects and the language takes care of allocating memory as required and de-allocates the memory at an appropriate time. To see this in action, consider the following trivial C function and its JavaScript equivalent:

C #

void foo() {
  int a = 1;
  int b[2] = {1}; 
  size_t b_len = 1;
  b[b_len++] = 2;
}

JS #

function foo() {
  let a = 1
  let b = [1]
  b.push(2)
}

Both versions of this code to the same thing. First, they create two variables.

a: : An integer set to one
b: : A list consisting of the single integer 1

We then push another element onto b to make the list [1, 2].

The first line of the function is basically the same in both languages. Take a look at the second line, however, where we create b. This C code actually makes two memory-related decisions:

It puts the memory on the stack (because we didn't call malloc())
It allocates a fixed-size array of size 2.

Note that even though we only add one value (1) to b, the array is still of size 2. This is why we need a separate length field b_len to keep track of how many elements are actually in b. The syntax {1} tells C to initialize the array with 1 and then as many zeros as are required to fill the rest of the array. Except for the initialization, this should all be pretty familiar from part I.

Now compare the corresponding JS code, which looks fairly similar, but that's just because JS imitates C syntax. Just like in C, we make a local variable b that can hold a list of things, but we never explicitly tell JS whether it should be on the stack or the heap or how big it should be. So, what are the answers to those questions? Who knows? Who cares? None of your business! The JS engine will do whatever it thinks best, and may not even do the same thing every time. Specifically:

The JS engine will automatically grow b whenever you add new elements. In this respect it's like the C++ vector container.
Local variables can be stored on either the stack or the heap. In fact, they can be stored in one place and then moved to the other when conditions change; it's totally up to the JS engine.

Whatever the JS engine does, it's essentially transparent to the programmer, who just writes code and lets the language worry about it. The same thing applies to many other languages like JS, Python, Lisp, etc.

In these languages, just as you don't have to worry about when you are allocating memory, you also don't have to worry about de-allocating it; the language automatically detects when you aren't using memory and de-allocates it, in a process called "garbage collection" (commonly, GC). You just write code!^[2]

Memo: A Tiny Language #

In this post, we'll be taking a slightly different approach than with previous posts. Because the internals of garbage collection are (mostly) invisible and real-world garbage collectors are very complicated, working with a real language isn't that useful for explanatory purposes. Instead, I've designed and implemented a tiny language called Memo (for "memory demo") that lets us look at the impact of various garbage collection approaches without being distracted byu a lot of language mechanics.

Memo is deliberately not Turing complete—it has no conditionals or loops—and only contains a small number of operations for manipulating objects.

Data Types #

Memo comes with three native types. The first two of these are familiar:

Integers representing bare numeric values.
Pointers to objects in memory (i.e., the address of those objects).

The only other data type in Memo is the Tuple, which represents an ordered set of values, each of which can be either an integer or a a pointer. Tuples are wrapped in parentheses, as in (1 2 3). Unlike Python lists or JS lists—but like Rust or Python tuples—you can't extend tuples, so a tuple of length X can't be turned into a tuple of length Y, though of course you can create a new tuple of the right size.^[3]

This isn't a particularly rich type system, but it's actually sufficient to construct a variety of data structures, as anyone who has worked with Lisp, will recognize. For example you can make a list of integers out of 2-valued tuple objects, with the first value of each tuple being an integer and the second value being a pointer to the next tuple.

Variable Naming and Addressing #

Like any language, Memo has named variables. All variables are global and variables are automatically created upon assignment without the need for let or var (simple, remember?). It's not legal to read variables which haven't been assigned to yet.

Variables in Memo are named in the usual fashion, as strings of letters and numbers starting with a letter, e.g., tmp1.

So, for instance, the following code:

a = 20

Creates a variable a and assigns the value 20.

You create a tuple in the way you expect:

a = (1 2 3)

This code automatically allocates a tuple of size 3 on the heap and assigns the address to a. It's also legal to have tuples contain other tuples, which really just means that one of the elements of the tuple is the address of another tuple.

a = (1 2 3 (4 5))

Variables themselves aren't typed, so it's perfectly legal to do:

a = (1 2)      # a is a pointer to the tuple (1 2)
a = 20         # a is the integer 20

In order to make this work, internally, Memo keeps track of whether a given value is a pointer or an integer (see below). This should be familiar if you've used other weakly typed languages like Python or JavaScript. The inner values in a tuple are addressed with the notation a.0, a.1, and so on.

Variables never go out of scope, but you can assign them to null, which has most of the same effect, except that they're still floating around in the namespace.

Demo #

The whole implementation of Memo is in JavaScript, so you can run it directly in your browser (which is why I did it). I've embedded a "read-eval-print-loop" (REPL) window so you can play with it:

Note that all of the operations we've looked at so far are "expressions" which is to say that they return the result of the operation, which then gets printed in the console (this is the "print" part of the REPL). For instance, if we set a=20 and then type a we will get Integer(20). This is how you get the value of an object, because there's no print() function.

It should be perfectly safe to type anything in this window: it doesn't interact with anything in the rest of this post or on your computer.^[4] If you violate Memo's syntax, it will just complain to you and you can enter a new instruction.

The Allocator Interface #

Next we need to look at how memory allocation works in Memo, because we're going to need that to understand how the GC system works.

The Heap #

Any memory allocator needs a pool of memory blocks (the heap) to implement from. JS doesn't really allow for raw memory access, so instead we are going to emulate the heap as a single big JS ArrayBuffer—which is just JS's way of conveniently handling an array of bytes—encapsulated in a Memory object. Internally, we create the heap like so:

let heap = new Memory(10000); // Make a heap of size 10000 bytes

Addresses in the heap are just integers in the range [0, heapSize), so we can read and write with obvious-looking interfaces:

let byte = memory.readUInt(1);   // Read a byte from address 1.
let word = memory.writeUInt(32); // Read a 32-bit word from address 32.
memory.writeUInt8(1, byte + 1);  // Write byte + to address 1.

And so on. There aren't any rules about aligned access in this implementation, so you can read a 32-bit word from address 3 or whatever. Similarly, you can read the pieces of a word byte by byte and then put it back together into a word. Many real systems actually do have alignment requirements.

Allocation #

Objects are allocated using the Allocator class, which has a simple interface. For instance, this code allocates an object of type Simple and returns its address (i.e., the index of the first byte of the object on the heap).

addr1 = allocator.allocate("Simple");

As a practical matter, the only allocated type in Memo is the tuple, but when I wrote this code originally I expected to have more than one kind of type (e.g., structures with named members) and so we have a more flexible system in which you can have objects of arbitrary types, which is more than we need for Memo. In Memo, however, each size tuple is its own type, automatically named something like (5) for a tuple of length 5.

This is all hidden from the programmer, with the consequence that when you write something like a = (1 2 3) internally the language runtime does:

allocator.allocate("(3)");

and then assigns the internal values.

Object Layout #

The diagram below shows the situation after running a trivial program which is shown below. This program allocates five tuples:

The tuple (1 2 3) which is assigned to the global variable a.
The tuple (3 4) which is assigned to the first element in a.
The tuple (8 9) which is at memory address 44 but is not assigned to any global variable.
The tuple (5 6 7 Pointer(44)) which points to the previous tuple.
The tuple () which is assigned to the global variable c.

You can use the "Previous" and "Next" buttons to step through this program line by line and see how the various tuples get made. The highlighted line of code is the one that is about to run (just like with a normal debugger) rather than the one that has just run.

The global variables are shown in the top row. These wouldn't typically be on the stack not the heap but of course are somewhere in memory, so I'm just showing them here for convenience. Memory address 0 starts at the left of the gray box marked "Reserved", so the first allocatable address is 16. This is actually reasonably realistic because the allocator typically needs to reserve some space for its own bookkeeping operations (e.g., the last allocated block). In my implementation, these values are just stored in JS variables outside of the allocated memory region, and I decided to block off the first 16 octets for more prosaic reasons: I wanted the value of the null pointer (the one that doesn't point anywhere) to be 0, and for that to work 0 cannot be a valid address for a real object. Note that there is actually nothing that requires the null pointer to have memory representation of all 0 bits, even in C, but it's convenient and common.

Each pointer is drawn with an arrow that shows the object it points to. You'll notice that each object starts out with a single 4 byte word which is where I store the type of the object (in this case, just the number of elements in the tuple). This word is also used for some other metadata as we'll see later. The result is that even an empty tuple like () consumes a minimum of 4 bytes of storage. We'll see some other reasons why we need this later. What these words currently show is the address of the object (e.g., @16) and the length of the tuple in parentheses (e.g., (3) for a tuple of length 3). Note: this is the representation with a specific type of garbage collector (mark-sweep). Other garbage collectors will have slightly different layouts, as seen below.

This is a very simple allocator, in which each object is allocated directly after the end of the previous object, with the result that all the objects are contiguous. This is what's called a "bump allocator" and is very easy to implement because we just need to store one piece of extra data, the address of the next object to be allocated, which is right after the end of the last object that was allocated. When you allocate an object of size S you then just "bump" this value up by S. Here is the actual code for our bump allocator, which fits neatly in your head.

  bump_allocate(size) {
    let address;

    if (this._end + size > this._context.heapSize()) {
      throw new Error("Out of memory");
    }
    address = this._end;
    this._end += size;

    return address;
  }

One interesting thing to note is that the tuple (8 9) appears in memory before the tuple (5 6 7 Pointer(44)) which points to it, despite the tuples being introduced in the opposite order, as in:

b = (5 6 7 (8 9))

What's going on here is that Memo's interpreter works from the bottom up, which means that it needs to first allocate the memory for (8 9) and then it can stuff the address in the other newly-created tuple. This is a common design for this kind of simple parser.

Reading Objects in Memory #

Importantly, everything we have stored on the heap is self-describing, which allows us to decode the contents of the heap without ancillary storage, as long as we know the address of the first allocated object in memory, in this case 16. This works beacause each object has a common prefix in the first word, as noted above:

 0 1 2 3 4 5 6 7 8 9 9 1 2 3 4 5 6 0 1 2 3 4 5 6 7 8 9 9 1 2 3 4 5 6 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|F| RESERVED  |             TypeId (24 bits)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here we have a 32-bit (1 word on 32-bit processors) prefix which starts with a flags byte. The first two bits in this byte are assigned to a M (for marked) and F (for free) flag; we'll cover these later. The rest are reserved for futrue use.

The rest of the prefix contains the TypeId, which is an identifier for the type of the object. This identifier can be implemented in a number of ways, including:

A pointer to a type description.
An index into a table of type descriptions.

In either case, the type description will store the number of pointers in the object and their memory locations within the object. Importantly, every instance of an object needs to be laid out the same way, so that once you have the object pointer and the type, you know everything else about every element in the type.

The object decoding process for an object at address addr proceeds as follows:

Read the first 32-bit word and use that information to extract the type ID, which, as above, is stored in the low order 24 bits.
Look up the type using the type ID and from there determine the number of elements in the object.
Iterate over the elements and decode them. As noted above, elements are always of type pointer or type integer, but any given element can be either and element types can change. In order to address this we steal a bit from the top of each element to use for the type (this is often called "coloring" the pointer). For pointers, the high bit is 0 and for integers, the bit for 0x80000000 is set. This allows you to immediately see whether a given element is a pointer or an integer, but at the cost that you can only express values up to 2³¹.

Because all elements are the same size, the type also tells us the size of the object and so we can skip over to the next object, which, as noted above, starts immediately after the current object (we'll get to holes created by fragmentation later).

Aside: Dealing with binary flags in JS #

As an aside, it's a giant pain dealing with binary flags in JS because there's really only one number type (float) and JS has decided that 0x80000000 is a positive number but 0x80000000 is a negative number. As a result you get this kind of thing.

> flag = 0x80000000
2147483648
> a = 3
3
> a | flag
-2147483645
> (a & flag) == flag
false

LOLWAT?

I'm not a JS wizard but according to Gemini the fix is to add a bunch of 0-sized unsigned right shifts, like so:

> ((b & flag) >>> 0) & flag
-2147483648
> b = (a | flag) >>> 0
2147483651
> ((b & flag) >>> 0) == flag
true

So when you see these scattered all over the code you know why.

What is garbage? #

After that warmup, we're now ready to talk about garbage collection. As already stated, there's no way to explicitly tell Memo that we're not using a piece of memory, but we don't want to just have the amount of memory we use grow monotonically, so we need some way for Memo to reclaim that memory when it's no longer in use, hence garbage collection.

Conceptually, we have three kinds of memory:

Un-allocated (or freed/de-allocated) memory
Memory which has been allocated and is in use
Memory which is allocated but is not in use ("garbage")

In C and C++, the allocator (malloc()/free()) knows what memory has been allocated and what has not but it does not know which allocated memory is in use and which is not; it leaves that responsibility to the programmer, who must free memory when it is no longer in use. Automatic memory management requires a mechanism to identify which allocated memory is garbage and collect it.

Defining "in use" is a somewhat tricky proposition: if I allocate some memory at time T and just keep it around until the program ends, is it in use?^[5] It's entirely possible that under other circumstances I might have used it. For instance, suppose my browser loads some math fonts and then I never go to a page that renders math. But I might have, and obviously both I and the programmer would be unhappy if the language decided that the fonts would never be needed and just deallocated them, with the program crashing when I went to a site that used math!

Pretty much every system I am familiar with uses unreachability as the definition of garbage. Specifically, the assumption is that there are a set of "root" pointers which aren't themselves on the heap such as local variables (on the stack) or global variables. A piece of memory is defined as in use if you can reach it by following pointers from one of those root variables, e.g., root → B → C → D. If it's not reachable from one of the roots, then it's not in use. Because the language already knows which data is allocated and which isn't, it can no distinguish all three types of memory:

Un-allocated (or freed/de-allocated) memory
In-use memory is allocated and reachable
Garbage is memory that is allocated but unreachable

Note that this excludes some data which is morally garbage in the sense that the programmer knows they will never use it, but the language has no way of knowing that. The reachability definition defines garbage as memory which the language can prove the program can't use because there's no way to reference it. The figure below provides a simple example: allocations A – G are all reachable by either root1 or root2. Allocations H–K are unreachable and are therefore garbage.

Some in-use memory and some garbage

Now that we understand what garbage is, let's take a look at how to collect it.

Reference Counting #

As noted above, the simplest form of garbage collection is reference counting, which we already saw in part III. Reference counting works similarly in a garbage collected language as it does in C++, except that all of the machinery is hidden under the hood:

Every pointer is a reference counted pointer. This can be done with an intrusive pointer style design because we're starting from scratch and so can just insist that every object have an embedded reference count.
It's not possible to unbox pointers, so you never have to worry about any aliasing issues such as a raw pointer and a shared pointer pointing to the same object.

The language runtime automatically takes care of incrementing and decrementing reference counts as appropriate, and freeing objects when the reference count goes to zero. After that, things just work without you having to think about it.

The following widget shows reference counting in action with a simple memo program. You can use the previous and next buttons to step through the program one line at a time.

In the first three lines we build up a structure with four tuples:

The tuple (P1 2 3) pointed to by a
The tuple (4 5 6) pointed to by a.0 (P1).
The tuple (7 8 P2) pointed to by b.
The tuple (9 10 11 pointed to by b.2 (P2).

Note that in Memo it's not possible to create an object that isn't pointed to by anything, so we can ignore that case. In line 4, we set a to null, which turns both the object it points to into garbage as well as the (4 5 6) tuple that it points to. Once you execute line 4, both objects will be freed, leaving only the (7 8 P2) tuple pointed to by b and the (9 10 11) that P2 points to.

Note that the memory layout is slightly different than in the previous example in that we have an extra RefCt field between the type word and the elements. As suggested by the name, this field stores the reference count value. We have 32-bits for the reference count, which means that we can have up to 2³² references, which should be enough given that we can only have 2³¹ objects (because our pointers are 31 bits long). The result, however, is that when we use reference counting, we consume more memory per object than with some other kinds of garbage collection. This kind of efficiency concern can be a big deal in some systems, but not in a toy implementation like ours.

The key thing to notice is that what makes easy automatic memory management straightforward is that the system doesn't give you a choice. C and C++ were originally built with manual memory management and so every attempt to add automatic memory management has to contend with the old semantics. If you just build a language with automatic memory management from the ground up, things are a lot simpler.

Freed Memory #

I said above that when the reference count goes to zero, we free an object does that mean in practice? We've got one big contiguous memory region, so it's not like we can return the memory associated with a single object. Instead, freeing an object is a bookkeeping operation in which we note that that region is no longer in use. We do this by setting the F (for free bit) in the first word. Of course, even though the object is not in use, we still need to know how big it is. We address this by using the rest of the first word to store the object size.^[6] Because even unused memory regions aren't unstructured, we can understand the entire memory layout just by starting at the bottom of the heap and working forward one object at a time until we get to the top. For instance, here is a simple function which counts all the live objects:

  function ct() {
    let counter = 0;
    let scan = this._start;

    while (scan < this._end) {
      const flags = ObjectManager.getFlags(this._context, scan);
      const len = ObjectManager.getSize(this._context, scan);
      scan += len;

      if ((flags & FREE_BIT) === 0) {
        counter++;
      }
    }

    return counter;
  }

The only extra information you need is the address of the start of the heap (the start of the lowest allocated object) and the end of the heap (the last allocated byte). From there, you can just scan the entire heap, stopping when you get to the end.

Circular References #

Unfortunately, reference counting has a number of disadvantages that prevent most languages from using it as the sole form of garbage collection. The most important of these is that, as discussed in part III is that it deals badly with circular references, as shown in the example below:

As expected, when we have two objects which point at each other, neither will be freed even if we delete the reference from global variable a.

In part III we showed how to break reference cycles using weak pointers, but weak pointers require that the programmer explicitly tag some references as weak and some as strong, which undercuts the "it just works" value proposition of the garbage collector. Some languages do have support for weak pointers, but you really don't want the programmer to have to pay attention to this every time they create a reference cycle, which happens all the time. Less important, but still relevant, is that there is performance overhead from constantly having to increment and decrement the reference count of objects whenever you pass them around.

For these reasons, most garbage collected languages use another form of garbage collection, either on its own or in combination with reference counting. This nearly always means one of a broad class of algorithms called "tracing garbage collection".

Tracing Garbage Collection #

The basic idea behind a tracing garbage collector is to start from the root pointers and follow each pointer until you've enumerated every reachable object. Every other allocated object is garbage and can be freed. This is a simple idea, but doing it well is hard.

Mark-Sweep #

Let's start with the most elementary^[7] type of tracing garbage collector: mark-sweep. A mark-sweep collector proceeds in two passes:

Trace all the objects from the roots, recording which objects are reachable.
Scan over the entire heap, examining each object and freeing those which were not recorded as reachable.

Marking #

The first problem is how to trace all the reachable objects. Conceptually this is just a standard graph traversal problem, where you want to start at the roots and touch every node connected by an edge. You may be familiar with algorithms for traversing trees, and this is a similar problem with two additional complications:

You don't just start from the single root of the tree but from multiple roots, which may point to some of the same nodes.
This isn't necessarily an acyclic graph in the you can have reference cycles; recall that this is why we can't just use reference counting.

Nevertheless, this isn't particularly complicated. Here's a simplified version of the marking algorithm from our code (I've removed some of the JavaScript generator machinery that we use to step through the GC one piece at a time.)

  function *mark_incremental(roots) {
    this._work_queue = [];

    for (let root of roots) {
      if (!isPointer(root) || root == NULL_POINTER) {
        continue;
      }
      ObjectManager.mark(this._context, root);
      this._work_queue.push(root);
    }

    while (this._work_queue.length > 0) {
      // Pop first, then process
      const current = this._work_queue.pop();
      const num_ptrs = ObjectManager.getNumValues(this._context, current);

      for (let i = 0; i < num_ptrs; i++) {
        const ptr = ObjectManager.getValue(this._context, current, i);

        if (isPointer(ptr) && ptr !== NULL_POINTER) {
          const flags = ObjectManager.getFlags(this._context, ptr);

          if (!(flags & MARK_BIT)) {
            ObjectManager.setFlags(this._context, ptr, flags | MARK_BIT);
            this._work_queue.push(ptr);
          }
        }
      }
    }
  }

The basic logic is that every time we encounter a pointer to a new object we add it to the work_queue. Initially the queue is populated by the pointers stored in the roots (global variables), but then as we chase them we encounter new pointers stored in objects on the heap, which are themselves added to the work queue. We continue to pop objects off the work queue until the work queue is empty, at which point the marking process is done.

This design needs some way to know which objects we have already seen before. Otherwise if we have a loop where A points to B and B points to A we'll just go around that loop indefinitely. Unlike the pointer/integer distinction, this "seen" information cannot be stored in the pointers themselves because you might have two pointers to the same object, and if you first reach the object via pointer A you want to know that it was marked when you reach it again via pointer B; instead, it has to be stored along with the object, just as the reference count was. In this case, we have plenty of space in the type word, so we use the M bit to store a "marked" value, which indicates that the object has already been seen. When we encounter an object, we only add it to the work queue if the "marked" bit is clear (i.e., 0)

Sweeping #

Once we've completed the marking phase, we move on to the sweeping phase. As described above, we can just move through memory from the bottom of the heap one object at a time, using the object type field to know the size of an object and thus where one object ends and another begins.

When we encounter a new object, we first check the free bit. If that is set, the object is free and we move on to the next object. This can happen if the object was freed in a previous pass. We then check the mark bit.^[8]

If the mark bit is set, we clear it so that it can be marked in a future GC pass.
If the mark bit is clear, we set the free bit.

We then move on to the next object, continuing until we get to the end of the heap. Here's a slightly cleaned up version of the JS code Memo uses for mark-sweep.

  *gc_incremental(roots) {
    // Mark.
    this.mark_incremental(roots);

    let scan = this._start;

    while (scan < this._end) {
      const flags = ObjectManager.getFlags(this._context, scan);
      const len = ObjectManager.getSize(this._context, scan);
      // This is already free.
      if (flags & FREE_BIT) {
        scan += len;
        continue;
      }

      const nextscan = scan + len;
      // This is not marked, so free it.
      if ((flags & MARK_BIT) === 0) {
        ObjectManager.setFlags(this._context, scan, FREE_BIT);
        this._free_bytes += len;
      } else {
        ObjectManager.unmark(this._context, scan);
      }

      // Skip to the next entry.
      scan = nextscan;
    }
  }
}

You can use the following widget to step through the entire mark-sweep process. This is the same code as we saw above with reference counting with one small change which I'll get to shortly. As before, you can step through the code and watch how memory changes.

The first thing to notice is that after line 4 executes, we have the same two pieces of garbage (4 5 6) and (Pointer(48) 2 3), but unlike with reference counting they haven't been freed, but instead are just lurking around. This is because unlike reference counting, tracing garbage collectors don't free memory as soon as it becomes garbage; instead you have to explicitly run the garbage collection algorithm. The objects are still unreachable, so there's no way for them to be accessed, but they're still there taking up space:

In order to actually garbage collect these objects, we need to to run the mark-sweep algorithm. Ordinarily this is something that the system would do automatically, but to make things simple I've added a pseudo-instruction that invokes the garbage collector in the form of #gc. I say this is a pseudo-instruction because from the perspective of Memo it's a comment; instead the widget notices that you've asked for GC and runs the garbage collector externally.^[9]

Once we get to the GC instruction, you can then step through the GC algorithm one step at a time. The orange "scan" pointer shows which object we are examining now, and at appropriate times the "work queue" will be shown. For instance, here is the situation when the algorithm is examining the object at 64 and has just marked the object at 48 ((9 10 11)) and added it to the work queue.

Note that the marking phase doesn't proceed in any particular order through memory, because it's just tracing out the graph of object relationships. That's why we look at 64 first (because it's pointed to by b) and then 48 (because it's pointed to by 64). By contrast, the sweeping phase proceeds linearly through memory. Below, you can see partway through the sweeping phase, after we have freed 16 and right before we free 32.

At the end of the sweep process, all of the unreachable objects will be freed, leaving only the reachable objects, just as with reference counting,.

Reclaiming Memory #

Now consider what happens if we do a new allocation as in:

c = (12 13 14)

At this point, there are two things that can happen:

We can continue to bump allocate, and put the new object above the last object in memory, in this case at address 80.
We can reuse one of the regions we've freed, in this case probably at address 16.

There's a tradeoff here in that bump allocation is generally faster—you just need to increment one pointer—but eventually we have to start reusing free memory or there wasn't any point in garbage collecting at all. The basic challenge is fragmentation: once the program has run for a while you end up with a lot of "holes", which is to say small free regions interspersed with allocated regions, and you can have a situation where you have plenty of total free memory but no region big enough for a new allocation. If you reuse aggressively, this conserves the open region at the top of the heap for big allocations, but at the cost of having to search for a region that will fit each new allocation rather than just incrementing the next pointer. Your allocation strategy needs to try to compromise between these two.

Memo's allocator uses a fairly simple compromise strategy where it bump allocates up to the point where about:

The top of the heap is about halfway through the heap size.
About half of the region that has been used is holes.

After that it tries to reuse free space; this means that you get to use the fast allocator when there is no memory pressure but you start trying to reuse before you still have plenty of room for allocations that don't fit into any existing holes. Memo will coalesce adjacent free regions as necessary, so multiple small holes can be merged into a single bigger hold.

There are a lot of fancier strategies one can use, especially for figuring out which hole to put new allocations into. For instance, you can have a table of the free regions of a given size or "bucket" allocations into a small number of sizes so that it's easier to find an appropriate location (at the cost of wasting space when an allocation is just over the size of one bucket and a lot smaller than the next biggest bucket). None of these eliminate fragmentation, but they can reduce it. Whatever strategy you use, this is just something you have to deal with with mark-sweep or reference counting.

The reason we have fragmentation is that we don't get to choose which objects will be freed. Suppose we have three objects at 16, 32, and 48 of size 16. If we then free the objects at 16 and 48, we now have 32 bytes worth of free memory, but we can't allocate a 32 byte object because that memory is discontinuous; instead we need to use the bump allocator. Eventually this process results in lots of fragmentation. But what if we could instead slide the object at 32 over to 16, leaving the whole 32--64 region free? This isn't possible in C-like languages where the pointers are directly exposed to the programmer, but if you don't let the programmer look at pointers, you have a lot more freedom to operate.

Mark-Compact #

The next garbage collector we'll be looking at is what's called mark-compact. As the name suggests, a mark-compact collector starts with a marking phase just like mark-sweep, but after the sweep phase is complete, instead of just leaving holes it slides every object as far towards the left (low memory) as possible, eliminating all the holes.

The following two diagrams show the situation before and after the GC pass.

As you can see, the tuples (7 8 Pointer) and (9 10 11) have moved from their original positions at 56 and 76 to 16 and 36 respectively. As a result, all the allocated memory is now contiguous and so you can just bump allocate all the time.

This seems great because allocation is now super fast, but the cost is complexity in the GC phase. Specifically, we need to rewrite every pointer—or at least every pointer which points to an object we are keeping—to point to the location where the object will eventually end up. There are a number of algorithms for making this work, but Memo uses the relatively simple "Lisp 2" algorithm,^[10] which works in three passes.

Scan through memory one object at a time computing the eventual location of each live object. This effectively simulates bump allocation because each live object will just be right after the previous one. This information is stored in a new "Moved" field in each object, which is now one word larger than with mark-sweep (but the same size as in reference counting, in our implementation). Note that we need a separate word here because the object has to remain intact until we copy it.
Scan through memory one object at a time. For each pointer in each object, go to the object it points to and find the "Moved" pointer and rewrite the pointer with the "Moved" value (see the diagram below):
Scan through memory one object at a time, copying each live object to its new location.

The figure below shows an early part of phase 1, in which the moved pointer for the object at 56 has been set to its new location at 16.

A simplified version of Memo's code for this is below.

  function gc_incremental(roots) {
    // First mark.
    this.mark_incremental(roots);

    let free_ptr = this._start;

    // Step 1. Set the future addresses for each object
    // we are retaining.
    for (let scan = this._start; scan < this._end; ) {
      const size = ObjectManager.getSize(this._context, scan);
      if (ObjectManager.isMarked(this._context, scan)) {
        ObjectManager.setXword(this._context, scan, free_ptr);
        free_ptr += size;
      }
      scan += size;
    }

    // Step 2. Update references for each marked object.
    for (let scan = this._start; scan < this._end; ) {
      const size = ObjectManager.getSize(this._context, scan);
      if (ObjectManager.isMarked(this._context, scan)) {
        const num_ptrs = ObjectManager.getNumValues(this._context, scan);

        // Iterate over all the pointers and update the value to whatever
        // is in the moved field in the pointed at value.
        for (let i = 0; i < num_ptrs; i++) {
          const ptr = ObjectManager.getValue(this._context, scan, i);
          if (!isPointer(ptr) || ptr === NULL_POINTER) {
            continue;
          }

          const new_ptr = ObjectManager.getXword(this._context, ptr);
          ObjectManager.setValue(this._context, scan, i, new_ptr);
        }
      }
      scan += size;
    }

    // Update the roots.
    let new_roots = [];

    for (let root of roots) {
      new_roots.push(ObjectManager.getXword(this._context, root));
    }
    // Step 3. Move all objects into their expected locations.
    let end = this._start;
    for (let scan = this._start; scan < this._end; ) {
      const size = ObjectManager.getSize(this._context, scan);
      if (ObjectManager.isMarked(this._context, scan)) {
        const target = ObjectManager.getXword(this._context, scan);
        Memory.memmove(this._heap, target, this._heap, scan, size);
        // Unmark the new copy so it can be GCed later.
        ObjectManager.setXword(this._context, target, NULL_POINTER);
        ObjectManager.unmark(this._context, target);
        end += size;
      }
      scan += size;
    }
    this._end = end;
    return new_roots;
  }

The widget below will let you watch the mark-compact process in action.

Mark-compact collectors minimize fragmentation but at a modest cost in terms of memory overhead (due to the "moved" field) and a performance cost in terms of multiple passes over memory. There are fancier mark-compact two pass algorithms (one mark pass, one compaction pass) that use ancillary storage for the forwarding addresses (see § 3.4 of the Garbage Collection Handbook for one such example). If you're willing to really go wild with memory consumption, however, you can have an even simpler GC phase. This is the idea behind a copying (also called "semispace") collector.

Copying Garbage Collectors #

The idea behind a copying collector is that you have two heaps, A and B.^[11] Each of these heaps is about the same size as your normal heap, so this consumes twice as much memory.^[12] You initially allocate your objects in A using a standard bump allocator, and then when it is time to perform garbage collection you copy all the live objects into B and abandon anything left in A. Because B is compact, you can continue to use a bump allocator, and then when you GC, you copy from B into A, and so on. This can all be done in a single pass because you're using the source heap as temporary storage while you copy into the destination heap.

Memo's copying algorithm is shown below, but it's helpful to walk through it.

  process_ptr(address) {
    if (ObjectManager.isMarked(this._context, address, this.#from_heap)) {
      // The first word is overloaded for the forwarding address.
      return [
        ObjectManager.readHeaderWord(this.#from_heap, address) & ~MARK_BIT,
        false,
      ];
    }

    // Not moved yet.
    const size = ObjectManager.getSize(this._context, address, this.#from_heap);
    const new_address = this._end;
    Memory.memmove(this._heap, new_address, this.#from_heap, address, size);
    this._end += size;

    // Now overwrite the first word to point to the new location.
    ObjectManager.writeHeaderWord(this.#from_heap, address, new_address);
    ObjectManager.mark(this._context, address, this.#from_heap);
    this.#movedList[address] = { labels: [["Moved", new_address]], size };
    return [new_address, true];
  }

  *gc_incremental(roots) {
    this.#movedList = {};
    this.#inGc = true;
    this.flip();

    this._work_queue = [];
    let new_roots = [];
    // First process the roots.
    for (let root of roots) {
      if (!isPointer(root) || root === NULL_POINTER) {
        continue;
      }
      let [address, todo] = this.process_ptr(root);
      new_roots.push(address);
      if (todo) {
        this._work_queue.push(address);
      }
    }

    // Now trace through all objects, copying as we go.
    while (this._work_queue.length) {
      const current = this._work_queue.pop();

      const num_ptrs = ObjectManager.getNumValues(this._context, current);
      for (let i = 0; i < num_ptrs; i++) {
        const pointer = ObjectManager.getValue(this._context, current, i);
        if (!isPointer(pointer) || pointer === NULL_POINTER) {
          continue;
        }
        let [address, todo] = this.process_ptr(pointer);
        if (todo) {
          this._work_queue.push(address);
        }
        ObjectManager.setValue(this._context, current, i, address);
      }
    }

    this.#inGc = false;
    return new_roots;
  }

Like mark-sweep and mark-compact, a copying GC works by tracing objects from the roots. Every time you encounter a pointer p for the first time you do the following (this is mostly in process_ptr():

Copy the object into the destination address space ("to-space") Call the new address n
Overwrite the first word (at p) with the new address (n). This makes the object invalid, because valid objects have the type in the low-order three bytes of the first word, but this is safe because you have already copied the object so you can use the original (in "from-space") as scratch space. We don't need a separate word in each object like we do for mark-compact.
Set the mark bit in the first word (at p) so you can tell you have seen it.^[13]
Add the object to the work queue.

Every time you pull an object off the work queue (by definition, all these objects are already copied) you look at each pointer p. If the pointer p is new, you copy the object (as above) and remember n. Otherwise, you just look at the type field to get n. You then overwrite the pointer with n, leaving this object with correct pointers. Once you have finished with the work queue, you have (1) copied every live object and (2) updated all their pointers and you are done. You can then abandon the source heap, which will become the destination heap the next time around.

This is a simple algorithm but can be a bit confusing, so it's helpful to go through this step by step.

The above figure shows the result of the first GC step, where we have processed the object pointed at by the first root, which was at address 64. As this was the first object processed (the only one pointed to by the root) it got copied to the lowest address in the other half the heap (to-space). Note that it was copied as-is, which means that it's internal pointers all still refer to some object that has not been copied yet (i.e., they point to from-space). This will have to be patched up later, which is why this object had to be added to the work queue. We used the original copy of the object (in from-space) to store a tombstone indicating where the object was moved to. The rest of the object has the original contents, but those will never be examined and could in principle be invalid.

Now that we've exhausted the roots, we move to process the work queue, which means processing the object at to:16. We iterate through all the pointers in that object, copying the objects into to-space (again, as-is), and then patch up the pointer in to:16 to match the new location, as shown below:

Now, the work queue has the object we just copied, which is stored at to:32. Next we scan through that object looking through pointers, but there aren't any, so once we've completed that the GC process will be complete, and we can just abandon from-space and all its objects.

The widget below will let you walk through this all one step at a time if you want.

One thing to notice here is that unlike mark-compact, which just slides all the allocations to the left, a copying GC does not necessarily preserve the relative order of allocations on the heap. For example, in the line

b = (7 8 (9 10 11))

This allocates the internal tuple first (at lower memory) and the external tuple second (at higher memory). However, when we trace from the roots, we encounter the external tuple first and so it gets copied first, ending up at lower memory, as seen below.

This won't have a correctness impact, but may have a performance impact depending on the original layout and memory access patterns. Note that on a second copy, this order will be preserved, because we access the outer tuple first.

Next Up: Advanced Garbage Collection #

The algorithms described in this post are the foundation of basically every modern GC, but I've only described them in their simplest form. In the next post, I'll be covering some of the complexities in making GC deployable, especially for a high performance interactive system (e.g., a Web browser). Importantly, all of these complexities are (nearly) completely hidden from the programmer, because they mostly have performance impacts in terms of when and how fast the GC runs. This allows the language implementor to improve the GC in their runtime without the language user having to do anything to get the benefits of the new implementation. This isn't to say that they aren't important, however: GC can have a huge impact on the performance of a system.

There's also a minor approach where you can't do any memory allocation, like in old school FORTRAN, but we can ignore that. ↩︎
Mostly. Note that this doesn't mean you don't need to think about whether you are doing deep or shallow copies because they have different programming semantics. You don't have to worry about whether there is memory being allocated, though. ↩︎
Some languages have nice idioms for this, like the JS ... spread operator, but Memo is deliberately minimalist, and so there's not even a way to do this generically without knowing the length. However you can use Lisp-style lists. ↩︎
Don't trust me, trust the Web security model. ↩︎
Occasionally you'll see someone propose a system for avoiding memory leaks that comes down to just keeping a pointer to all allocated memory, with the result that that data is morally leaked but not formally leaked. I can never tell if these people are serious. ↩︎
I went back and forth on whether to just keep the type field, which also carries the size, but eventually decided it was better to store the size. The reason for this is slightly subtle: when we get to mark-compact later, it is possible to temporarily have holes which are smaller than any valid object (because the smallest object will be two words and the hole can be one word). This isn't an issue for the garbage collector itself, which doesn't need to skip over them, but it messes up the code I'm using to draw the heap. Storing the length in the first word always works and doesn't have this problem. ↩︎
Or, as I once heard Frank Jackson, who had worked extensively on the Smalltalk 80 garbage collector call it "the second lamest form of garbage collection". ↩︎
Note that it's not possible for the mark bit to be set on a freed object because otherwise it wouldn't have been freed. ↩︎
I could have added a GC instruction to Memo, but I didn't for two reasons. First, this would be unusual because GC is usually automatic. Second, I wanted to let you step through the GC one operation at a time and that wouldn't work if the instruction were processed by the Memo interpreter directly. ↩︎
See § 3.2 of the Garbage Collection Handbook. ↩︎
In our implementation, we just have two heaps that share the same address space starting at 0, and internally I keep track of which heap is in use. This is fine because the addresses are just indexes into a table. In a system which was closer to the metal, you might instead tag the addresses using the higher order bits, as we have been doing so far. ↩︎
The other way of looking at it is that you have one heap which is split into two "semispaces". ↩︎
This is all a bit fiddly because in other contexts the same bit (0x80000000) means that the field is an integer rather than a pointer, but in this case we know it's a pointer so we can overload the meaning. ↩︎

Understanding Memory Management, Part 5: Fighting with Rust

2025-04-20T00:00:00Z

This is the fifth post in my planned multipart series on memory management. You will probably want to go back and read Part I, which covers C, parts II and III, which cover C++, and part IV, which introduces Rust memory management. In part IV, we got through the basics of Rust memory management up through smart pointers. In this post I want to look at some of the gymnastics you need to engage in to do serious work in Rust.

Unexpected Moves #

Consider the following simple Rust code:

fn main() {
    let x = vec![1, 2];

    for y in x {
        println!("{}", y);
    }
    println!("{}", x.len());
}

This is straightforward: we create a vector containing the values [1, 2], then iterate over it and print each element, and then finally print out the length of the vector. This is the kind of code people write every day. Let's see what happens when we compile it.

Error[E0382]: borrow of moved value: `x`
   --> iter_into.rs:7:20
    |
2   |     let x = vec![1, 2];
    |         - move occurs because `x` has type `Vec`, which does not implement the `Copy` trait
3   |
4   |     for y in x {
    |              - `x` moved due to this implicit call to `.into_iter()`
...
7   |     println!("{}", x.len());
    |                    ^ value borrowed here after move
    |
note: `into_iter` takes ownership of the receiver `self`, which moves `x`
   --> /Users/ekr/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/iter/traits/collect.rs:346:18
    |
346 |     fn into_iter(self) -> Self::IntoIter;
    |                  ^^^^
help: consider iterating over a slice of the `Vec`'s content to avoid moving into the `for` loop
    |
4   |     for y in &x {
    |              +

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0382`.
make: *** [iter_into.out] Error 1

No joy! The error message is reasonably helpful, though:

note: `into_iter` takes ownership of the receiver `self`, which moves `x`

At a high level, here is what is happening.

The for y in x syntax tells Rust you want an iterator
In order to produce that iterator, Rust calls x.into_iter(), defined by the trait IntoIterator which results in an iterator over i32.
The iterator takes ownership of the input vector x.

In the spirit of this series, though, let's dig one level deeper. You can ignore the rest of this section if you don't really care about Rust details, but this took me a little while to work out, so it's going up on the Internet.

The for y in x expression in Rust is syntactic sugar for creating an iterator. The x value must implement the IntoIterator trait, which has the method into_iter():

pub trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item = Self::Item>;

    // Required method
    fn into_iter(self) -> Self::IntoIter;
}

.into_iter() returns an Iterator object which exposes a .next() method that returns the next value in the iterator. You can loop over the iterator by calling .next() until it returns None (see here for some background on union types in Rust). For reference, here's what the Rust reference says is the equivalent code to for ...:

{
    let result = match IntoIterator::into_iter(iter_expr) {
        mut iter => 'label: loop {
            let mut next;
            match Iterator::next(&mut iter) {
                Option::Some(val) => next = val,
                Option::None => break,
            };
            let PATTERN = next;
            let () = { /* loop body */ };
        },
    };
    result
}

As the code above says, Rust implicitly calls IntoIterator::into_iter(x), which is to say it calls the .into_iter() method call for x (in this case of type Vec<i32>, i.e., x.into_iter()). The IntoIterator::into_iter() syntax is needed in case x implements more than one trait that has an into_iter() method because we need to tell the Rust compiler which method to choose (see below).

This syntactic sugar is all internal compiler magic, but from here on in the rest is normal (though a bit arcane) Rust.

Function Overloads #

So why does this result in a move and why does replacing x with &x fix it? If you've done any Rust programming, you know that you can call a method that takes any kind of self parameter (i.e., a moved object, a reference, or a mutable reference) as self.foo and Rust will automatically produce the right kind of parameter assuming your object is compatible in terms of mutability.

For instance:

Code #

struct X {}

impl X {
    fn ref_method(&self) {
        println!("ref");
    }

    fn mut_ref_method(&mut self) {
        println!("mut_ref");
    }

    fn move_method(self) {
        println!("move");
    }
}

fn main() {
    let mut x = X {};
    let mut y = X {};
    let yref = &mut y;

    x.ref_method();
    x.mut_ref_method();
    x.move_method();
    // x.move_method();     Does not compile
    yref.ref_method();
    yref.mut_ref_method();
    // yref.move_method();  Does not compile
    (&y).ref_method();
    (&mut y).mut_ref_method();
}

Output #

ref
mut_ref
move
ref
mut_ref
ref
mut_ref

x is actually a mutable object, but as you can see, when we call the ref_method, it gets an immutable reference and the mut_ref_method it gets an immutable reference, so the compiler just handles this. Note that if we try to call x.move_method() twice, we get an error about the use of a moved value, just as we expect (that's why I called this method last).

error[E0382]: use of moved value: `x`
  --> receiver1.rs:23:5
   |
18 |     let mut x = X {};
   |         ----- move occurs because `x` has type `X`, which does not implement the `Copy` trait
...
22 |     x.move_method();
   |       ------------- `x` moved due to this method call
23 |     x.move_method()
   |     ^ value used here after move
   |

Similarly I can create a new X named y and a reference to it called yref and call most of the methods via it. Note that you can't call move_method() because you're not allowed to move things via references that way:

error[E0507]: cannot move out of `*yref` which is behind a mutable reference
  --> receiver1.rs:27:5
   |
27 |     yref.move_method();
   |     ^^^^ ------------- `*yref` moved due to this method call
   |     |
   |     move occurs because `*yref` has type `X`, which does not implement the `Copy` trait
   |
note: `X::move_method` takes ownership of the receiver `self`, which moves `*yref`
  --> receiver1.rs:12:20
   |
12 |     fn move_method(self) {
   |                    ^^^^

I can even do the same thing without the temporary and just say (&y).ref_method().

So, if x and &x are (mostly) interchangeable in method calls, why do we have a problem and why does &x fix it. The answer lies in the fact that we're not calling a normal method but rather an implementation of a trait (in this case IntoIterator). Because traits are disconnected, it's possible for two traits to have the same methods, like so:

struct Hat {
    size_cm: f64,
}

trait Metric {
    fn size(&self);
}

impl Metric for Hat {
    fn size(&self) {
        println!("Metric: {}", self.size_cm);
    }
}

trait Imperial {
    fn size(&self);
}

impl Imperial for Hat {
    fn size(&self) {
        println!("Imperial: {}", self.size_cm / 2.5);
    }
}

Both Metric and Imperial have size() functions, so if we make a Hat and call .size(), what will happen? The answer is a compilation error:

error[E0034]: multiple applicable items in scope
  --> trait-overload.rs:28:7
   |
28 |     h.size();
   |       ^^^^ multiple `size` found
   |
note: candidate #1 is defined in an impl of the trait `Imperial` for the type `Hat`
  --> trait-overload.rs:20:5
   |
20 |     fn size(&self) {
   |     ^^^^^^^^^^^^^^
note: candidate #2 is defined in an impl of the trait `Metric` for the type `Hat`
  --> trait-overload.rs:10:5
   |
10 |     fn size(&self) {
   |     ^^^^^^^^^^^^^^

What's going on here is that the compiler has no way of knowing which version of size() we want to call, because there are two equally valid versions. In order to fix this, we need to disambiguate them, and the compiler helpfully tells us how:

help: disambiguate the method for candidate #1
   |
28 |     Imperial::size(&h);
   |     ~~~~~~~~~~~~~~~~~~
help: disambiguate the method for candidate #2
   |
28 |     Metric::size(&h);

You can get pretty far with Rust by just doing what the compiler says, and if we do that, things work as expected:

Code #

struct Hat {
    size_cm: f64,
}

trait Metric {
    fn size(&self);
}

impl Metric for Hat {
    fn size(&self) {
        println!("Metric: {}", self.size_cm);
    }
}

trait Imperial {
    fn size(&self);
}

impl Imperial for Hat {
    fn size(&self) {
        println!("Imperial: {}", self.size_cm / 2.5);
    }
}

fn main() {
    let hat = Hat { size_cm: 10.0 };

    Metric::size(&hat);
    Imperial::size(&hat);
}

Output #

Metric: 10
Imperial: 4

If you look closely, though, you'll notice something that we had to pass a reference to size(), as in Metric::size(&hat); if we just change this to Metric::size(hat) you get a compilation error:

  --> trait-overload2.rs:28:18
   |
28 |     Metric::size(hat);
   |     ------------ ^^^ expected `&_`, found `Hat`
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected reference `&_`
                 found struct `Hat`
note: method defined here
  --> trait-overload2.rs:6:8
   |
6  |     fn size(&self);
   |        ^^^^
help: consider borrowing here
   |
28 |     Metric::size(&hat);
   |                  +

That's interesting: when we invoked a method with .size() it didn't matter whether we explicitly provided a reference or an object, everything worked great. But when we invoke it this way, we actually have to provide an argument that will match the self parameter, whether that's a value, a reference, or a mutable reference, because we don't get the magic behavior associated with ..^[1]

Implementations of `IntoIterator` #

We're now in a position to understand what's happening here. When we do IntoIterator::into_iter(x) this tells Rust to expect a version of into_iter() that takes a value argument (i.e., Vec<i32>) which means we have to move x into the function, so we can't reuse it.

It's a short step from there to understand why doing for y in &x works: there is also a version of IntoIterator for &Vec<i32>, so if we call IntoIterator::into_iter(&x) then that version gets invoked (at this point, these are just totally different types from Rust's perspective). Because that version just borrows x, things work fine with no double move.^[2]

[Fixed to_iter to be into_iter -- 2025-05-26].

Code #

fn main() {
    let x = vec![1, 2];

    for y in &x {
        println!("{}", y);
    }
    println!("{}", x.len());
}

Output #

1
2
2

You might ask at this point why Rust doesn't instead just do .into_iter()? I can't find an explanation in the Rust documentation but I expect the reason is that someone could implement another trait that provides .into_iter() on whatever the x is in for y in x, thus resulting in a compiler error because there would be two candidate implementations.

Method Calls #

The next thing I want to look at is the impact of method calls. This section uses the following (over)simplified model of a photo album module to walk through the relevant issues:

#[derive(Debug, Clone)]
pub struct Photo {
    pub label: String,
    pub content: Vec<u8>,
}

impl Photo {
    fn new(label: &str, content: Vec<u8>) -> Photo {
        Photo {
            label: String::from(label),
            content,
        }
    }

    pub fn scale(&self, _scale: f32) -> Photo {
        // In a real program this would adjust the
        // size, but here it just makes a copy.
        Photo {
            label: self.label.clone() + "-copy",
            content: self.content.clone(),
        }
    }
}

pub struct Album {
    photos: Vec<Photo>,
}

impl Album {
    // Load photos from disk. Right now just a stub.
    pub fn init(_directory: &str) -> Self {
        let mut album = Album { photos: Vec::new() };

        for i in 0..5 {
            // This is where we would load the content.
            let content = Vec::new();
            album
                .photos
                .push(Photo::new(&format!("Image {i}"), content));
        }
        album
    }

    pub fn add_photo(&mut self, photo: Photo) -> usize {
        self.photos.push(photo);
        self.photos.len()
    }

    pub fn get_photo(&self, index: usize) -> &Photo {
        &self.photos[index]
    }

    pub fn list_photos(&self) -> Vec<String> {
        self.photos
            .iter()
            .map(|photo| photo.label.clone())
            .collect()
    }
}

This should be easy to follow if you know any C-like language, even if you don't know Rust, but just to orient you:

A Photo is a structure containing a label and some bytes that represent the image (content) (recall that I said this was oversimplified).
An Album is a collection of photos.

Obviously, these "photos" are vacuous, in that they're just bytes, but we're not going to be displaying them. Moreover, in a real program, the album constructor (init) would load the photos from a directory, but in this case it just makes up 5 empty Photos; this is all fake, but the point here is just to have some scaffolding to motivate/demonstrate the relevant issues.

Now, consider this simple program:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo);
    println!("Photos {:?}", album.list_photos());
}

Obviously, this does the following:

First, we create the photo album (again, this is supposed to be loading photos from the disk).
Make a new photo that is a scaled down version of the first photo.
Add the new photo to the album.
List the photos.

This program compiles and runs just fine, like so:

Photos ["Image 0", "Image 1", "Image 2", "Image 3", "Image 4", "Image 0-copy"]

So far so good. Now, let's make a trivial modification where we also add a bigger photo. No problem, we'll just do some copy-and-paste DRY be damned:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo);
    let bigger_photo = first_photo.scale(10.0);
    album.add_photo(bigger_photo);
    println!("Photos {:?}", album.list_photos());
}

Unfortunately, this totally doesn't work. Instead, we get the following error.

error[E0502]: cannot borrow `album` as mutable because it is also borrowed as immutable
 --> examples/ex2.rs:7:5
  |
5 |     let first_photo = album.get_photo(0);
  |                       ----- immutable borrow occurs here
6 |     let smaller_photo = first_photo.scale(0.1);
7 |     album.add_photo(smaller_photo);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
8 |     let bigger_photo = first_photo.scale(10.0);
  |                        ----------- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `photos` (example "ex2") due to 1 previous error

LOLWAT?

The error message here is pretty good, but it's worth going through what's happening:

When we called album.get_photo() the return value was a reference to an individual photo in album. In order to effectuate this, Rust takes an immutable reference to album, even though it's actually just returning a reference to one of the photos.
When we now go to call album.add_photo() we need to take a mutable reference to album in order to provide it as the &mut self argument to album.add_photo(). However, because we already have an immutable reference to album, this is a double borrow and the compiler generates an error.

But wait, you say, I'm doing exactly this in the first program, and indeed you are. Let's look at these side by side:

Working #

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo);
    println!("Photos {:?}", album.list_photos());
}

Broken #

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo); // <--- Double borrow here.
    let bigger_photo = first_photo.scale(10.0);
    album.add_photo(bigger_photo);
    println!("Photos {:?}", album.list_photos());
}

Sure enough, the offending line is the first call to add_photo() which was in the original code, not in the new code we added after. How can later code break earlier code?

The answer here is—surprise!—the borrow checker. What's going on is that in the original code the last time we use first_photo is in the call to .scale(), so even though it's in scope when we call .add_photo() the borrow checker knows we're not going to use it and so decides that it's not really live at the earlier point, and so we don't have a double borrow. What causes the problem in the new code is that we use first_photo in the second call to scale(), which means that it has to be still be live when we call add_photo(), resulting in the double borrow error.

OK, so we know the problem. How can we fix it? There are a number of options.

Drop and Re-borrow #

The easiest thing to do is to invalidate first_photo by dropping first_photo and reacquiring it after we call .add_photo(), as shown below:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0); // Acquire `first_photo` the first time
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo);
    let first_photo = album.get_photo(0); // Re-acquire `first_photo`
    let bigger_photo = first_photo.scale(10.0);
    album.add_photo(bigger_photo);
    println!("Photos {:?}", album.list_photos());
}

I've done the Rust idiomatic thing here and reused the name first_photo, thus shadowing the original variable, and you might think that that's important, but this actually isn't necessary because the Rust compiler can infer when a variable is being used, as we saw before. It works just as well if you name the new variable first_photo2.

Re-acquiring first_photo is a reasonable approach in this case because finding the photo is just a matter of looking up the first value in the .photos vector in album and vector lookups are fast. However, imagine that instead we had to do some expensive operation that involved examining all the photos in the album. Imagine there was an API that asked for the photo of the cutest cat. Clearly we wouldn't want to do that computation again!

Store a Handle #

If we were using some expensive API to find the photo, then we need to find some way to avoid paying that cost for each photo we want to transform. One way to handle that is to have that API return a handle to the photo rather than the photo itself. The obvious thing to do here is to have the handle just be the index in the array, like so:

fn get_cutest_cat(&self) -> usize;

You could then store the index and call get_photo() repeatedly, as in the previous example, thus amortizing the expensive operation and repeating the cheap one.

This will work as long as add_photo() doesn't invalidate the handle. In this case, it doesn't because we add photos to the end of the vector, but if we inserted them at the front, then it would shift our photo up by one, invalidating the handle. Note that this isn't something that would be caught by the compiler; it just causes a correctness error because the second time through we try to resize the previous photo rather than the one we intended. Deleting a photo would have a similar problem. Note that no matter how badly you screw up, this won't cause a memory error because Rust won't let you index outside of the array; it's just a correctness issue, but that doesn't mean it's not serious.

Make a Copy #

Alternatively, we can make a copy of the photo. Fortunately,^[3] Photo implements Clone, so this is straightforward:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0).clone(); // Code changed here.
    let smaller_photo = first_photo.scale(0.1);
    album.add_photo(smaller_photo);
    let bigger_photo = first_photo.scale(10.0);
    album.add_photo(bigger_photo);
    println!("Photos {:?}", album.list_photos());
}

The obvious problem here is that the .clone() is actually moderately expensive: we need to allocate enough space for a new copy of the image and then copy the image data over. That's a lot of work to solve a simple problem. Worse yet, this solution isn't always available, as we might be working with a type that didn't implement Clone or that wasn't in principle cloneable, for instance because it was holding some external resource like a file. Nevertheless, this is a common approach.

Restructure the Code #

The final approach available to us is to restructure the code a bit so that the lifetime of first_photo doesn't overlap the calls to .add_photo(). In this case, this is a fairly simple matter of computing both smaller_photo and bigger_photo and then adding them both, like so:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let smaller_photo = first_photo.scale(0.1);
    let bigger_photo = first_photo.scale(10.0);
    album.add_photo(smaller_photo);
    album.add_photo(bigger_photo);
    println!("Photos {:?}", album.list_photos());
}

This is probably the most idiomatic thing to do in this specific case in that it doesn't have the negative performance effects of the previous options and doesn't require any changes to the API as the last two options potentially do (making Photo Clone or adding a handle API). However, it's also a lot more disruptive to the logic of the code. Suppose that you wanted to use a loop to generate images of various size, like so:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let sizes = [0.1, 0.5, 1.0];
    for size in sizes {
        let new_photo = first_photo.scale(size);
        album.add_photo(new_photo);
    }
    println!("Photos {:?}", album.list_photos());
}

Now we have to aggregate all of the modified versions of the original photo and then add them all at once, like so:

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory");
    let first_photo = album.get_photo(0);
    let sizes = [0.1, 0.5, 1.0];
    let mut new_photos = Vec::new();
    for size in sizes {
        let new_photo = first_photo.scale(size);
        new_photos.push(new_photo);
    }
    for photo in new_photos {
        album.add_photo(photo);
    }
    println!("Photos {:?}", album.list_photos());
}

At one level, this is just irritating, in that we have to restructure the code. But because we're having to store the transformed photos in memory we're potentially increasing the memory footprint of the program significantly. That's not the case here because add_photo() just moves a photo from the temporary vector to the vector in album,^[4] but if Album stored photos on disk, we could run out of memory in the first loop whereas if we stored photos right away that wouldn't happen. In this situation you would have to use one of the other approaches.

Non-Lexical Lifetimes #

I said above that Rust could infer that first_photo wasn't in use and therefore it didn't count as a reference for the purposes of the borrowing rules. This didn't used to be true. In older versions of Rust, the fact that the variable existed was enough to keep the reference alive, whether it was subsequently used or not. So, for instance, if we go back to our original code, we would have a double-borrow problem because first_photo is still in scope through the end of the function. Instead, you would have had to do something like this:

    let mut album = Album::init(&"directory");
    {
      let first_photo = album.get_photo(0);
      let smaller_photo = first_photo.scale(0.1);
    }  // first_photo dropped here
    album.add_photo(smaller_photo);
    println!("Photos {:?}", album.list_photos());

Putting first_photo in a braced block like this causes it to be explicitly dropped so that when add_photo needs to borrow &mut self it's not a double borrow. This was obviously a pain in the ass and Rust eventually added a feature called non-lexical lifetimes which made the compiler smarter about knowing when references were really live.

One thing to notice is that the original code was always safe, it's just that the compiler didn't realize it. Rust's borrow checker is conservative in that it will only accept code it can prove is safe, but it will also reject code which is actually safe but the borrow checker can't prove is safe. This leaves room for improvements in the language as the borrow checker gets smarter and constructs which would previously have been errors—but were actually safe—become allowed.^[5]

Why, oh why? #

At this point, you might want to ask why Rust is torturing you like this? Why can't I just do what I want to, like in good ol' C++? And at first glance, it looks like the original double borrow code is safe. After all, we're not using first_photo simultaneously with album.add_photo(), it's just sitting there waiting for us to use it again.

But actually what's happening here is the same problem we saw in the previous post: first_photo is a reference (a pointer) to an element in the array, as shown below:

first_photo is a reference

If we add a new photo and that causes the memory allocated to the array or vector to resize (this can happen even if we just add an element to the end), then suddenly first_photo is pointing to an unallocated region of memory, as shown below.

first_photo after a resize

If Rust is going to be safe, it can't allow this, so the code won't compile.

Safer Handles #

As an aside, it's somewhat possible to write handles in a way that is safer than just a simple integer. For example, we could have the handle store not just the index of the element but also some identifier for the contents of the element in such a way that the handle would become invalid if the element changed. In this case, the result would be that if an element were inserted before the photo, shifting the elements to the right, an attempt to dereference the handle would fail, so you'd get a runtime error.

Probably a better approach in this case is to replace a generic handle with a query which caches its results. For instance, we could have find_cutest_cat() remember the current cutest cat and which photos it had looked at and then when you ask for the result, it just looks at any new pictures of cats to compare them to the current cutest; this is far more robust than trying to build some kind of safer handle structure.

It's important to realize that the logical situation is the same as with handles: we have a reference (in the general sense, not the Rust technical sense), which is now invalid. The difference is that the handle (in this case an integer) is an offset into the vector, as opposed to the address of some random region in memory. This means that only one of two things can happen:

The handle is smaller than the size of the array and so there's an element at the relevant location, just not the one that's expected. This causes the program to silently malfunction.
The handle is greater than or equal to the size of the array, in which case you'll get a runtime error right away.

In neither case do you have a memory error. This nicely illustrates the sense in which Rust is "safe", namely that it prevents you from memory errors but not logic errors (though it does protect against some, as seen below). It's still very possible to write bugs in Rust; it's just that they don't result in memory corruption.

Lifetimes #

In the previous section I just glossed over something tricky. Let's take another look at Album::get_photo():

    pub fn get_photo(&self, index: usize) -> &Photo {
        &self.photos[index]
    }

In this code I'm taking a reference to &self.photos[index] and returning it, but what makes this safe? Suppose that album gets deleted while I'm still hanging on to the return value. Don't I get a dangling reference. Let's try it and see.

use photos::photos::*;

pub fn main() {
    let first_photo;
    {
        #[allow(unused_mut)]
        let mut album = Album::init(&"directory");
        first_photo = album.get_photo(0);
    }
    let _ = first_photo.scale(0.1);
}

Reassuringly, this won't compile, producing the following error:^[6]

error[E0597]: `album` does not live long enough
  --> examples/ex4.rs:8:23
   |
7  |         let mut album = Album::init(&"directory");
   |             --------- binding `album` declared here
8  |         first_photo = album.get_photo(0);
   |                       ^^^^^ borrowed value does not live long enough
9  |     }
   |     - `album` dropped here while still borrowed
10 |     let _ = first_photo.scale(0.1);
   |             ----------- borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `photos` (example "ex4") due to 1 previous error

Dodged a bullet there. After we've taken a deep breath because Rust saved us from ourselves, we might start to wonder what is actually going on here: how does Rust know that first_photo is a borrow of album? That's information that is only available by looking at the implementation of get_photo() and remember what I said about local reasoning?

Understanding what is going on here requires understanding what Rust calls "lifetimes". Let's start with the basic rule that Rust enforces.

If B is a reference to object A then B can't outlive object A.

Obviously, what's gone wrong here is that album goes out of scope at the end of the block enclosing it, at which point the reference to album in first_photo is invalid. I.e., it has outlived album.

The lifetime of a variable is the time between when it's first created and when it's last used. So, another way of stating the above rule is that:

If B is a reference to object A then B's lifetime must be contained within A's lifetime (though they can be coextensive).

Just to see the problem more clearly here, I've annotated the code to show the relevant lifetimes. The annotated code below shows the lifetime of album and first_photo in our working code. As you can see, first_photo is last used before the end of the block, which is when album goes out of scope (and hence the end of its lifetime).

use photos::photos::*;

pub fn main() {
    let mut album = Album::init(&"directory"); <---------------+
    let first_photo = album.get_photo(0);      <-\ Lifetime of | Lifetime of
    let smaller_photo = first_photo.scale(0.1);<-/ first_photo | album
    album.add_photo(smaller_photo);                            |
    println!("Photos {:?}", album.list_photos());              |
}                                              <---------------+

Now compare the annotated version of the broken code:

use photos::photos::*;

pub fn main() {
    let first_photo;
    {
        #[allow(unused_mut)]
        let mut album = Album::init(&"directory"); <-+ Lifetime
        first_photo = album.get_photo(0);            | of album  <-+
    }                                              <-+             | Lifetime of 
    let _ = first_photo.scale(0.1);                <---------------+ first_photo
}

As before, album's lifetime ends at the end of the enclosing block, but in this case, first_photo is used after that point, so its lifetime extends past the end of album, which, as noted before, is forbidden. Note that first_photo exists before it is first assigned to point to album, but it's not a reference to album. Actually, in this case it's not assigned to anything, and so using it would be forbidden prior to assignment.

This brings us back to the question I asked above: how does Rust know that first_photo is a borrow of album and not of something else? And what if I did want to borrow something else?

Seeing Like a Compiler #

Although every variable in Rust has a lifetime, so far we've managed to avoid dealing with that because the compiler can often infer those lifetimes and act appropriately. However, there are situations where that's not the case.

Let's start with a simple example to get the idea:

fn return_first(first: &str, second: &str) -> &str {
    first
}

fn main() {
    println!("{:?}", return_first(&"first", &"second"));
}

This is some pretty obvious code: we pass two string references into return_first() and it returns the first one. But when we try to compile it we get an error:

error[E0106]: missing lifetime specifier
 --> examples/ex5.rs:1:47
  |
1 | fn return_first(first: &str, second: &str) -> &str {
  |                        ----          ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `first` or `second`
help: consider introducing a named lifetime parameter
  |
1 | fn return_first<'a>(first: &'a str, second: &'a str) -> &'a str {
  |                ++++         ++               ++          ++

For more information about this error, try `rustc --explain E0106`.
error: could not compile `photos` (example "ex5") due to 1 previous error

Rust error messages are usually clearer than this, but what's going on is that the compiler isn't able to verify that the lifetimes here follow the rules. Specifically, the return value of return_first() is a reference to something, but the compiler doesn't know how long it's supposed to be valid for. This will cause a problem when we try to use println!() on it, because Rust doesn't know if it's safe to use in that context. We are able to examine the function and realize it's safe, but because the compiler wants to use local reasoning, it's not able to do so.

What I mean by local reasoning is when checking main() from the compiler's perspective, at this point the program looks like this:

fn return_first(first: &str, second: &str) -> &str {
    // STUFF WE WON'T LOOK AT.
}

fn main() {
    println!("{:?}", return_first(&"first", &"second"));
}

When checking to see if main() is following the lifetime rules, the compiler wants to use only the information it has available from the function signature, without looking at the implementation. Conversely, when it checks return_first() it won't look at main(). If you're a C or C++ programmer, this should be conceptually familiar because C and C++ programs have header (.h) files which conventionally contain function and method signatures, with the implementation (the body) living in .c or .cc (or .cpp or .c++) files. This allows the compiler to compile one file (technical term: "translation unit") without knowing how another file works, but only the interfaces it provides. Rust doesn't have a header/body split like C and C++ but you can still get into the same situation if you are operating on a "trait object" (the Rust equivalent of C++ virtual functions), because you only know the trait definition.

In order to make this code compile, we have to help the compiler out by telling it the expected lifetime of the return value. We do this by decorating variables with a lifetime annotation, which looks like 'a.^[7] Specifically, what we need to express here is that the return value is not expected to outlive the first argument and thus it's safe to use the return value as long as the first argument is also alive. The notation for this looks like:

fn return_first<'a>(a: &'first str, second: &str) -> &'a str

Note how the notation here looks a little like C++ templates (and Rust generics, which we didn't go into as much), because this is a kind of generic. You read this line as follows:

There is some lifetime 'a such that the return value is valid during 'a (and can't be safely used after) and that whatever first is pointing to lives at least as long as 'a.

The way to look at these lifetime annotations is that they are defining the contract for this function. In order to enforce that contract, the compiler does two things:

Analyzes the caller of the function to verify that it isn't using the return value outside of the lifetime of whatever it passed as the first argument. As noted above, it can do this without looking at the function body.
Analyzes the body of the function to verify that the return value is actually derived from the first argument, so that it will be safe as long as the first argument is valid.

We've seen the first check in action, but let's look at the second check. Consider what happens if we change the return value to be derived from the second argument:

fn return_first(first: &str, second: &str) -> &str {
    second
}

fn main() {
    // println!("{:?}", return_first(&"first", &"second"));
}

I've commented out the call to return_first() so we're not even using the return value, but we still get an error because the function body isn't fulfilling the contract:

error[E0106]: missing lifetime specifier
 --> examples/ex6.rs:1:47
  |
1 | fn return_first(first: &str, second: &str) -> &str {
  |                        ----          ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `first` or `second`
help: consider introducing a named lifetime parameter
  |
1 | fn return_first<'a>(first: &'a str, second: &'a str) -> &'a str {
  |                ++++         ++               ++          ++

For more information about this error, try `rustc --explain E0106`.
error: could not compile `photos` (example "ex6") due to 1 previous error

As illustrated here, it's not possible to produce unsafe code by giving the compiler the wrong lifetime: if we screw up the compiler will throw an error. In this sense, lifetimes are just a hint to the compiler and a sufficiently smart compiler could do without them.

Lifetime Elision #

In fact, it's because lifetimes are a kind of hint that our original photo handling code works without lifetime annotations. To see this, consider the following trivial modification of this program in which we only pass in one argument:

fn return_first(first: &str) -> &str {
    first
}

fn main() {
    println!("{:?}", return_first(&"first"));
}

The compiler will process this just fine because it contains a set of default rules ("lifetime elision") that handle common cases. The rule that is applicable to this case are:

The second rule is that, if there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters: fn foo<'a>(x: &'a i32) -> &'a i32.

In other words, Rust is secretly changing the function signature to be:

fn return_first<'a>(first: &'a str) -> &'a str

This is reasonable because the vast majority of—but not all—valid code that has this kind of signature will be returning a reference to something derived from one of the arguments. However, once again, this is just a default: if we were to change return_first() to return a reference to something not derived from first, then the compiler would generate an error. First, consider the following:

fn return_first(first: &str) -> &str {
    let s = String::from(first);
    &s
}

In this case, we are returning a dangling reference to s, which only lives to the end of the function. This is plainly illegal—in fact, this is exactly what Rust lifetimes are designed to prevent—and so the compiler returns an error. No amount of lifetime decorations will make it compile.

Multiple Arguments #

Functions with a single argument are easy mode. For functions with multiple arguments, Rust will assign each one its own lifetime (rule one), at which point it doesn't know which lifetime to associate the return value with. This is why the version above with two arguments doesn't work without lifetime annotations, because Rust is internally giving it the following signature:

fn return_first<'a,'b,'c>(first: &'a str, second: &'b str) -> &'c str

Because it doesn't know the lifetime of 'c, the compiler is not able to determine either whether the return value is being used safely at the call site. We can resolve this issue as above by explicitly labeling the return value with a lifetime matching one of the arguments. To take one of the examples from the Rust book, if the function might return either first or second then you need to attach the same lifetime to both arguments, with the result that Rust will verify safety for whatever lifetime is shorter (recall that 'a only has to be a lifetime that satisfies all the constraints).

Member Functions #

There is one more special case: when you have a method call, then Rust assumes that the lifetime of any references returned will be the same as self. Turning back to get_photo(), this means that Rust is internally assigning the lifetime.

    pub fn get_photo<'a>(&'a self, index: usize) -> &'a Photo

If you wanted a member function to return another argument, you would need to explicitly annotate the function, like so:

    fn get_stuff<'a>(&self, s: &'a str) -> &'a str

Structs #

There's one more case worth covering: structs can have members that are references, in which case you have to provide a lifetime for the reference. This looks like:

struct Foo<'a> {
    x: &'a i32
}

The semantics of this are the same as having a variable with the same reference label: the lifetime of x and hence Foo has to be shorter than the lifetime of whatever x is a reference to. This all works, but things start to get hairy pretty fast because you have to decorate a lot of stuff with the lifetimes, as in:^[8]

#[derive(Debug)]
struct Pair<'a> {
    x: i32,
    y: &'a i32,
}

impl<'a> Pair<'a> {
    fn new(x: &i32, y: &'a i32) -> Pair<'a> {
        Pair { x: *x, y }
    }
}

Now let's try one more thing. Check out the following code:

#[derive(Debug)]
struct Holder<T> {
    t: Option<T>,
}

impl<T> Holder<T> {
    fn set_value(&mut self, t: T) {}
}

pub fn main() {
    let mut holder = Holder { t: None };
    {
        let tmp: i32 = 10;
        holder.set_value(tmp);
    }
    println!("{:?}", &holder);
}

Just to orient you, this code defines a struct called Holder. It's a generic type parameterized on T so that it can hold an instance of any T. The actual member value (t) is an Option<T> so that we can create an empty Holder and then fill it with .set_value()—or at least in principle can fill it with .set_value(). In practice, .set_value() has the signature you would expect from the name, but doesn't actually do anything, so Holder always contains a None. You have to use this Option trick a lot in Rust because there's no way to have empty object references like C++ nullptr (or, arguably, that's what Option is for).

If we call .set_value() with an instance of i32, then everything works as expected. The program compiles and outputs:

Holder { t: None }

Note that even though this is a generic, we didn't need to tell Rust which type to instantiate it (Rust jargon: monomorphize) with. Instead, it inferred it from the fact that we called .set_value() with a type of i32: set_value() is defined as taking an argument of type T and thus this means we must have a Holder<i32>.^[9]

Now let's do the exact same thing but but with one small change: pass &tmp to holder.set_value():

#[derive(Debug)]
struct Holder<T> {
    t: Option<T>,
}

impl<T> Holder<T> {
    fn set_value(&mut self, t: T) {}
}

pub fn main() {
    let mut holder = Holder { t: None };
    {
        let tmp: i32 = 10;
        holder.set_value(&tmp);
    }
    println!("{:?}", &holder);
}

Surprise (or maybe not?)! This doesn't compile at all.

warning: unused variable: `t`
 --> examples/ex10-ref.rs:7:29
  |
7 |     fn set_value(&mut self, t: T) {}
  |                             ^ help: if this is intentional, prefix it with an underscore: `_t`
  |
  = note: `#[warn(unused_variables)]` on by default

error[E0597]: `tmp` does not live long enough
  --> examples/ex10-ref.rs:14:26
   |
13 |         let tmp: i32 = 10;
   |             --- binding `tmp` declared here
14 |         holder.set_value(&tmp);
   |                          ^^^^ borrowed value does not live long enough
15 |     }
   |     - `tmp` dropped here while still borrowed
16 |     println!("{:?}", &holder);
   |                      ------- borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `photos` (example "ex10-ref") due to 1 previous error; 1 warning emitted

We're now seeing the downstream consequences of the lifetime annotations for structs. As mentioned above, if you have a reference member in a struct, it needs a lifetime, so when we monomorphized Holder with an i32, it had to associate a lifetime with it, so we ended up with something like:

struct Holder<&'a i32> {
    t: Option<&'a i32>,
}

And when we called .set_value(&tmp), 'a got associated with the lifetime of tmp. That lifetime ends when the block ends, but holder extends past the end of the block, so we have a lifetime error. You'll note that we didn't even have to use the reference passed to .set_value() to make this happen: Rust just looked at the function signature and decided that in principle we could be using it and so that meant holder had to be treated as if it were holding a reference to tmp. If we change .set_value() to take a &self instead of a &self (this is fine because we're not touching self.t anyway), then the problem resolves itself and the program will compile just fine.^[10]

Bonus: Thread Safety #

Everything in this post has been about memory allocation, but here's the cool part: Rust also provides thread safety, mostly through the same mechanisms that provide memory safety. This post is already quite long, but I want to briefly give you an intuition of how this works.

The basic cause of thread safety issues in software is when you have the same data value being modified by two threads at once. Consider the following trivial function for a bank's accounting system:

function pay_money(payee, amount) {
  if (balance < amount) {
     throw Error("Insufficient funds");
  }
  balance = balance - amount;
  send_money(payee, amount);
}

This looks like perfectly reasonable code, but what happens if we decide to run it in a multithreaded program where requests to pay people can come in in parallel. Suddenly, we have a serious problem because the individual steps of these threads can execute in any order. For instance, we might have the following order of execution:

Thread 1                                  Thread 2

function pay_money(payee, amount) {       
  if (balance < amount) {                 
     throw Error("Insufficient funds");   
  }                                       
                                          function pay_money(payee, amount) {     
                                            if (balance < amount) {               
                                               throw Error("Insufficient funds"); 
                                            }                                     
                                            balance = balance - amount;           
                                            send_money(payee, amount);            
                                          }                                       
  balance = balance - amount;
  send_money(payee, amount);            
}

This will (maybe) work fine sometimes but what happens if we have $100 in the account and then we get two transactions for $75 each? The obvious thing to expect is that we end up with $-50 dollars in the account—or, depending on the language, maybe $4294967246 dollars, oops!—because thread 1 checks the balance prior to thread 2 debiting it. This is what's called a "time of check time of use" bug.

Actually the situation is much much worse than this because compiler output isn't really anywhere near as neat as I've suggested here, so all sorts of things could happen. For example, the compiler during the initial read of balance the compiler could decide to store the value of balance in a register and then write it back to balance from that register, with the result that the first write is lost. To take a more extreme example, the compiler can move values in registers into your variables if it wants to (this is called a "register spill") as long as it restores them afterwards; this can cause obvious problems if you then contaminate one of the values it's using. This great post by Dmitry Vyukov) goes into a lot more detail here, but the basic point is that if you ever do uncoordinated writes to the same data values it's incredibly bad news (again, it's undefined behavior in C/C++). In general, the compiler is allowed to assume you never try to access the same value in two threads and so if you do, all bets are off.

If you've written any multithreaded code, you know that the basic defense against this kind of problem is what's called "locking": one thread "locks" a region of memory and as long as it's holding the lock, no other thread can touch that region.^[11] There are a lot of different kinds of lock, but one common one is what's called a "read-write lock". A read-write lock has the following semantics:

If you hold a read lock on a particular region, you're allowed to read the memory but not write it. An arbitrary number of threads can hold read locks on a given region as long as no thread holds a write lock.
If you hold a write lock on a particular region, you can read or write it. No other thread^[12] can hold any kind of lock on a region as long as someone is holding a write lock.

This should sound very familiar because it's precisely the semantics Rust uses for mutability, if you just substitute "immutable reference" for "read lock" and "mutable reference" for "write lock". This is not an accident, but instead it's a sign of a deep connection between memory safety and thread safety.

Moving Data Between Threads #

As we've discussed from the very beginning, Rust is a single ownership language; if a given object is owned by one thread then obviously it cannot be modified by two threads at once. It can, however, be moved between threads, by two basic mechanisms:

When you spawn a thread, you provide a function for the thread to run. This function can be a closure, which is a fancy term for an anonymous function defined in line. The closure can capture variables from the environment.
Rust provides mechanisms to write from one thread to another, such as channels.

Spawning a Thread #

Let's start with spawning a new thread. The basic code looks like this:

use std::thread;

fn main() {
    let val = 10;

    thread::spawn(move || {
        println!("{:?}", val);
    });
}

The || {} is the syntax for a closure and when used with the move keyword, which means that any variable used in the body of the closure ("captured") is moved into the closure. This means that val will be unavailable inside main after this point, but will be available inside the closure, which is why we can pass it to println!().

Now look what happens if we do the same thing but moving a reference to val:

use std::thread;

fn main() {
    let val = 10;
    let val_ref = &val;

    thread::spawn(move || {
        println!("{:?}", val_ref);
    });
}

As expected, this doesn't compile at all.

error[E0597]: `val` does not live long enough
  --> examples/ex11-ref.rs:5:19
   |
4  |       let val = 10;
   |           --- binding `val` declared here
5  |       let val_ref = &val;
   |                     ^^^^ borrowed value does not live long enough
6  |
7  | /     thread::spawn(move || {
8  | |         println!("{:?}", val_ref);
9  | |     });
   | |______- argument requires that `val` is borrowed for `'static`
10 |   }
   |   - `val` dropped here while still borrowed

For more information about this error, try `rustc --explain E0597`.
error: could not compile `photos` (example "ex11-ref") due to 1 previous error

The lifetime problem here is that main() may exit or at least start to exit while the thread is still running, which means that val get dropped and val_ref becomes invalid. There's no way to statically verify that main() will wait for the other thread to complete, so there's no way to have the thread reference a local variable of main(). As indicated by this error, the only kind of reference you can pass to a thread is one that has the special 'static lifetime, which means it lasts the entire lifetime of the program (typically it's a global variable).

You can make val static, as shown in the code below, but safe Rust forbids mutable static variables, so the result is that the variable is read only in both the thread and in main(), which preserves the "arbitrary number of immutable references" invariant.

use std::thread;

static VAL: i32 = 10;

fn main() {
    let val_ref = &VAL;

    thread::spawn(move || {
        println!("{:?}", val_ref);
    });
}

While the logic is similar to what we saw above, the enforcement mechanism for this is slightly different. The reason for this is that thread::spawn() is just a function and so even though we're passing it a reference there's nowhere for it to store it, so once thread::spwan() returns, that reference should have been dropped which would mean it was safe to drop the object it pointed to. You know and I know that what thread::spawn() actually does is to create a new thread that runs independently from the main thread, but how is the compiler to know that?

What is happening here is that thread::spawn() is defined with a specific set of trait bounds (traits which the arguments and return values have to implement):

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T + Send + 'static,
    T: Send + 'static,

Focus your attention on the generic parameter F, which is the type of the closure passed to spawn(). This is defined as having to implement the following traits:

FnOnce() -> T:: Be a function which can be safely called at least once and has a return value of type T. The at least means that it might not be safe to call the function twice (and hence the compiler will prohibit it). [Clarified -- 2025-05-25].
Send:: Can be safely [transferred across thread boundaries.
'static:: Lasts for the duration of the program.

It's this last constraint which matters for our purposes, because it requires that the closure and anything it captures has the lifetime 'static. Because a reference to a local variable doesn't have 'static lifetime, it can't be passed to thread::spawn() so there's no way to use thread::spawn() to create an unsafe reference.

Channels #

The other main option is to use some sort of messaging system to write data from one thread to another. For instance, Rust has a built-in mechanism called channels, which works like this:

Sender #

let value = Foo { ... };

channel_tx.send(value);

Receiver #

let value = channel_rx.recv().unwrap();

As with thread::spawn(), we can't use channels to unsafely send references from one thread to another, though the mechanisms Rust uses to prevent this are somewhat more complicated, and I'm not going to go into them here.^[13] With that said, here's an example of the obvious thing that you might try to do and the compiler will reject:

use std::sync::mpsc::channel;
use std::thread;

fn main() {
    let val = 10;
    let (tx, rx) = channel();

    let _ = tx.send(&val);

    thread::spawn(move || {
        let _ = rx.recv().unwrap();
    });
}

Obviously, there are situations when you do want to share data across threads, and just as Rust provides a mechanism (RefCell) for controlled mutation of data shared through immutable references, it similarly has a set of mechanisms for controlled sharing of writable data. A full description of how to do this is outside of the scope of this already long post, but here is a trivial example.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let val = Arc::new(Mutex::new(10));
    let val_to_share = Arc::clone(&val);

    let t = thread::spawn(move || {
        let mut tmp = val_to_share.lock().unwrap();
        println!("Inside thread val={:?}", *tmp);
        *tmp += 10;
    });

    let _ = t.join();
    println!("Main thread val={:?}", val.lock().unwrap());
}

The basic idea here is that we first wrap our shared data in a Mutex, which allows one reference (either readable or writable) at once at a time. You obtain the reference by calling .lock(), and if someone else has it your thread will wait until they have unlocked it.^[14] A reference to a Mutex can't be shared across threads directly any more than any other variable can, but we can wrap it in a reference counted structure, in this case Arc (the thread safe version of Rc) and move that across threads. The logic here is:

We have two copies of Arc, one in each thread, but both pointing to the same Mutex.
Each thread uses .lock() to access the data inside the Mutex.

This allows us to share the data across the threads but guarantees that only one thread at a time can use it.^[15] The call to .join() in the main thread is just waiting for the other thread to finish to guarantee we have a chance to print both values.

There's a lot more to say about multithreaded programming in Rust, but I'm not trying to teach you how to write parallel programs in Rust; instead I want to make two points here:

Writing memory safe and thread safe programs depends on the same basic concepts, namely ensuring single ownership, guaranteed lifetimes, and preventing simultaneous writing and reading, whether that simultaneity is a result of concurrency or not.
The mechanisms that Rust uses to provide thread safety are much the same basic mechanisms as those which are used to provide memory safety and similarly are based on clear contracts between components plus local analysis for safety.

As I said this isn't an accident, but rather a result of the connection between memory safety and thread safety, which logical errors related to unclear ownership, and the results of trying to touch the same data in inconsistent ways in multiple places.

Next Up: Garbage Collection #

There's plenty more to say about Rust memory management and in particular about how to write manageable code that conforms to Rust's rules—as well as how to break those rules using unsafe when you have to—but hopefully this gives you an overall sense of how things are put together. In the next post, I want to talk about a completely different approach to memory, namely automatic memory management with garbage collection, as used in languages ranging from Lisp to Go to JavaScript.

I was too lazy to dig into this, but I'm pretty sure what's happening under the hood is that . is basically just syntactic sugar for "call this function with self as the first argument". This allows Rust to figure out what the right version of self to provide is. Metric::size() addresses the function directly, and so you have to provide self directly, and that means you need to also provide the right version of self. ↩︎
This isn't immediately evident, but in this code, y is of type &i32 rather than i32; println!() just takes care of the dereference for you. ↩︎
Well, fortunately in that I added #[derive(Clone)] when I wrote it. ↩︎
As an aside, note that we are doing for photo in new_photos rather than for photo in &new_photos because we need to consume the vector. If we used &new_photos we would iterate over references and not be able to move the object behind the reference when calling add_photo(). ↩︎
There's actually an ongoing project called Polonius to replace the borrow checker with one that properly handles some cases which are safe but which it currently rejects. ↩︎
Ignore the #[allow(unused_mut)]. This just stops the compiler from complaining about how album is unnecessarily mut, and I wanted to keep the code the same as before. ↩︎
One of the bad habits that Rust seems to have picked up from C++ is the convention of making generic parameters single letters, so you end up with T, U, V, etc. Just when we'd persuaded people not to name regular variables like that, too. ↩︎
And I haven't even gotten to '_. ↩︎
We actually don't even have to tell Rust that tmp is an i32, because that's the basic type for bare integers. ↩︎
On the other hand, if we change Holder.t to be a RefCell<Option<T>> then we get a compile error even if we make .set_value() take &T. You need to dig pretty deep into Rust internals to understand why, but the logic is clear: you could in principle have used the RefCell to store a reference. ↩︎
I'm simplifying here, because there's also a lot of machinery you need to make sure the region is in good shape when the lock is removed, due to the kinds of optimizations I mentioned above. We won't cover that here. ↩︎
I'm being precise here, because some systems let you take recursive locks and some don't. There are pluses and minuses. ↩︎
I spent quite a while working through this and I'm still not done. Potentially the subject for a future post. ↩︎
Note that we don't have to explicitly unlock because we're using RAII, just as with RefCell. ↩︎
Rust also has a read-write lock mechanism that allows for multiple readers at once, but I just decided to show Mutex here. ↩︎

Understanding Memory Management, Part 4: Rust Ownership and Borrowing

2025-03-31T00:00:00Z

[Post updated 2025-04-20 to fix some minor errors flagged by Erik Taubeneck]

This is the fourth post in my planned multipart series on memory management. Part I covers the basics of memory allocation and how it works in C, and parts II and III covered the basics of C++ memory management, including RAII and smart pointers. These tools do a lot to simplify memory management but because they were added on to the older manual management core of C you're left with a system which is mostly safe if you hold it right but which can quickly become unsafe if you're not careful. Next I want to talk about a language which was designed to be safe from the ground up and won't let you be unsafe:^[1] Rust. I'd originally planned to talk about garbage collected languages next, but after all that time spent on how C++ works, I decided it would work better to do Rust next and then close with garbage collection.

Single Ownership #

Unlike C and C++—or any other language we'll be looking at—the basic design concept of Rust is single ownership. I.e.,

Any given object can only have a single owner.

We've already seen how to implement this model in C++ using unique pointers, but in Rust single ownership is just how everything works. Just as we saw with C++ unique pointers, this makes life simple: when the owning variable goes out of scope, the object is destroyed.

In C/C++, when you assign one variable to another, the default is to do a copy. By contrast, Rust moves the variable. Consider the following code:

C #

#include <stdio.h>
#include <stdlib.h>

struct Hat {
  uint8_t size;
};

int main(int argc, char **argv) {
  struct Hat h1 = { .size = 5 };
  struct Hat h2 = h1;

  printf("%u %u\n", h1.size, h2.size);
}

Rust #

struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = Hat { size: 5 };
    let h2 = h1;

    println!("{} {}", h1.size, h2.size);
}

This is a simple piece of code: we first create a Hat named h1 of size 5. We then create a new hat h2 and assign h1 to h2 and then print out h1 and h2. With C this works exactly like you would expect:

5 5

With Rust, however, the situation is totally different, and the compiler gets mad at us:

error[E0382]: borrow of moved value: `h1`
 --> assign-rs.rs:9:23
  |
6 |     let h1 = Hat { size: 5 };
  |         -- move occurs because `h1` has type `Hat`, which does not implement the `Copy` trait
7 |     let h2 = h1;
  |              -- value moved here
8 |
9 |     println!("{} {}", h1.size, h2.size);
  |                       ^^^^^^^ value borrowed here after move
  |
note: if `Hat` implemented `Clone`, you could clone the value
 --> assign-rs.rs:1:1
  |
1 | struct Hat {
  | ^^^^^^^^^^ consider implementing `Clone` for this type
...
7 |     let h2 = h1;
  |              -- you could clone this value
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0382`.
make: *** [assign-rs.out] Error 1

This rather long error message is trying to be helpful, but it can be a bit confusing unless you're familiar with Rust. For instance, what does it mean for something to be a "borrow of moved value"? By the end of this post, you should be able to understand pretty much everything in this message.

Moving Variables #

As I said above, in Rust assigning variable A to variable B moves the object from A to B. In C++ this just means that it executes the move assignment operator and leaves the source object in a "valid but unspecified" state, but in Rust it means something different and much stronger: it makes B the new reference for the object and then renders A totally invalid. Unlike in C++, this invariant is enforced by the compiler, so when we later try to use h1 in the println!() statement, the compiler refuses and throws an error. This would happen with any use of h1 after it was assigned to h2.

All of this works because—unlike in C++—move semantics were baked into Rust from the start, and the compiler is easily able to enforce them (as well as produce a less confusing error message than you might get with some C++ template). Similarly, Rust doesn't need you to implement a move assignment operator because in Rust all moves are implemented the same way—at least conceptually—as a bitwise copy^[2] of the object. I say "at least conceptually" because in this case you don't need to do a copy at all: the compiler can internally note that h1 is now defunct and it is now named h2 and move forward without doing any copying. Some playing around with Compiler Explorer reveals that that's what rustc does when optimization is on.^[3]

Copying Integers #

Now consider some very similar Rust code, but using a bare integer in place of the struct containing just one integer:

pub fn main() {
    let h1: u8 = 5;
    let h2 = h1;

    println!("{} {}", h1, h2);
}

This code compiles and runs perfectly well, exactly like our original C code.

5 5

Why does this code work and the other code not? The answer is instead of moving h1, the compiler has copied it. But that just requires us to ask why it copied it when I already said that Rust did moves on assignment? The answer to that question is that Rust knows that integers are simple objects which can be safely copied. As a practical matter, this mostly means that they don't contain pointers to anything, so that you don't have to worry about having two pointers to the same object (thus violating the single ownership rule). In this case, when you assignA to B it automatically makes a copy rather than invalidating B. This saves you the trouble of asking Rust to copy the variable rather than moving it.

Note that we're talking here about language semantics here, not the output binary. The net effect here is that the compiler knows that h1 and h2 can be used simultaneously, but it's free to make a copy or just note that h1 and h2 have the same contents and use them interchangeably in the println!() statement.

Copying Structs #

Of course, there's no real difference between an integer variable and a struct with only a single integer in it, so it's actually just safe to copy Hat as it is to copy u8, and we can tell Rust that by decorating the Hat definition like so:

#[derive(Copy, Clone)]
struct Hat {
    size: u8,
}

With this slight change, our original Rust program will work, just like the C version or the bare integer Rust version. To understand why this works, we need to take a detour into the Rust type system.

Traits #

Although not a fully object-oriented language like C++, Rust includes some object-oriented features and in particular a feature called traits. Like a class, the idea behind a trait is to define a set of behaviors (in some other languages this is called an "interface") that types can implement. You may recall our shapes example from part II where we had a class called Shape and then derived classes for Rectangle and Circle. Here's the C++ code and the corresponding Rust code:

C++ #

class Shape {
  virtual int area() = 0;
};

class Rectangle : public Shape {
public:  
  int width;
  int height;
 
  ...
  
  virtual int area() {
    return width * height;  
  }
};

Rust #

trait Shape {
    fn area(&self) -> usize;
}

struct Rectangle {
    width: usize,
    height: usize,
}

impl Shape for Rectangle {
    fn area(&self) -> usize {
        self.width * self.height
    }
}

These two snippets have the same basic structure:

Shape defines the interface and says that all Shape objects implement an area() method.
Rectangle is a concrete type that implements Shape and provides its own definition for area().

Just like with C++, we can now write code that expects a Shape and use any struct that implements Shape. For instance, we can write:

fn print_area(shape: impl Shape) {
    println!("Area is {}", shape.area());
}

pub fn main() {
    let rect = Rectangle {
        width: 10,
        height: 5,
    };

    print_area(rect);
}

There are a number of important differences between class inheritance and trait implementation that aren't apparent here. For example, Rust traits can't have any data whereas C++ classes do; it just so happens that Shape doesn't have any data, but if we wanted to add (say) a name field to Shape we could do that in C++ and all classes that inherited from Shape would inherit that field; you can't do that in Rust. However, for the moment we can ignore these differences.

Marker Traits #

Our Shape trait just defines a single method, area() but there's actually nothing that requires us to define any methods at all; you can just have an empty trait like so:

trait Circular {}
impl Circular for Circle {}

It may not be immediately obvious why this would be useful, but here's an example. Unlike other shapes, you can compute the circumference of a circle from the area. So, we can write a function like this:

fn print_circumference(shape: impl Shape + Circular) {
    let radius = (shape.area() / std::f64::consts::PI).sqrt();
    let circumference = radius * 2.0 * std::f64::consts::PI;
    println!("Circumference is {}", circumference);
}

The impl Shape + Circular type in the function signature says that the shape argument has to not only be a Shape but also implement Circular.^[4] Note that we don't use any functions from Circular (there aren't any!), we just use it to restrict which shapes can be provided to print_circumference(). Consider the following function signature:

fn print_circumference(shape: impl Shape) {
    ...

This would compile and run, but would let you try to compute circumference from rectangles, even though that will give the right answer. The trait restriction for Circular (technical term: "trait bound") ensures that only circular objects can be used with print_circumference(). This particular example may feel a little contrived because we could just require print_circumference() to take a circle, but this design also lets us handle cylinders, which are also circular; all we have to do is implement Circular for Cylinder.

Circular is what's called a "marker trait"; it doesn't have any functionality of its own, it's just used to indicate that a type has a specific property.

The Copy Trait #

At this point, it should be obvious where this is going: Rust has a marker trait called Copy, which tells the compiler that an object is safe to copy. You can implement the Copy trait on a struct using the Rust derive macro, like so:

#[derive(Copy, Clone)]
struct Hat {
    size: u8,
}

This code tells the Rust compiler to implement both the Copy and Clone traits on Hat. We'll get to the Clone trait in a little bit, but the Copy [Fixed: 2025-04-20] part is just syntactic sugar for impl Copy for {} (Rust has a lot of this kind of syntactic sugar). Again, Copy doesn't have any methods, it just tells the compiler that it's OK to make a shallow copy.

Of course, not all structs are safe to copy. For instance, if you have a struct that contains a pointer to some data on the heap, then copying it would violate the single owner rule—indicating which data is safe to copy is why we need to have the Copy trait in the first place—so what happens if we try to apply the trait to a non-copyable object, as below:

struct Inner {}

#[derive(Copy, Clone)]
struct Outer {
    inner: Inner,
}

rustc will refuse to compile this, producing the following error:

error[E0204]: the trait `Copy` cannot be implemented for this type
 --> uncopyable.rs:3:10
  |
3 | #[derive(Copy, Clone)]
  |          ^^^^
4 | struct Outer {
5 |     inner: Inner,
  |     ------------ this field does not implement `Copy`
  |

The problem here—from the compiler's perspective—is that we asked Rust to implement Copy on Outer, but outer includes Inner, which doesn't implement Copy; and since copying Outer requires copying Inner and Inner doesn't implement Copy, then you can't copy Outer either. Because Rust knows which structs are safe to copy and will refuse to let you implement the Copy trait on them, it's not possible to incorrectly label an unsafe to copy object with Copy.

The second thing to notice is that Inner is actually perfectly safe to copy, seeing as it's empty. We've already seen that Rust knows when it's safe to implement Copy, so you might ask why it doesn't just automatically let you Copy whenever it's safe to do so (recall that the trait is empty, so it would be trivial to do so automatically). This is actually a common feature of Rust: there are any number of situations where you try to do something that requires trait X and Rust knows it's safe to implement, but forces you to explicitly derive traits even though it could do so automatically. As a friend said to me, writing Rust means resigning yourself to writing a lot of boilerplate; fortunately, the compiler will mostly tell you what boilerplate you need to add, and if you have a good IDE it will probably have affordances to let you automatically add it.

Clone #

Above, we told the compiler to derive both Copy and Clone. Above we went through Copy, which is approximately a shallow copy. By contrast, Clone allows for copying objects which can't be safely shallow copied. Here's the definition of the Clone trait:

pub trait Clone: Sized {
    // Required method
    fn clone(&self) -> Self;
    
    ...
}

Note how this is signature is reminiscent of C++'s copy assignment operator:

C++ #

  T& operator=(const T& other);

Rust #

fn clone(&self) -> Self;

Unlike C++, where assignment causes the copy assignment operator to be invoked (and where you have to explicitly invoke move semantics, in Rust you need to clone an object explicitly, in the obvious way using the .clone() method, as in:

    let h1 = Hat { size: 5 };
    let h2 = h1.clone();

Like C++, Rust will provide a default implementation (in this case, if you do #[derive(Clone)]. As you would expect, the default implementation recursively clones all of the members of the struct, so it will work as long as all of those members also implement Clone (which of course means that all of their members need to implement Clone, etc.). However, again as with C++, when you implement Clone you can supply any method clone() that you want as long as it returns an instance of the object (that's what the -> Self means). For example, as we'll see later, this is how Rust implements reference counted pointers, with .clone() implementing the reference count. By contrast, you can't override the behavior of Copy because it has no methods; it's just a marker.

As shown above, if you want to implement Copy Rust also requires you to implement Clone. As far as I can tell, this isn't logically necessary, but it's obviously the case that if you can safely shallow copy a struct, you can implement clone() by just doing a shallow copy, so it's somewhat silly to allow people to implement Copy but not Clone.

Heap Allocation and `Box` #

So far we've just looked at ordinary stack variables, but in Rust, just like in C++, you frequently need to allocate memory on the heap, but as we saw, giving the programmer to have direct access to pointers results in all kinds of shenanigans. Rust addresses this by requiring that all pointers be boxed and forbidding you from unboxing them (again, except in special code).

The basic smart pointer in Rust is called Box, which is the rough equivalent to C++ unique_ptr. For example, the following code allocates space containing the integer (10) and then prints it out:

use std::boxed::Box;

fn main() {
    let b = Box::new(10);

    println!("tmp = {}", *b);
}

Unlike the way we've used C++ smart pointers, where we first called new and then passed the result to the smart pointer (shared_ptr<Obj> s(new Obj())), Box::new() does the memory allocation itself, and what you pass it is actually a created object, which it then moves into the box.^[5] You can in fact break these up, as in the following code where we make a Hat named h1 and then move it into hbox. As usual, h1 will be unusable after we've done that, so we're still following the single ownership rule.

use std::boxed::Box;
struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = Hat { size: 5 };
    let hbox = Box::new(h1);
    println!("{}", hbox.size);
}

Conventionally, you'd do this in one operation, as in Box::new(Hat { size: 5 }) but there's no real difference between these two pieces of code.

Like all the Rust pointer types, Box is actually a generic, so it can contain a pointer of any type. In this particular case, this is a 32 bit signed integer (i32), so b is actually of type Box<i32>.

Box behaves like any other Rust struct, so you can pass it around, assign a Box to other variables, etc. You can even make a Box of a Box if you want to.

Mutability and Immutability #

By default, variables in rust are immutable, which is to say that once you have assigned their values. For instance, the following code will not compile:

let x = 10;
x = 20;

The error looks like this:

   |
9  |     let x = 10;
   |         - first assignment to `x`
10 |     x = 20;
   |     ^^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
9  |     let mut x = 10;
   |         +++

Characteristically, the compilation error tells us exactly what we need to do, which is to make x mutable using the mut keyword:

    let mut x = 10;

This is another case where Rust is the opposite of C/C++, in which variables are mutable by default but can be labeled immutable with the const keyword:

    const uint8_t x = 10;

You can get along OK programming with just mutable variables—or, for that matter, with just immutable variables^[6]—but it's a lot more convenient to have both because it forces you to be intentional about which variables will change and which will not.^[7] Generally good practice is to have as many variables be immutable as possible and then make them mutable only when necessary. The Rust compiler will stop you from modifying immutable variables and complain—though not generate a hard error—if you make a variable mutable unncessarily.

References and Borrowing #

Consider the following trivial piece of Rust code:

struct Hat {
    size: u8,
}

fn print_hat_size(h: Hat) {
    println!("{}", h.size);
}

fn main() {
    let h1 = Hat { size: 5 };

    print_hat_size(h1);
    print_hat_size(h1);
}

This won't compile because we moved h1 into print_hat_size() the first time we called it and so we can't pass it into print_hat_size() again because it's now been invalidated. This is obviously really unhelpful: we know that once print_hat_size() has returned it's not doing anything with the Hat, so it's available to use again, but the compiler won't let us.

One option here would be to have print_hat_size() pass Hat back by returning it and then we could call it again, like so:

struct Hat {
    size: u8,
}

fn print_hat_size(h: Hat) -> Hat {
    println!("{}", h.size);
    h
}

fn main() {
    let h1 = Hat { size: 5 };
    let h1 = print_hat_size(h1);
    print_hat_size(h1);
}

This will obviously work, but it's really clunky, and what if we wanted print_hat_size() to return something else? Then we'd need to deal with the actual return value. Instead, what we want to do is let print_hat_size() temporarily use its argument without actually taking ownership. In Rust this is called borrowing and the resulting borrowed item is called a reference.

We've already seen this kind of operation in C and C++ where we we passed a pointer or a reference (C++) to an object to a function, like so:

Passing a Pointer #

void foo(Hat* hat) {...}

struct Hat h1 = { .size = 5 };
foo(&h1);

Passing a Reference #

void foo(Hat& hat) {...}

struct Hat h1 = { .size = 5 };
foo(h1);

Borrowing in Rust is conceptually more like passing a reference in C++ in that in C++ references the callee has access to the object in the calling function but it's not a pointer and so you can't do pointer-like things like free(); this shouldn't be surprising because Rust doesn't let us access raw pointers at all. And just as with C++ references, you use . notation to reference inner values of the struct rather than -> as you would with a pointer.

Mutable and Immutable References #

Just as Rust supports both mutable and immutable objects, it also supports mutable and immutable references, which have the semantics you would expect:

fn addone(input: &mut i32) {
    *input += 1;
}

fn print_value(input: &i32) {
    println!("Value {}", input);
}

pub fn main() {
    let mut i = 10;

    print_value(&i);
    addone(&mut i);
    print_value(&i);
}

Which produces the following output when run:

Value 10
Value 11

The basic way to take a reference to i is to do &i, which is what we do with print_value(), which does not need to modify its input. By contrast, addone() does need to modify its input, so it needs to take a &mut reference. Note that we need mut in three places:

Labeling i as mutable
In the signature for addone()
At the call site to addone()

Note that addone() is modifying i in place, which is why when we call print_value() in main() we see it modified. This is just the same call by reference semantics we've seen before.

References are a critical tool but the way I've just described them creates an opportunity for people to really screw things up. Consider the following C++ code (I'm using C++ here for a reason which will will be apparent soon):

#include <vector>
#include "./print-array.h"

void do_something(std::vector<size_t> &numbers, size_t &sum) {
  numbers.push_back(5);
  for (auto i : numbers) {
    sum += i;
  }
}

int main(int argc, char **argv) {
  std::vector<size_t> numbers = {1,2,3};
  size_t sum;

  do_something(numbers, sum);
  std::cout << "Numbers = " << numbers << " Sum=" << sum << std::endl;
}

Just to orient yourself, what this code does is to allocate a vector of length 3 containing the values 1, 2, 3 and then passes it to a function do_something() along with a reference to an integer of type usize that will hold the sum of the values. do_something() then does the following:

Adds the value 5 to the end of the vector.
Sets the value of sum to the sum of the values

And then finally main prints out the list of numbers and the sum:

Numbers = [1, 2, 3, 5] Sum=11

This code is fine (though kind of pointless), but now let's consider a very slight modification of this code where instead of passing a reference to a separate local variable in the sum argument, we instead pass a reference to the first element in the numbers vector:

#include <vector>
#include "./print-array.h"

void do_something(std::vector<size_t> &numbers, size_t &sum) {
  numbers.push_back(5);
  for (auto i : numbers) {
    sum += i;
  }
}

int main(int argc, char **argv) {
  std::vector<size_t> numbers = {1,2,3};

  do_something(numbers, numbers[0]);  // Changed code
  std::cout << "Numbers = " << numbers << " Sum=" << sum << std::endl;
}

[Fixed change marker: 2025-04-20]

Note that we just changed the line labeled Changed code. Everything else is the same. Naively, the expected outcome of this program would be the following:

Numbers=[11, 2, 3, 5], Sum=11

This is certainly one possible outcome, but it's not the only one, and the others are bad. To see why, we need to take a closer look at what's actually going on in memory. The figure below shows the situation at the start of do_something():

Memory layout at the start of `do_something()`

On the left, we see the two arguments to do_something():

numbers which is a reference to the vector of numbers (itself a local variable in main).
sum which is a reference to the first number in the vector (currently the value 1), though do_something() doesn't know that; it's just the same code as before.

Recall from part II, that a minimal container structure like a vector will look something like this:

class<typename T> Vector {
   T* data_;       // The elements of the vector
   size_t len_;    // The length of the vector
   size_t size_;   // The total size of the vector
}

data_ contains the address of the memory region allocated for the elements of the vector and len_ contains the number of elements in the vector, and size_ contains the total size of the data_ region.

The reason we need separate size_ and len_ fields is to make it cheap to grow and shrink the vector. Typically with a container structure like this, you wouldn't just allocate enough space for the initial number of elements requested, but instead allocate more space (maybe twice as much). When you want to add another element, you just add it to the end of the region and increment len_ [Fixed: 2025-04-20] but you don't need to allocate more memory until you've exhausted the initial allocation. Similarly, if someone wants to remove the last element in the buffer, you can just decrement len_, leaving one more slot for a future insertion. The idea here is to avoid unnecessary allocation and copying of the memory region.

Of course, no matter how much you overallocate you'll eventually reach the end of the pre-allocated buffer, at which point you'll need to do a new allocation.^[8] That's the situation here because len_ and size_ are the same, so the next insertion will require reallocating, with the result shown below:

Memory layout after inserting `5`

As you can see, we've allocated a new region to hold the expanded vector and inserted the new element 5 at the end. This is all totally fine as far as numbers is concerned; the problem is with sum, which is now pointing to the old (free()ed) region of memory which used to contain the contents of the vector but could now contain anything at all or even be in use for something (e.g., for allocator bookkeeping). When we now go and attempt to write into *sum, this is a classic use-after-free issue and can have pretty much any result (in C/C++ this would be undefined behavior), and could easily lead to a crash or a vulnerability.^[9]

I want to emphasize that this is would be totally legal C++ code and the compiler will be perfectly happy to compile it: the only thing that causes the problem is that we know that .push() might cause a reallocation, but you could easily have a fixed-size container which refused to reallocate, in which case this code would be safe; the fact that it's not depends on information which the compiler doesn't have. This code is not, however, legal Rust.

The Rules of Borrowing #

The way that Rust avoids the kind of issues we just saw is by restricting borrowing. Specifically: any given object can have either:

One mutable reference
An arbitrary number of immutable references

The compiler enforces these rules for you via the "borrow checker" and will throw an error if you try to violate them.

The code above violates these rules because we are taking two mutable references to numbers. This might not be apparently obvious because the second reference is actually to one of the elements of numbers, but the reference to numbers also transitively covers every element in numbers, the effect is the same.^[10]

Now let's try to write the corresponding Rust code, which looks like this:

fn do_something(numbers: &mut Vec<usize>, sum: &mut usize) {
    numbers.push(5);
    for i in numbers {
        *sum = *sum + *i;
    }
}

pub fn main() {
    let mut numbers = vec![1, 2, 3];

    do_something(&mut numbers, &mut numbers[0]); // Changed code
    println!("Numbers={:?}, Sum={}", numbers, &numbers[0]);
}

[Updated 2025-03-31 with the right code. Thanks to Dave Cridland.]

When we try to compile this code, we get the following error:

error[E0499]: cannot borrow `numbers` as mutable more than once at a time
 --> double-borrow-bad.rs:8:37
  |
8 |     do_something(&mut numbers, &mut numbers[0]);
  |     ------------ ------------       ^^^^^^^ second mutable borrow occurs here
  |     |            |
  |     |            first mutable borrow occurs here
  |     first borrow later used by call

It should be obvious, but you can't fix this just by changing these to immutable references: the compiler knows that do_something() takes mutable references and so will refuse to compile that code too:

error[E0308]: arguments to this function are incorrect
  --> double-borrow-bad.rs:11:5
   |
11 |     do_something(&numbers, &numbers[0]); // Changed code
   |     ^^^^^^^^^^^^           ----------- types differ in mutability
   |
note: types differ in mutability
  --> double-borrow-bad.rs:11:18
   |
11 |     do_something(&numbers, &numbers[0]); // Changed code
   |                  ^^^^^^^^
   = note: expected mutable reference `&mut Vec<usize>`
                      found reference `&Vec<{integer}>`
   = note: expected mutable reference `&mut usize`
                      found reference `&{integer}`

Similarly, even if we were to change the signature of do_something() to take immutable references, then do_something() wouldn't compile because the compiler knows that .push() [Fixed: 2025-04-20] modifies the vector, and assignment to *sum changes the object being referred to (whatever it is), so it won't compile do_something().

Global Safety via Local Reasoning #

I want to step back for a moment to pull out the larger point that this example shows, which is that the way Rust delivers global safety is by enforcing local properties. Recall from above that the original C++ [Fixed: 2025-04-20] code was unsafe as the result of two different properties:

When we called do_something() we took a pointer to an inner value of numbers.
.push_back() potentially causes a reallocation, invalidating any pointer to an inner value of numbers.

These two properties are very distant in the code and so you need global analysis to determine that it's unsafe. This analysis is difficult and may not even be possible (in fact the source code of .push_back() may not be available to the compiler at the time it is compiling do_something()), so the C++ compiler cannot detect the error at compile time, leaving you with a run time problem. Rust's conservative borrowing rules prevent this via enforcing the following properties:

do_something() modified numbers and *sum and so these references need to be mut.
do_something() takes mut arguments and so when you call it in main() you need to take mut references.
&mut numbers and &mut numbers[0] both borrow numbers and so the compiler forbids the double borrow.

The important thing to realize is that each of these properties is enforced purely locally; when the compiler forbids the double borrow in do_something() it doesn't need to know anything about the behavior of do_something(), just that it needs to take two mut references. However, the result of applying the rules locally is to provide global safety.

Unfortunately, this safety doesn't come for free because these rules are conservative and therefore forbid code which would actually be safe but which the compiler cannot locally verify is safe. For example, suppose that as hypothesized above .push() never allocated new memory but just allocated out of a fixed-size buffer and returned an error when you tried to exceed the size of that buffer. In that case, what we're doing here would be fine—though odd—but Rust still wouldn't allow it, as we'd still need to take a mut reference to &numbers[0].^[11] Much of the experience of programming in Rust is about trying to structure your code in such a way that the compiler can determine that what you are trying to do is safe—or, as is often the case, determining that the reason it can't determine it's safe is that it actually isn't.

In the rest of this post and the next, I want to talk about some of the gymnastics you have to do when writing Rust code in order to satisfy the borrow checker; this will also come up in the next post.

Shared Ownership #

As mentioned in part III while single ownership is easier to reason about there are situations where you really need to have some kind of shared ownership. C++ provides the shared_ptr class for this, and Rust has a similar affordance called Rc (for "reference counted"), as well as a weak pointer type called Weak. These are implemented (mostly) the same as C++ smart pointers but with some important differences.

Just to orient you, here is the Rc-ized version of the code we started with:

Code #

use std::rc::Rc;

struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = Rc::new(Hat { size: 5 }); // Reference count 1
    let h2 = Rc::clone(&h1);
    println!("{} {}", h1.size, h2.size);
}

Output #

5 5

As you can see this works perfectly fine.

Note that unlike with C++, you can't just assign one Rc to another but instead you call Rc::clone, which invoked the "associated function" clone of the struct Rc, which increments the reference count and returns a new copy of the Rc object which can then be assigned to h2. If you were to instead just assign h1 to h2 it would move it and you would get the same type of use-after-move compilation error we got in our original code.

The question you should immediately be asking here is why Rc doesn't violate Rust's single ownership rule, given that we now have both h1 and h2 pointing to the same Hat instance. The reason is that Rc mediates access to the owned object in order to ensure safety. Specifically:

Ordinary access to the object through Rc only allows immutable operations^[12] so that if you try to modify it (e.g., h2.size = 1) it will fail.
It is possible to get a mutable reference to the owned object via the Rc::get_mut() function, but this will only succeed if the reference count is equal to one. You also can't get a reference of either type to the owned object once you called Rc::get_mut() because the compiler detects that this would be a double borrow (the rules that make this work are a bit advanced to go into right now).

The result of these two rules is that you can have as many immutable references as you want but that you can't combine a mutable reference with either another mutable reference or another immutable reference, just like with the ordinary borrowing rules; unlike with the borrowing rules, Rc enforces its rules at runtime, so attempting to call Rc::get_mut() at the wrong time will fail.

Interior Mutability #

I said we weren't going to implement Rc but ask yourself this:

How does Rc maintain the reference count?

Presumably there is some internal reference count value in Rc just like there is in C++ shared_ptr, but that's only half the story because we can call Rc::clone() with an immutable reference to the Rc object, like so:

    let h2 = Rc::clone(&h1);

Rc::clone() obviously has to increment the reference count, but the whole point of an immutable reference is that you can't change the referenced object, so what's going on here? The answer is that Rust has a set of special smart pointers that allow you mutate an object—under controlled conditions—even when you only have an immutable reference: Cell and RefCell. Rc actually uses Cell, but in this post I'll be talking about RefCell, which is the one I have used more often.

Like Rc, we make a RefCell with RefCell::new(T) where T is an instance of the relevant type. Unlike Rc, you can't use the RefCell directly but have to explicitly call .borrow() to get an immutable reference and .borrow_mut() to get a mutable reference, as shown in the code below.

Code #

use std::cell::RefCell;

struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = RefCell::new(Hat { size: 5 });
    println!("{} {}", h1.borrow().size, h1.borrow().size);

    let mut borrowed = h1.borrow_mut();
    borrowed.size = 10;
    println!("{}", borrowed.size);
}

Output #

5 5
10

RefCell enforces the usual rules about references, namely that you can have as many immutable references outstanding as you want as long as there aren't any mutable references, and if there is a mutable reference then there can't be any other references. If you try to violate these rules, Rust will call panic!(), which terminates the program (unless caught).^[13]

This tells us how to implement the reference count in Rc: put the reference count object in a RefCell (as I said, it's actually a Cell, which has a different syntax but can be used to the same effect). Then we can hold an immutable reference to Rc<Hat> but still call Rc::clone(). It's Rc's job to ensure that it follows the borrowing rules—or risk a program crash—but note that even if you mess up with RefCell you still can't cause a memory error or another unsafe condition; all that will happen is that the program crashes.

It's quite common to combine Rc with RefCell to get functionality that is sort of like C++'s shared_ptr: once you have two Rcs pointing to the same object you can't use either one to mutate it, but there are a lot of settings in which you want to have shared ownership of an object but allow it to be mutated in one place or the other. In C++ you can just do this, but in Rust you have to do something like Rc<RefCell<Hat>>, with Rc providing the reference counted pointer to the immutable RefCell object which itself lets you mutate the internal Hat object.

Enforcing the Reference Count #

There's one more interesting point to make about RefCell. If the compiler isn't enforcing the rules about the number of mutable and immutable references, and they're enforced by RefCell at runtime, how does that work? Obviously, it maintains a count of the number of references it has given out, but how does it know when they go away? This involves a little bit of cleverness but you should be able to work it out for yourself given what we've seen so far. I'll wait.

Figure it out?

Instead of returning &T and &mut T, borrow() and borrow_mut() instead return some new smart pointers named Ref and RefMut. These smart pointers act (mostly) as if they were actually references to the owned object, so you can (mostly) use them that way without thinking too hard about it. They are attached to the underlying RefCell and when Ref and RefMut go out of scope, their destructors fire (Rust calls this the Drop trait, and this decrements the RefCell's count of the number of outstanding references.

We can see this in the following code snippet:

use std::cell::RefCell;

struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = RefCell::new(Hat { size: 5 });
    println!("{} {}", h1.borrow().size, h1.borrow().size);
    {
        let mut borrowed = h1.borrow_mut();
        borrowed.size = 10;
        println!("{}", borrowed.size);
        // borrowed is dropped here.
    }
    println!("{} {}", h1.borrow().size, h1.borrow().size);
}

In the the first call to println!() we borrow h1 twice immutably (which is safe) but these borrows go out of scope after println!() returns. We then call borrow_mut() and assign it to borrowed, at which point no other borrows are permitted; if we were to try to do another borrow right before the next println!() the program would panic. However, once the braced block {...} is closed, then borrowed goes out of scope, it's drop callback fires, and so there are no more borrows of any kind and the immutable borrows in the final println!() are permitted.

Decoding our Original Error #

We are now in a position to understand our original error, which I've reproduced for your convenience.

Code #

struct Hat {
    size: u8,
}

pub fn main() {
    let h1 = Hat { size: 5 };
    let h2 = h1;

    println!("{} {}", h1.size, h2.size);
}

Output #

error[E0382]: borrow of moved value: `h1`
 --> assign-rs.rs:9:23
  |
6 |     let h1 = Hat { size: 5 };
  |         -- move occurs because `h1` has type `Hat`, which does not implement the `Copy` trait
7 |     let h2 = h1;
  |              -- value moved here
8 |
9 |     println!("{} {}", h1.size, h2.size);
  |                       ^^^^^^^ value borrowed here after move
  |
note: if `Hat` implemented `Clone`, you could clone the value
 --> assign-rs.rs:1:1
  |
1 | struct Hat {
  | ^^^^^^^^^^ consider implementing `Clone` for this type
...
7 |     let h2 = h1;
  |              -- you could clone this value
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0382`.
make: *** [assign-rs.out] Error 1

Most of this should now be straightforward:

Hat doesn't implement Copy so when we assign h2 = h1 on line 7 Rust does a move.
We then try to use h1 on line 9 which is illegal because it has been moved.
The Rust compiler suggests that we should implement Clone, which is reasonable, but really we should implement Copy (which, recall, also requires Clone).

One thing might be confusing, though, which is that the error is "borrow of moved value: h1" even though there's no explicit borrow here: we're passing h1.size not &h1.size to println!(). The clue here is the !, which denotes that println! is a Rust macro; inside that macro, println!() is taking a reference to its arguments to avoid consuming them, hence this is a borrow, not just a use.

Next Up: More Rust #

As you may have gathered, one of the main experiences of learning Rust is figuring out how to architect your code in a way that is consistent with Rust's ownership and borrowing rules. A lot of that is building a mental model of how Rust works, which is what this post is about, but at the end of the day, there's also a fair amount of gymnastics required. I'll be going into that more in the next post.

Appendix: C++ vs. Rust smart pointers #

As a reference, here is a comparison table between C++ and Rust smart pointers.

Type	C++	Rust
Single ownership	`unique_ptr`	`Box`
Shared ownership (strong)	`shared_ptr`	`Rc`
Shared ownership (weak)	`weak_ptr`	`Weak`
Atomic shared pointers	`atomic<ptr-type>`	`arc::Arc`/`arc::Weak`
Internal ref counting	`boost::intrusive_ptr`*	`intrusive_collections`*
Interior mutability	N/A	`Cell`, `RefCell`

Non-standard feature.

Unless you explicitly tell it that's what you want in which case you better know what you're doing. ↩︎
i.e., just copying the memory ↩︎
Interestingly, when optimization is off rustc doesn't copy h1 to h2 but rather just initializes h1 and h2 with the same value. However, if you change h1 before doing the assignment (after making h1 mut, of course), then the assignment copies the fields as you would expect). ↩︎
Technical note for Rust nerds: this is actually a generic function and impl Shape + Circular stuff is syntactic sugar for fn print_circumference<T: Shape + Circular>(shape: T). ↩︎
Though cool people use make_unique() and friends. ↩︎
All mutable is a pretty common design pattern in languages ranging from C and C++ to Python and JavaScript. A number of functional languages (e.g., Erlang) are all immutable, which requires a somewhat different set of programming idioms, typically involving explicitly maintaining state by passing around the result of computations. ↩︎
Though this is undercut a little bit by Rust allowing you to redefine (shadow) variable names. ↩︎
Recall that malloc() will also over-allocate, so this reallocation might actually return the same region. ↩︎
NGL, this contrived example is probably not going to do anything bad, but that kind of thinking is a big part of why memory errors in C/C++ are so dangerous, because they often don't cause problems during testing but can then be exploited in bigger systems. ↩︎
I wrote the example this way rather than double borrowing numbers directly because it's a bit hard to create a dangerous example that way without using some kind of concurrency (parallelism) mechanism. In multithreaded programs, concurrent access to exactly the same data structure routinely causes problems. ↩︎
We'd also need a mut reference to numbers because we want to modify the elements of the array and the len_ field. ↩︎
Specifically it implements Deref and not DerefMut ↩︎
There are also try_borrow() and try_borrow_mut() which will fail if you try to break the rules. ↩︎

Understanding Memory Management, Part 3: C++ Smart Pointers

2025-03-10T00:00:00Z

This is the third post in my planned multipart series on memory management. In part I we covered the basics of memory allocation and how it works in C, and in part II we covered the basics of C++ memory management, including the RAII idiom for memory management. In this post, we'll be looking at a powerful technique called "smart pointers" that lets you use RAII-style idioms but for pointers rather than objects.

Why do you want pointers? #

Recall from before that I said that if you want to use RAII you need to store an actual object on the stack, not a pointer to the object, because if the object is on the heap, it won't be cleaned up when the function exits. This is an annoying limitation.

For example, suppose we want to write a function which hashes the contents of the file, returning a single string containing the hash. With just one hash function, that might look like this:

std::string hash_file(std::string filename) {
  char buf[1024];
  std::fstream fs(filename, std::fstream::in);
  SHA1 sha1; // Hash object

  if (!fs.is_open()) {
    abort();
  }

  while (fs.read(buf, sizeof(buf))) {
    sha1.update(fs.gcount());  // Hash a chunk of data.
  }
  
  return sha1.final();
}

Our hash function is just an object with two methods:

update() which hashes a chunk of data.
final() which returns the hash value.

I.e.,

class SHA1 {
 public:
   void update(const char* buf, size_t len);
   std::string final();
};

This works fine, but what happens if we want to support more than one hash function, for instance SHA-1, SHA-256, etc. One way to do this is to have the caller of the function provide the name in a string, i.e.,

std::string hash_value = hash_file("input.txt", "sha-1");

Internally, we'd have what's called a factory functionthat makes a hashing object given the string name. I.e.,

class Hasher {
 public:
   virtual void update(const char* buf, size_t len);
   virtual std::string final();
};

Hasher *get_hasher(std::string hash_name);

All of the concrete hashers (e.g., HashSHA) inherit from Hasher and get_hasher() returns an instance of the desired hash object. Because of inheritance, we can just assign all of them to Hasher *. This gives us a function like the following:

std::string hash_file(std::string filename, std::string hash_name) {
  char buf[1024];
  std::fstream fs(filename, std::fstream::in);
  Hasher *h = get_hasher(hash_name);

  if (!fs.is_open()) {
    abort();
  }

  while (fs.read(buf, sizeof(buf))) {
     h->update(fs.gcount());  // Hash a chunk of data.
  }
  
  return h->final();
}

So far so good, but now instead of having an instance of SHA1 on the stack we have an instance of Hasher on the heap and it leaks when the function returns. So much for RAII. Fortunately, it's possible to recover RAII semantics in a generic way using a "smart pointer".

What's a smart pointer and why is it smart? #

At a high level, a smart pointer is an object that can be used as if it were a pointer but has better semantics. For instance, C++ unique_ptr provides stack-like RAII properties for objects on the heap. It gets used like this:

  unique_ptr<Hasher> h(get_hasher(hash_name));

This is literally the only change we have to make. From there on, we can use h, which is actually a unique_ptr holding Hasher *,as if it were a Hasher *. When h goes out of scope out the end of the function, the pointer it's holding will be freed, just as if the hasher object itself were on the stack.

C++ has a number of different smart pointer types built into it, but first I want to look at how you actually implement a smart pointer.

Implementing a Smart Pointer #

Suppose, for example, we want to implement a unique_ptr-like for Hasher. For starters, we need a class that holds a Hasher* and destroys it on destruction:

class UniquePtrHasher {
 private:
  Hasher *ptr_;
 
 public:
  UniquePtrHasher(Hasher *ptr) {
    ptr_ = ptr;
  }
  
  ~UniquePtrHasher() {
    delete ptr_;
  }
};

This is actually enough to give us RAII behavior: we can create a UniquePtrHasher in the usual way and when it goes out of scope it will be destroyed along with the hasher object inside:

HasherUniquePtr h(get_hasher(hash_name));

This isn't really a smart pointer, though, it's just a container for the object. If we want to do anything with object inside, we somehow need to get at the pointer. The obvious thing is to just provide a function called get() that gives you the pointer:

  Hasher *get() {
    return ptr_; 
  }

This is called "unboxing" because we have the pointer in a box (the smart pointer) but now we take it out to use it. Unboxing will work, but now we have to change all the code which previously used h as if it were a pointer to use h.get():

  while (fs.read(buf, sizeof(buf))) {
     h.get()->update(fs.gcount());  // Hash a chunk of data.
  }
  
  return h.get()->final();
}

Yuck! Not only is this a pain in the ass, but it undercuts the whole thing we are trying to do here, which is to avoid having to work with the raw pointer.

Fortunately, C++ has a feature that makes this unnecessary because we can use operator overloading. In part II, we overloaded the copy assignment operator but here we are going to overload the -> operator instead so that UniquePtrHasher acts like Hasher*. The code for that looks like this:^[1]

  T *operator->() {
    return ptr_;
  }

You don't need to worry too much about the syntax, but the net effect is that when you use -> with UniquePtrHasher it acts like you were using -> with the internal pointer, which is what we want. Here's our new code:

std::string hash_file(std::string filename, std::string hash_name) {
  char buf[1024];
  std::fstream fs(filename, std::fstream::in);
  UniquePtrHasher h(get_hasher(hash_name));  // NEW

  if (!fs.is_open()) {
    abort();
  }

  while (fs.read(buf, sizeof(buf))) {
     h->update(fs.gcount());  // Hash a chunk of data.
  }
  
  return h->final();
}

The only line that's changed from our original code is the one marked NEW where we create the UniquePtrHasher but now we've eliminated the memory leak.

This is a smart pointer after the fact, but it's kind of a dumb one. There are at least two big problems:

It doesn't guarantee uniqueness.
It's not generic.

Let's solve these in turn.

It's good to be unique #

Consider the following code:

  UniquePtrHasher h(get_hasher(hash_name));
  UniquePtrHasher h2 = h;

As we saw in part I, this will invoke the copy constructor. Because we haven't defined a copy constructor, we end up with the default one which makes a shallow copy, with the result that h and h2 both point to the same instance of Hasher. When the function ends they will both try to delete it, which leads to a double free, with the following error:

uniqueptrhasher(20294,0x2000dcf80) malloc: *** error for object 0x600003694040: pointer being freed was not allocated
uniqueptrhasher(20294,0x2000dcf80) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

As expected, the destructor for UniquePtrHasher fires twice, but with the same pointer (0x600003694040). In this case, the implementation has chosen to generate an error and crash the program for the double free() (note that the error is in malloc() because this C++ implementation of new/delete is based on malloc()), but that's just whoever wrote it doing you a favor. As noted in post I, anything could happen at this point, but whatever it is is likely to be bad. This is definitely a defect and quite possibly a vulnerability.

What we want to do is make this case impossible, which is to say to make UniquePtrHasher actually unique. By this point it should be clear how to do this: we're going to overload the copy constructor and the copy assignment operator. With what we know now, the obvious thing to do is to just make them abort, like so:

  UniquePtrHasher(UniquePtrHasher &other) {
    abort();
  }

This works in some sense, but it's a runtime error, which means that our program will crash if we try to copy a UniquePtrHasher but that the compiler won't catch it so the program will still compile. Moreover, there's no guarantee that the failure will be this safe; it could easily be a serious vulnerability via use after free.

What we really want is a compile time guarantee. The old way to do this was to make the copy constructor private so that it wasn't possible to call it, but the new way (as of C++-11) is to mark it with delete:

  UniquePtrHasher(UniquePtrHasher &other) = delete;

If we then try to construct a new UniquePtrHasher from an existing one, we get the somewhat helpful error:

uniqueptrhasher.cpp:23:19: error: call to deleted constructor of 'UniquePtrHasher'
   23 |   UniquePtrHasher u2(u);
      |                   ^  ~
uniqueptrhasher.cpp:18:3: note: 'UniquePtrHasher' has been explicitly marked deleted here
   18 |   UniquePtrHasher(UniquePtrHasher &other) = delete;
      |   ^

If we do the same thing for the copy assignment operator, we've then prevented anyone from making a second UniquePtrHasher pointing to the same underling object. Well, sort of.

It's true that if we do all of this you can't make another UniquePtrHasher from an existing one, but nothing stops you from making two UniquePtrHashers from the same pointer:

  Hasher* hasher = get_hasher(hash_name);
  UniquePtrHasher h(hasher);
  UniquePtrHasher hr(hasher);

The obvious answer is "don't do that then" but we're just depending on programmer discipline, because the compiler won't stop you. How is it to know you didn't want that outcome (and later we'll see an example of where this kind of thing is totally legitimate, if slightly inadvisable)?

Moving Smart Pointers #

OK, so now have a unique pointer, but this is pretty limited. While we don't want to be able to make a copy of a unique pointer (that's what makes it unique), sometimes we want to move an object from one unique pointer to another. For example, suppose we have created an object but we want to store it in a container, like a vector. This presents two problems:

We want the vector to own it so our destructor doesn't destroy it when it goes out of scope.
The vector may need to move the object around when it reallocates its own memory to grow or shrink.

The key thing here is that we want to preserve the uniqueness guarantee. After we do a = b, we want a to be holding the pointer and b not to be.

Unsurprisingly, we're going to do this with the move assignment operator, which we saw in part I. It looks something like this:^[2]

  UniquePtrHasher& operator=(UniquePtrHasher &&other) {
    // Check for self-assignment.
    if (this == &other) {
      return *this;
    }
    ptr_ = other.ptr_;
    other.ptr_ = nullptr;
    return *this;
  }

The move assignment operator does two things:

It sets the ptr_ field in the new smart pointer (the one being moved to) to point to the object that is being held.
It invalidates the ptr_ field in the original pointer (the one being moved away from) by setting it to nullptr.

Put together, these will prevent the object from being destroyed when the source smart pointer is destroyed. We also want to make sure that any use of the old smart pointer fails cleanly, so we should add a check in the operator->() implementation:

  Hasher *operator->() {
    if (!ptr_) {
      abort();
    }
    return ptr_;
  }

We'll also need to implement the move constructor, which is basically the same as the move assignment operator.

A generic smart pointer #

This is all fine, but note that we haven't written a generic unique pointer class, but instead one that only works for Hasher. If we want one for a new class called Smasher we need to write it all again, or rather we need to take the Hasher class and globally replace Hasher with Smasher (and better hope you don't have anything called NotHasher because it will become NotSmasher). Fortunately, C++ offers a better way of doing this: templates.

Templates #

The idea with templates is to let the compiler do that search and replace for you, which obviously works a lot better than text replacement. We do this by making a version of the class with a placeholder typename (conventionally T) instead of the actual concrete typename, like so:

template<class T> class UniquePtr {
  T* ptr_;

public:
  UniquePtr(T *t) {
    ptr_ = t;
  }

  ~UniquePtr() {
    delete ptr_;
  }

  T *operator->() {
    return ptr_;
  }

  UniquePtr(UniquePtr &&u) {
    ptr_ = other.ptr_;
    other.ptr_ = nullptr;
    return *this;
  }
  
  UniquePtr& operator=(UniquePtr &&u) {
    // Check for self-assignment.
    if (this == &other) {
      return *this;
    }
    ptr_ = other.ptr_;
    other.ptr_ = nullptr;
    return *this;
  }
  
  // Delete the copy constructor and copy assignment operator.
  UniquePtr(UniquePtr &u) = delete;
  UniquePtr& operator=(const UniquePtr& other) = delete;
};

Note that we're going to call this UniquePtr rather than unique_ptr to avoid confusing it with C++'s built-in implementation.

Developing a Template Class #

It's true that one of the advantages of templates is that they avoid all the grotty search and replace, but it's actually fairly common to develop a concrete instance of the template for one class and then do search and replace of Hasher (or whatever) to T. It's typically easier to implement classes in the specific case and then generalize, especially with C++'s famously terrible template-related error messages..

The syntax template<class T> tells C++ that this is a template and that the name of the placeholder type is T (as an aside, you can have multiple placeholder types). When you actually go to use the template class, you tell it what type you want to make a unique pointer for and the compiler replaces the Ts with that typename, producing a new version of the UniquePtr class that is customized just for that type (technical term: instantiating the template).

The syntax should be familiar by now:

  UniquePtr<Hasher> h(get_hasher("sha-1"));

Importantly, UniquePtr<Hasher> and UniquePtr<Smasher> are totally different classes, as you can see if you try to stuff a Smasher * into UniquePtr<Hasher>, provoking the following super-helpful compiler error message:

./smart.cpp:44:21: error: no matching constructor for initialization of 'UniquePtr<Hasher>'
   44 |   UniquePtr<Hasher> h(new Smasher());
      |                     ^ ~~~~~~~~~~~~~
./smart.cpp:6:3: note: candidate constructor not viable: no known conversion from 'Smasher *' to 'UniquePtr<Hasher> &' for 1st argument
    6 |   UniquePtr(UniquePtr &t) = delete;
      |   ^         ~~~~~~~~~~~~
./smart.cpp:10:3: note: candidate constructor not viable: no known conversion from 'Smasher *' to 'Hasher *' for 1st argument
   10 |   UniquePtr(T *t) {
      |   ^         ~~~~

Thinking Outside The Box #

This isn't a complete implementation of a unique pointer, but it illustrates the essential features.

The good news is that if you only use smart pointers and not regular pointers, then your programs will be a lot safer. This isn't to say that there can't be any memory errors because there are other ways to do unsafe stuff, but to a first order you won't have to worry about memory leaks or use after free. The problem here is that nothing in C++ restricts you to just using smart pointers.

For example, with unique pointers:

You can create a raw pointer and then add it to a smart pointer, but this doesn't invalidate the original raw pointer; you just end up with both the copy in the smart pointer (the "boxed" version) and the original one in the raw pointer (the "unboxed" version).
You can get an unboxed copy of the pointer just by doing .get(). This doesn't invalidate the boxed version the way that std::move() does.

Both of these violate the uniqueness guarantee of unique_ptr<T>, so if you do either of them, then you're back in the situation where you have to worry about manually managing memory and C++ won't protect you.

The natural thing to say is "I'll just work with boxed pointers", and to some extent you can do that (though again, C++ won't stop you from unboxing stuff, you just have to not do it) but it's very common to have to work with code that doesn't know about smart pointers, and then you end up unboxing them, at which point you're back in the soup.

Other Smart Pointers #

One common situation where you end up having to sort of unbox unique pointers is when you want to pass them to a function, as in:

void doit(std::unique_ptr<Foo> foo) {
  // do something
}

void f() {
  std::unique_ptr<Foo> x(new Foo());
  
  doit(x);
}

As expected, this fails because passing x by value would require making a copy of x, which would violate the uniqueness invariant. We could move x but then we couldn't use it later, when what we really want is to just let doit() do something with x temporarily but keep ownership. One way around this would just be to pass a pointer to x, like so:

void doit(const std::unique_ptr<Foo>* foo) {
  // do something
}

void f() {
  std::unique_ptr<Foo> x(new Foo());
  
  doit(&x);
}

This will work, but what it's really doing is working around the uniqueness rule: we only have one object holding onto the inner Foo * but we've got multiple variables pointing at the unique_ptr<Foo>, one in f() and one passed as a pointer to doit(). So, technically we haven't unboxed the inner pointer, but we've unboxed x which has all the same problems as before. C++ also has a feature called "references", where the callee (in this case doit()) can just ask for what's effectively a pointer to the object without modifying the call site, and you could ask for a reference to x but this still has the problem that you can copy the references around, so it's possible to have a reference to x outlive x. This isn't to say that it's not possible to safely use references or pointers to a unique_ptr, just that you have to be careful to follow the rules because the compiler won't help you out. (Aside: in production code you should use references rather than pointers, but I'm trying to keep new syntax to a minimum).

It's also quite common to have situations where you actually want to have two pointers to the same underlying object. For example, suppose that we're building an HR application and we want to keep track of people's managers. It's normal for two people to have two managers, but we can't copy unique_ptr so things get tricky. Fortunately, unique_ptr isn't the only type of smart pointer. For this task, the tool we want is called shared_ptr.

Shared Pointers #

Unlike a unique_ptr, multiple shared_ptr instances can point to a given object, just like with a regular pointer (or, if you're used to a programming language like Python, JavaScript, or Go, just like you happens all the time). shared_ptr keeps track of how many instances there are (the "reference count"). When you copy a shared_ptr the reference count increases by one. When a shared_ptr instance is destroyed the reference count decreases by one. If the reference count reaches zero, that means that there are no shared_ptrs to the object and it's destroyed.

For example, consider the following code:

class Foo {
 public:
  Foo() {}
  ~Foo() {
    printf("Destructor for Foo\n");
  }
};

int main(int argc, char **argv) {
  std::shared_ptr<Foo> p1(new Foo());
  printf("Reference count %ld\n", p1.use_count());
  std::shared_ptr<Foo> p2 = p1;
  printf("Reference count %ld\n", p1.use_count());
  printf("Reference count %ld\n", p2.use_count());  
  p2.reset(); // Forget about the pointer.
  printf("Reference count %ld\n", p1.use_count());
  p1.reset();
}

When run, this produces the output:

Reference count 1
Reference count 2
Reference count 2
Reference count 1
Destructor for Foo

Note that when both p1 and p2 point to the object, then they also share the same reference count (2). When we reset p2, telling it to forget about the object, then the reference count drops to 1 and then when we reset p1, then the reference count drops to zero and the object is destroyed.

Once we have a shared pointer we can use it to pass an object around without unboxing it:

void doit(std::shared_ptr<Foo> foo) {
  // do something
}

void f() {
  std::shared_ptr<Foo> p1(new Foo());
  doit(p1);
}

When we pass p1 to doit(), it makes a copy of p1, incrementing the reference count. Then when doit() returns, that copy is destroyed, decrementing the reference count. The same thing happens when we want to have multiple pointers to the same object, as in the case of storing a pointer to an employee's manager.

It's worth taking a quick look at how shared_ptr works. The code below shows the core of a homegrown implementation, focusing on the new stuff.

template<class T> class SharedPtr {
  struct detail {
    T* ptr_;
    size_t ct_;
  };

  detail *ptr_;


 public:
  SharedPtr() {
    ptr_ = nullptr;
  }
  
  SharedPtr(T *t) {
    ptr_ = new detail();
    ptr_->ptr_ = t;
    ptr_->ct_ = 1;
  }

  SharedPtr(SharedPtr &u) {
    ptr_ = u.ptr_;
    ptr_->ct_++;
  }
  
  SharedPtr& operator=(const SharedPtr& u) {
    ptr_ = u.ptr_;
    ptr_->ct_++;
    return *this;
  }
  
  ~SharedPtr() {
    ptr_->ct_--;
    if (!ptr_->ct_) {
      delete ptr_->ptr_;
      delete ptr_;
    }
  }
};

The key intuition is that we need somewhere to store the reference count, and that needs to be shared between the different instances of SharedPtr so that they have the same view of the reference. This means that it can't be stored in any one copy in case that copy goes out of scope. Instead, we allocate a new detail object which stores the reference count and every instance of SharedPtr just points to the single detail instance, as shown here:

Two shared pointers to the same object

In this case, it also stores the pointer to the owned object, though that could in principle also go in the SharedPtr class, with each one having its own copy of the pointer, which is what Windows seems to do.

Circular References #

Consider the following (potentially more complicated than necessary) code, which models a trivial family with one parent and one child. We want each parent to know its own child and and each child to know its own parent so that we can go from parent to child and vice versa.^[3]

class Child;

class Parent {
 public:
  Parent() {}
  ~Parent() {
    std::cout << "~Parent" << std::endl;
  }
  std::shared_ptr<Child> child_;
  
  // Forward declaration.
  void set_child(std::shared_ptr<Child>& child);
};

class Child {
 public:
  Child(std::shared_ptr<Parent>& parent) {
    parent_ = parent;
  }
  ~Child() {
    std::cout << "~Child" << std::endl;
  }
  
  std::shared_ptr<Parent> parent_;
};

// Definition of set_child()
void Parent::set_child(std::shared_ptr<Child>& child) {
  child_ = child;
}

void make_family() {
  std::shared_ptr<Parent> parent(new Parent());
  std::shared_ptr<Child> child(new Child(parent));
  parent->set_child(child);
}

When we run make_family() code, we would expect to get the following output:

~Parent
~Child

However, in practice we get nothing. The reason is simple: parent and child aren't actually being destroyed. But why not? To debug this, let's add some instrumentation:

  std::shared_ptr<Parent> parent(new Parent());
  std::cout << "Parent refct=" << parent.use_count() << std::endl;
  std::shared_ptr<Child> child(new Child(parent));
  std::cout << "Parent refct=" << parent.use_count() << "; Child refct=" << child.use_count() << std::endl;
  parent->set_child(child);
  std::cout << "Parent refct=" << parent.use_count() << "; Child refct=" << child.use_count() << std::endl;

And here's the output:

Parent refct=1
Parent refct=2; Child refct=1
Parent refct=2; Child refct=2

It's a little tricky to print out the reference counts after make_family() has completed, because if we return shared_ptr<Parent> then we'll have a reference to it in the caller and don't expect it to be destroyed. What we want is to somehow keep ahold of parent without having a reference to it. We can do this if we unbox parent via parent.get() and return it, allowing us to look inside:

  Parent* parent = make_family();
  std::cout << "Child refct=" << parent->child_.use_count() << std::endl;
  std::cout << "Parent refct=" << parent->child_->parent_.use_count() << std::endl;

The output is:

  Parent* parent = make_family();
  std::cout << "Child refct=" << parent->child_.use_count() << std::endl;
  std::cout << "Parent refct=" << parent->child_->parent_.use_count() << std::endl;

The output is:

Child refct=1
Parent refct=1

You may have figured out what's going on here, but if not, it's helpful to walk through things step by step and look at the structure, as shown in the following diagram.

Shared pointer step by step.

First, we allocate a new instance of Parent, storing a pointer to it in the shared pointer local variable parent, with reference count=1.
We then allocate a new instance of Child, passing it a shared pointer to parent. The constructor for Child copies the pointer to parent to its own internal parent_ shared pointer, incrementing the reference count to 2. We then assign the new Child to the local shared pointer child.
We then tell our instance of Parent about our new instance of Child with the set_child() function, which copies the shared pointer into its own internal child_ shared pointer, incrementing the reference count to 2.
Finally, when make_family() returns, both local shared pointer instances are destroyed, decrementing the corresponding reference counts, with the result that each shared pointer now has reference count 1.

The reason that neither Parent nor Child is being destroyed is that each is being owned by a shared pointer with reference count 1, held by the other: Parent holding a shared pointer to Child and Child holding a shared pointer to parent. Nothing else is pointing to either, except for the the unboxed pointer to the Parent that we leaked for debugging purposes, which you can ignore as it has no effect on the reference count (you can easily reproduce this effect without returning that as we did in the original program). Each object is keeping the other alive, but they're not otherwise relevant.

What we've done here is reproduce the classic problem with reference counting for memory management: circular references. The basic assumption behind a reference counting system like shared pointers is that it assumes that the shared pointers are laid out in what programmers call a directed acyclic graph (DAG),^[4] which is to say that there are no loops where if you follow the shared pointers from object A you eventually get back to A. If there are, then you can end up with objects which can't be freed even if all the references external to the loop are destroyed. In this case, the memory will be inaccessible but can't be freed.

Assuring Destruction #

OK, so we have some data which can't be freed? Is that such a big deal. It's important to recognize that when you are using RAII, this kind of error is not just a matter of wasted resource but a correctness issue because object destruction can have visible side effects.

As a simple, consider the following trivial code:

function write_stuff() {
  std::ofstream file("x.out");
  file << "Hello world";
}

This just writes Hello world to the file x.out. However, there's a lot hiding under that "just", because the program doesn't address the disk hardware directly. Instead, it uses the "system call" write() to ask the operating system to write some stuff to the disk, which sets off a long chain of other events which I won't go into here. Each call to write() is somewhat expensive, so programs typically will buffer up individual writes internally and then flush the buffer when it gets full or, critically, when the file is closed. In this code, that is hidden by the use of RAII, which just magically takes care of things when the function returns, but what's really happening is something like this:

function write_stuff() {
  std::ofstream file("x.out");
  file << "Hello world";
  // flush |file|
  // free file's memory
}

If something interferes with file being destroyed, then some data may be left in the buffers, with the result that x.out will be truncated. We can reproduce this by calling exit() at the end of write_stuff().

void write_stuff() {
  std::ofstream file("x.out");
  file << "Hello world";
  exit(1);
}

As the name suggests, exit() causes the program to exit, and it never returns, which means that write_stuff() never returns, which means that file is never destroyed (or, rather, that the destructor never runs, because of course all the program memory is freed), which means that anything still in the buffers is never written to disk. On my computer (a Mac) the result of this program is a file containing only the letter H, so presumably ello World is still in the buffer, lost to us forever. The same thing would happen if instead we had some bug that prevented the object from being destroyed, such as it was held by some circular reference as above.

Note that the exact behavior you observe will depend on the precise buffering strategy employed by your C++ implementation, as the standard doesn't appear to prescribe one behavior. In fact, the astute observer will note that I didn't end the write with a std::endl, which adds a line feed to the end of the line; on my machine this seems to cause the buffer to flush.

The key point here is that many nontrivial uses of RAII depend on the destructors actually executing at the right time, so defects like circular references, while not precisely a memory leak in the technical sense (each object is being pointed to by something), can lead to serious correctness issues.

Weak Pointers #

It's totally reasonable to want to make data structures which have reference loops, so if we can't just use shared pointers, what do we do? One option would be to have one of the pointers just be unboxed, but this undercuts the whole purpose of using smart pointers in the first place. What we instead need is a different kind of smart pointer called a "weak pointer".

Unlike other types of smart pointer, a weak pointer doesn't keep the pointed to object alive (in C++ jargon, it doesn't "own" it). This means that the object might be destroyed while you are holding the weak pointer. This means that you can have circular references as long as the reference in one direction is a weak pointer, because that breaks the cycle.

Because the object might be destroyed out from under you, in order to ensure that a weak pointer is safely used, then, you need to temporarily convert the weak pointer into a shared pointer using the lock() method. This shared pointer keeps the object while you use it and when it goes out of scope, you're still holding the weak pointer. For example:

  std::shared_ptr<Temp> temp(new Temp());
  std::weak_ptr<Temp> weak(temp);
  
  std::shared_ptr<Temp> locked = weak.lock();
  if (locked) {
    locked->foo();
  } else {
    std::cout << "Object destroyed" <<std::endl;
  }

Importantly, if the underlying object has already been destroyed (because the shared pointer reference count went to 0), the lock() method can fail, in which case the resulting shared pointer will have the value nullptr (pointing to nothing). This is an inherent consequence of the fact that the weak pointer doesn't keep the object alive.

While I'm not going to go into all the details of how to implement weak pointers here (there are a number of techniques) I do want to note that one way to implement it is for the shared pointer detail object to maintain two reference counts, one strong, one weak. When the strong reference count goes to zero, you destroy the object being held. When both the strong and weak pointer counts are zero, you destroy the detail object itself; this allows the weak pointer to continue to exist and point to valid memory—though just to the detail object—even if all the shared pointers have been destroyed. This doesn't violate the RAII correctness guarantees described above because the object is still destroyed, but it does mean that there is some overhead from a weak pointer hanging around even if the shared pointers are all gone.

When you have to unbox #

We now have unique_ptr, shared_ptr, and weak_ptr, which means we're all set, right? Well, maybe. If you're writing totally new code, then these three smart pointers are basically all you need, but if you have to deal with older code which doesn't use smart pointers, then you can run into problems.

Consider the following simple C-style API for timers.

void set_timer(unsigned int timeout,         // How long to wait
               void (*callback)(void *),     // The callback to call
               void *);                      // An argument to pass

This is a bit abstruse, due to a combination of C's limited semantics and arcane syntax, but what it says is that you pass in three arguments:

A timeout
A function to call when the timeout expires
An argument to pass to the function

In a modern language, you would either pass a Callback object that encapsulated the callback and the context or, even better, a closure that encapsulated all the relevant state, but neither of these is available in C, so instead we have this.

You use this API this way:

void print_string(void *ptr) {
  print("Called with argument '%s'\n", (char *)ptr);
}

set_timer(1000, callback, "Hello!");

When the timer expires, print_string() gets called with a pointer to the string provided as the third argument. Note that this can actually be a pointer to any type of object (that's what void *) means, and it's the job of the callback to know what type of pointer it actually is and use it appropriately. The (char *)ptr means "treat this as if it contains a string", which better be true or things can turn very ugly very fast.

This is all fine, though a bit fiddly, but what happens if we want to pass some dynamically allocated object to the callback? In C, static strings are stored in the data segment so you don't need to allocate or free them, but what if we had a dynamically constructed string? In that case, we may need to free the object in the callback, like so:

void print_string(void *ptr) {
  print("Called with argument '%s'\n", (char *)ptr);
  free(ptr);
}

We're back to C-style memory management here, but what if we want to work with an object which is owned by a smart pointer? We could unbox the pointer, like so:

shared_ptr<Foo> foo(new Foo());

set_timer(1000, do_something, (void *)foo.get());

This works as long as foo outlives the timer, but there are situations where you don't know the respective lifetimes. For instance, consider what happens if you are making some kind of network request and want to set a timer in case the request takes too long. In this case, it could be either the request error handler or the timer that is the last use of the object, which is exactly the kind of problem that shared pointers are designed to help you manage! What you actually want to do is to pass the shared pointer to the callback handler, but this impoverished API precludes that.

Internal Reference Counting #

One way to manage this situation is to move the reference count from outside the object (as in shared pointer) to inside the object. For instance, we can require that any managed object expose a reference counting interface like so:

class ManagedObject {
  static void AddRef();
  static void Release();
};

Internally, the object has to maintain a reference counter which is incremented whenever AddRef() is called. When Release() is called, the reference counter is decremented. If the reference count reaches 0, Release() will destroy the object using delete this, which is safe to do as long as you are super-careful. The implementation of the smart pointer itself looks sort of like SharedPtr, except that it calls the AddRef() and Release() functions rather than directly incrementing and decrementing its own reference count.

If we adapt our program to use a reference counted pointer it looks like this:

void outer_function() {
  {
    Foo *f = new Foo();                      // Reference count = 1
    RefCountedPtr<Foo> foo(f);               // Reference count = 1
    foo->AddRef();                           // Reference count = 2
    set_timer(1000, do_something, (void *)foo.get());
  } 
  // foo is out of scope. Reference count = 1
}

void do_something(void *ptr) {
  // Reference count = 1, because |outer_function()| exited.
  RefCountedPtr<Foo> foo((Foo *)ptr);
  foo->do_something();
  // object will be destroyed here.
}

Note that unlike shared pointers, this still requires some attention to the reference count. In particular, before we unbox the pointer and pass it to set_timer() we need to manually increment the reference counter. The reason for this is that the object is essentially being owned by the timer infrastructure, and if we didn't do that, then when outer_function() returned, the object would be destroyed as the smart pointer went out of scope.

Perhaps less obviously, we have to manage what happens when the RefCountedPtr takes ownership of an object: does it increment the reference count or not? You need an option to have it leave the reference count alone so that when it takes ownership in the do_something() callback we don't end up with a reference count of 2 rather than 1 (because it's being handed off from the timer infrastructure to the callback). In this code I've opted to only have that variant and force objects to self-initialize with a reference count of 1, but another alternative is to have a flag of some kind that tells the RefCountedPtr constructor whether to increment or not.

Implementation Status #

C++ doesn't have a standard implementation of this kind of reference counted pointer, but the popular Boost C++ library project provides a version called intrusive_ptr, though it works a little differently than what I've sketched above.

Firefox makes very extensive use of internally reference counted counted pointers using the RefPtr template (the sketch above is sort of modeled on Firefox's implementation). The decision to use this design is very old (long predating my time at Mozilla) and dates from a time when C++ didn't have good smart pointers. Once that changed and good smart pointers were widely available, there were a number of debates^[5] about which type to use (I was on Team use the C++ standard) and so now Firefox contains a mix of both styles. I don't know what decisions people would have been made starting from scratch (though Chrome seems to use the standard smart pointers a lot more, which is where I got used to it).

Unboxing (again) #

As should be clear from the discussion above, unless you're writing totally greenfield code, it's very hard to avoid having to unbox pointers sometime. In my experience, engineers seem to have two attitudes towards this reality:

Discourage it and make you work if you want to unbox.
Lean into it and make it as easy as possible to unbox.

One of the core loci of this debate is whether you should be able to implicitly convert a smart pointer to a raw pointer, like so.

shared_ptr<T> t(new T());
T* t2 = t;

Note that basically all smart pointers in C++ implement some unboxing method like .get() and operator-> so that you can access methods and properties; the question is whether you automatically convert to T* in other contexts. Ordinarily this wouldn't work in C or C++ because shared_ptr<T> and T* are totally different types and you can't just assign one to the other. However, you can make it work by implementing it explicitly as part of shared_ptr<T>.

The argument for implementing automatic conversion this is that it makes it easy when you inevitably have to unbox; the argument against it is that it's all too easy to unbox accidentally and that you should have to do it explicitly. C++'s smart pointers force you to call .get(). Firefox's do not and in fact discourage calling .get(). I think this is the wrong answer but was not able to persuade enough people to get it changed; it's easy to add affordances like this, but much harder to remove them once people start to rely on them and you need to change all the relying code.

This is all baked in #

One important thing to realize is that smart pointers aren't some new piece of C++ syntax; they're just a new combination of a number of existing C++ features, namely:

Constructors and destructors to enable RAII
Overloading the copy constructor, copy assignment operator, etc. provide the appropriate functionality for copying and assignment.
Overloading -> (and sometimes automatic conversation) to make the smart pointer act like a regular pointer.

That's why we're able to implement our own smart pointers that do the same thing as the ones shipped with the C++ library. This kind of thing is something you see a lot with powerful languages like C++: people realize that they can put together existing features in new ways to produce new functionality that wasn't built into the language.

Next Up: Rust #

The major reason this is all so messy is that smart pointers are layered onto C++'s previously existing unsafe memory management system. This means that you can always opt out of smart pointers and use unboxed pointers, at which point you've given up all your safety guarantees. This is actually something you have to do sometimes—especially when you are working with legacy code—but the lack of compiler enforcement encourages you to do that rather than figuring out how to do things safely without unboxing. Next up, we'll be looking at a language which was built to be safe from the ground up: Rust.

It's not obvious why this should work, because we want to actually operate on h->update() not get the internal pointer but the special sauce in C++ is that it will keep applying -> until it gets something that makes sense. ↩︎
Don't ask why the && syntax means move constructor; you don't want to know. ↩︎
Note that there are some odd shenanigans in this code to deal with the fact that C++ requires that objects be declared before they are used. Because Child and Parent both reference each other, there is no order in which you can have the complete code for Parent before or after the complete code for Child; instead we have to break them up a bit so the relevant pieces are available at the right times. Newer languages like Rust or Go tend to be better about looking ahead so you don't need to do this kind of thing. ↩︎
Programmers love to say "DAG". ↩︎
Centering primarily around alleged performance concerns for incrementing and decrementing the reference count for shared pointer. ↩︎

Understanding Memory Management, Part 2: C++ and RAII

2025-02-17T00:00:00Z

This is the second post in my planned multipart^[1] series on memory management. In part I we covered the basics of memory allocation and how it works in C, where the programmer is responsible for manually allocating and freeing memory. In this post, we'll start looking at memory management in C++, which provides a number of much fancier affordances.

Background: C++ #

As the name suggests, C++ is a derivative of C. The original version of C++ was basically an object oriented version of C ("C with classes") but at this point it has been around for 40-odd years and so has diverged very significantly (though modern C is a lot more like original C than C++ is) and accreted a lot of features beyond what you'd think of in an object oriented language, such as generic programming via templates and closures (lambdas).

Despite this, C++ preserves a huge amount of C heritage and many C programs will compile just fine with a C++ compiler;^[2] in fact, C++ was originally implemented with a pre-processor called "cfront" which compiled C++ code down into C code, though that's not how things work now. This is actually a source of a lot of issues with C++, when programmers do things the C way—or even the older C++ way—even though modern C++ has better methods. We'll see some examples of this later in this post.

The most obvious change in C++ is the introduction of the idea of objects and classes. At a high level, an object is a data type that has both data and code associated with it, where code means functions. But let's start by looking at a type which just has data associated with it, but where that data is somewhat complex.

C Structs #

Complex data types are already a feature in C. For instance, consider the following example type:

struct rectangle {
  int width;
  int height;
};

Even if you don't know C, if you've done any programming you can probably figure out what this means: it's defining a new type that represents a rectangle and has two values, the height and the width of the rectangle, each of which are integers (int being one of the C integer types). Obviously you could just have two variables, rectangle_width and rectangle_height, but this lets you group them together, like so:

int area(rectangle r) {
    return r.width * r.height;
}

rectangle r = { 10, 2 }; // Make a rectangle of width 10 and height 2

printf("Area is %d\n", area(r));

In this example, we've defined a function called area that takes a rectangle as an argument and returns the product of the width and the height. Note that the notation for accessing a one of the values inside a C struct is the a.b where a is the name of the variable containing the struct and b is the name of the field inside the struct (e.g., width).

Call by Value #

I've actually done something new here that you might not have noticed, which is that I've passed our struct to the function. All function calls in C are what's called "call by value", which is to say that C makes a copy of the data element that is available to the function but is disconnected from the original value. The called function can change its arguments without affecting the caller. Consider, for instance, the following example.

void shrink(rectangle r) {
   r.width = r.width/2;
   r.height = r.height/2;
   printf("Inner width=%d height=%d\n", r.width, r.height);
}

rectangle r = { 10, 2 }; // Make a rectangle of width 10 and height 2
shrink(r);
printf("Outer width=%d height=%d\n", r.width, r.height);

As expected, this prints out:

Inner width=5 height=1
Outer width=10 height=2

because shrink just modified its own copy of r. Function calls are just a special case of generically how assignments in C work: they make a copy of whatever memory was associated with the source and stuff it into the target.^[3]

C does provide a way for the called function to modify memory associated with the caller: the caller just passes a pointer to the callee rather than the variable itself, as in the following code:

void shrink(rectangle* rp) {
   rp->width = rp->width/2;
   rp->height = rp->height/2;
   printf("Inner width=%d height=%d\n", rp->width, rp->height);
}

rectangle r = { 10, 2 }; // Make a rectangle of width 10 and height 2
shrink(&r);
printf("Outer width=%d height=%d\n", r.width, r.height);

Note the new notation here:

& takes a pointer to a variable so &r is a pointer to r
a->b accesses a variable in a struct when you have a pointer to the struct. This is what is known as "syntactic sugar" because you could just do (*a).b, but it's used all the time.

This snippet does what we expect, which is to say modifies the value in the outer function:

Inner width=5 height=1
Outer width=5 height=1

It's important to realize, though, that C was still doing call-by-value; it's just that the value we passed was a pointer to r rather than r itself, which allowed the function to manipulate the memory that the argument pointed to rather than its local copy of that variable.

Objects and Classes #

Everything we've seen here is still normal C, but often we want to associate a function with a type. For instance, the area function we have shown above only works with rectangles, but what if we had circles as well? We'd end up with two functions, one called area_rectangle and one called area_circle. Objects give us another option, which is to associate the function with the type, so that we can do something like this:

Rectangle r = {10, 2}; // Make a rectangle of width 10 and height 2

printf("Area is %d\n", r.area());

We've got some new syntax here, but it's basically an extension of the old syntax. Instead of referring to a data element with r.height we are now referring to the function area() with the the syntax r.area(). Also we don't have to pass the data values to r.area() because it just gets them as part of the function call, which is very convenient if we also have circles, because then we can do:

Circle r = {10};

printf("Area is %d\n", r.area());

Note that the call to area() is exactly the same in both cases. This syntax hides what kind of object we are working with, which lets us reason about the logic of the program without worrying about what shape we are working with. Which area function gets called depends on the type of object (Rectangle or Circle). This type of function is called a method or a member function of the type it's associated with.

Of course, we still have to define Rectangle and Circle. The definition of Rectangle looks like this:

class Rectangle {
 public:
  int width;
  int height;
  
  int area() {
    return width * height;
  }
};

The first part of this is basically the same as struct rectangle, except for the public: line, which we can ignore for now.^[4] Just as before, we have width and height. What's new here is the area() function. This is also almost exactly the same as before, except for two things:

It's defined inside the class.
We don't need to pass a copy of Rectangle as an argument because the width and height fields are automatically available to any member function.^[5]

The definition of Circle is similar, except with the standard π r² area formula

To recap the terminology here: the class is the type definition and an object is a given instance of the class.

Inheritance #

We won't really need this in this post, but I'd be remiss if I didn't mention one of the most important features of classes, which is inheritance. The idea here is to say that a given class, say Rectangle is itself derived from a more general class, such as Shape. Anywhere you could use a pointer to Shape you can use a pointer to a Rectangle instead. For example, we could define a Shape as having an area() function like so:

class Shape {
  virtual int area() = 0;
};

Notice that we haven't provided a definition (body) for area(), instead we have the virtual keyword in front and there is = 0 in place of the body. Together these mean that all classes derived from Shape have to define area() for themselves.^[6] We then modify Rectangle to indicate that it is derived from Shape and we'll need virtual in front of area here for some technical reasons which we don't need to go into.^[7]

class Rectangle : public Shape {
public:  
  int width;
  int height;
 
  ...
  
  virtual int area() {
    return width * height;  
  }
};

The result of all this is we can now write a function which can take any shape and do stuff, as in:

void print_area(Shape *s) {
  printf("Area = %d\n", s->area());
}

If we have a Rectangle r then print_area() can be called just like you would expect:

print_area(&r);

If you've been paying attention, you'll have noticed that I said you can use a pointer to Rectangle wherever you could have used a pointer to Shape. You cannot, however, use a Rectangle wherever you would have used a Shape. If you try to assign a Rectangle to a Shape you end up with something with the properties of Shape but not Rectangle. This is called object slicing and it's usually not what you want.

Constructors and Destructors #

There's one more C++ feature we need in order to understand basic C++ memory management, and that's constructors (often abbreviated ctors) and destructors (dtors). So far we've initialized stuff just by setting the fields, but C++ lets us do more: a class can have a function that runs whenever an object of that class is created. That's not really that useful with this simple an object, but just as an example suppose we wanted to print something out for debugging purposes whenever someone created a Rectangle. Then we could do:

class Rectangle : public Shape {
public:  
  int width;
  int height;

  // Constructor
  Rectangle(int w, int h) {
     width = w;
     height = h;
     
     printf("Rectangle created with width=%d height=%d\n", width, height);
  }
  
  ...
};

The constructor also has to initialize the fields in the object, as we've done here.^[8] Then when you want to create a Rectangle you could do:

Rectangle r(10, 20);

This creates a Rectangle on the stack. If you want to create a Rectangle on the heap, you don't use malloc() but instead a new operator called new, as in:

Rectangle *r = new Rectangle(10, 20);

new tells the C++ compiler that this is an object and should run the constructor (conceptually it's like calling malloc() and then calling the constructor). If you used malloc() you would just get uninitialized memory of the right size.

C++ also supports destructors, which are functions that run before the object is destroyed. But when is an object destroyed, you might ask. Remember how I said that in C freeing an object just means that you release the memory for another use? C++, however, has a richer concept of object lifecycle: whenever a C object would just have its memory returned, C++ thinks of this as an object being destroyed. This means:

If the object is on the stack, when the object goes out of scope (e.g., when the function returns).
If the object is on the heap, when it is explicitly destroyed with delete (note: not free()).^[9] If you have a pointer to an object on the stack and it goes out of scope, you get a leak, just like in C.

A destructor gets written like this:

class Rectangle : public Shape {
public:  
  int width;
  int height;

  // Destructor
  ~Rectangle() {
     printf("Rectangle destroyed with width=%d height=%d\n", width, height);
  }
  
  ...
};

The ~ prefix indicates that it's a destructor. Note that the destructor still has access to the member variables, which is why it's able to print them out. As long as they're regular variables and not pointers, it doesn't need to do anything with them, as they'll just be destroyed when the object is finally destroyed. If they're pointers, however, the destructor needs to call delete or there will likely be a memory leak (unless the data is referenced elsewhere). In either case, the destructors of the member variables will themselves be run as part of the destruction process.

Putting it all together, if we have the following program:

Rectangle *r = new Rectangle(10, 20);
r->print_area();
delete r;

We would expect to see:

Rectangle created with width=10 height=2
Area = 20
Rectangle destroyed with width=10 height=2

You'll notice that I'm not checking for errors when I do new, unlike with C where we had to check that malloc() hadn't failed. By default, if new isn't able to allocate memory it will crash the program^[10] rather than returning an error (or rather a null pointer). The technical term for this is that new is "infallible" whereas malloc() is "fallible", thus forcing you to handle allocation failures. It's possible to tell C++ that you want new to be fallible using std::new_throw, in which case new will return nullptr (0) the way malloc() does. Infallible memory allocation is a pretty common pattern in newer languages, many of which don't even really let you detect memory failure; they just crash the program. Whether this is good or bad is a matter of opinion.

RAII #

We now have the pieces we need to significantly improve memory allocation. Let's go back to our previous program and instead of just having a raw pointer, we're going to define a class that holds the list of lines. It looks like this:^[11]

class Data {
public:
  char **lines;
  size_t num_lines;
  
  Data() {
    lines = nullptr;
    num_lines = 0;
  }

  ~Data() {
    for (size_t i=0; i<num_lines; i++) {
      free(lines[i]);
    }
    free(lines);
  }
};

This is the same data structure as before, except that we've:

Moved the local variables into the class.
Put the initialization logic in the constructor and the teardown logic in the destructor.

The rest of the program remains the same, except that we have to access lines and num_lines via the data object.^[12] Note that we never have to explicitly call the destructor, it just runs automatically when we return from the function. This may seem like a small improvement, but let's go back to the case we looked at in part I where we had an error handling block. Recall that that code looked like this:

  int status = OK;
    
  ...

    char *l = fgets(line, sizeof(line), fp);
    
    if (!l) {
      break;  // End of file (hopefully).
    }
    if (l[strlen(l)-1] != '\n') {
      status = BAD_LINE_ERROR;
      goto error;
    }
   
    ...
    
error:
  // Clean up.
  fclose(fp);
  for (size_t i=0; i<num_lines; i++) {
    free(lines[i]);
  }
  free(lines);
  return status;

We had to have the special cased and error prone error: block that did cleanup. Now let's look at (almost) the same code in C++:

  Data data();
  
  ...

    char *l = fgets(line, sizeof(line), fp);
    
    if (!l) {
      break;  // End of file (hopefully).
    }
    if (l[strlen(l)-1] != '\n') {
       return BAD_LINE_ERROR;
    }
   
    ...
    
  // Clean up.
  fclose(fp);
  return OK;

By using the destructor, we've gotten rid of the potential memory leak entirely: anything that causes data to go out of scope automatically invokes the destructor, and so the memory we've allocated gets cleaned up.^[13] We do, however, still have a leak: the file pointer fp, which gets cleaned up properly in the normal case but not in the error case. If we wanted, we could address this by making a new class to wrap fp, but C++ has already done this for us using the std::fstream, which gets used like this:

std::fstream fs("input.txt", std::fstream::in);
if (!fs.open) {
  abort();
}

fs.getline(line, 1024);

If we use std::fstream we don't need to clean up the file at all because it will just happen automatically, and the final block just looks like:

  return OK;

This style of memory management is often called "RAII", which stands for "Resource Acquisition is Initialization". RAII is not exactly winning any records for the clearest name, and mostly people just say "RAII". The idea here is that the process of creating the object (e.g., Data or fstream) allocates its resources and the process of destroying the object deallocates its resources, so as long as you have a valid copy of the object, you know it's safe to use and once the object goes out of scope, things will automatically get cleaned up. As you can see, RAII really simplifies memory management and is generally considered to be the most convenient way to do C++ memory management (though there are also vocal RAII opponents).

Note that what makes RAII work here is that the object is on the stack but it's holding resources on the heap. That way when the function returns, the object is automatically destroyed. If instead you were to allocate the object on the heap and stored a pointer on the stack, we would still have a problem. I'll be getting to how to address in a later post.

Containers #

Stuffing our list of stored lines into a class helps some, but it's not really ideal. We've had to make this new Data class and then we have to reach into the class to add new lines and to sort the lines. We could of course add new interfaces to Data but C++ has already done the heavy listing for us by providing containers. A container is basically just a fancy term for an object whose purpose is to holds some number of other objects like a list, vector, or map. Remember all_lines = [] from our original Python version? That's a container. Here's our new program rewritten with some C++ containers.

  std::vector<std::string> lines;
  std::string line;
  std::fstream fs("input.txt", std::fstream::in);

  // 1. Read in the file.
  if (!fs.is_open()) {
    abort();
  }

  while (std::getline(fs, line).good()) {
    lines.push_back(line);
  }

  // 2. Sort the list.
  std::sort(lines.begin(), lines.end());

  // 3. Print out the result.
  for (size_t i=0; i<lines.size(); i++) {
    printf("%s\n", lines[i].c_str());
  }

The key line to look at here is the following:

  std::vector<std::string> lines;

What this does is to make a "vector" called lines which is basically a self-growing container that can be indexed like an array. lines will contain an arbitrary number of objects of type string, which, unsurprisingly, is a C++ object that contains a string of characters. This is loosely analogous to the Python code all_lines = [] except that Python lists can contain mixed types of objects, as in:

all_lines = ["abc", 1]

which contains a string and an integer; this vector can only contain strings.

Containers massively simplify things because now when we want to add a line that we read in to our list of lines it's a one-liner:

  while (std::getline(fs, line).good()) {
    lines.push_back(line);
  }

This replaces all the complicated machinery we had before where we had to manually make room in lines and then make a copy of the string to add to lines, because C++ does all of that for us. Moreover, we don't need to worry about the string being too big because std::getline() will automatically grow our buffer (line) to whatever size is needed, which eliminates a lot of the error cases. However, if we did have an error for some reason, then RAII would of course clean up. For instance, the following code returns an error if lines are more than 1024 characters long.

  while (std::getline(fs, line).good()) {
    if (line.size() > 1024) {
       return BAD_LINE_ERROR;
    }
    lines.push_back(line);
  }

Because we are using RAII this is totally fine and both the file and the list of strings will be cleaned up properly.

The sort is a one-liner too, though the syntax is kind of gross. You can sort of see what's happening here, namely that we're providing the first and last items in the vector and then std::sort() figures it out. The actual details are sort of subtle and out of scope for this post.

  // 2. Sort the list.
  std::sort(lines.begin(), lines.end());

This leaves us with the last clause, where we iterate over the list of sorted lines and print them out. This code is the most similar to the previous version, differing mostly in that we don't have to remember how many lines there are because the .size() function lets you ask a vector how big it is:

  // 3. Print out the result.
  for (size_t i=0; i<lines.size(); i++) {
    printf("%s\n", lines[i].c_str());
  }

The other change is that we have to use .c_str() method to get the underlying char * to pass it to printf() because printf() doesn't know what to do with a C++ string.

This isn't really that idiomatic C++ for several reasons:

C++ has its own functions to print stuff to the console and most programmers prefer those. Those functions will also take a string directly rather than needing c_str().
In modern C++, you would use an iterator (for (auto x : lines)).

The more modern code would look like this:

  for (auto x : lines) {
    std::cout << x << std::endl;
  }

I've written it the less idiomatic way for two reasons. First, it's more familiar and I'm trying not to introduce too many new things at once. Understanding what's happening here requires a bunch of new concepts. Second, and more importantly, it illustrates something important about C++, which is that while the better modern techniques are available to you, you're not required to use them, and in fact C++ lets you do all kinds of unsafe stuff. For example:

Array-style accesses to vector elements aren't bounds checked, so if I did lines[100000] after reading one line, anything could happen, up to and including the compiler deciding to delete all your files, start mining Bitcoin, or call 911 (the technical term here is undefined behavior).
c_str() returns a pointer to whatever internal storage the string object is using to store its value (as of C++11), which means that we have to worry about all the same lifetime issues as before. For instance, if we were to return the value of c_str() from this function, that value would not be safe to use because it would be pointing to storage that had been destroyed when the string went out of scope.

The key point is that C++ provides safe ways to work with these objects, but it also lets you do all the old unsafe C stuff.

Shallow and Deep Copying #

Recall that I said above that when you assign one variable to another, C just copies the internal values. This includes structs, so that, for instance, when we do:

struct rectangle {
  int width;
  int height;
};

rectangle r = { 10, 2 };
rectangle r2 = r;

r2 just becomes a copy of r, and they're totally independent, so in the following code:

rectangle r = { 10, 2 };
rectangle r2 = r;
r2.height = 10; // I'm a square!

printf("Rectangle 1: %d x %d\n", r1.width, r1.height);
printf("Rectangle 2: %d x %d\n", r2.width, r2.height);

We would get the output:

Rectangle 1: 10 x 2
Rectangle 2: 10 x 10

The situation is no different when one of the fields in a struct is a pointer. For instance:

// Wrap strdup so that we don't have to error check every
// time we use it.
char *infallible_strdup(char *from) {
  char *retval = strdup(from);
  if (!retval) {
    abort();  // Out of memory
  }
  return retval;
}

struct rectangle {
  char *name;
  int width;
  int height;
};

rectangle r1 = { 10, 2, infallible_strdup("Rectangle 1") }; 
rectangle r2 = r;
r2.height = 10; // I'm a square!
strcpy(r2.name, "Square 1");
printf("%s: %d x %d\n", r1.name, r1.width, r1.height);
printf("%s: %d x %d\n", r2.name, r2.width, r2.height);

Attention: I added infallible_strdup() because I got tired of writing out the error checking and I thought it distracted from the main flow of the code. In a real program, you might do better.

This prints:

Square 1: 10 x 2
Square 1: 10 x 10

Wait, what? The sizes are different but the name is the same. This happens because when we did the assignment we just assigned the pointer's value not the string's value (i.e., r1.name == r2.name), so r1.name and r2.name are pointing at the same object. strcpy() just overwrites that memory, with the result that both objects end up with name = "Square". By contrast, because width and height are just values, then there are separate values in r1 and r2, as shown below:

The result of a shallow copy

This is what's often called a "shallow copy" as opposed to a "deep copy", where there would be two different strings in r1 and r2. Doing a deep copy in this case obviously requires allocating new memory for r2.name and then copying the contents of the string into it (presumably via some API like infallible_strdup). If we want a deep copy in C, we need to do it explicitly. For instance:

void copy_rectangle(rectangle *to, const rectangle *from) {
    to.name = infallible_strdup(from.name);
    to.width = from.width;
    to.height = from.height;
}

The result looks like this:

The result of a deep copy

Copy Constructors #

By default, C++ also does shallow copies, but it provides a facility that lets you do better. When you make one C++ object starting from another of the same type, the compiler invokes what's called the "copy constructor", which is a special method of the new object that takes the object you're copying from as an argument. For instance, if we just wanted to do a shallow copy of Rectangle it would look like this (recall that the unqualified names of member variables in methods just refer to the current object):

  Rectangle(const Rectangle& other) {
    name = name;
    width = other.width;
    height = other.height;
  }

This is just the same thing that happened above, but we've done it explicitly. If you don't supply your own copy constructor, C++ will make one that does a shallow copy, which is to say basically this code. But you can also provide a copy constructor that will do anything you want.^[14] For instance, here's a deep copy:

  Rectangle(const Rectangle& other) {
    // Deep copy of |name|
    char *tmp = infallible_strdup(other.name);

    // Just copy |width| and |height| because they are
    // numbers and don't point to other memory.
    width = other.width;
    height = other.height;
  }

Note that we don't need to do anything special for width and height because they aren't pointers to anything, just values. However, because we've replaced the copy constructor we do need to explicitly copy them. But for name we want to allocate new memory and copy name into it. Now let's do the do the same thing as before where we mess with the values in r2:

  Rectangle r1("Rectangle 1", 10, 2);
  Rectangle r2 = r1;
  r2.height = 10; // I'm a square!  
  strcpy(r2.name, "Square 1");
  printf("%s: %d x %d\n", r1.name, r1.width, r1.height);
  printf("%s: %d x %d\n", r2.name, r2.width, r2.height);

This has the result we want:

Rectangle 1: 10 x 2
Square 1: 10 x 10

At this point you could be forgiven for thinking that this is all just syntactic sugar. After all, copy_rectangle() and the copy constructor are basically the same code and how hard is it to just write copy_rectangle(r2, r1) instead of Rectangle r2 = r1? At some level this is true of course, in the sense that all programming languages are syntactic sugar on top of assembly, but this is very useful syntactic sugar.

Consider what happens if we have the following class:

class TwoRectangles {
 public:
   Rectangle r1;
   Rectangle r2;
}

If we now do:

TwoRectangles t1 = t2;

This will just work because the default copy constructor for TwoRectangles calls the copy constructors for Rectangle when we try to make t1 from t2. By contrast, without this feature we would need to write copy_two_rectangles():

void copy_two_rectangles(TwoRectangles *to, TwoRectangles *from) {
  copy_rectangle(&to->r1, &from->r1);
  copy_rectangle(&to->r2, &from->r2);
}

Basically, as long as you are working with objects which contain only other objects which have copying implemented correctly then they will behave properly when you try to copy them without you having to do anything special. This isn't that big an issue in a small system but once things get large it's pretty convenient not to have to think about writing all the boilerplate to recursively copy everything. As with our area() method before, the idea is to free you to focus on the program logic.

However, this only works if the object contains objects. If it contains pointers then those pointers will be copied directly as usual without invoking the copy constructor. Fortunately, C++ has an extensive set of container classes so that you can often—though not always—get away without having to store pointers in your objects. In this specific case, if we just used the C++ string class instead of C-style char *, as shown below, then the default copy constructor would work fine and we wouldn't have to do anything (which is why I showed the worse version that uses char *);

class Rectangle {
public:
  std::string name;
  int width;
  int height;
  ...

Copy Assignment Constructors #

Nerd sniping alert: this section is going to go a bit into some nitpicky C++ detail. You can safely skip it without missing the main point.

Let's go back to our above code where we use the Rectangle copy constructor:

  Rectangle r1("Rectangle 1", 10, 2);
  Rectangle r2 = r1;

What if we alter it slightly so that we construct r2 first and then assign r1 to r2:

  Rectangle r1("Rectangle 1", 10, 2);
  Rectangle r2("Rectangle 2", 10, 2);
  Rectangle r2 = r1;

This is superficially similar to the previous code but actually does something quite different. Instead of invoking the copy constructor, in this case it invokes the copy assignment operator, which is used whenever you assign one object to another. The reason that the copy constructor was invoked in the first example is that r2 [Fixed from r1 -- 2025-05-26] was still under construction, but in the second example, it's already fully constructed and so we instead invoke the copy assignment operator. In case all that's not clear, look at the following code

  Rectangle r1("Rectangle 1", 10, 2);  // Constructor
  Rectangle r2(r1);                    // Copy constructor
  Rectangle r3 = r1;                   // Copy constructor (r3 is under construction)
  r2 = r1;                             // Copy assignment operator

As with the copy constructor, the copy assignment operator can in principle do anything, but in practice what you usually want it to do is to clean up the destination object (similar to what you do do with the destructor) and then copy the source object onto it, similar to what the copy constructor would do.

Here's an example assignment operator implementation:

  Rectangle& operator=(const Rectangle& other) {
    if (this == &other) {
      return *this;
    }

    // Clean up name
    free(name);
    name = infallible_strdup(other.name);

    // Just copy the dimensions.
    width = other.width;
    height = other.height;
    
    return *this;
  }

There are two important things to notice about this code.

Self-assignment checks #

First, before we do anything else, we check to see if we are assigning to ourself, as in:

if (this == &other)

If so, we just return early without doing anything else. This may seem like an optimization but it's actually critical for correctness. To see this, take the assignment operator code and fill in the actual concrete values for a self-assignment of r1 to itself. In this case, the lines where we copy over the name look like this:

    // Clean up name
    free(r1->name);
    r1->name = infallible_strdup(r1->name);

Note that we've just freed r1->name and then right away we try to copy it. Holy use-after-free Batman!

Cleaning Up #

In the copy constructor we just assigned name = infallible_strdup(other.name), but here we have to free this.name first. Why?

The reason is that in the copy constructor we knew that the target object was uninitialized and so this.name isn't holding onto any valid memory—though it might be filled with a random pointer to nothing in particular—but when we are doing copy assignment, the target object already exists which means that it might have something in this.name^[15] and so we need to free it first to prevent a memory leak (the opposite of the use after free in the previous section).

Operator Overloading #

We just glossed over the odd syntax declaring this function:

  Rectangle& operator=(const Rectangle& other) {

What's going on here is that C++ allows for what's called operator overloading, which means that you can supply new implementations for existing "operators" like + or =. This is very useful because it allows for idiomatic code in some situations that would otherwise be confusing.

A common example here is complex numbers. These aren't built into C++, which means that it doesn't know how to add or subtract them. You can use operator overloading to provide implementations for + and - so you can write:

c3 = c1 + c2;

rather than:

c3 = add(c1, c2);

which is what you would do in C.

In this case we are overloading the default copy assignment operator implementation which would do fieldwise copy just like the copy constructor.

Why do I need this anyway? #

One natural question to ask is why we need to overload the = operator. The obvious alternative is to have the compiler run the target's destructor and then the copy constructor (after checking for self-assignment, of course).

To be honest, I don't really have a clear picture of whether this is actually infeasible or whether instead it's just a matter of maintaining maximum programmer flexibility. I've spent a bunch of time searching online and had a number of somewhat frustrating conversations with ChatGPT and the overall impression I am getting is that it would violate some pre-existing commitments in C++ (ChatGPT gave me a bunch of stuff about "object identity" and performance),^[16] but it's not clear to me how serious these issues are. It's certainly true that C++ has so much history that any new feature needs to exist within a complex web of existing constraints, so it's possible that this approach would violate one, and it often takes a lot of analysis to determine if that's true. If someone has a better! answer, email me!

The rule of three (or five) #

If you have an object for which you need to implement your own copy constructor, then you probably need to also implement your own destructor and copy assignment operator. Rectangle provides a good example:

We need to implement our own destructor to free name.
We need to implement our own copy constructor to make a deep copy of name.
We need to implement the copy assignment operator to free name in the target and then make a deep copy from the source.

In C++ circles, people talk about the rule of three which says: that if you define any one of these then you probably should define all three. In modern C++, people talk about the "rule of five" which also includes the move constructor and the move assignment operator.

Moving On #

Disclaimer: The feature I am about to describe was introduced in C++ comparatively late (by which I mean in the past 15 years) and I haven't really worked with it, so I'm writing based on what I've read online. Don't write code based on this section (or really, on the rest of this post either).

C++-11 introduced the concept of moving on assignment rather than copying. Consider the following somewhat contrived code.

void f() {
  Rectangle r1("Rectangle 1", 10, 2);
  Rectangle r2("Rectangle 1", 10, 2);
  TwoRectangles two(r1, r2);
  // r1 and r2 aren't used after this point.
  
  TwoRectangles.do_stuff();
  TwoRectangles.do_other_stuff();
  
  // r1, r2, and two are all destroyed here.
}

Under normal circumstances, transferring r1 and r2 into two would involve calling the Rectangle copy constructor to copy them into two. r1 and r2 aren't used after this point but just hang around until they go out of scope at the end of the function, where they are destroyed, at the same time as two. This isn't a correctness issue because we eventually clean up, but is wasteful because we copy them unnecessarily (including allocating new memory to copy name) even though they're only used via two thereafter.

In modern C++ you can instead move r1 and r2 into two. The details are complicated, but the high order idea is that the source of the move isn't required to continue to be usable and so you can make move more efficient than copying, in this case by just coping the pointer to name rather than allocating new memory; you just copy width and height as usual. The source is left in an "unspecified but valid state", which seems to leave a lot of room for implementation discretion.

For obvious reasons you can't just go moving stuff around any time someone assigns one variable to another, as before move was introduced in C++-11 they would have been copied and it would be very surprising to have the source variable suddenly become unusable. There are some specific circumstances where the compiler will do a move automatically, but otherwise you have to tell it you want a move by wrapping the source in a std::move() wrapper, like so:^[17]

foo = std::move(bar);

Importantly, nothing stops you from using the source object after moving it, so in this case you could use bar, but with unpredictable results. You probably don't want to do this, because, as noted above, it is left in a "valid but unspecified state", but the compiler assumes you know what you're doing (in a future post we'll look at Rust, where using a value after a move is explicitly forbidden and the compiler will stop you).

Internal References #

In many cases you can implement move with a shallow copy by just copying the fields, because we don't need the original version to be valid. A shallow copy is obviously more efficient, but there are some situations where it doesn't work. One common example is when the object contains an internal reference. Consider the following example:

class Internal { 
  int a;
  int* ap;
  
  Internal(int i) {
    a = i;
    ap = &i;
  }
}

Now ap is a pointer to the internal field a. This is obviously a contrived example, but there are real situations where it makes sense.

The result is that if you were to just assign the fields of one Internal to another, then ap will end up pointing to the field a in the original object not the new one.

A shallow copy of an object with an internal pointer

If the original is destroyed, ap points to free memory, which brings us back to use-after-free problems. Obviously, if you are using this kind of class you will need to provide a smarter move assignment implementation; the point is just that you need to do that.

C++ is full of this kind of situation, where the compiler allows things that are unwise or even dangerous and you're just supposed to know to not do them. To a great extent this is a result of the way C++ developed: it used to be that these were the only way to do things and so they're allowed even though we have better ways now. When we get to Rust we'll see that it just doesn't let you do dangerous stuff—unless you ask it very nicely—because it was designed from the ground up to be safe.

Next Up: Smart Pointers #

RAII is a powerful technique but what we've seen so far is only a partial solution. Things are (mostly) fine when working with objects but if we want to work with pointers, as in our Rectangle example, then we need to implement custom copy constructors, copy assignment operators, etc. if we want them to be safe. This is true even if we want to store on object on the heap but have a pointer on the stack. In the next post I'll be covering a technique called "smart pointers" that helps address these problems.

I've hopefully learned my lesson about not committing ahead of time to the length. ↩︎
In fact, the C program we showed in part I will almost compile, except that in C, you can implicitly cast from void * to any pointer type T *, whereas in C++ you cannot, so you would need to cast the return value of malloc() and realloc(). ↩︎
At least as long as the assignments are of the same type. If you try to assign two values of different types, such as a signed to an unsigned integer , then C may try to convert them, but they still will end up as discrete values. ↩︎
What's going on here is in C++ data and methods are "private" by default, which means they can't be accessed from outside the class. The public: line says to allow access. ↩︎
Note that in some languages, such as Python or Rust, you explicitly have to reference member variables with something like self.width, but that's not how C++ works. ↩︎
It's possible to provide a default implementation that derived classes can override. ↩︎
A virtual function is one which is associated with the type of object rather than on the type of the pointer pointing to it. This is what allows us to have a Shape * where Rectangle and Circle have different behavior. ↩︎
Note that I had to name the function arguments w and h because in C++ the bare width means "the member of the object with the name width". This is one reason why some other languages explicitly require you to specify self. or this->. ↩︎
Do not attempt to mix malloc()/free() with new/delete. Who knows what will happen, but it's probably not good. ↩︎
Technically, it raises an exception which you could catch, but if you don't the program crashes. ↩︎
Don't hate me for not using initialization syntax. ↩︎
Common practice in working with classes would actually be to make these fields "private" so they couldn't be accessed by the rest of the code, but that's not necessary for the point I'm trying to make here. ↩︎
Incidentally, my original code was main() and used exit(), but exit() turns out not to fire the destructor, because it never returns; the program just terminates. ↩︎
There are, however, some rules about what's safe to do. ↩︎
The alternative is that it this.name is assigned to nullptr, meaning that there is nothing there, but free() handles this case correctly. We don't need to handle the case because it can't happen in a correctly constructed object. ↩︎
After I convinced it that I wanted the compiler to do it rather than do it myself. ↩︎
Don't ask what this does; you're better off not knowing about "rvalues", "lvalues", and "xvalues" ↩︎

Understanding Memory Management, Part 1: C

2025-01-13T00:00:00Z

UPDATED: 2025-02-15: Fixed some bugs in the examples and pointed out that you don't usually just want to panic on memory allocation failure.

I've been writing a lot of Rust recently, and as anyone who has learned Rust can tell you, a huge part of the process of learning Rust is learning to work within its restrictive memory model, which forbids many operations that would be perfectly legal in either a systems programming language like C/C++ or a more dynamic language like Python or JavaScript. That got me thinking about what was really happening and what invariants Rust was trying to enforce.

In this series, I'll be walking through the logic of memory management in software systems, starting with the simple memory management in C and then working up to more complicated systems. This series isn't intended to be a tutorial on how to write C, Rust, or any other language; rather the idea is to look at how things actually work under the hood at a level that we usually ignore when all we are doing is trying to write code.

How Programs Use Memory #

Consider the following program, written in Python

all_lines = []

f = open("input.txt")
for l in f:
    all_lines.append(l.strip())

all_lines.sort()
for l in all_lines:
    print(l)

This program does something very simple, namely, it reads input from the file one line at the time, then sorts the lines, and prints out the lines in sorted order. So if input.txt has the following contents:

jim
bob
deb
carol

The output will be:

bob
carol
deb
jim

However, there is something complicated hiding under the hood: because we don't know the sort order of the lines in advance, we have to store all of the lines we've read until we know that we've seen all of them, and only then can we write them in sorted order.^[1] If we're going to store all the lines, they have to go somewhere, which is in the computer's memory.

Storing a List #

Conceptually, a computer's memory is just a giant table of values, with each value having an address. For convenience, let's assume that entries are numbered from 0 and each entry can hold a single character. Thus, if we want to store the string "computation", we end up with something like:

Memory Address	Value
0	c
1	o
2	m
3	p
4	u
5	t
6	a
7	t
8	i
9	o
10	n

Or, in a more compact notation:

Starting Address
0           | c | o | m | p | u | t | a | t | i | o |
10          | n |

The way to read this is that each cell is a memory location and on the left we have the starting address for each row, so the p is at address 3 (the fourth column in the first row).

With this in mind, how do we store the data from this file into memory. The obvious way is something like this, which immediately reveals that we have a problem:

0           | j | i | m | b | o | b | d | e | b | c |
10          | a | r | o | l |

If we just concatenate the values in memory, how do we know where one line ends and the next begins? For instance, maybe the first two names are "jim" and "bob" or maybe it's one person named "jimbob", or even two people named "jimbo" and "b". Obviously, we need some way to keep track of the memory regions associated with individual values.

There are a number of alternatives here, but let's just do something obvious, which is to prefix every value with its length, like so:

0           | 3 | j | i | m | 3 | b | o | b | 3 | d |
10          | e | b | 5 | c | a | r | o | l |

If you know that an entry starts at address X, then you can print out that entry in the obvious way:

address = X
length = *X
address = address + 1
while length > 0 {
    address = address + 1
    print *address
}

For non-C programmers, the notation *X means "take the value at memory address X" (technical term: dereferencing X) so the second line is setting length to be whatever is in X and the 5th line is printing whatever is currently stored at address. So, what happens here is that we first read the length of the current line out of address, then count down one character at a time.

So far so good, but what if we want to print out the whole list? The obvious thing to do is just to repeat the process above, but now we have a new problem, which is knowing when to stop. Remember that the memory is a giant table and we're just showing the relevant portion of it. In reality, we have:

0           | 3 | j | i | m | 3 | b | o | b | 3 | d |
10          | e | b | 5 | c | a | r | o | l | O | T |
20          | H | E | R |   |   | S | T | U | F | F |
30          | . | . | . |

This is just a new version of the same problem, which is we don't want want to read off the end of the list. This requires knowing where does our list end and the other stuff in memory begins. One obvious thing to do is to prefix the list with the amount of memory that it consumes, like so:

0           | 19| 3 | j | i | m | 3 | b | o | b | 3 |
10          | d | e | b | 5 | c | a | r | o | l |

Now we can write a program to go over the whole list, like so:

total_length = *X
address = address + 1
while total_length > 0 {
    length = *X
    address = address + 1
    total_length = total_length - (length + 1)
    while length > 0 {
        address = address + 1
        length = length - 1
        print *address
    }
}

Note that this is a self-contained object. As long as you know where it starts and what type it is (i.e., a list of strings), then you can read it out knowing just the starting address X. I.e., we can have a subroutine/function, like so:

function print_list(X) {
    total_length = *X
    address = address + 1
    while total_length > 0 {
        length = *X
        address = address + 1
        total_length = total_length - (length + 1)
        while length > 0 {
            address = address + 1
            length = length - 1            
            print *address
        }
    }
}

However, we do have to remember where the object starts, as it's not going to always start at 0 (what if we have two lists, or a list and something else?). So how do we do that?

The Stack #

Up till now I've been acting like memory is just an undifferentiated table, but the reality is much more complicated. Although from a hardware perspective the memory is largely undifferentiated there is a conventional way to lay things out, as shown in this diagram I borrowed from Geeksforgeeks:

To orient yourself, address zero is at the bottom of the diagram and higher addresses are at the top. The program is actually split up into two pieces: the program itself ("the text segment") There are also two different parts of memory where the program's data is stored call the "stack" and the "heap". Very roughly speaking, they are used like this:

The stack is used to store fixed-size data that is part of the local context of the function.
The heap is used to store arbitrary-sized data or data that survives past the lifetime of a function.

For instance, in our print_list() function above, total_length, address, and length are fixed size values (effectively integers big enough to hold a memory address), so they can be allocated on the stack. By contrast, the list of strings is arbitrary sized and in fact of a size that's dependent on the file we are reading in, and so is allocated on the heap.

When we call a function in a compiled language like C (or Rust), the compiler makes sure you have enough space on the stack to store all the variables it needs and makes room for it in memory. This is called a "stack frame". So, print_list() would have a stack frame big enough to store all three of these values just laid out end to end, like so:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total_length  |   address     |   length      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Importantly, the layout here is fixed (and dictated by the compiler) and so we don't need to have any metadata telling us how long things are; the compiler just knows.

The stack is laid out contiguously in memory, with each function call extending the stack by enough room for the stack frame associated with that function, which depends on which function it is. For technical reasons, the stack grows "downward" in memory towards smaller addresses, so the callee has a lower address than the caller. The following figure shows a simple example.

The stack before, during, and after simple function call

At the left of the figure, we see the situation where we are in the function f(). The stack just consists of the stack from for f(). If f() calls g() then we add a new stack frame for g() (technical term: pushing onto the stack), shown in the middle of the figure. Then when g() returns, the stack shrinks (technical term: popping the stack), leaving us back where we were before. Note that if f() called a different function h(), it would end up where the g() frame was before, but might be of different size, depending on how many local variables it had.

You should now be able to see why the stack isn't suitable for variable-sized objects: we need to allocate the stack frame when the function is called, and we can't do that if we don't know how big the variables in the stack will be. It's possible to grow stack frames but not convenient, so instead, we need to allocate them somewhere else, which is what the heap is used for.

The Heap #

Conceptually the heap is just a big pile of memory that we can allocate space out of. In many languages (e.g., Python or JavaScript) this is done automatically when you make an object, but in C, you have to do memory management by hand. This is done with the malloc() API, which is used like this:

space = malloc(100);

This works exactly like you would expect, namely reserving a block of 100 bytes on the heap that the caller can then use however they want. The return value from malloc() is the memory address of the allocated region. Internally, of course, malloc() has to do some bookkeeping to know which memory is in use and which is not. There are a large number of different data structures that can be used here, but essentially any technique will involve using some of the heap for that bookkeeping, leaving the rest available for allocation.

Memory Management in C #

With that background, let's try rewriting our program in C, where we have to do the memory management by hand. This gets a lot more complicated, so let's take it in pieces.

Read in the file. #

First, we have to read in the file.

  FILE *fp = fopen("input.txt", "r");
  char line[1024];
  char **lines = NULL;
  size_t num_lines = 0;

  if (!fp) {
    abort();
  }

  // 1. Read in the file.
  while (1) {
    char *l = fgets(line, sizeof(line), fp);
    if (!l) {
      break;  // End of file (hopefully).
    }

    // Make room in the list of lines.
    if (!num_lines) {
      lines = malloc(sizeof(char *));
    } else {
      lines = realloc(lines, (num_lines + 1) * sizeof(char *));
    }
    if (!lines) {
      abort(); // We are out of memory so panic.
    }

    char *copy = strdup(l);
    if (!copy) {
      abort(); // We are out of memory so panic.
    }
    lines[num_lines] = copy;
    num_lines++;
  }

We start by opening the input file, in this case input.txt. Then, as before, we're going to iterate over the lines in the file and add them to our list of stored lines. This is accomplished by our while loop.

We can read the line in using the fgets() function, which reads a line (defined by ending in a \n newline character) out of the file fp into the buffer (memory region) associated with line.

  char line[1024];

  ...
  
  // 1. Read in the file.
  while (1) {
    char *l = fgets(line, sizeof(line), fp);
    if (!l) {
      break;  // End of file (hopefully).
    }

What's a buffer? #

For those of you who haven't heard the term before, a buffer is just programmer jargon for some piece of storage used to hold data temporarily, as in this case case where we're reading in a line of data and then quickly doing something with it. It's also the name for this doodad which is responsible for stopping trains which don't stop on their own at the end of the track.

From Wikipedia by User:Orderinchaos - Own work, CC BY-SA 3.0, Link

There's already something sus here, though. Did you notice the line char line[1024]? This is C notation for "make a buffer called line which is long enough to hold 1024 characters". As noted before, line has to be fixed size and 1024 is just an arbitrary number that's hopefully large enough to hold any line in the file.^[2] But what if one of the lines is longer? In that case, fgets() will break up the line into two pieces, causing the program to be incorrect. The right way to do this would actually be to keep reading until we had a full line, but this would make the program even more complicated, so we'll just live with the defect, seeing as it's an example program.

fgets() returns a pointer to the input buffer if successful and a zero value (NULL) at the end of the file (or any error, actually), so when we test for l, we are actually testing for the end of the file, at which point the loop exits.

At this point, we have the next line of the file in line, but we overwrite that buffer every time we read a new line from the file, so we need to store it somewhere. We use the lines variable for this, which is defined as:

  char **lines = NULL;
  size_t num_lines = 0;

This notation can be a bit hard to read for non C programmers, but briefly * means that something is a pointer, which is to say that it's something that holds a memory address. ** means that it's a pointer to a pointer, which is to say that lines holds the address of a block of memory that is itself full of values that themselves are memory addresses, in this case the individual stored lines. num_lines stores the number of lines that we have in memory.

We can see this in action by looking at the next block of code:

    // Make room in the list of lines.
    if (!num_lines) {
      lines = malloc(sizeof(char *));
    } else {
      lines = realloc(lines, (num_lines + 1) * sizeof(char *));
    }
    if (!lines) {
      abort(); // We are out of memory so panic.
    }

    char *copy = strdup(l);
    if (!copy) {
      abort(); // We are out of memory so panic.
    }
    lines[num_lines] = copy;
    num_lines++;

Storing a copy of line is a two-part process:

Make a copy of the line itself.
Store the pointer to that line in lines.

However, in order to store that pointer, we first need to make room in lines, which means allocating some memory. This happens on the two lines at the start of this snippet. There are actually two cases here:

Lines is empty (nothing is stored), which happens at the start.
Lines is non-empty but doesn't have enough room.

We distinguish these by looking at num_lines which starts at 0. In the former case, we allocate enough memory for a single line, like so:

      lines = malloc(sizeof(char *));

This says "make enough room to hold the address of a single string", and is nothing we haven't seen before.

The latter case is more complicated, however, because we already have something in lines, it's just that there's not (necessarily) enough room in memory to add another value. This means we (may) need to

Allocate enough memory to hold the new number of values.
Copy over the current contents of lines into the new memory region.
De-allocate the original memory.

What are all the parentheticals doing here? The answer is that the block of memory pointed to by lines may already be big enough. When you call malloc(size) the system guarantees that the returned pointer is at least big enough to hold an object of size size—assuming that the allocation succeeds—but it's allowed to be larger. This could happen for a number of reasons (see How Malloc Works below for some more background), but one of which is to facilitate exactly this case: if people want to resize an object frequently, as we are doing here, then it's not efficient to have to copy the contents of the object over and over again. Instead, you can allocate more space than the programmer asked for and then when they ask for more, just say "ok" without taking any other action.^[3] All of this is handled automatically by the realloc() function call.^[4] At the end of this process lines may or may not have the same value from what you passed into realloc. What matters, though, is that the memory that lines points to has the same contents as before, and that's what realloc() guarantees.

It's also possible that the memory allocation will fail, for instance if the computer is out of memory. In that case, lines will be set to NULL and we need to abort:

    if (!lines) {
      abort(); // We are out of memory so panic.
    }

I'm just calling abort() which makes the program crash, but you could do something more sophisticated here, such as having the function fail and let some higher level handle it, either via an orderly shutdown of the program or actually trying to recover enough memory to let the program survive. The right thing to do here was fairly hotly contested on the Hacker News thread for this post, but in my experience most programs crash. [2025-02-15 -- added]

Now that we have room in lines we can store a copy of the actual line we've read in, but first we have to make a new buffer to store it in (remember that line will be overwritten). We can do that with the strdup() function call, which makes a copy of a string, allocating new memory as needed:

    char *copy = strdup(l);
    if (!copy) {
      abort(); // We are out of memory so panic.
    }

Here too, we can run out of memory, so we need to check for copy being NULL.

Finally, we can append the copied line to the end of lines and increment the number of stored lines:

    char *copy = strdup(l);
    if (!copy) {
      abort(); // We are out of memory so panic.
    }

The diagram below should help provide an understanding of the data structures here:

Data structure for stored lines.

On the left we have the lines variable itself, which is stored somewhere on the stack. It contains the address of the memory we have allocated to store the list of lines, namely address 1024. That memory region is shown in the middle of the diagram. Finally, on the right we have the individual regions for each stored line. The memory region for lines stores their addresses, each laid out one after the other. Note that there's no variable on the stack which points to these regions, they're just pointed to by the addresses stored in the region pointed to by lines.

Sorting the Lines #

The next thing we do is to sort the lines. This is done by the qsort() library function.

  // 2. Sort the lines.
  qsort(lines, num_lines, sizeof(char *), compare_string);

qsort() is kind of hard to use because it's designed to sort a list of any kind of object of any size. This means that you have to pass:

The pointer (address) to the first object in the list (in this case lines)
The number of objects in the list (num_lines).
The size of the objects sizeof(char *). In this case, that's the size of a pointer to a string.^[5]
A comparison function which tells qsort() the sort order for two objects. I'm going to skip over the details here.

qsort() sorts its arguments in place, so this means that after it's done, lines is sorted, like so:

Data structure for sorted stored lines.

Importantly, the only thing that's changed here is the values in the middle memory region, referenced by lines. The actual strings are unchanged and are in the same memory regions; we've just rearranged the pointers in lines to point to the strings in the right order. Note that that order is not given by the numeric order but rather by the lexical order of the strings. That's convenient, but actually required, because qsort() doesn't know anything about the objects it's sorting; it just knows how to pass them to the comparison function, so all it can do is manipulate its own data as if the objects were numbers, whatever their actual semantics.

Printing the Results #

After all this, we're ready to print the results. This is comparatively simple, just iterating over the entries in lines and printing the corresponding strings:

  // 3. Print the lines.
  for (size_t i=0; i<num_lines; i++) {
    fputs(lines[i], stdout);
  }

One thing you may be wondering about here is how we know how long each line is, as we haven't stored any length information. The convention in C is actually to have each string end with a byte with the value of 0, usually written as \0. This is pretty universally agreed to have been a bad idea, but we're taking advantage of it here because it means that the strings are self-contained.

Cleaning Up #

Finally, we want to clean up. In this simple program, that's not really required because when a program terminates the operating system automatically reclaims its resources, including memory, but this function might be used by some bigger program, in which case we'd want to reclaim the memory used by the list of strings, as well as close the open file (remember input.txt?).

If this function were to return without cleaning up, it would create what's called a "memory leak". Remember that the only variable in our program that knows about any of this memory is lines, which points to the list of pointers for the individual stored lines. lines is on the stack and will be lost when the function returns, so if the function returns without cleaning up, then there is no program variable pointing to any of this memory and it's just lost.^[6] The result of a memory leak is that the leaked memory isn't available for new allocations but also can't be used because there's nothing pointing to it. If the program runs long enough and has a big enough leak, you can eventually accumulate enough leaked memory to affect the program function or even cause it to run out of memory, so you want to clean up. This is one reason why it often works to restart a program that seems stalled.

In C, memory is freed using the free() function, which takes the pointer to be freed. Here's what the cleanup looks like:

  // Clean up.
  fclose(fp);
  for (size_t i=0; i<num_lines; i++) {
    free(lines[i]);
  }
  free(lines);

Note that we need to free the stored lines before we free lines because once we've freed lines nothing points to the stored lines and so there's no way to free them (remember, we need their addresses). This means we need to iterate through lines freeing each individual allocation and then only when we're done freeing lines itself. Recall that all the local variables will just be deallocated when the function returns. However, this doesn't mean that the things they point to are deallocated, just that the storage used by the variable itself is reclaimed.

Error Handling #

Because this is demonstration code, I've chosen to ignore the case where a line is longer than 1024 characters, but what if we wanted to handle that instead? You can detect this case with fgets() by checking to see if you have a newline at the end of the buffer^[7]

    char *l = fgets(line, sizeof(line), fp);
    
    if (!l) {
      break;  // End of file (hopefully).
    }
    if (l[strlen(l)-1] != '\n') {
      return BAD_LINE_ERROR;
    }

The problem with this code is that it has a memory leak: if we have already read in some of the lines, then we'll leak lines and whatever lines we read in. In order to avoid the leak, we need to run our cleanup routines. Once common way to handle this is to have an error block that we execute. For instance:

  int status = OK;
    
  ...

    char *l = fgets(line, sizeof(line), fp);
    
    if (!l) {
      break;  // End of file (hopefully).
    }
    if (l[strlen(l)-1] != '\n') {
      status = BAD_LINE_ERROR;
      goto error;
    }
   
    ...
    
error:
  // Clean up.
  fclose(fp);
  for (size_t i=0; i<num_lines; i++) {
    free(lines[i]);
  }
  free(lines);
  return status;

The goto instruction here just says to go to the line labelled error.

This works but is error prone: you need to note every case where the function might return and jump to the right error block. Moreover, the error block needs to be able to clean up after any kind of error, so, for instance, it needs to be able to handle when lines = NULL (fortunately, free() handles this case automatically). Finally, if you forget to set the status value, then you are incorrectly returning an OK status even if there was an error.

Locally Scoped Allocations #

You might ask why you can't just free all the memory that was allocated by a function when the function returns rather than just the memory on the stack? Then we wouldn't have to do all of this stuff where we explicitly free everything.

There's an obvious answer to this question: some functions intentionally allocate memory and don't clean it up. An obvious example here is the strdup() function we used above. Internally, strdup does something like this:

char *strdup(const char *str) { 
  size_t len = strlen(str);
  char *retval = malloc(len);
  if (!retval) {
    return NULL; 
  }
  strcpy(retval, str);
  return retval;
}

If we automatically freed all memory that was allocated by the function, then we would free retval before returning, at which point the caller would be left with a pointer to memory that has been freed, which is clearly a problem. In fact, it's the source of a common security vulnerability called use after free. Clearly we would need something more sophisticated than just freeing everything that was allocated in the function when it exits.

What you actually want is the compiler to know when objects are intended to outlive the function and when they are not, but actually distinguishing these cases is very difficult in C, at least without help from the programmer, as we will see in the rest of the series. In fact, making this kind of analysis possible is one of the the main motivating design choices for much of the Rust memory model.

How `malloc()` works #

So far we've just been treating malloc() as a kind of black box, and that's generally fine for most programming tasks, but it's helpful to have some sense of what's going on internally. The first thing to realize is that malloc() isn't magic. In fact, you can write your own memory allocator in C (Firefox, for instance, uses a custom allocator).

At a very high level, you should think of malloc() as having access to one or more large contiguous blocks of memory, which it then dispenses on demand. On a very simple computer, malloc() would just have access to the entire memory of the machine, but on a modern multiprocess operating system, it gets chunks of memory from the operating system. For our purposes, let's easiest to think of it as having a big contiguous chunk of memory to work with. As I said, we usually wouldn't start at memory location 0, so we'll just assume the block starts at 1000.

The figure below shows the situation after a single allocation of size 200, with the allocation being red and the unallocated space being blue. What's happened here is just that malloc(200) just picked the first available memory region, which is at the start of the block because no memory has been allocated.

1: 1000-1199

Unallocated

The allocation starts at address 1000 and goes to address 1199, so malloc() just returns the address 1000, which points to the start of the allocated region.

The next figure shows the situation with two more allocations, one of size 400 and one of size 200. Again, this is what you'd expect: the allocator just picks the lowest available region. As noted above, a real allocator would probably leave some extra space to facilitate growing the allocation but we're trying to keep things simple for the purpose of examples. Designing fast memory allocators is a whole (complicated) topic all on its own.

1: 1000-1199

2: 1200-1599

3: 1600-1799

Unallocated

So far so good, but now what happens when we free allocation #2? The result is shown below.

1: 1000-1199

Unallocated

3: 1600-1799

Unallocated

We have a 400 byte sized hole of free memory. If we try to do another 200 byte allocation, it will work fine, like so:

1: 1000-1199

4: 1200-1399

Unallocated

3: 1600-1799

Unallocated

But if we now try to allocate another 400 bytes, it obviously won't fit, so we need to go into higher memory.

1: 1000-1199

4: 1200-1399

Unallocated

3: 1600-1799

Unallocated

4: 2000-2399

Unallocated

As the program runs longer and memory is allocated and freed you tend get lots of small holes that can't be filled with big allocations, and so you have to allocate higher and higher memory regions. This is called fragmentation. In the extreme, you can get to the point where you can't allocate new memory even though there's actually plenty of free space; it's just not in a convenient form. There are techniques for avoiding this kind of fragmentation as well as for allocating memory more efficiently, but they're too advanced to cover here.

How does `malloc()` get its memory? #

As I said above, malloc() gets chunks of memory from the operating system. Remember that your program has to share the computer, including its memory, with other programs and the operating system is responsible for arbitrating which program has which chunk of memory. Conceptually this is actually somewhat like malloc() except that malloc() calls some system API (for instance, mmap() to request memory from the operating system.

Note that modern systems all have virtual memory, systems in which the system automatically moves ("swaps") data in and out of the physical memory and onto disk so that programs can allocate more space than is in the hardware of the system. In order to this, the operating system may have to move stuff around in physical memory, so it maintains a mapping from the address the programs use to the actual physical location in memory. In a future post, I may cover virtual memory in more detail, but no promises.

A natural question to ask is why we can't just move things around to accommodate the holes? The reason is that the pointers stored in the program literally just point to the memory addresses where the allocations are stored. So if (for instance) we were to slide allocation #3 over to the right to make room for allocation #4, then whatever pointer was returned from the initial malloc() for #3 would now point somewhere in the middle of allocation #4, which is obviously a problem. The compiler doesn't keep track of the variables holding the pointers, so it has no way to go back and readjust them. The key thing to realize here is that all that malloc() and free() are doing is bookkeeping: the allocator remembers which memory is currently in use and then hands out pointers to regions that aren't currently in use as needed. This naturally raises the question of how the allocator does the bookkeeping. How does it remember which regions are in use and which aren't? The obvious answer is the right one: the allocator reserves some of the memory it has to work with for this kind of bookkeeping metadata, at minimum:

The size of each allocation (so it can be freed)
The regions that are currently free, for instance the top of the highest allocation and the addresses of the the freed holes.

When you call malloc() the allocator finds a suitable region and allocates it. When you call free() it adds it to the list of holes (or adjusts the highest allocation value if it's the highest allocation).

Interestingly, it's not always necessary to store a list of every chunk of allocation memory. You can do this, but that means you need some data structure that lets you look up the allocations from their addresses. A common thing people do instead is to store the per-allocation metadata as a header right before the allocated region. The header contains the size of the allocation and maybe some other stuff. For instance, the first allocation above might look like this:

1: 1100-1299

Unallocated

Instead of returning 1000, in this case malloc() would return 1100. (I've drawn it as 100 to make the figure more readable, but hopefully you're not wasting 100 bytes of overhead on every allocation.) Then when you call free(1100) the allocator would subtract the size of the header and deallocate the whole region from 1000-1299. The reason this works is that free() requires knowing the memory address anyway, so there's no need to store it. If you call free() on some region of memory that wasn't returned from malloc() the results are likely to be disastrous, because free() has no way of knowing that this is a mistake and will just treat whatever is right before the pointer you passed in as the header. If that data is attacker controlled, it can easily lead to a vulnerability.

Multiple References and UAF #

Let's consider a slight modification of the function we've been looking at, in which along with printing out all the lines, we instead return the last line in sort order.^[8] With a lot of trimming, the function might look like this:

char *find_smallest(const char *filename)
{
  ...
  
  // 2. Sort the lines.
  qsort(lines, num_lines, sizeof(char *), compare_string);
  largest = lines[num_lines - 1];
  
  ...
  
  // Clean up.
  fclose(fp);
  for (size_t i=0; i<num_lines; i++) {
    free(lines[i]);
  }
  free(lines);

  return largest;
}

This function gets called like this:

char *largest = find_largest("input.txt");
printf("%s\n", largest);

The experienced C programmer will immediately note that this code has a serious bug, because we are trying to use the memory pointed to largest after we have free()d it. When the calling function tries to use largest, there are no guarantees at all about what will happen. This is called a use after free (UAF) bug. For example, the allocator might have reallocated the memory in response to some other call to malloc(), in which case it is now full of some other data. Of course, it's also quite likely that the region is still unused and has the same contents as before; it's just that the allocator added it to the list of holes. In this case, the program may work fine under test but then fail unpredictably later when some change to your code causes allocations to happen differently and suddenly largest points to some memory reason being used for something else.

The reason this is all possible is that in C pointers are just values that hold the memory address; effectively they're just numbers and they behave like numbers. So if you assign a pointer value to another variable, now you have two variables that point to the same thing (i.e., they have the same value). When we call free on the first copy of the variable, that doesn't have any effect at all on the other copy (or on the first one, for that matter). It just changes the state of the memory region addressed by the variable. Once you've called free(x) you're still left with whatever is in x, and nothing in C stops you from using it; it's just illegal to do so, and it's your job not to, or else.

Next up: C++ #

As you have probably gathered by now, managing memory yourself is a huge amount of work, which is one reason why C programs have so many memory issues. In the next post in this series, we'll be taking a look at C++, which has some features that make things a bit better, at least some of the time.

This code actually stores the lines in unsorted order, then sorts them, and then finally writes the output, but you could also store them in a sorted data structure. Either way, you need to store all of the lines. ↩︎
C99 supports a feature called "variable length arrays", but they don't automatically grow the way a Python array does, so that doesn't help us much. There seems to be a lot of sentiment that they are a misfeature. ↩︎
If you know you're going to be doing a lot of reallocation like this, many people will themselves overallocate, for instance by doubling the size of the buffer every time they are asked for more space than is available, thus reducing the number of times they need to actually reallocate. I've avoided this kind of trickery to keep this example simple. ↩︎
In reality, you can pass a NULL to realloc() for the existing memory and it will just allocate new memory, but I'm handling the cases separately for pedagogical reasons. ↩︎
In C, pointers to different kinds of objects can be different sizes. ↩︎
This isn't technically true because the memory allocator has kept track of what memory has been allocated, but the allocator doesn't know that we should have cleaned up (for instance, we might have stored the value in lines somewhere) and so it can't clean up for us. ↩︎
For the nitpickers out there, this will also catch the case where the last line in the file doesn't end in a newline. ↩︎
Obviously you don't need to sort the lines in order to do the largest one, but this is necessarily an artificial example. ↩︎

Why it's hard to trust software, but you mostly have to anyway

2024-12-28T00:00:00Z

[Edited to change the title and subtitle -- 2024-12-28].

Two children under a trenchcoat. Image from ChatGPT.

My long-time collaborator Richard Barnes^[1] used to say that "in security, trust is a four letter word", and yet the dominant experience of using any software-based system—which is, you know, pretty much anything electronic—is trusting the manufacturer. Not only is there no meaningful way to determine what software is running on a given device without trusting the device, even when you download the software yourself, verifying that it's not malicious is extraordinarily difficult in practice and mostly you just end up trusting the vendor anyway. Obviously, most vendors are honest, but what if they're not?

A good motivating case here is secure messaging apps like iMessage, WhatsApp, or Signal. People use these apps because they want to be able to communicate securely and they are willing to trust them with really sensitive information. In fact, a large part of the value proposition of a secure messenger is that not even the vendor can see your communications. For instance, here's what Apple has to say about iMessage and FaceTime.

End-to-end encryption protects your iMessage and FaceTime conversations across all your devices. With watchOS, iOS, and iPadOS, your messages are encrypted on your device so they can’t be accessed without your passcode. iMessage and FaceTime are designed so that there’s no way for Apple to read your messages when they’re in transit between devices. You can choose to automatically delete your messages from your device after 30 days or a year or keep them on your device indefinitely. Messages sent via satellite also use end-to-end encryption to protect your privacy.

This security guarantee critically depends on the app behaving as advertised, which brings us right back to trusting the vendor.

"But what about open source software?" I hear you say. "I'll just review the source code and determine whether it's malicious".

I would make several points in response to this. The first is: "LOL". Any nontrivial program consists of hundreds of thousands to millions of [2024-12-28 -- fixed typo] lines of code, and reviewing any fraction of that in a reasonable period of time is simply impractical. The way you can tell this is that people are constantly finding vulnerabilities in programs, and if it were straightforward to find those vulnerabilities, then we would have found them all. You're certainly not going to review every program you run yourself, at least not in any way that's effective. And that's just the first step: the supply chain from "source code available" to "I actually trust this code" is very long and leaky. Even if you did review the source, most software—even open source software—is actually delivered in binary form (when was the last time you compiled Firefox for yourself?) so what makes you think the binary you're getting was compiled from the source code you reviewed?

Obviously, this is a bad situation if what you're using software to do sensitive stuff—which, again, pretty much everyone is—and there's been quite a bit of work on the general problem of being able to give people more confidence in the software they're running. It's far from a solved problem, so what I'd like to do here is give you a sense of the problem, hard it is, the solution space that's been explored, and how far we are from a real solution.

Checking Software Provenance #

As a warm-up, let's look at the problem of verifying downloaded software (e.g., via your Web browser). This is a much easier problem because we're trusting the publisher not to provide malicious software; we're just trying to ensure that the software we got is what the publisher intended.

The Basic Supply Chain #

For reference, here's an example of a relatively simple software supply chain with just a single code author.

A simple software supply chain

The process starts with the vendors engineers developing the code. Typically this is done on their desktop (or laptop) machines, with the engineers collaborating via some code repository site (usually GitHub. When engineer A makes a change to the code, they publish it on GitHub and then engineers B, C, etc. update their local copy.

When it's time to build a release, a number of things can happen, including:

Some engineer builds it on their local machine (step 2(a) above)
The engineers tag the release on GitHub, prompting it to build a release (step 2(b) above).

The release then gets uploaded to the vendor's website, which is probably hosted on some cloud service like Amazon or Netlify. You can also host the binaries on GitHub. In principle, users could just download the binaries directly from your site (or GitHub) but it's common to instead use a content distribution network (CDN) like Cloudflare or Fastly which retrieves a copy of the binary once, caches it, and then gives out copies to each user. CDNs are designed for massive scaling, thus saving both load on your servers and cost.

One thing you should notice right away is how many third parties are involved in this process. Each of these is an opportunity for corruption of the code on its way from the developers to the user.

Code Signing #

The obvious "right thing" approach to software authentication that everyone comes up with is to just digitally sign the package. This provides both integrity (ensuring things weren't changed) and data origin authentication (telling you who the package is from). Moreover, signed objects are self-contained, so, for instance, you can sign your package and then put it up for download on someone else's site (or, in the diagram above, a CDN) and users will still be able to verify it's from you. These is a pretty good sounding set of properties and unsurprisingly, both MacOS and Windows support signed applications.

The basic idea here is that when you install a piece of software you get a dialog like this (on Windows):

Windows code signing dialog. Image from Sectigo.

Or alternately, maybe you just get warning:

Mac unsigned binary dialog. Image from Dennis Babkin.

Here's what Apple's dialog looks like for a signed binary.

Mac signed binary dialog.

The way that Microsoft's version of code signing (Authenticode) works is the software author gets a code signing certificate issued by a public certificate authority. They then use their private key to sign the binary. Apple's system is similar, except that instead of using a public CA you need to be an Apple registered developer (surprise!). When you download a binary and try to run it the first time, the operating system checks the signature and then pops up the appropriate dialog box, telling you who signed the code, or warning you that it's unsigned, with the exact details depending on the operating system version.^[2] Modern versions of MacOS have become increasingly aggressive about not letting you run unsigned code, but as of this writing, it's still possible.

Mobile operating systems are even more locked down, where almost all software is installed from some app store (typically operated by the vendor). Historically, Apple has only let you install apps from the iOS app store, whereas on Android you could install third party apps if you were willing to work a bit. In response to the EU Digital Markets Act, Apple is allowing alternative app installation inside Europe, but even then it's much less convenient, and not available in the US at all. Apps installed through the app store are also signed and the mobile OS automatically verifies the provenance of the app.

The basic problem with code signing systems is that they rely heavily on user diligence, because the OS only verifies that the code was signed but doesn't know who was supposed to sign it. In the simplest case, consider what happens if you are lured to the attacker's web site and persuaded to download an app. As long as the attacker has a code signing certificate—or is an approved Apple developer—then they can send you a malicious binary, which will run fine. In principle users are supposed to check the publisher name—assuming, that is, that the OS even shows a dialog box—but we know from long experience that users don't check this kind of thing. If it becomes well-known that a given publisher is signing malicious binaries, the OS vendor might blocklist the publisher, but this takes time and leaves the vendor constantly chasing bad behavior.^[3] Moreover, "well-known" is doing a lot of work here, as it's not exactly unheard of for malicious apps to make it into various app stores.

If you're on a mobile operating system, you'll of course be downloading programs via the app store. The situation is a little better here because the app store operates the directory, and so offers (sort of) unambiguous naming and at least in principle the app store operator can do something about copycat software with confusing names, so it's harder to trick you into installing the wrong package, though of course you're trusting the app store vendor to provide the right package. It's still signed but the device vendor controls the signing key authentication system, so they can can impersonate anyone they want.

Whether you are downloading software directly or via an app store, it's usually necessary to download software over a secure transport even if there is code signing. If you don't download software using secure transport then a network attacker can substitute their own code—signed with their own valid certificate—during the download process; unless you check the publisher's identity, you'll end up running the attacker's code.

Of course, if you have to download software over secure transport anyway, this raises the natural question of why bother to sign the code at all? Why not just have all downloads happen over secure transport? One reason is that is that signing allows for third party hosting. The big technical difference between code signing and transport security is that the signed object is a self-contained package that can be distributed by anyone. This is a big asset in any scenario where the publisher doesn't want to—or isn't allowed to—distribute the software directly.

Blocklisting #

Another reason for signing is to make blocklisting easier. As I mentioned above, if the OS vendor determines that a publisher is misbehaving, they can revoke permissions for that publisher, thus preventing software signed with their certificate from being installed. This is a highly imperfect mechanism for two obvious reasons:

An attacker can register as a different publisher and continue to sign as that publisher until they get caught.
An attacker can just distribute unsigned software.

Note that you could operate a blocklist where you just listed malicious software—for instance by publishing a hash—but that would be much easier to evade, as the attacker could just change their software until it evaded detection; this is a common problem with antivirus software. If you require software to be signed by some key that chains back to some non-free credential, then this allows you to increase the level of friction to distribute all software, but especially malicious software. If you want to register as a different publisher, you have to establish that identity and then get a certificate, join the developer program, etc. None of this is free, though we're probably talking hundreds of dollars, not thousands,^[4] so it makes it somewhat more expensive to distribute malware.

Of course, the attacker could just distribute unsigned software, but then there's some additional friction in the install experience, so you might not manage to infect quite as many victims.

Automatic Updates #

A lot of modern software has some sort of self-updating feature. Unlike the initial install, however, the software updater is written—or at least distributed—by the publisher, who knows precisely who should be signing the update, and so signatures work just fine as a security measure. Conceptually, this is a similar to the trust on first use (TOFU) mechanisms used by SSH: as long as you get the right packager the first time, you're safe in the future because the publisher can directly authenticate the code.

Package managers #

In the open source world, it's common to have a package manager which lets you install software from the command line. For instance:

Linux and FreeBSD come with a variety of package managers (apt, dpkg, etc.). On MacOS it's possible to install third party software via Homebrew
Many modern programming languages have some kind of package manager, such as npm (JavaScript), Cargo/Crates (Rust), PyPi (Python), etc.

The way these systems typically work is that people publish their packages onto the package manager site and people download the packages from there using some local program provided with the language or the operating system. This obviously makes the distribution site a single point of vulnerability, in at least two ways:

The package author's account on the package repository might be compromised (e.g., if they don't use MFA), and the attacker uploads a malicious version. A huge amount of the energy in securing open source supply chains has gone into preventing this kind of attack.
The package repository itself is compromised, and the attacker uses their access to upload a malicious package.

Using secure transport to the package repository is standard practice, but it doesn't help against either of these threats because the problem is the data on the package manager itself is compromised. In theory it seems like signatures offer a way out of this: if packages are signed then even if the attacker compromises the repository they won't be able to replace the package with their own.

Unfortunately package signing isn't a complete solution for the same kind of identity reasons as before.

Attackers can submit malicious copycat packages to the package repository with similar names to legitimate packages. It's easy to be fooled by this.
If the package repository is malicious, then it can point you to the wrong package. When you first decide to use a package, you probably go to the package manager site and do some kind of search (e.g., "give me a package for task example). If the package manager site is under the control of the attacker, then they can just tell you to install package example-attacker (hopefully with a less obvious name) instead of package example. The package will be signed, just by the attacker.
Even if you know the right package name, a malicious package repository can still attack you because you don't know what key should be signing the packages, so once again you have to worry about identity substitution. What's needed here is some way to issue credentials that are tied unambiguously to the package name. One could imagine a number of ways to do this, including (1) having the package manager repo run its own CA or (2) tying package names to domain names the way Java does (e.g., com.example.package-name and using the WebPKI, which already attests to domain names.

As with the case of software updating, however, the problem is easier once a package has been downloaded, because you could store the package signing key along with the package (e.g., in the package.json) file, and then generate an alert if packages aren't signed with that key (TOFU again). Better yet, this would also work when other people go to use your package: if they get your list of keys then all the dependencies would be protected.^[5]

There's been talk for a long time about signing packages, but it doesn't seem to have really gotten off the ground for any of the major package managers. For example, PyPi used to have GPG signatures, but it looks like they didn't work that well for a variety of operational reasons and they were recently removed and replaced with "digital attestations" based on sigstore, but many popular packages are not signed,^[6] and as far as I can tell there is as yet no automatic verification. Note that npm supports what's called "registry signatures" using ECDSA, but the signatures are made by the npm registry (package manager) using its keys, so this doesn't protect you against compromise of the package management system. The bottom line is that you mostly need to trust the server that is publishing the packages not to send you malicious packages.

How not to trust the publisher (or at least trust them less) #

Of course, this was all warmup for the real problem we want to solve. Everything up to now was about ensuring that you get the binary that the publisher wanted to send you. This still leaves you trusting the publisher, which you shouldn't, both because it's bad security practice to have to trust people and because there is plenty of evidence of software publisher misbehavior.

There are two main threats to consider from a malicious vendor:

A broad attack where a malicious binary is distributed to everyone.
A targeted attack where a malicious binary is only distributed to specific people.

Over the past 10 years or so, the industry hive mind has developed a sort of aspirational three part roadmap for what it would take to actually provide confidence in binaries without trusting the vendor.

Reviewable source code to allow people to verify program functionality.
Reproducible builds to verify the compilation process.
Binary transparency to ensure that people are getting the right binary and that everyone is getting the same binary (thus preventing targeted attack).

The relationship between these is shown in the diagram below.

Ensuring software provenance

The process starts with the publisher releasing the source code. As a practical matter, some kind of review of the source code is a necessary but not sufficient precondition to being able to have confidence in a piece of software. Reviewing the binary is not really practical on any kind of scalable level; it is of course possible to reverse engineer binaries, but it's incredibly time consuming even for experts. The expectation is that if the software is important enough, then some set of people will scrutinize it, looking for defects. If this process is working correctly, then it should be safe for people to download the (reviewed) source code and compile it themselves.

That's enough in some cases (e.g., if you're building a Web app and you didn't minify or obfuscate the code), but in most cases, people want to download compiled versions even when the software itself is open source. But how do you know that the binary that the vendor is distributing to the user corresponds to the (presumably) safe source code. The general idea is that some set of people (the reviewers again?) build the binary themselves and compare it to the binary that the vendor is distributing. This is actually harder than it sounds for two reasons:

It's often not the case that you can compile the same source code and get the same binary.
Even if the reviewers get the same binary as the vendor, how do you know that you got the same binary as both of them?

The first problem is addressed by having what's called "reproducible builds", which is what it sounds like: making it possible for two people to get the same binary from the same source. Once you have reproducible builds, then it should be possible for third parties to check the compilation process.

The second problem is addressed by a technique called binary transparency (BT). BT is like Certificate Transparency (CT) and involves publishing hashes of each binary generated by the vendor. For instance, when Mozilla releases Firefox 140, they would publish hashes for the Mac, Windows, and Linux builds into the BT log. Users and reviewers could then independently verify that their copy of the binary (downloaded in the case of the user, built in the case of the reviewer) were what was in the log, providing assurance that everyone got the same binary.

When you put all of this together, you get what should be end-to-end verifiability for the program's behavior:

Independent source code review verifies that the source code is non-malicious.
Reproducible builds allow for comparison between the vendor compiled binary and independently produced binaries from the reviewed source code.
Binary transparency allows users to verify that they got the same binaries that were compiled from the reviewed source code, and that they are the same as everyone else got.

Let's look at each of these in more detail.

First, we publish the source #

Even with access to the source code, it's very difficult to really be sure what a program does and even hard to exclude the possibility that it does something malicious.^[7] The basic problem is that software is incredibly complicated and so just getting to the point where you understand approximately what it does is very time consuming.

Moreover, the easiest way to read code—at least for me—is to try to figure out what it's trying to do, which means just reading it. Like reading text, this means that you skip over little details and errors because they interfere with overall comprehension. It's much harder to put yourself in the mode of really studying each piece of the code and making sure you know exactly what it is actually doing rather than what you think it should be trying to do and assuming it does that. However, that's exactly what you need to do when you review a piece of code, because defects so often arise when the programmer wrote something that is superficially sensible but is actually broken on closer inspection. It's a similar task to copy editing, where you have to focus on the details and deliberately suppress your mind's natural tendency to correct any errors and process the big picture. And of course the more code you have to read the harder the job is.

10 lines of code = 10 issues.

500 lines of code = "looks fine."

Code reviews.
— I Am Devloper (@iamdevloper) November 5, 2013

I'm certainly not telling you not to review code, but it's important to recognize its limits. To a first order, every line of code that goes into Chrome and Firefox is reviewed and the reviewers take their jobs seriously, and yet both browsers still ship with plenty of undetected vulnerabilities and even more undetected defects. Humans simply aren't up to being able to the task of finding every defect in a piece of software, especially when it requires reasoning about hundreds of thousands of lines of code all at once; it's not even easy to find defects when you know they're there and and approximately what the misbehavior is, as anyone has had to debug a complicated issue can tell you.

Moreover, everything I've just said is about the setting where the original author and the reviewer are on the same side, with the author trying to write clear, correct code and the reviewer trying to genuinely understand it. The problem is of course much harder if the author is trying to actively deceive the reviewer, which is what we are worried about here. There used to be something called the underhanded C contest where the idea was to write a program which looked normal and behaved normally under most conditions but had a defect that could be triggered with the right input. Some of the programs are quite clever and it's easy to believe you would miss errors during the review phase.

Vulnerabilities vs. Malicious Code #

It's important to recognize that a malicious vendor doesn't need to embed all the functionality that they want into the source code; they just need to introduce a vulnerability that allows them to exploit the software once it's compiled, just as attackers regularly do with unintentional vulnerabilities. This makes it much harder to detect malicious code because you can't just study the functionality to see if there is something fishy, you need to find all the defects.

The problem is especially acute in non-memory safe languages like C and C++ because (1) it is easy to create defects that cause memory vulnerabilities and hard to detect them (2) exploiting those vulnerabilities is a very well understood problem and (3) memory vulnerabilities are generally lead to powerful exploits, up to and including remote code execution, which would allow an attacker to do anything they wanted on your machine. By contrast, in a language like Rust or Python, many defects just cause program failure and you have to work a lot harder to get to remote code execution.

Actually, a malicious vendor doesn't really have to do anything to deliberately introduce defects because, as I keep saying, real software is full of vulnerabilities, which in almost all cases were introduced by accident. All the vendor has to do is not fix some of those defects (assuming they discovered them themselves). Presto, instant malicious software, plus plausible deniability.

You're not really going to do this yourself are you? #

Even if it were in principle possible to verify that a piece of software was free of malicious code and vulnerabilities, it would be at best an incredibly time consuming process. For example, Firefox consists of tens of millions of lines of code. If you were to review one line of code a second, you'd still be looking at something like a year wall clock time just to review that one program. And this assumes that you're expert enough to do that, which almost nobody is. Clearly, this isn't something people are going to do for themselves.

This is a piece of the puzzle that doesn't get talked about that much, but I think that people have some vague that somehow the open source community will self-organize to review the entirety of all open source software in the given enough eyeballs, all bugs are shallow sense, and if something bad was found, it would be reported and fixed, and if really obviously bad, there would be some consequences for the vendor, if only in the form of negative press and people complaining on Hacker News.

I think you should be suspicious of this in at least two ways. First, open source software routinely has quite old vulnerabilities, so clearly whatever we have now is not effectively fulfilling this function. Second, it's not clear to me what such a structure would look like: would someone parcel out the pieces of code for others to look at? Would we have a registry of what had been reviewed? How would you know that reviewers weren't malicious? Who would pay for all this reviewer time? I suppose it's possible we could build some mechanism for the highest profile software, though in practice my experience is that that's precisely the code that everyone just assumes is nonmalicious.^[8] In a number of cases vendors have contracted for some published third party audit (e.g., cURL, Homebrew, Mozilla VPN, etc.), and there has been some progress on crowdsourcing review of Rust crates, but I don't think anyone really thinks audits capture every vulnerability so much as providing an overall assessment of code quality, and in my experience auditors don't usually go into the engagement assuming that the vendor is malicious.

Verifying the Build #

OK, so you've convinced yourself that the source code is non-malicious, but in most cases you don't run the source code but rather the compiled binary, and you usually don't compile it yourself but rather download it from the vendor, even for open source software. There are a number of reasons for this, but for starters, compiling even a modestly large package can take a long time, and that's not even to mention installing all the prerequisites (do you even have a compiler installed?). There certainly are systems where people have to install everything from source (Gentoo Linux, I'm looking at you), but it's not exactly the most convenient thing; there's a reason why even systems like Homebrew which start with other people's source code provide binaries.

However, if you're installing the binary, how do you know that the vendor has actually compiled it from the source code you looked at rather than from some other malicious source? The obvious thing to do is to just download the source code and compile it yourself. This is actually a lot harder than it looks because two independent compilations of the same source code often do not produce the same binary. This may be somewhat surprising, as compilation feels like a mechanical process, but there are actually a number of important sources of variation, including:

You may not have exactly the same toolchain (libraries, compiler, etc.) as the publisher used.
- If you have two different versions of some dependency and that is included in the final binary, the result will obviously be different.
- The compiler has a lot of discretion in how to compile a given piece of source code, and even different versions of the same compiler might behave differently (e.g., using different optimizations).
Binaries often include timestamps, which will obviously be different each time you compile.
Some build chains are inherently non-deterministic. For instance, Firefox builds uses a technique called profile-guided optimization in which you run the program under instrumentation and use the results to inform the optimization process. Because profiling is sensitive to the underlying state of the computer, you can have small instabilities in the results which produce different outcomes.

This isn't to say that it's impossible to have builds be exactly the same each time (this is called reproducible builds, and there is a known set of techniques for making them work) but it's a nontrivial task to make a given build reproducible, and if the publisher hasn't done it for their system—including providing reproduction information—then you're pretty much out of luck. However, if the publisher has enabled reproducible builds, then it should be reasonably practical to independently verify a given binary.

A non-reproducible build #

Back when I was at Mozilla, one thing I worked on was the the NSS security library in Firefox. NSS dated back to the original origins of Firefox back at Netscape and had some unusual and very old feeling formatting choices. The team decided to adopt the Google C style guide, in part because you could use an automated formatter to mass reformat all the code. Naturally we were a little worried about introducing defects, so we decided to compare the output binaries pre- and post-format. NSS compilation was pretty simple and so we expected this to just work, but surprisingly the results didn't match.

After a fair bit of head scratching, one of the engineers discovered the issue: we had a few locations in the code that used the C __LINE__ preprocessor macro, which is translated to the current line of source code, and embedded the result in a a string. When we had reformatted the code, it had changed what line this use of the macro appeared, leading to a difference.

Binary Transparency #

If the publisher has made builds reproducible, then, then in principle you should be able to compile the code yourself and compare the binary you get to the one on the publisher's Web site, but then why did you bother to download the binary at all? Just as with reviewing the source code, maybe somebody else that you trust could do this and report back if there was a mismatch. This is where binary transparency (BT) comes in.

BT is like Certificate Transparency (CT) but instead of publishing every certificate, the publisher instead publishes a hash of every binary they release. The idea here is that there should be only a small number of canonical binaries for every version (say one for each platform/language combination). When you went to install a piece of software you would verify that it appeared in the BT log and that there weren't an unreasonable number of entries in the log (ideally there would be exactly one for every configuration). This doesn't verify that the binary is non-malicious but just that you're getting the same binary as everyone else.

Our hypothetical auditors would independently build copies of the binary and verify that they matches whatever was in the log. If there was a mismatch, they would (somehow) report the issue and hopefully it would get enough PR that the publisher would be required to explain the issue; if they didn't have an innocuous explanation (e.g., an alternate way of compiling to that binary) then this is evidence that something is wrong. Note that this system relies crucially on some assumptions about the behavior of third parties, namely that:

Someone is actually doing their own builds and checking the logs.
Reporting of log mismatches gets enough attention that there will be consequences for the publisher.

This seems like something that will work a lot better for big vendors; if Chrome^[9] builds can't be matched to something in the BT log, this is a much bigger issue than some package with 20 users.

Even without open source and reproducible builds, BT still provides some value in that it makes it harder for the vendor to supply individualized malicious builds to a small number of people; if you get a unique build you should perhaps worry that you have been targeted. Of course in this case we're depending even more heavily on the BT logs being audited because the signature of this attack is just an unusual number of versions in the log, and it's not at all uncommon to have a lot of software versions floating around for various reasons (alpha/beta releases, A/B testing, development builds, localization, etc.)

Smuggling Binary Transparency into Certificate Transparency #

When I was at Mozilla, we spent some time trying to figure out how to deploy Binary Transparency. At the time there weren't any BT logs at all, so one of us (I think it was either Richard Barnes or I) came up with the idea of publishing the binary hashes in the CT log by minting new domain names of the form <hash>.<firefox-version>.fx-trans.net, getting certificates for that name, and then using the CT log to provide transparency.

At present we're seeing modest levels of binary transparency. In particular, Google has deployed it for Android firmware and APKs, using Google-provided logs. The sigstore project provides generic tooling for binary signing, reproducible builds, and binary transparency and seems to be getting some uptake. However, we're not seeing the kind of large-scale deployment that we have for certificate transparency, and there don't seem to be any generic logs in wide use like there are with CT. Facebook has also deployed a system called Code Verify to provide a form of binary transparency for Facebook Messenger. See below for more on this.

What's your Trusted Computing Base? #

If you've been paying attention you may have noticed that this all requires a fair amount of computation on the user's computer. After they've downloaded the binary, they need to compute its hash and verify that it's been published in the BT log; obviously you're not going to do this by hand unless you have a lot of time. All of this requires some kind of software on the user's computer, and it needs to be software you trust.

Ideally, of course, we'd have some sort of generic system that handled all of this, but that's not generically the case on a desktop operating system, so we're mostly back to the problem at the very beginning of identifying which software package the user is trying to download; it's not just that the binary is somewhere on the BT log; it needs to be associated with the right name, which is to say firefox and not firef0x, but the vendor knows

Updaters #

Once you have downloaded the right software, then the publisher can incorporate BT checking into the software updater as it's already custom software so you don't need to worry about having a generic BT log (because there really isn't one). Moreover, this solves the problem of knowing what binary to look for in the BT log, because the vendor knows the name of their own software.

Of course, now we've just shifted the problem from having to trust the software provider to provide you a nonmalicious binary to having to trust the software provider to send you a nonmalicious updater, so things haven't necessarily improved that much. However, it is better in one specific way: it protects you from the publisher starting out nonmalicious and then becoming malicious. That's a real problem, for instance if the attacker takes over a legitimate package or if they decide to attack you personally for some reason.

App Stores #

By contrast, mobile operating systems do have a generic initial software installation mechanism, which is to say the app store. App stores also come with automatic updating, and because the app store operator rather than the publisher is responsible for the update, it's much harder for the publisher to provide target-specific malicious code, though of course they can provide a malicious build to everyone. This provides some guarantee that everyone is getting the same binary even without binary transparency, because the publisher can't supply multiple binaries.

Of course, as noted above, you have to trust the platform vendor who operates the app store not to themselves send you a malicious binary, but in most cases you're trusting them anyway because they provided the operating system, the installer, and any mechanism you have to view the binary. This is obvious on iOS, which is a completely closed system, but even on Android, all of your interactions with the system are intermediated by hardware and firmware provided by the device vendor, so you're reduced to trusting Google and the phone manufacturer anyway. I'm not saying this is good, just that it's the way it is.

Note that it doesn't really help that much if the platform vendor actually did binary transparency, because it's their software that does the checking and you don't have a good way of checking that software. So while I think it's good that Google is trying to prime the pump some with Android binary transparency, I'm skeptical that it provides significant benefit to the user.

On the other hand, if you do trust the platform vendor, then the app store model can provide a significant amount of additional security even in the absence of the app store enforcing strict policies on the binaries, just because the app store insulates you from the publisher. Moreover, if the vendor requires reproducible builds, then any source code review that they do—or if the program is open source, that others do—can be connected to the resulting binary. For example, Firefox add-ons can be submitted in two ways:

In source code form directly (add-ons are written in JavaScript, so you don't need to compile prior delivery).
In a pre-packaged form, but with a complete copy of the source code sufficient to build the packaged version (and even then, obfuscation is forbidden).

Mozilla does some source code review, and this system ensures that whatever ships is what was reviewed, though of course you're reliant on the quality of Mozilla's review, which is somewhat variable. If the add-on isn't open source (which isn't required by Mozilla's policies) this is all you get, but if it is open source (or just delivered as source), then anyone can in principle do this kind of review for themselves.

The Web #

We're well over 7000 words already, but I do just want to briefly touch on the topic of the Web. The Web has a number of properties that do make the problem somewhat easier:

Web programs execute in the browser, which serves as the trusted computing base.
There's a clear way to identify the "program" the user is trying to run, which is to say the origin.
Web applications are (mostly) not compiled but rather HTML and JavaScript, which are (again mostly) readable, which might make the problem of reproducibility easier.

However, it also has several important properties that make the problem much harder:

The Web application is individually downloaded directly from the publisher by each user, often after they have been authenticated, making it very easy to mount a targeted attack.
It's very common to send each user a slightly different Web page, for instance if there is personalized content, which makes the question of whether it's the same program very difficult.
Authors of Web applications often change the application very frequently, either deploying as soon as changes are made ("continuous deployment") or for experimentation purposes (A/B testing), which means there are a lot of different versions floating around even without personalization.
Web pages often consist of a lot of pieces of JavaScript from various servers (e.g., all the ads that are displayed on the page). This JavaScript is part of the application and so has to be validated somehow, but in many cases it's not even meaningfully under the control of the Web site.

Probably the most serious attempt to provide binary transparency for Web applications, is Facebook's Code Verify) system, provided in collaboration with Cloudflare. Code Verify works by the user installing a browser extension which checks that code running on WhatsApp, Facebook, Instagram, and Messenger matches the source of truth known to Cloudflare. This is a good start but it's also fairly far away from being globally usable.

The Bigger Picture #

As should be clear at this point, the situation is fairly dire: if you're running software written by someone else—which basically everyone is—you have to trust a number of different actors. We do have some technologies which have the potential to reduce the amount you have to trust them, but we don't really have any plausible venue to reduce things down to the level where there aren't a number of single points of trust.^[10] This doesn't mean we should succumb to security nihilism: there's still plenty of room for improvement and we know how to make some of those improvements. However, this isn't a problem that's going to get solved any time soon. Open source, audits, reproducible builds, and binary transparency are all good, but they don't eliminate the need to trust whoever is providing your software and you should be suspicious of anyone telling you otherwise.

Designer of ACME and MLS. ↩︎
Apparently on Windows if the binary is signed with an Extended Validation certificate, then you don't get a dialog at all, and the binary just runs. ↩︎
I should also mention that requiring code signing allows the platform vendor to centrally control who is allowed to write programs for their platform and what those programs are allowed to do. This kind of control can be used in ways that protect users from malware or just software that has user-hostile behaviors but can also be used to restrict user choice. How big a deal this is depends on how hard the platform makes it to run unsigned programs. iOS is a good comparison point here, where Apple requires that (1) all software be installed from the app store and that (2) that software comply with Apple's rules, with the result being that you just can't run any software at all that Apple doesn't approve of, whether that's pornography, encouraging smoking, or just using a browser engine other than WebKit (except in Europe where you sort of can as long as you jump through a lot of hoops). ↩︎
For instance, a GlobalSign code signing certificate is $289/yr, though you have to establish your company first. ↩︎
Many systems allow you to distribute a package "lock" file that contains both the versions and a hash of the package, thus guaranteeing that any dependencies will be exactly what the original programmer expected. This obviously has some side effects, and practice around use of lock files varies. ↩︎
For instance, pandas, numpy, pytorch, requests. It's a little hard to get hard numbers here, but PyPi says that they are hosting almost 600,000 packages and the Trailofbits announcement of signatures from November 2024 says that just under 20,000 packages use the "trusted publishing" workflow, which seems to be the main workflow for signing. ↩︎
Just to get this out of the way, if you've taken automata theory, you know that it's not possible to mechanically determine the behavior of every program, even for trivial properties like does it run forever, but most of those situations arise with specially contrived programs. I'm talking here about perfectly ordinary programs which you could figure out if you had enough time. ↩︎
For example, when I was at Mozilla we just imported several hundred thousand lines of WebRTC code from Google as part of its WebRTC implementation, and nobody thought we were going to really review all that code. ↩︎
As an aside, it doesn't appear that Chromium builds are reproducible and Chrome itself has some proprietary components, which makes verifying the whole system problematic. Firefox builds aren't reproducible either, although the Firefox-derived Tor Browser builds are. ↩︎
There's not even a remotely plausible story about not needing to trust anyone, but that's true for mostly everything in life. ↩︎

Overloaded fields, type safety, and you

2024-08-19T00:00:00Z

Image by Kate Hudson with help from Photoshop AI

I recently learned that Southwest has a policy of giving passengers who don't fit in a single seat a free second seat. This isn't an issue for me personally, but I was curious how it worked and that lead me to Southwest's page on how to book a second seat:

Southwest's passenger entry field

Here are the instructions:

Complete the "Who's Flying?" name fields for a Customer of size as follows:

Without a middle name: A Passenger named Tom Smith would designate Passenger One as "Tom Smith," and Passenger Two as "Tom XS Smith" (first name Tom, middle name XS, and last name Smith).

With a middle name: A Passenger named Tom James Smith would designate Passenger One as "Tom James Smith," and Passenger Two as "Tom James XS Smith" (first name Tom, middle name James XS, and last name Smith).

What's happening here will be instantly familiar to anyone with programming experience: Southwest's systems aren't set up to carry the information that someone wants a spare seat and so instead they have shoehorned the information into the passenger's middle name. This kind of thing happens all the time in software engineering, and is often necessary when you find yourself in a tricky situation, but can also lead to a number of different kinds of problems.

Some Examples #

In my experience the most common way to get yourself into this kind of situation is when you have to deal with some system you can't change, and especially when you have a sandwich like the figure below where you have two components you can change with a component you can't change in between.

Something you can't change in between two things you can.

For example, in the case of Southwest, mostly likely the problem isn't the Web page itself; it's quite easy to modify the form to add an extra checkbox or something. Similarly, there is eventually some system that knows about the extra seat policy. But almost certainly there is some back-end system somewhere which doesn't know about the policy and doesn't have room for an extra field (e.g., some database with a fixed set of columns) and so the easiest thing to do is to smuggle the information in the middle name field and then have the system you have some other system which does know about the policy and is able to pick out names with "XS".

You don't have to look very far to find plenty of other examples, both in software and in the real world.

Hi, I'm Bob NLN #

The form above assumes that everyone has a first and last name (hence the red *s indicating it's mandatory) even if you don't have a middle name. However, many people only have one name (Afghans, Indonesians, Grimes, ...), so what do you do when the form insists you put something in both fields. Depending on the design of the form validation logic, there are various options, but the one commonly used on official forms is to use either:

NFN for No First Name or FNU for First Name Unknown
NLN for No Last Name or LNU for Last Name Unknown

Of course, if you just have one name, is it the first or the last name? For the US passport, at least, you provide single name as your surname and use FNU for your Given Name. As an aside, people sometime use "No Last Name", but then you occasionally fall afoul of form validation logic which won't allow embedded spaces. This is also bad news for people with multiple word non-hyphenated last names.

Credit Card PANs and Format-Preserving Encryption #

The next one is a little more complicated. Suppose you have a database which stores credit card numbers (technical term: Payer Account Number (PAN)) or social security numbers. It's good practice to have the database validate the number and lots of software that uses the database will also rely on the number having a given structure. For instance:

The first digit of the PAN indicates the type of card (4 for visa, 5 for MasterCard, etc.)_
Some of the next 5 digits indicate the issuing bank
There is a check digit (the last digit in most cards, digit 13 for Visa).

Suppose you want to give access to the database to someone who you don't entirely trust but needs to do some analysis. You could just remove the card numbers, but maybe you want to be able to detect PANs which are duplicated across users (this is even more relevant for SSNs). One way to do this is to encrypt the PAN,^[1] but here we run into a technical limitation in the design of our cryptographic algorithms.

The basic encryption primitive you have to work with here is what's called a "block cipher", which operates on binary blocks of size 2ⁿ, typically 64 bits or 128 bits. The way that a block cipher works is that it's a mapping from input blocks to output blocks, with each key producing a different mapping. In other words:

Encrypt(K, Plaintext) → Ciphertext

If the PAN is 16 digits long, then it's easy to map it into a 128-bit block, just use one digit per byte.^[2] The problem is that the ciphertext is then evenly distributed over the space of binary blocks, which means that you're quite likely to end up with a value which isn't a valid PAN,^[3] for instance, it might contain letters or unprintable characters. When you take that ciphertext and try to insert it into your database, it will fail the database validity checks, which creates an obvious problem.

The solution is something called format preserving encryption (FPE), which is effectively a block cipher which works on arbitrary-sized blocks instead of blocks that are powers of 2. This allows you to encrypt from inputs that look like PANs into outputs that also look like PANs, and therefore can be inserted into the database, just like regular PANs.

TLS Extensions and SCSVs #

This kind of hackery doesn't just happen in text files and databases; we do it all the time in network protocols. The way that TLS negotiation works is that the client sends an initial ClientHello message to the server. In the predecessor protocol to TLS, SSLv3, was designed, ClientHello looked like this

    struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        CipherSuite cipher_suites<2..2^16-1>;
        CompressionMethod compression_methods<1..2^8-1>;
    } ClientHello;

The important values here for our purposes are:

client_version: A two byte version number reflecting the highest version the client supports.
cipher_suites: A list of two byte values indicating which algorithms the client supports. Each suite reflects all the algorithms that will be used for the connection (e.g., signature, key exchange, encryption, etc.).

The server responds with a ServerHello message which selects a specific version and cipher for the connection:

    struct {
        ProtocolVersion server_version;
        Random random;
        SessionID session_id;
        CipherSuite cipher_suite;
        CompressionMethod compression_method;
    } ServerHello;

One thing to notice is that this is not a very flexible structure; for instance if you wanted to (for instance) say that you wanted the server to send packets no bigger than a certain size, there would be no place to do it. You'll notice the echoes here of the discussion above about having a format that is inflexible and then wanting to extend it.

When TLS 1.0 was standardized, however, the designers noticed that there actually was a place that had some flexibility. Each handshake message is carried in an outer wrapper which looks like this:

    struct {
        HandshakeType msg_type;
        uint24 length;
        ... // The message itself
    }

This wrapper servers two purposes:

It lets you identify which message you are receiving, because there are parts of the handshake state machine where the peer can send more than one message and you need to know which one it is.
It allows you to have a single function which reads the entire handshake message (using length) that works for every message type and then you can hand the whole message off to a different per-message function.

However, this also creates a situation in which the body of the handshake message (i.e., the next length bytes on the wire) can be inconsistent with what the message was supposed to be. For example, imagine that the client sent a message which was nominally a ClientHello but was only two bytes long. Obviously that's not valid, and the server needs to detect it and fail. On the other hand, it's also possible for the message to be too long, which is to say that there are trailing bytes after you've consumed everything in the handshake structure. This is also an encoding error, but it's one that's survivable because you already have the data you need. The TLS 1.0 designers noticed this too and decided to make a special exception for ClientHello:

In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely.

A subsequent specification provides some actual rules about what was allowed to go in this section, namely a list of "extensions" formatted in tag-length-value format:

  struct {
      ProtocolVersion client_version;
      Random random;
      SessionID session_id;
      CipherSuite cipher_suites<2..2^16-1>;
      CompressionMethod compression_methods<1..2^8-1>;
      Extension client_hello_extension_list<0..2^16-1>;
  } ClientHello;

  struct {
      ExtensionType extension_type;
      opaque extension_data<0..2^16-1>;
  } Extension;

Because extensions are typed, this is a general extensibility mechanism and you can always add new stuff just by adding new extension_type code points.^[4]

Intolerance #

So everything is great, right? Well, not quite. SSLv3 was first deployed in 1996 and TLS 1.0 was published in 1999 the definition of extensions in 2003. This meant that by the time TLS 1.0 was deployed, there were a lot of SSLv3 servers in the field and not all of them accepted more modern ClientHello messages. There are at least two sources of intolerance:

Not liking any version number different from that for SSLv3 (which is 0x0030, as it happens)
Not liking trailing bytes in ClientHello (this actually isn't too surprising, as what to do in this case was a bit ambiguous in SSLv3).

In either case the server would generate an error (maybe a TLS Alert or maybe just cling the connection). This creates a compatibility problem when a client sends a modern ClientHello to one of these servers and it rejects it.

Fallback and Downgrade Attacks #

In order to deal with this, some TLS clients used a technique called fallback in which they reconnect with older version ClientHello after a newer one fails, like so:

TLS Fallback to SSLv3 without extensions

The problem here is that this process is insecure because the attacker can forge an error and force you to reconnect, like so:

TLS downgrade attack via fallback

If the newer version of TLS is more secure than the older version, then the attacker just forced you to use a less secure protocol. This is called a "downgrade attack". Of course clients could have just decided not to do any fallback, but that would have made it so they couldn't connect to those old server, which the client vendors didn't want to do.

SCSVs #

What you need is some way to distinguish attacks from extension- or version-intolerant servers. The problem is that neither alerts nor TCP closures are authenticated, and there's no straightforward way to authenticate them. Instead, what we want is some way for the client to safely signal that it supports modern TLS in a way that doesn't trigger older servers. The options are fairly limited, but there is a field that is safe to use, the cipher_suite list.

Recall that the semantics of this list are that the client provides some ciphers and the server picks one, so servers are used to seeing ciphers they don't recognize them and just ignore them. All we have to do is define a new cipher that means "I am actually a modern client". TLS calls this a Signaling Cipher Suite Value (SCSV). The way this works is that when the client falls back to an older TLS version it also includes this value; if the server sees the SCSV cipher suite and it supports a newer version of TLS, it rejects the connection.

Defending against a TLS downgrade attack with an SCSV

Note that this doesn't stop the attacker from blocking the connection from happening—that's not really possible if the attacker controls the network—it just prevents them from forcing the connection down to a weaker version.^[5] This isn't a perfect defense because servers have to deploy the SCSV and not all of them have, but it's better than nothing. Even better, of course, would be not to fall back, which is what browser clients eventually did.

Random Signaling Values #

TLS 1.3 also does some other signaling shenanigans where it overloads the Random value in the ServerHello in order to signal some special conditions:

That a ServerHello is actually a special message called HelloRetryRequest
That the Server supported TLS 1.3 even though it received a TLS 1.2 ClientHello.

This is actually a case where these are technically valid Random values, but are just extremely unlikely to be generated by accident.

When TLS 1.3 was being designed, we discovered that there was a nontrivial number of servers which didn't support version number 1.3 (despite accepting number 1.2). The TLS WG decided to address this by designing an entirely new version negotiation scheme, ironically based on extensions. The idea here was that as long as the server handled extensions properly it would be safe to offer the new version extension. Of course, if you don't handle extensions properly, you're back in the soup, but the normal process of upgrading eventually got the fraction of servers which didn't support extensions low enough that we were able to deprecate TLS versions below 1.2 and for browsers to disable the fallback mechanism.

Overloading #

The common thread in all of these cases is that we have taken a field that has one meaning and overloaded it with another meaning.

Case	Original Meaning	Alternate Meeting
Name field	Actual name	No name
Credit cards	PAN	Encrypted PAN
TLS Cipher suites	Cipher suite	Fallback
TLS Random	Random nonce	Fallback, Alternate message

The problem here is that the values associated with the alternate meaning would actually be valid for the original meaning (that's why the trick works in the first place). What you're relying on is that the values for the alternate meaning don't actually overlap with those for the original meaning, so, for instance, the SCSV cipher suite has actually been reserved, so there's actually no chance that it will happen accidentally, and the random values have a statistically very low chance of collision, but there are also real world cases where this kind of overloading causes serious problems.

NO PLATE #

Probably one of the best real-world examples here comes from license plates. Snopes has the full story of a guy named Robert Barbour who registered for a set of vanity plates providing the options "SAILING", "BOATING", and "NO PLATE" indicating that he didn't want a vanity plate if the first two options weren't available. Instead, the DMV sent him "NO PLATE" (ambiguity one). Even better, it turned out that San Francisco police officers used plate number "NO PLATE" to ticket cars which didn't have plates (ambiguity two), and he started getting tickets. The story doesn't end there, though:

couple of years later, the DMV finally caught on and sent a notice to law enforcement agencies requesting that they use the word NONE rather than NO PLATE to indicate a cited vehicle was missing its plates. This change slowed the flow of overdue notices Barbour received to a trickle, about five or six a month, but it also had an unintended side effect: Officers sometimes wrote MISSING instead of NONE to indicate cars with missing license plates, and suddenly a man named Andrew Burg in Marina del Rey started receiving parking tickets from places he hadn't visited either. Burg, of course, was the owner of a car with personalized plates reading "MISSING."

This turns out to happen fairly often, with different theoretically invalid values in the place of "NO PLATE", such as "VOID", "UNKNOWN", or "XXXXXX", because it turns out that they aren't actually invalid, or rather, they are regarded as invalid by one system (the police officers who are reporting the error) but not invalid by another system (the people requesting vanity plates and the order entry system that accepts their proposed plates).

It's tempting to think that the solution here is to have a single defined invalid value (as with the SCSV example above), and there are actually a number of systems which do have pre-determined invalid values. For example:

No social security number can have a field that is all zeros (e.g., 123-00-1234)
The phone number exchange "555" as in 415-555-1234 is reserved for demonstration values.
The domains .example and .invalid cannot be allocated and so are used for examples.

However, it turns out that this isn't enough.

`malloc()` return values #

In C, the way that you allocate memory on the heap is to use the malloc() function, as in:

Foo *tmp = malloc(sizeof Foo)

This allocates an object of the size of the object Foo and then assigns it to tmp.^[6] But what happens when there isn't enough memory so the call to malloc() fails? The answer is that it returns a zero valued pointer. The correct code here is:

    Foo *tmp = malloc(sizeof Foo)
    if (!tmp) {
       error(...);
    }

This of course works fine, but nothing actually makes you check, so what happens if you forget. In that case you end up with what's called a "null pointer" and if you try to use it you get what's called a "null pointer dereference" (what Tony Hoare called a billion dollar mistake). In the best case, this will crash your program; in the worst case it's an exploitable vulnerability. The problem here is that even though the invalid value (0) is easily detectable, you have to actually check it. A better situation is one where it's not actually possible to end up with an invalid value.

Infallible allocation and `new` #

One approach is to have the function be what my Mozilla co-workers used to call "infallible", which is to say that it can't return an invalid value. Instead, the program crashes. For instance, you could have a function called safe_malloc() which looks like this:

void *safe_malloc(size_t size) {
    void *ptr = malloc(size);
    if (!ptr) {
       abort();
    }
    return ptr;
}

In C++, malloc() (which allocates arbitrary memory) is fallible, but the new operator (which creates objects) is infallible: if it fails to allocate the memory the program will crash.^[7]

Union Types #

An alternate approach is to have the function return what's called a union type, which is a type that can contain multiple values, but not all at once. For instance, consider the following C code:

union {
   int a;
   char b;
} U;

The way this works is that the union type is as big as the largest possible value it contains (in this case a) but a and b share the same space in memory, as shown below:

An example union type

This isn't actually the solution to our problem, but instead recreates the problem. Suppose that I give you a pointer to an instance of U (the C notation is U *), with the memory region it points to being the bytes [00, 01, 02, 03]. This could be either of two things: the integer 0x00010203 (I'm assuming a big-endian architecture) or the character 0x00. There's no way to tell from context.

What you actually need here is what's sometimes called a discriminated union, which also has a type field telling you what is inside it, like so:

struct {
  enum { INT, CHAR } union_type;
  union {
   int a;
   char b;
  } u;
} U;

The way this works is that the union_type field tells you what's inside the value. If we think about this in the memory allocation context, we would have something like:

struct {
  enum { MEMORY, ERROR } union_type;
  union {
    void *result;
    int error;
  } u;
} MallocResult;

If malloc succeeds, then it returns a MallocResult of type MEMORY (i.e., union_type is set to MEMORY) and sets result to the allocated memory. If it fails it returns a MallocResult of type ERROR and sets error to the actual error value. To use this, you would write code like this:

MallocResult r = malloc(sizeof Foo);
if (r->type == ERROR) {
   error(r->u.error);
}

Foo *tmp = r->u.result;

This solves the problem of knowing what the type of the result is, but still doesn't really solve your problem because you can just assume things are working, and have a null pointer dereference anyway:

MallocResult r = malloc(sizeof Foo);
Foo *tmp = r->u.result;

This is about the best you can do in C, but more modern languages have a safer structure. For instance, here is what the same union looks like in Rust (where it's called an "enum"):^[8]

enum {
   Result(Memory),
   Err(Error)
} Result;

This looks pretty similar but the important difference between C and Rust in this case is that you're not allowed to access the values directly. The enum keeps track of what is inside it and Rust won't let you access the wrong type. Instead, you do something like this:

let result = malloc();  // Rust doesn't really have malloc

match result {
   Result(memory) => {
     // We have successful result in |memory|
   },
   Err(error) => {
     // Things failed with error |error|
   }
}

The point here is that the language protects you from screwing up: you can only access the value that's actually in the union type, not the other alternate values.

The syntax above is a bit complicated and in practice, Rust has a special type just for this called Result. Result is set up so you don't have to use the match stuff above, but instead has a function called unwrap(), which works like this:

let result = function().unwrap();

The way this works is that malloc returns a Result that contains either the result of the call to function(). If you call Result.unwrap() then one of two things happens:

If the function succeeded, then unwrap() will return the function return value.
If the function failed, then unwrap() will terminate the program (there is also a way to ask if it succeeded).

The technical term here for the property Rust is providing here is "type safety", with the compiler guaranteeing that you can't misinterpret one type (error) as another (a result).

Excel Date Translation #

Type safety isn't just about exceptional cases where we have one "main" meaning (e.g., the license plate) and one exceptional meaning (there is no valid plate). There are many situations where we have a field that can be of multiple types of actual data (union types can of course be used this way). This is conceptually powerful, but can lead to major problems, as in Excel.

Excel, like all spreadsheets, is structured as a set of cells. Cells can contain freeform text data but can also contain other more specific kinds of data (e.g., numbers, dates, etc.). While you can specifically tell Excel what type a field is (as with an option type), you usually don't, because Excel can usually figure out what the field is from what you type in. For instance, if you type in 1234, then it's probably a number, and Excel will treat it accordingly; If you type in ABCD, then it's proably just freeform text; and if you type in 2024-01-01 then it's probably a date.

This last case is where things can go spectacularly wrong because that Excel is quite aggressive about converting things to dates if they can plausibly be interpreted that way. For instance, if you type MARCH1 into Excel it will convert it to Mar-1, which is to say "March 1st".^[9] Unfortunately, it's quite common to name genes with strings that look like dates, for instance one gene is named "Membrane Associated Ring-CH-Type Finger 1" (MARCH1), which, as noted above, Excel turns into "1-Mar". This turns out to be quite a pervasive problem in genomics, as documented by by Ziemann, Eren, and El-Osta in 2016:

The problem of Excel software (Microsoft Corp., Redmond, WA, USA) inadvertently converting gene symbols to dates and floating-point numbers was originally described in 2004 [1]. For example, gene symbols such as SEPT2 (Septin 2) and MARCH1 [Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase] are converted by default to ‘2-Sep’ and ‘1-Mar’, respectively. Furthermore, RIKEN identifiers were described to be automatically converted to floating point numbers (i.e. from accession ‘2310009E13’ to ‘2.31E+13’). Since that report, we have uncovered further instances where gene symbols were converted to dates in supplementary data of recently published papers (e.g. ‘SEPT2’ converted to ‘2006/09/02’). This suggests that gene name errors continue to be a problem in supplementary files accompanying articles. Inadvertent gene symbol conversion is problematic because these supplementary files are an important resource in the genomics community that are frequently reused. Our aim here is to raise awareness of the problem.

The problem here, as so often happens in software, is that someone tried to be smart. Also that friends don't let friends use spreadsheets.^[10]

Quoting #

I want to hit one more related topic: quoting, starting with a simple example, the comma separated value (CSV) file.

Comma Separated Values #

CSV is a format for tabular data, which is to say a table of rows and columns like a spreadsheet. A CSV file consists of a series of rows, with each row on its own line, separated by a newline character. Each row consists of a set of columns, with the columns separated by commas, like so:

first name,last name,age
John,Smith,20
Jane,Doe,23
Nicolas,Bourbaki,100

This is a conceptually simple format, and you might think that it's simple to parse: just go line by line and then split on the commas.

But what happens if you want to have a field that itself contains a comma, like so:

first name,last name,age
John,Smith,20
Jane,Doe,23
Nicolas,Bourbaki,100
Robert,Kennedy, Jr.,70

If you split this on commas the last row will consist of four columns rather than the three columns every other row has.

Robert, Kennedy, Jr., 70

Obviously, this is no good. The way you address this is by "quoting" fields that contain the separator character by wrapping them in quotes, like so:

Robert,"Kennedy, Jr.",70

So far so good. But what happens if you have a field that itself contains a quote? The typical answer is that you escape it by prefixing it with another character, such as backslash (\), like so:

Elvis \"The King\",Presley,42

This is called "escaping" and the backslash is called the "escape character". But this just pushes the problem around, because now we have the problem of fields which contain backslash. The convention here is that you represent those with a pair of backslashes (\\).

In other words:

A,A\\B,C

Represents the following three values:

A
A\B
C

When you put all of this together, you can unambiguously parse the file into fields and still represent any valid character inside each field, but at the source of a lot of complexity in the parser. It's not uncommon to see CSV parsing code just split on commas and hope there aren't any fields with embedded commas. The source of the problem is the same thing we've been fighting all along, namely that the comma has two meanings in this context:

As a separator between fields
As a character inside fields

We need some way to distinguish between those two contexts, which is what quoting does. But then we have to distinguish between quotes around fields and quotes within field, hence the backslash escape character. But now we have the same problem with the backslash, hence double backslash.^[11] The easiest way out of this hole is to have a separator that isn't valid inside a field, in which case you can just split on the separator without any quoting, escaping, etc. Comma isn't a good choice here because it's very common to have data that has embedded commas, but what you'll often see used here is the tab character (character code 9), in what's called a tab separated value (TSV) file. This is easier to work with because most data won't have tabs in it at all and you can often replace tabs with spaces with no loss of meaning. An additional benefit is that the tabs help align the data so that columns will often line up properly.

SQL Injection #

If you incorrectly split up a CSV into fields, it's probably not that bad—you'll probably end up with the wrong number of columns, which is easily detectable—but there are cases where getting the quotes wrong can be much worse.

The most common tool for interacting with databases is a language called SQL. For instance, you might ask for every row in a database where someone had the first name "John" like so:^[12]

SELECT * FROM Table WHERE FirstName='John';

Note the single quotes around 'John'. The reason for these is that you're using spaces as separators and you might want to search for a field value with embedded spaces, which you would do like Jim Bob.

Now consider the case where you have a Web interface and you want to look up a user by name, as in the passenger entry field we started with at the top of this post: the user puts in their name and you want to look up their passenger record, like so:

SELECT * FROM Passengers WHERE FirstName='John' AND LastName='Smith'
  AND DOB='1986-01-01';

Of course, if you're building a Web application, you're not really programming in SQL. Instead, you're working in some other language, such as Python, and then using it to execute SQL, like this:

cursor.execute("SELECT * FROM Passengers WHERE LastName='Smith'")

Notice how I've wrapped the SQL command in double quotes to tell Python "this is all one string" and Smith in single quotes to tell SQL "this is all one field". This is an alternative to escaping for dealing with situations where you have embedded quotes in some field, at least in languages which allow both single and double quotes.

But of course I don't know the name that I want to search for in advance, as it's entered by the user. So instead what the Web app has to do is read the name the user entered in and then assemble it into an SQL command, something like this:

command = "SELECT * FROM Passengers WHERE LastName='" + name + "';"

cursor.execute(command)

In this case, the name is in the variable name and we insert it into the command template to form the actual SQL command we want to send to the database to execute.

But now what happens if the name the user enters contains a quote, like, for instance d' Artagnan.^[13] In that case we get this SQL command:

SELECT * FROM Passengers WHERE LastName='d' Artagnan'

In this case the embedded quote in "d' Artagnan" gets interpreted as the end of the string to search for, which just becomes the letter "d" (as you can see from the syntax coloring) and the string "Artagnan" looks like the next bit of SQL, which (incorrectly) ends in single quote. This particular example will likely just create a syntax error in your SQL parser, because it's not a complete SQL statement, but that if the attacker deliberately crafts their name in order to be valid SQL. For instance they might enter the following name:

Smith'; DROP TABLES;'

This produces the following string:

SELECT * FROM Passengers WHERE LastName='Smith'; DROP TABLES;'';

Which gets parsed as three SQL commands, namely a select from the database:

SELECT * FROM Passengers WHERE LastName='Smith';

followed by a command which erases the entire Passengers table.

DROP TABLE Passengers;'

Followed by some syntactically invalid SQL.

'';

This last command is a syntax error (though with some more cleverness we could make it valid) but by this point the other commands have executed and the Passengers database has been erased. We've just invented the SQL injection attack, which is a major problem in database-backed Web systems.

From XKCD

The root cause here isn't so much quoting as inconsistent quoting. Specifically, the quote characters are special in SQL but get passed transparently through the Web form and Python APIs we are dealing with—though they are special in other contexts—as a result, the attacker is able to get them all the way through to the database where they can cause damage.

As it turns out, there is another attack in which the objective isn't to contaminate the database but rather the victim's Web browser. In this attack, called cross-site scripting (XSS), the attacker submits some data (e.g., in a comment on a Facebook post) that passes transparently through the site all the way to some other person's browser when the read the comment, but instead of displaying to the user, the browser instead interprets it as a piece of JavaScript and executes it in the victim's browser. As with SQL injection, XSS relies on constructing a special string that makes the browser think that the user-generated content (the comment) is over and that the rest of the text is JS, but in this case the attacker needs to construct the string in such a way that the database doesn't interpret it but the browser does. Describing how to do that is outside the scope of this post.

Final Thoughts #

We've come a long way from reserving an extra seat on the plane, so I wanted to try to see if I could pull things together. The underlying problem we are facing here with all these examples is the same: having the same set of bits which can mean two different things and needing some way to distinguish those two meanings. Failure to do so leads to ambiguity at best and serious defects at worst. That's why you see so much emphasis in modern systems on type safety and on strict domain separation between different meanings. In the best case, it would simply be impossible to treat data of type A as data of type B, but as a practical matter, you sometimes have to do so; it's those times when extreme caution is warranted.

You can also build a giant lookup table of random values to PANs, a process often called "tokenization". ↩︎
The situation is more complicated with 64-bit blocks, but it's obviously possible because there are many more 64 bit blocks than 16 bit credit card numbers. ↩︎
What I mean here is that it's not even properly formatted, as many properly formatted number strings are not valid PANs. ↩︎
People sometimes worry that the code point space might run out, but the type field is two bytes and we're nowhere near 65K extensions. Moreover, if we did get close we could always define a new extension which contained other extensions! ↩︎
Note that if the oldest version of is weak enough (imagine it wasn't authenticated at all) then this defense wouldn't work, but at least so far even SSLv3 is strong enough to prevent that bad an attack. ↩︎
Technical note: malloc() returns an object of type void *. In C, void * is automatically cast to a type of T * for any type T, but in C++ it's not. In C++, the same code would be Foo *tmp = (Foo *)malloc(sizeof Foo). ↩︎
Technically it throws an exception which you can catch, but I advise against this! ↩︎
In Rust you wouldn't actually be allowed to talk to raw memory, but let's ignore that for now. ↩︎
If you export to CSV you get 1-Mar. ↩︎
Google Sheets does some of the same stuff. ↩︎
The way to think about this is that there are really two backslashes, the backslash literal and the escape character. We're trying to map them onto one character in the text, but that flattening process inevitable means that one or the other variant has to be bigger. ↩︎
The SELECT * means "Give me every column". I could get just one column by doing SELECT birthdate. ↩︎
Yes, I know there is no space after the "d'" but the example works better this way. ↩︎

River of No Return 108K Race Report (2024)

2024-08-05T00:00:00Z

My "A" races for 2024 were Sean O'Brien 100K at the end of January and Tushars 100K at the end of July. 6 months is a long training block and so I decided to break it up with something in between. I've been leaning towards mountainous races with a lot of vert lately (SOB notwithstanding) and after doing a bunch of searching on UltraSignup I decided on the River of No Return 108K (RONR)^[1] Challis Idaho. This turned out to be a good call because I ended up bailing on Tushars after the race was seriously impacted by a giant fire.

Here's a long-delayed race report for RONR.

Badwater Crewing #

Badwater logistics are nuts. Unlike most ultras which have aid stations, Badwater is just an undifferentiated stretch of road and your crew has to follow along in a van and can (mostly) crew you wherever you want. They just pull over to the side of the road, feed you, etc., and you keep going. It's also unbelievably hot and the crew is likely to be pulling at least one all nighter themselves, if not two.

RONR (pronounced row-nurr) is nominally 68 miles and ~17000 ft of gain, with pretty much the whole race above 5000ft, so it seemed like a good warm-up for Tushars (100K and 17000ft mostly above 9000 ft). The original plan was to do RONR as a "B" race without really going to the well and then try to really focus on Tushars, but my friend Lisa asked me to crew her at Badwater 135, which is the week before Tushars and the more I looked at the schedule the more I realized that it was going to be tough to really land the taper for Tushars, so we promoted RONR to at least an "A-", meaning that we would set up the training block for Tushars but I'd still taper for RONR and wouldn't hold back on the day.

The training block leading up to RONR went really well and then in the last mile of my last longish run—a week out so already into my taper—I caught a toe and landed really hard on my right hand. The next day the wrist was really swollen and I was worried I'd actually broken something, which would have obviously interfered with racing—especially because you want to use poles on a race like this and so you need to be able to push with your hand—but an x-ray didn't turn up anything, so it was just ice, advil, and crossed fingers.

Course Info #

Screenshots from Runalyze

Above is a map of the course along with a profile. There was quite a bit of uncertainty about the actual amount of vert, with the Web site showing a bunch of different values (17000 on the site itself, 15314 in CalTopo, 16425 in ultraPacer with the same GPX, etc). Computing the amount of vert from a GPX is kind of a mess. As the Runalyze guys say:

The calculation of elevation data is very difficult - there is not one single solution. Bad gps data can be corrected via srtm-data but these are only available in a 90x90m grid and not always perfectly accurate. In addition, every platform uses another algorithm to determine the elevation value (for up-/downwards). We give you therefore the possibility to choose algorithm and threshold such that the values fit your experience.

I figured it would be around 15000 ft or so and at the end of the day Runalyze shows 14767 and Garmin 15439, so that seems to have been about right. As you can see, it consists of four big climbs, up to around 10kft and all above 5kft, with a really long final descent into town at the end. The last descent is kind of a mixed blessing, with the last 5 miles being on actual asphalt, so you really don't have much of excuse not to run, but you know it's not gonna be fun.

Looking at past year's times I was struck by how slow they were: the course record was set in 2021 by Jimmy Elam at 11:03, which is really slow for a 100K (the SOB record is 8:24). Sometimes a slow course record like this means a soft field, but not in this case: Jimmy Elam was 14th at UTMB in 2022, doing 22:36 the same year Kilian Jornet did 19:39 (and I did 37:49) and so I knew it was going to be a long day, estimating between 16 and 18 hrs. I used ultraPacer to give me a pace sheet for 16:30, which seemed on the optimistic side.

The weather on the day was actually really good, but it was a close thing: two weeks out there was a lot of snow on the course and then the next 12 days or so were really hot, so the course was actually almost snow free. When we drove in on Thursday it was unbelievably hot but it cooled down on Friday and then Saturday was nice and cool.

Travel #

Challis is not easy to get to. I had originally planned to fly to Salt Lake and then drive (5+ hrs) but then decided instead to fly to Sun Valley. Neither of these is ideal. There is no direct flight from SFO to SUN on Friday so you have to fly in on Thursday. Normally this isn't a big deal as you just chill out at the location, but if I'm racing at altitude I prefer to get in the night before to minimize the crappy acute altitude adaptation phase that happens after 24 hrs or so, and you obviously can't do that. On the other hand, if you fly into SLC, then you can come in on Friday, but you get in super late, which also isn't great.

I stayed at one of the recommended hotels (the Challis Village Inn), which turns out to have been a great choice as it's about a half mile away from the race start/finish. This meant we could walk over in the morning without having to build in a lot of extra time to deal with glitches around race day parking.

Challis is a pretty typical small town, but just a heads-up if you're thinking about doing RONR that the restaurant situation is pretty limited: there are only a few places and most only have like one vegetarian option (e.g., grilled cheese). Moreover, there's nothing really open after 10 PM, so think about that when you plan for your post-race meal. There is, however, a perfectly reasonable grocery store, so it's not like you can't get food and cook for yourself (my hotel room had a stove and a microwave).

Overall Logistics #

My plan was to use the same food schedule as I had used for SOB, namely Maurten and more Maurten. RONR serves Tailwind (which I like OK) and Gu (which I don't love), so I decided to mostly just carry stuff and use drop bags. There were only 3 drop bag stations, so this meant carrying a bit more food than I usually want, but it never got too heavy.

My feed schedule is roughly:

1 500 ml bottle of Maurten 160 drink every hour, with 250ml each 30 min
Some mix of Maurten solid and Maurten gel aiming for ~100-200 cal/hr.

I use a 30 minute timer to manage all this, so I have to do something every 30 minutes. I started with Maurten solid and then moved onto a mix of regular gel and the caffeinated gels.^[2]

That's a lot of Maurten

As before, I bagged up what I need for each aid station in a ziploc, as well as a sort "spare food" bag just in case.

RONR is a much more rugged race than SOB and due to all the snowmelt I knew there would be a lot of water crossings, so I also had spare socks in every drop bag as well as spare shoes in two of them in case I wanted to change. In the event I only changed socks once and kept the same shoes (Salomon S/LAB Genesis the whole time.

Start to Birch Creek [7.66 mi, +2329/-358 ft, 1:33:33] #

This first stretch is about 3 miles of rolling terrain followed by a long climb (the AS is about 2/3 of the way up). That first three miles is quite runnable and I was just trying to keep my pace contained, as it's easy to get carried away at the start, especially after watching the top pros just take off from the gun. This was made a bit easier by the definitely feeling that I wasn't at my fastest at 5000 ft.

I'd decided to start without a headlamp because sunrise was shortly after the start, so I had to be a bit careful, but you could mostly follow other people's headlamps in the twilight until the sun finally came up. I made it through this section OK and then managed to trip and land on my right hand (again!), but not badly enough to do more than make it more sore. This was the first of two falls on course and the only one that was more painful than embarrassing.

The climbing started soon enough and I was able to switch to hiking and poles. The trail itself was somewhere between double track and fire road, so it's basically just a matter of putting your head down and focusing on moving forward without having to worry too much about your feet.

This turned out to be my strongest section of the race, I think due to a combination of several factors:

Low temperatures
Being fresh and so comfortable pushing
Not having had a chance to fall behind on nutrition.
Comparatively low altitude (Birch Creek is at 7000 feet).

By the time I hit the AS I was almost 24 minutes ahead of pace for my already optimistic 16:30 target, and I was thinking I was going to have a pretty good day. The next AS (Keystone) wasn't far ahead, so I burned through the AS really quickly (~30s).

Keystone [3.56 mi, +1444/-463 ft, 55:45] #

It's mostly uphill from Birch Creek to Keystone and so just more hiking. I don't remember much of this, except that it went by fairly fast. I was still moving well so I continued to be well ahead of schedule. This stretch through Bayhorse was the furthest ahead of pace I ever was, almost 30 minutes; if you multiply that 6 (I was 11 miles into the race) we'd be looking at almost 3 hrs ahead, but obviously that wasn't going to happen. Another quick AS stop and then the long descent to Bayhorse Lake and the first drop bag.

Bayhorse [4.26 mi, +157/-2136 ft, 56:59] #

As you can see, this is a huge descent, which I mostly cruised. I ran this section with Kat Schuller, a runner with Rabbit Elite, someone about my pace to chat with and just get through the miles. Generally, in a race of this size I'll be somewhere near the female podium (I was behind the first woman at Sean O'Brien this year, though I would have been 8th at RONR), so if I'm with the elite women I generally figure I'm pacing about right. Kat's descending skills were a bit better than mine, so she'd drop me a bit on the trickier sections but I was able to just push a little bit and catch up once it got smooth.

We came into Bayhorse Lake together and arranged to meet up on the way out for the next big climb once we'd grabbed our drop bags, etc. In the event, though, I needed to hit the bathroom and by the time I came out and had my bottles filled, etc. I couldn't find Kat and wasn't sure if she had left already or was still at the AS (it turned out that she had decided she was in a race and had just taken off, but I caught up to her later) I waited around for a minute or two and couldn't find her, so headed out on my own. All in all, this was a really long AS stop; I had budgeted for 6 minutes but it was almost 10. On the other hand, I was still almost 30 minutes ahead.

Ramshorn [9.67 mi, +5000ft/-1250 ft, 2:58:32] #

This next leg is a 5000+ climb, made more interesting by the fact that it's also the first leg of the 32K, which started shortly after I left Bayhorse. This meant initially I had the really fast people passing me, but eventually things kind of stabilized as I caught up to people who had gone out too hard.

The Ramshorn aid station is almost 10 miles out and supposedly just a water drop, so I had planned to carry 2l of water, but right as I was about to leave Bayhorse I was told they had a water drop part way up so I scaled back to 1.5. I don't remember this stretch that clearly, so TBH I don't recall if Ramshorn was real aid or not. I do, however, recall starting to drag as I got up above 8000 ft, and as Ramshorn is the high point of the course at ~10000ft, that meant a long time working to breathe. Even so, I didn't lose too much time on this section, hitting the top at about 22 minutes ahead of schedule.

Towards to top of this climb I caught up to Lara Mccabee, an Idaho local and former track athlete. Again, it was good to have someone to run with so we stuck together for quite a while.

Juliette [4.58 mi, +64/-3024 ft, 51:31] #

As they say, it's all downhill from here, and the section from Ramshorn to Juliette is quite runnable double track and fire road, so it was mostly a matter of just cruising through it while remembering that we still had a lot of climbing to go. Not too much to say about this section; I stayed about 20 minutes ahead of pace.

Bayhorse Lake [8.36 mi, +3081/-1395 ft, 2:13:39] #

At the pre-race meeting, we were told that the climb out of Juliette had a lot of creek crossings, and it didn't disappoint. In any case, this is where things started to go sideways, I think due to a combination of factors:

Fatigue
Difficult footing and creek crossings making it hard to find my rhythm
The altitude starting to get to me (Juliette is already at ~7000ft)

I left the AS with Lara and felt like I was moving faster, but in reality was just kind of yoyoing, and eventually we mostly just settled in together.

Psychologically this was a really hard section because I wasn't feeling great and there was still a really big climb to go out of Buster Lake. Worse yet, this stretch actually has two summits, with the first one followed by a mile plus stretch of rolling terrain and then a mile long descent and then another climb. This is all kind of hard to see on the Garmin watch, so I incorrectly thought that part of the rolling section was the second summit (wishful thinking) and it was pretty demoralizing to realize there was another big climb to go.

By the time I got to the Bayhorse Lake AS (not to be confused with Bayhorse) I had given up basically all of the time I gained in the first half of the race and was right at the ultraPacer target for 16:30. Unsurprisingly, things didn't get much better from here.

I had a drop bag at Bayhorse Lake and after all those creek crossings I decided it was time to change my socks, so I spent quite a while here wiping down my feet, swapping out all my nutrition, and watching the AS people try to get the Maurten in my bottles to dissolve (more on this later). While I was messing around, Lara picked up her pacer and left, but I figured it was more important to have my stuff in good order than to have company, and I knew I had my own pacer at the next AS.

Squaw Creek [7.57 mi, +847/-3023 ft, 1:43:14] #

There's some climbing out of Bayhorse, followed by a really long downhill. The downhill starts fairly technical with a bunch of rocks and talus and then turns into easy fire road. By this time I had caught up with Lara and her pacer, who had done RONR before and advised me that it wasn't worth trying to run the technical bit, because you wouldn't go that much faster and were just courting a fall. This was welcome news as I was feeling pretty tired.

Soon enough we hit the easier fire road section and from here it was just a long cruise down to the AS. You can actually see the transition quite clearly on the pace chart around mile 43 as I go from losing time to slightly making it up. The reason for this isn't that I was somehow a lot worse on the technical bits but that ultraPacer doesn't really know what kind of footing there is (you can tell it but I didn't) but instead is modeled on grade, so it overestimated pace on the technical sections and underestimated pace the easy sections. Somewhere in here I caught up and passed Kat, who had had a good middle section but was now dragging badly and eventually DNFed.

This section felt pretty long but was manageable, in part because I knew I would have company for the rest of the race once I hit Squaw Creek. At this point I was 20 minutes behind target.

Buster Lake [7.57 mi, +2854/-738 ft, 2:04:05] #

Squaw Creek isn't an official drop bag, but as my pacer Kate was there (she had been working the AS), she had brought food resupply, and I took a bit longer at the AS then I really wanted to. In the meantime, Lara and her pacer took off and I never saw them again (she eventually finished almost 30 minutes ahead of me).

The leg from Squaw Creek to Buster Lake is the last big climb and this was the hardest part of the race for me. Almost immediately I started to feel really tired and out of breath, and it just got worse as I gained altitude. Moreover, I was starting to feel really nauseated and dizzy. In the first few miles I actually had to stop a few times and just rest for 30 seconds or so. We were sort of going back and forth with a few other guys and after I'd passed them, I said I wanted to rest and Kate really saved me by asking "do you really need to or can you just slow down a bit?" That was the right question and the answer was of course "keep going, just slowly".

This section also had a lot of water crossings, though not as many as the previous sections, and some of it was really muddy. Partway through I just slipped and landed more or less face down in the mud. Nothing was injured but I got super dirty and just had to finish the race that way.

It was really a relief to hit Buster Lake, as it meant the end of the climbing and now I just had to survive the giant downhill. My last drop bag was here, so I swapped out my food again, with the intention that to eat gels from here on in, grabbed my headlamp, and ditched my poles (not going to need them on the downhill) and headed out. My stomach was still feeling pretty bad, so I grabbed some quesadillas in the hope they would settle things down—they go really well with dirt—and decided to hike a bit while I got them down.

At this point, I was 48 minutes behind target, but with 13 miles of downhill ahead of me.

Custer Motorway [8.35 mi, +290/-2841ft, 1:34:59] #

Like the descent out of Bayhorse Lake, this stretch starts out as somewhat technical rocky trail and then turns into fire road. As before, I opted to sort of hike the technical part and then run the fire road. I'd heard that this section was pretty easy, but the technical section seemed to go on forever—I was of course really tired, but even Kate said so—and even when I hit the fire road part, running didn't feel great and I found myself hiking some of the really not-steep uphill sections.

Finally, we got to the last AS at Custer Motorway. My stomach still didn't feel great at this point but they didn't have any quesadillas ready and I sure wasn't waiting, so spent almost no time here.

Finish [4.68 mi, +36/-878 ft, 50:09] #

From Custer to the finish is all paved road (it starts a little before the AS). I had been sort of going back and forth with a few other guys on the fire road section, but as soon as I hit the paved road I felt like I could really run again and Kate and I completely dropped them (eventually finishing almost 9 minutes ahead).

This section is entirely runnable and it's merely a matter of putting your head down and gutting it out. Kate and I had been talking all the way through here, but for the rest of the race I didn't want to talk but just needed to focus on keeping the pace up. This was the hardest I've ever pushed at the end of an ultra and it was super helpful just to have someone next to you keeping a steady pace when everything hurts. This section felt like it took forever and towards the end we were just counting down the tenths of miles to the finish, but we did the last 5 and change miles at 9:43, 9:42, 9:31, 9:05, 9:03, and 8:56 pace, going from over an hour behind target to just over 50 minutes behind.

Retrospective #

Comparison of ultraPacer target to actual race. Source: ultraPacer

Overall, this feels like a solid result, though probably not as strong as Sean O'Brien. I went in not really knowing what to expect and so my pace targets were pretty handwavy. I would have been unhappy with 18 and quite happy with <17, so 17:18 seems reasonable.

My nutrition worked reasonably well, with two real things I'd like to deal with:

As before, I felt like the bars at the start didn't go down that well.
I was really having problems getting the Maurten drink to mix, even when I had volunteers shaking it for me. This is a known issue with Maurten, but it slows you down and it's also pretty gross when you get a bunch of wet powder in your mouth instead of gel.

The first item is easy: just switch to gels the whole way. I'm less sure what to do for the drink mix, as Maurten really just goes down a lot easier. I used Tailwind on a recent outing in the Sierras and after 6 hours or so I'd just had enough of how sweet it was. Maybe it's time to try Never Second.

I think the biggest limiting factor here was the altitude. It's always a challenge to go from sea level to 7000+ feet and while I was mostly OK at the start of the race, I could really feel myself dragging later whenever I got above 8000 or so feet. I suspect that this also contributed to my stomach issues, as nausea is a common altitude sickness symptom.

This probably isn't the best I could possibly have done with this training base but I don't think it was that far off. I lost a lot of time on the last climb—as you can see by Lara putting 30 minutes on me—and think it's possible I could have pushed it harder, but I doubt I could have gone that much faster. I think to really turn in a better performance I would have had to spend a few weeks at altitude so that the higher elevations didn't hit me so hard. I'm quite pleased with how much I managed to push the last hour or so. That's something I'll want to remember how to do in future races.

Chilling at the finish. Still muddy.

Overall #

17:18:39, 24th/(66 finishers, 92 starters), 17th/51 male, 2nd 50-59

That name sounds pretty ominous but turns out to refer to the 1800s when miners would carry supplies on boats down the Salmon river but not be able to get back up the river. In any case, I returned. ↩︎
As you can see, I also have some Spring energy gels. The flavor is a nice break from Maurten, but in light of the recent measurements of Spring's calorie counts coming in way lower than claimed, I don't want to rely on it. I had some floating around though, so figured I might bring it just in case I really lost the ability to tolerate Maurten. ↩︎

New EV Habits for ICE Vehicle Owners

2024-06-03T00:00:00Z

Generated by Midjourney. Prompt "Man waiting for EV to charge, bored expression, EV charging station, photorealistic --ar 4:3"

I spent some time reading this HN thread in response to Wired's article on how many EV charging stations we need and I'm dumber than when I started (isn't that usually the way it is on the orange site?). On one side, we have the Internal Combustion Engine (ICE) forever crowd enders worried about the tragedy of wasting 30 minutes charging on their 500 mile road trip and on the other side we have EV lovers acting as if there's really no tradeoff.

I have two EVs so there's no doubt about what side of the argument I'm on, but I'm also not going to tell you that it's not inconvenient at times. The truth is that EVs really are a lot more convenient for most people for day to day driving but less convenient for long road trips, especially if you treat them the way you would an ICE vehicle rather than adapting yourself to their idiosyncrasies.^[1]

Background Facts #

The two basic vehicle parameters that dominate any discussion of EVs versus ICE vehicles are:

range: how long you can drive without refueling
refueling speed how long it takes to refuel

Range #

When EVs were first introduced, range was fairly bad,^[2] but things have gotten a lot better. Edmunds lists the Toyota RAV4 as the most popular non-truck ICE vehicle,^[3] and the Tesla Model Y as the top EV. Both of these are compactish SUVs, so pretty comparable. The RAV4 Hybrid gets about 38 mpg highway with a 14.5 gallon tank, so has a range of about 550 miles (this is a little hard to estimate because it's a hybrid). The most popular EV, the Tesla Model Y, has a listed range of 320 miles.

This is a real physics problem for EVs because the energy density of batteries is much worse than for gasoline cars: the RAV4's gas weighs about 120 lbs; the Tesla's battery weighs 1700lbs. What this means in practice is that adding range to an EV involves tradeoffs in terms of cost and weight but it's trivial to add range to an ICE vehicle just by making the tank a bit bigger. If Toyota has chosen 14.5 gallons, that's because they don't think you need more.

Power Units versus Energy Units #

The terminology around EV units can be a bit confusing. A battery stores a certain amount of energy, which is conventionally measured in kilowatt hours (kWh), which is to say the amount of energy you would put into the battery if you added it at the rate of one kilowatt (kW) for an hour. What's a kilowatt, then? It's 1000 watts, where a watt is the power needed to transfer one joule (the SI unit of energy) per second.^[4] In other words, a kilowatt hour is 3.6 million joules (3.6 megajoules (MJ)). Electricity tends to get sold in units of kWh, which is probably why batteries are rated this way rather than in MJ.^[5]

EV efficiency varies dramatically, but a reasonable estimate is around 3-4 mi/kWh (5-7 km/kWh). Battery size also varies quite dramatically, but the median is around 75kWh. Multiplying these two values you get a range of 225-300 mi, which is about what you should expect from the above.

Refueling Speed #

ICE vehicles charge faster than EVs. Period. The HN thread had some crazy fast estimates, but gasoline pumps do about 50l/13 gallons per minute, so we're looking at on the order of 5 minutes to fill up your tank. No deployed EV battery charges even remotely this fast.

At a high level, there are three main types of charger in the US:

AC level 1:: Plugs into an ordinary 110V socket. About 1-2kW.
AC level 2:: Requires a dedicated circuit but installable in your home. Typically around 7kW.
DC Fast Charging ("Level 3"):: Commercial charging stations. Typically between 30 and 350 kW. My experience is that there is a lot of variation in actual charging speed for fast chargers, both in terms of rated power and in terms of actual power delivery. In addition, not all cars will charge at the maximum speed of the charger, with newer cars doing better.

Of course, what really matters isn't the rate of power delivery but rather the rate of range added. If we assume 3.5 mi/kWh, we get something like:

Charger type	Charging power	miles added/hr	Time to add 250 miles of range
L1	1.5	5.25	47 hrs
L2	7	24.5	10 hrs
L3 (normal)	50	175	85 minutes
L3 (fast)	150	525	29 minutes
Tesla Supercharger (rated)	250	875	17 minutes
L3 (ultrafast)	350	1225	12 minutes

As I mentioned above, real world experience varies. As a reference point, I have a BMW i3 and a Kia EV6. The BMW will nominally accept up to 49kW, but I don't think I've ever seen above 40. The Kia will nominally charge at up to 233 kW, but I think the highest I have ever seen is around 180 kW. It's also important to know that charging slows down quite a bit once the battery hits 80%, so as a practical matter it takes a lot longer to get to the full nominal range of the car than it does to get to 80% range. Again, this isn't an issue with gas cars where filling rate is comparatively constant.

Day to Day Driving #

The day-to-day driving experience for an EV is totally different from an ICE vehicle. With an ICE vehicle, you just drive around until you are low on gas and then visit the filling station. If you have an EV and a home charger—which you really want to have^[6]—you basically never have to use a public charger on a daily basis, even if all you have at home is an L1 charger. all you do is plug your car in when you get home, which quickly becomes a habit. If you have a home L2 charger, you don't even need to do it every day.

The average US commute distance is 42 miles, which represents about 8 hrs on an L1 charger. This means that if you just drive to work and back and you're at home for 12 hrs a day, you'll always have a full battery when you leave in the morning, with about 4 hrs to spare. As long as you don't drive more than 60ish miles, you'll still have a full battery every morning. This means that you almost never have situations where you get up, are late for something, and realize you need to stop and get gas, as happens with ICE vehicles.

Obviously people don't just commute and if you take a longer drive then you'll use up more of your battery. However, on a day to day basis, most people don't drive more than the range of their car. If you drive more than overnight charge's worth in one day, then you'll just have a slightly less than full battery, but the net amount of drain is just however many miles you drove minus the amount you can charge overnight, so unless you have a lot of days with long trips, your battery never gets too low, and when you return to a normal pattern, it will refill again, unless you routinely drive as many miles as your charger can support.

For example, consider someone who has an EV with a range of 200 miles and drives 40 miles a day regularly, then has a few days where they need to drive 80. Here's what their battery state looks like after the overnight charge:

Day	Morning Range	Miles Driven	Evening Range
1	200	80	120
2	180	80	100
3	160	80	80
4	140	40	100
5	160	40	120
6	180	40	140
7	200	40	160

The bigger your battery, the longer you can sustain periods when you're consuming more than you're charging (this is of course also the situation when you're driving the car). Consider a vehicle with a 100 mile battery driven the same way:

Day	Morning Range	Miles Driven	Evening Range
1	120	80	20
2	80	80	0
3	60	80	-20 (oops)

On day three, instead of being down to less than half the battery, you're actually at negative battery instead! The only difference here is that you don't have as big a buffer, so that when you consume more than you charge you run out. The bigger the battery, the more buffer you have and therefore the less of a big deal it is if you do a long drive one day. This buffer is built up in the days before your long drive when you're charging more than the drain; with a small battery, the car is just sitting fully charged whereas with a big battery it would still be charging.

Of course, all of this is just with an L1 charger. If you have an L2 charger at home, then 12 hrs of charge is around 300 miles of range and so you'll nearly always have a full battery in the morning and will essentially never have to visit a public charger. You really just have to worry about situations where you do enough driving in one day to completely deplete your battery. This brings us to the topic of road trips.

Road Trips #

It's clearly more convenient to not have to worry about refueling on a day-to-day basis, once you want to drive more than the range of your vehicle in one day, the situation gets quite a bit worse. In an ICE vehicle you can just generally drive from point A to point B and when you get low on gas, pull out your phone and look for a gas station. This is not a good plan for an EV for several reasons.

First, there are a lot fewer EV chargers than there are gas stations. As of Jan 2024, California had less than 2000 DC fast charging stations (there are around 7000 total in the US). By comparison there are over 13000 gas stations in California. Moreover, because of charging network incompatibility, you can't use every charger (though Tesla is supposed to be opening up its network to non-Tesla cars, which will improve the situation for non-Tesla owners, as Tesla operates the biggest network).^[7] The result of this is that when you get down to (say) 30 miles of range, you may not be able to find a conveniently located fast charger. And because the range of EVs is somewhat lower you will need to find a charger more often.

Second, as should be clear from above, EV charging is significantly slower than filling your gas tank even in the best case scenario where you have a fast DC charger (say 10-20 minutes). If you can only find a normal L3, you're looking at closer to an hour. I wouldn't generally even bother with stopping at a L2 charger, though they can be useful for charging overnight at a hotel or something. You can, of course, sit in your car at the charger for 30-60 minutes but it's not an ideal experience. Worse yet, it's not uncommon for the chargers to be full and/or one of the ports to be broken, in which case you also need to wait for someone else to finish.

Basic Strategy #

My recommendation instead is to lean into the way an EV behaves rather than trying to treat it like an ICE vehicle. What this mostly means is to plan your trip around actually stopping to charge.

As a real example, consider a trip from Palo Alto to Los Angeles in my Kia EV 6 GT (range: 210 miles). The total trip is 360 miles, so I should be able to do it with one charging stop, as long as it's located more or less halfway through. There's really only one choice here, which is Kettleman City, located 184 miles from Palo Alto and 178 from Los Angeles, where there is a 10 port Electrify America charging station. The station itself is located at Chalios Mexican Restaurant, but it's in a complex with a pile of other fast food restaurants (In-n-Out, Baja Fresh, McDonalds, etc.). To be honest, this is actually on the good side in terms of location options; lots of Electrify America stations are in Walmart parking lots. Anyway, what you want to do here is plan to get there around lunchtime, plug your car in, and then go grab some food while it charges. If there's a spare port when you arrive, it's actually reasonably likely that charging will be done before you finish eating (be nice, move your car), but even if not, you can just chill in In-n-Out for a bit.

This is basically the only good option if you have an EV with a 200-odd mile range and you want to make one stop: the next closest choices are Coalinga (203 miles from LA) and (214 miles from Palo Alto). you might make it with one of these, but you're cutting it a lot closer than I like. By contrast, if you have an EV with a 300 mile range, you could pick either of these, or even make it down to Bakersfield before finding a charging station. Of course, if you had a 400 mile range (e.g., Tesla Model 3 or S long range, Rivian R1, etc.) then you can actually do the whole trip in one shot, though you'd need to charge when you got there.

Trip Planning #

For the best result, an EV trip requires a lot more planning than with an ICE vehicle. I've certainly done trips where I just drove for a while and then searched for a charger, but this definitely has a higher risk of charging in a Walmart parking lot. You're going to be happier if you do some advance research. There are a number of trip planning tools available to you (Tesla, PlugShare, A Better Route Planner). There's no magic here, just put in your source and destination and play around a bit. Some of the tools will actually recommend specific stops and some you have to do it manually, but in either case you end up with an itinerary telling you where to stop.

Less good cases #

The Palo Alto to Los Angeles trip is basically the best case scenario: California has a lot of EV chargers and you can take Interstate 5 pretty much the whole way, so you're never that far from something. Even so, I tried a few experimental but realistic trips (Palo Alto to Yosemite, Denver to Silverton, Los Angeles to Beaver UT^[8]), and was usually able to find some kind of route. There's even an Electrify America charger at the Days Inn in Beaver, so you're not stuck at 10% when you arrive. With that said, you could easily spend a lot of time in gas station and Walmart parking lots.

Probably the worst case is when you are headed to somewhere remote and there may not be a charger, so you need to plan for a round trip. For instance, Lone Pine California doesn't really have anything in the way of non-Tesla chargers, and there are only two stations on the way:

A Chargepoint L2 that might have one L3 port in Beatty
A pair of non-networked L2 plugs in Stovepipe Wells

Honestly, this would all leave me feeling pretty antsy and I'm not sure I'd want to do that trip in an EV that didn't have a really long range. You don't want to be stuck out in the middle of Death Valley with a dead battery.

Summing Up and the Future #

The bottom line is that neither an EV nor an ICE vehicle is overall better in terms of convenience. For day-to-day driving, just having a car which basically never needs to be fueled is clearly a win, so as long as you have a charger at home, it's hard to go wrong with an EV. You just have to remember to charge it every night.

When it comes to road trips, an ICE vehicle is more convenient, but you can close a lot of the gap with some good planning in terms of when you stop and charge. If you try to drive an EV the way you would an ICE vehicle by just driving until you are low on charge and then looking for a charger, you're going to have a much worse experience.

The good news is that the EV charging situation is getting rapidly better on all three fronts: (1) Batteries are getting bigger so you need to charge less frequently; (2) charging is getting faster so it's less of a hassle; and (3) more stations are being built so you have more options in terms of where to charge. As of today I'd feel comfortable doing most road trips on the West Coast in an EV, but there are still a few for which I'd want to rent something else, which seems like a reasonable tradeoff for the other ways in which an EV is better. If you buy an EV in five years or so, I expect there will be very few trips you won't be able to do in it.

I'm talking here just about charging, but obviously there are a lot of ways in which EVs are just plain better, starting with dramatically better driving performance. I'm not here to sell you that, though. ↩︎
For example, the original BMW i3 had a range of less than 100 miles in 2014. ↩︎
The top 4 vehicles are all trucks. ↩︎
As a reference point, a reasonably fit person can put out around 300 W on a bike for an extended period of time. ↩︎
Note that this isn't some scenario where we're using goofy non-metric units. kWh are still defined in a sensible way from the base units, they're just not the SI official way of doing things. Calories (the amount of energy to heat a gram of water by 1^oC) are in a similar position of being a metric but not SI unit that is widely used in specific contexts. ↩︎
Exception: people who can charge at work ↩︎
For non-Tesla owners, this mostly means you want Electrify America, which operates a lot of 150 kW and 350 kW DC chargers. The bad news is that it's not at all uncommon for EV chargers to be broken. ↩︎
Ultrarunners may be sensing a theme here ↩︎

Notes on Post-Quantum Cryptography for TLS 1.2

2024-05-24T00:00:00Z

As mentioned in previous posts, the IETF has decided not to add support for post-quantum (PQ) encryption algorithms to TLS 1.2. In fact, the TLS WG is taking a rather stronger position, namely that it's going to stop enhancing TLS 1.2 more or less entirely, including support for PQ algorithms:

While the industry is waiting for NIST to finish standardization, the IETF has several efforts underway. A working group was formed in early 2013 to work on use of PQC in IETF protocols, [PQUIPWG]. Several other working groups, including TLS [TLSWG], are working on drafts to support hybrid algorithms and identifiers, for use during a transition from classic to a post-quantum world.

For TLS it is important to note that the focus of these efforts is TLS 1.3 or later. TLS 1.2 is WILL NOT be supported (see Section 5).

As I wrote previously, to some extent this is a political position:

One challenge with the story I told above is that PQ support is only available in TLS 1.3, not TLS 1.2. This means that anyone who wants to add PQ support will also have to upgrade to TLS 1.3. On the one hand, people will obviously have to upgrade anyway to add the PQ algorithms, so what's the big deal. On the other hand, upgrading more stuff is always harder than upgrading less. After all, the TLS working group could define new PQ cipher suites for TLS 1.2, and it's an emergency so why not just let use people use TLS 1.2 with PQ rather than trying to force people to move to TLS 1.3. On the gripping hand, TLS 1.3 is very nearly a drop-in replacement for TLS 1.2. There is one TLS 1.2 use case that it TLS 1.3 didn't cover (by design), namely the ability to passively decrypt connections if you have the server's private key (sometimes called "visibility"), which is used for server side monitoring in some networks. However, this technique won't work with PQ key establishment either, so it's not a regression if you convert to TLS 1.3.

In this post, I want to look at what it would actually take to add PQ support to TLS 1.2 and why we probably shouldn't do it (as well as "revise and extend" that last point). This requires going into some more detail about the cryptographic primitives we are working with here as well as the history of TLS key establishment.

Static RSA #

SSLv3 (and later TLS) originally supported two main key establishment modes:

Static RSA
Diffie-Hellman

For a long time by far the most common mode was static RSA, shown below:

TLS 1.2 static RSA mode

The way that this mode worked was that the server's certificate contained a public key for the RSA algorithm. The client then generated a random value (the premaster secret (PMS)) which it encrypted under the RSA public key. The server used its private key to decrypt the PMS, at which point both client and server knew it. They would each derive traffic keys from the PMS (as well as some other components of the handshake) which could be used to protect the traffic. Because the attacker doesn't have the private key it is unable to recover the PMS and therefore will not be able to communicate with the client.

This design has the property that if you know the RSA private key you can decrypt any connection protected with it. This means that an attacker who is able to obtain the private key, for instance by compromising the server, will be able to decrypt any connection that they have recorded, including connections months or years in the past (note that this is the same kind of attack we are worried about with a CRQC, except that a CRQC could recover the key from the handshake without compromising the server).

Ephemeral Diffie-Hellman #

SSLv3 also included a mode based on Diffie-Hellman key exchange:

TLS 1.2 ephemeral DH mode

In this mode, the server generates a Diffie-Hellman key share (public/private key pair) and sends it to the client. In order to authenticate the share, it signs the share using the RSA key, thus proving that the server controls the private key. An attacker who doesn't have the private key will not be able to sign the key share and therefore cannot impersonate the server.

As long as the client and server generate a fresh key share for each connection—which isn't strictly required by the specification, but is common practice—and then delete the private part of the key share after use, then even if an attacker subsequently compromises the server's private signing key, it still won't be able to decrypt connections that happened in the past. This property is called forward secrecy (sometimes "perfect forward secrecy").

In the early days of SSL/TLS deployment, there was a lot of concern about the performance cost of the cryptography and ephemeral DH mode is much more expensive than RSA key exchange (DH itself is expensive and you also have to do the RSA signature), so most servers did static RSA in order to save CPU. Over time, however, a number of factors combined to make forward secret key establishment more attractive:

New Diffie-Hellman variants based on elliptic curves were developed. Elliptic Curve Diffie Hellman Ephemeral (ECDHE) algorithms were much faster than the older finite-field based algorithms and so the marginal cost of doing ECDH was much less important.
Servers got faster so that the cryptography wasn't as big a deal overall.
There was increasing concern about the practical security of non-forward secret algorithms, in part due to the Snowden revelations.

Because of the design of TLS, it was possible to incrementally deploy ECDHE. As described in a previous post, TLS negotiates the key establishment algorithm and many clients already supported ECDHE key establishment, so as soon as the server turned on ECHDE, it would automatically be able to use it with compatible clients. Moreover, RSA has the interesting property that you can use the same key pair for both encryption/decryption and digital signature, so the server could use its existing RSA certificate to authenticate to the client; all it had to do is enable ECDHE.^[1]

Starting in 2013, TLS deployments increasingly used ECDHE for key establishment, as shown in the graph below.

TLS 1.2 key exchange modes over time. From Kotzias et al, 2018.

Because ECDHE is so much faster, it didn't make much of a difference in terms of cost to the server to do so; in fact if you also enabled EC-based signatures using ECDSA, the total cost to the server was actually less than using RSA, though as a practical matter many servers still use RSA certificates (which should also suggest to you that the performance issues are less of a factor now then when SSLv3 was first designed).

TLS 1.3 #

When TLS 1.3 was designed starting in 2013, we had a number of objectives:

Clean up: Remove unused or unsafe features
Improve privacy: Encrypt more of the handshake
Improve latency: Target: 1-RTT handshake for naıve clients; 0-RTT handshake for repeat connections
Continuity: Maintain existing important use cases
Security Assurance: Have analysis to support our work (added slightly later)

In order to address objectives (2) and (3) TLS 1.3 adopted a new handshake skeleton which reverses the order of the DH key shares, as shown below:

TLS 1.3 handshake overview

In TLS 1.3, the client supplies its key share in its first message (the ClientHello) and the server responds with its key share in its first message (ServerHello). As a result, the server is able to start encrypting messages to the client immediately upon receiving the ClientHello, starting with its own certificate (thus concealing the certificate from passive attackers on the wire).^[2] The client can start encrypting as soon as it gets the server's first flight of messages, so after one round trip, which is an improvement over TLS 1.2 in some situations.

This handshake flow is inconsistent with static RSA. Because its the client sends its key share in its first message, it needs to be able to generate it without knowing the server's public key (or key share). This works fine with Diffie-Hellman (and elliptic curve Diffie-Hellman) because the key shares are generated independently of each other, but not with RSA because in RSA the sender has to use the recipient's public key to encrypt. Moreover, because the public key is in the certificate, a static RSA-based handshake makes encrypting the certificate much more difficult, as you need the certificate in order to learn the public key and hence to establish the encryption key.

Finally, static RSA is also quite difficult to implement correctly There have also been a series of adaptive attacks on the RSA implementations in TLS stacks. The general idea is that the attacker probes the server over and over by initiating handshakes and then observing the server's behavior. It can use this technique to gradually learn secret information from the server. For instance the attacker might take the encrypted PMS from some other handshake and send variants of the message until it has recovered the PMS itself.^[3] These attacks take advantage both of implementation issues with RSA and of the fact that server uses the same RSA key over and over, which gives the attacker multiple opportunities to learn small bits of inforation that add up over time (another reason why it's attractive to use a fresh key for each handshake).

Aside: Forward Secrecy and Session Resumption #

You actually need more than just forward secret key establishment to make a forward secret protocol. TLS incorporates a feature called "session resumption" in which a key established in connection 1 can be reused in connection 2, thus saving some of the cost of the key establishment (and authentication). In TLS 1.2, that key is sufficient to decrypt connection 1, so if you implement resumption you don't have forward secrecy as long as the resumption key sticks around, but in TLS 1.3 they keys are generated in such a fashion that the key to connection 2 does not let you decrypt connection 1.

But wait, there's more: some stacks implement session resumption by encrypting the resumption key with a fixed secret and sending that value to the client as a "ticket", thus removing the need for a database. Obviously, as long as that key is around, you also have a forward secrecy issue: if the attacker compromises that key then it can decrypt any tickets it has observed and learn the keys. The impact on this depends on what TLS 1.3 modes you are using. TLS 1.3 has a resumption + DHE handshake mode that provides forward secrecy for resumption while still allowing you to omit the authentication. In addition, TLS 1.3 also includes a "zero-RTT" mode in which the resumption key is used to encrypt the first packet from the client; this doesn't benefit from the resumption + DHE handshake mode because it happens before the DH key establishment.

PQ TLS #

As mentioned previously, PQ is being added to TLS 1.3 by acting as if each PQ algorithm corresponds to a new elliptic curve (group). However, in reality our PQ key establishment algorithms are much more like RSA than Diffie-Hellman. Specifically, they're Key Encapsulation Mechanisms, as shown in the figure below.

KEM overview

As with RSA, in a KEM Bob starts by generating a public/private key pair, (K_pub, K_priv). He sends K_pub to Alice, who then uses a function called Encap and some randomness to produce two values:

A shared random secret value
An associated ciphertext value

She keeps secret and sends ciphertext to Bob, who can then use the Decap function and K_priv to compute secret; at this point Alice and Bob both know it.

Just like with DH, a KEM ends up with both Alice and Bob knowing the secret, but in DH Alice can generate her key share independently of Bob as long as she knows which curve (group) he supports. I.e., it doesn't matter who speaks first and—in protocols which support it—Alice's key share and Bob's could actually cross paths. By contrast with a KEM Alice needs to know Bob's public key first, which means that Alice can't send the ciphertext until she has received the first message from Bob. This is fine with TLS 1.2, but in TLS 1.3 it's a problem because the client speaks first, so we can't use the server's public key.

In order to use a KEM with TLS 1.3, we need to reverse the direction of the KEM, as shown below. The new elements are shown in red and I've omitted the DH elements of the hybrid mode for simplicity.

TLS 1.3 with a KEM

The client generates a public/private key pair and sends the public key to the server in the ClientHello
The server sends the ciphertext to the server in the ServerHello

Reversing RSA #

It's actually possible to deploy RSA this way as well by having the client generate a public key and provide it to the server. Because RSA encryption is very fast and decryption is much slower, this allows you to offload work from the server to the client, which is an advantage in Web scenarios because the clients have to establish far fewer connections. EC crypto has gotten fast enough that we didn't specify this mode for TLS 1.3, but Bittau et al used this trick in tcpcrypt.

This allows you to establish a shared secret in a single round trip. As with DH, the server authenticates to the client by signing the connection transcript, which includes the ciphertext value, thus binding the ciphertext to the server's key. Like DH key establishment, TLS 1.3 key establishment also offers forward secrecy it the client generates a fresh key pair for each connection (because the server's contribution depends on the client's key pair, the server automatically generates a fresh value).

TLS 1.2 #

This brings us to the topic of PQ for TLS 1.2.

If we wanted to add PQ support for TLS 1.2, we would presumably do more or less the same thing as with TLS 1.3, namely pretend that the PQ KEM is a elliptic curve group. Just as with TLS 1.2 DHE mode, this is in the reverse direction from TLS 1.3, with server providing the first chunk of keying material (its public key) and the client generating the ciphertext and sending it to the server.

TLS 1.2 with a KEM

It's actually not clear that this would be safe as-is. The reason is that TLS 1.3 binds the entire handshake transcript to the resulting key by feeding the transcript into the key schedule along with the initial cryptographic shared secret. By contrast, TLS 1.2 only feeds in the random nonces in the ClientHello and ServerHello. The result is that in some circumstances an attacker can arrange that two connections (e.g., one from the client to the attacker and one from the attacker to another server) have the same cryptographic key. This property lead to the Triple Handshake Attack) by Bhargavan, Delignat-Lavaud, Fournet, Pironti, and Strub, which was one of the motivations for the more conservative design of TLS 1.3.

As Deirdre Connolly describes in detail,^[4] KEMs have different properties than ECDHE (in some ways closer to RSA) and so we'd need to analyze precisely how to integrate them with TLS 1.2. I'm not saying it can't be done, but it's not necessarily just a simple matter of crossing out "X25519" in the specs and writing in "ML-KEM". Adapting TLS 1.3 to ML-KEM also requires some thinking but that thinking is already happening and is somewhat easier because of TLS 1.3's more conservative design. Obviously the TLS WG could do that work, but the question is whether it's worth doing, given that we are trying to transition everyone to TLS 1.3.

Why you might want to do PQ for TLS 1.2 anyway #

The basic argument for why you would want to do PQ for TLS 1.2 is that some people might find it difficult to upgrade their deployments TLS 1.3 and much easier to upgrade their TLS 1.2 deployments to do PQ. I'm generally fairly skeptical of these arguments, but I want to walk through them anyway.

Sporadically Maintained Deployments #

The broad argument is that there are a lot of environments that aren't that actively maintained and so upgrading is difficult in general and are kind of stuck on TLS 1.2. For instance, they might be using a TLS library which is updated only for security issues either because the library vendor updates it infrequently or because the library consumer is stuck on an old version.

Consider the (hypothetical) case of a TLS library which has current version 2.0 but also has a version 1.1 which is on long-term support. Version 2.0 supports TLS 1.3 but version 1.1LTS only supports TLS 1.2. A deployment which is on 1.1LTS might hope that the vendor would add PQ support to 1.1LTS even though they weren't going to upgrade it to support TLS 1.3, and that upgrading to 1.1.1LTS would be less disruptive than upgrading to version 2.0.

This doesn't apply to the Web which is generally quite up to date—and which is in the process of transitioning to TLS 1.3—but there are of course lots of environments which are much slower to upgrade and arguably might have more trouble upgrading (Peter Gutmann is one of the main advocates of this view.) I do have some sympathy for this perspective, but at the end of the day one of the costs of using software is you have to upgrade it—if only to fix the inevitable vulnerabilities—and I don't think it's unreasonable to expect people to upgrade in order to get a major change like PQ support rather than expecting the rest of the world to do a lot of work to make it slightly easier for them.

I want to emphasize that this is (almost) exclusively a software issue; as I said above TLS 1.3 is intended as a drop-in replacement for TLS 1.2, meaning that in most cases you should just be able to update your TLS stack, and get TLS 1.3 as soon as the other side updates.

Passive Decryption #

As I said, TLS 1.3 is intended to be a drop in replacement for TLS 1.2. There is, however, one notable and high profile exception, what's called TLS visibility. The problem statement goes something like this. Imagine you operate an encrypted Web server of some kind and you want to monitor traffic between users and your server. There are a number of reasons you might want to do this, such as:

Debugging problems with your server.
Looking for malicious activity (attacks by clients connecting to the server).
Measuring the performance of the server on live traffic.

It's possible to do all of these things by instrumenting the server, but not all servers have great instrumentation and what if the server is the source of the problem? Another approach is to capture the traffic as it goes over the network (e.g., via port mirroring) and then decrypt it using the RSA private key. This can be done entirely passively (i.e., without interfering with the connection) and you can decrypt either in real time or by recording the traffic and then decrypting only the connections of interest. This has the advantage that you don't need to touch the server beyond getting a copy of the private key and you get to dig as deep as you want into whats going on without trusting the server.

However, these techniques don't work if you are using ephemeral Diffie-Hellman (whether of the ordinary or EC variety): knowing the server's private key allows you to impersonate the server but not to decrypt the traffic. Decrypting the traffic requires the DH private key share, which is usually generated internally by the server rather than stored on the disk the way that the long term private key is. Moreover, if the server uses a fresh DH share for every handshake—which is required for forward secrecy—then allowing decryption would require somehow sending the decryption device a copy of every key, which is obviously a lot more difficult than just a copy of a single key.

Although DH establishment became more common, even with TLS 1.2 (see above), that didn't interfere with the use of passive decryption because servers weren't required to enable it. The TLS key establishment mode as long as there is a significant population of servers which only do static RSA, clients had to support static RSA, which meant that servers could insist on it, thus making allowing this kind of passive decryption to work fine with TLS 1.2. Of course, those servers wouldn't be following best security practice in terms of protecting user traffic, but it was still technically possible.

By contrast, because TLS 1.3 doesn't support static RSA at all, it's incompatible with naive passive inspection. Of course servers could just refuse to negotiate TLS 1.3, but staying on TLS 1.2 forever isn't really an answer, especially now that the IETF has decided not to add new features to TLS 1.2. When TLS 1.3 was being finalized, a number of organizations—especially high sensitivity sites like banks or health insurance companies—raised concerns about losing this tool, but at the end of the day the TLS working group felt that forward secrecy was an important security feature and that re-adding static RSA would have been way too disruptive to the resulting protocol.

It is possible to adapt TLS 1.3 to enable passive decryption even with Diffie-Hellamn. There are at least three obvious approaches here:

Have the server re-use the same Diffie-Hellman key share for multiple connections. The server can then save a copy of the key somewhere (e.g., on disk) and the administrator can send a copy to the monitoring device.
Have the server send copies of the per-connection keys (hopefully in some secure fraction) to the monitoring device, which can use them to decrypt the connections.
Have the server deterministically generate the per-connection DH key shares based on a static secret and information in the connection. You then provision the monitoring device with the static secret and it can compute the DH key shares for itself.

None of these are particularly difficult to implement but they also require modifying the TLS stack in a way that isn't required to provide service to the client but only to provide the ability to passively decrypt. Moreover, options (2) and (3) also require specifying exactly how the keys will be transmitted (2) or computed (3), both of which have the potential to create severe vulnerabilities (up to perhaps complete compromise of every connection) if they are done incorrectly.

It's really important to understand at this point that what makes passive inspection work in the first place is basically just due to an idiosyncracy of the way that static RSA mode works. Specifically, you need to configure the server with the private key and the private key is also what you need to decrypt the traffic passively. This means that the administrator usually already has the credential in hand and can easily transfer it to the monitoring device without any special affordance by the server or TLS stack implementor. What we've seen over the past 8 or so years is that the implementors are much less enthusiastic about building special features to enable passive decryption. So, for instance, BoringSSL and OpenSSL don't seem to implement any of them. However, NIST has been running an initiative around this, specifying techniques (1) and (2), and it seems like some big vendors (e.g., F5), are participating. I don't know if they are actually planning to ship anything.

PQ and Passive Decryption #

This brings us to the topic of passive decryption for PQ. The obvious way to use PQ—just swapping it for DH—is not really compatible with this kind of passive decryption.^[5]

This is most obvious with TLS 1.3: because the server generates its ciphertext based on the client's public key, there's simply no server private key to provide to the decryption device, because a fresh key is generated for each connection. Unlike with DH, it's not even possible to generate a single static key pair and reuse it (technique (1) above) because the Encap() operation depends on the client's public key.

The situation is slightly more complicated with TLS 1.2 because the server rather than the client generates the private key. In principle, the server could just generate a single ML-KEM key and use it indefinitely (similar to approach (1) above), but, as with approach (1), there is no real reason for the server to do this other than to enable visibility. Specifically:

Re-using the same ML-KEM key breaks forward secrecy, so it's less secure.^[6]
It's actually more programming work to remember the ML-KEM key between transactions rather than just generate a new one, especially in a multi-threaded system.
You need to build some mechanism to allow either export or import of the ML-KEM key, which you wouldn't otherwise need.

Moreover, because the most common way to deploy PQ algorithms is as a hybrid, you'd need to also do something for DH, which TLS 1.2 deployments that are set to allow passive decryption don't usually currently do now, because they just do static RSA instead. The bottom line, then, is that it's not really significantly easier to support passive decryption ("visibility") for TLS 1.2 with PQ than it is for TLS 1.3, so that's not really a very good argument for porting PQ into TLS 1.2.

The Bigger Picture #

Designing and maintaining cryptographic protocols is a lot of work, and TLS 1.3 and TLS 1.2 are different enough that it's obviously desirable only to maintain one of them even if TLS 1.3 were no better than TLS 1.2. As should be clear at this point, it's technically possible to add support for PQ to TLS 1.2, but it's not trivial. That in and of itself doesn't mean it's not worth doing, but it has to pass the cost/benefit test. For instance, there might be some important application where it was hard to swap TLS 1.3 in for TLS 1.2. However, as far as I can tell that's not true. While there are deployments stuck on TLS 1.2, they should be move to TLS 1.3 without significant impact on their existing functionality, although it might involve some inconvenience in terms of software. It would be better if they were to do so rather than the IETF community needing to maintain TLS 1.2 indefinitely.

This is not considered good practice in modern systems, but it's very convenient in this particular situation. ↩︎
Of course, active attackers can replay the ClientHello with their own key and get the server to encrypt the certificate to them, but this is more work than passively snooping. TLS Encrypted ClientHello addresses this issue. ↩︎
There is also a version in which the attacker can extract a signature on a specific value. ↩︎
See Cremers, Dax, and Medinger for more on how to think about the security properties of KEMs. ↩︎
As an aside, there is actually a proposal called AuthKEM that adapts TLS 1.3 to use a handshake more like static RSA but with KEMs in the place of RSA. However, that doesn't change the situation for TLS 1.2, and everyone assumes that AuthKEM would be run in a forward secret mode where the client also provided a KEM public key. ↩︎
In addition, reusing the same key makes remote side channel attacks on the key (like those we see with RSA) easier. If you use a different key for each transaction, then the attacker only has one chance to learn about it so the side channel has to leak a lot more information. ↩︎

How to manage a quantum computing emergency

2024-04-15T00:00:00Z

Illustration by Kate Hudson with MidJourney and Photoshop AI.

Recently, I wrote about how the Internet community is working towards post-quantum algorithms in case someone develops a cryptographically relevant quantum computer (CRQC). That's still what everyone is hoping for, but nobody really know when or even if a CRQC is developed, and even in the best case the transition is going to take a really long time, so what happens if someone builds a CRQC well in advance of when that transition is complete? Clearly, this takes the situation that is somewhere between non-urgent and urgent to one that is outright emergent but that doesn't mean that all is lost. In this post, I want to look at what we would do if a CRQC were to appear sooner rather than later. As with the previous post, this post primarily focuses on TLS and the Web, though I do touch on some other protocols.

Obviously there are a lot of scenarios to consider and "cryptographically relevant" is doing a lot of work here. For instance, we typically assume that the strength of X25519 is approximately 2¹²⁸ bits. A technique which brought the strength down to 2⁸⁰ would be a pretty big improvement as an attack and would definitely be "cryptographically relevant" but would also still leave attack quite expensive; it probably wouldn't be worth using this kind of CRQC to attack connections carrying people's credit cards, especially if each connection had to be attacked individually, at a cost of 2⁸⁰ operations each time. This would obviously be a strong incentive to accelerate the PQ transition, but probably wouldn't be an outright emergency unless you had particularly high value communications.

For the purpose of this post, let's assume that:

This is a particularly severe attack, bringing the existing algorithms within range of commercial attackers in a plausible time frame, whether that's days or real time.^[1]
It happens at some point in the next few years, while there is significant deployment but by no means universal deployment of PQ key establishment and minimal if any deployment of PQ signatures and certificates.

This is close to a worst-case scenario in that our existing cryptography is severely weakened but it's not practical to just disable it and switch to PQ algorithms. In other words ~~isn't~~ it's an emergency and we leaves us with a fairly limited set of options. [Corrected, 2024-04-15]

Key Establishment #

The first order of business is to do something about key establishment. Obviously if you haven't already implemented a PQ-hybrid or pure PQ algorithm, you'll want to do that ASAP, selecting whichever one is more widely deployed (or potentially doing both if some peers do one and some the other).

Once you've added support for some PQ algorithm, the question is whether you should disable the classical algorithm. The naive answer is "no": even if the classical algorithm severely weakened, any encryption is better than no encryption. In reality, the situation is a bit more complicated.

Recall that in TLS, the client proposes a set of algorithms and the server selects one, as shown below:

TLS handshake sketch

The idea here is that the server gets to see what algorithms the client supports and pick the best algorithm. As long as the client and server agree on the algorithm ranking, then this will generally work fine. However, it's possible that the servers and clients will disagree, in which case the server's preferences will win.^[2]

This actually happened during the transition away from the RC4 symmetric cipher. After a series of papers showed significant weaknesses in RC4, the browsers decided they preferred AES-GCM. Unfortunately, many servers preferred RC4, and so the result was that even when both clients and servers supported RC4 and AES-GCM, many servers selected RC4. In response, browsers (starting with IE^[3] adopted a system in which they first tried to connect without offering RC4, and if that failed they then retried with it, as shown below:

TLS fallback to RC4

The result was that any server which supported AES-GCM would negotiate it, but if the server only supported RC4, the client could still connect. This also made it possible to measure the fraction of servers which supported AES-GCM, thus providing information about about how practical it was to disable RC4.

Downgrade Attacks #

So far we've only considered a passive attacker, but what about an active attacker? TLS 1.3 is designed so that the signature from the server protects the handshake, so as long as the weakest signature algorithm supported by the client is strong, an active attacker can't tamper with the results of the negotiation.^[4] The fallback system described above weakens this guarantee a little bit in that the attacker can forge an error and force the client into the fallback handshake. However, the client will still offer both algorithms in the fallback handshake, so the attacker can't stop the server from picking its preferred algorithm; it can just stop the client from getting the client's preferred algorithm by manipulating the first handshake.

Of course, if the server's signature isn't strong—or more properly the weakest signature algorithm the client will accept isn't strong—then the the attacker can tamper with the negotiated key establishment algorithm. However, an attacker who can do that can just impersonate the server directly, so it doesn't matter what key establishment algorithms the client supports.

Maybe it's better to fail open #

The bottom line here is that as long as you're not under active attack, TLS will deliver the strongest^[5] algorithm that's jointly supported by the peers, and, if you're under active attack by an attacker who can break signature algorithms, then all bets are off. That's probably the best you can do if you're determined to connect to the server anyway. But the alternative is, don't connect.

The basic question here is how sensitive the communication with the site is. If you're just looking up some recipes or reading the news, then it's probably not that big a deal if your connection isn't secure (in fact, people used to regularly argue that it wasn't necessary at all, though that's obviously not a position I agree with). On the other hand, if you're doing your banking or reading your e-mail, you probably really don't want to do that unencrypted. This isn't to say that we don't want ubiquitous encryption—we do—or that it's not possible for even innocuous seeming communications to be sensitive—it is—but to recognize that this scenario would force us to make some hard choices about whether we're willing to communicate insecurely if that's the only option. These are hard choices for a human and even harder for a piece of software like a browser (it's much easier for a standalone mail client, obviously).

This is actually a situation where ubiquitous encryption makes things rather more difficult. Back when encryption was rare, it was a reasonable bet that if a site was encrypted then the operators thought it was particularly sensitive. But now that everything is encrypted, it's much harder to distinguish whether it's really important for this particular connection to be protected versus just that it's good general practice (which, again, it is!).

One thing that may not be immediately obvious is that an insecure connection can threaten not just the data that you are sending over it, but other data as well. For example, if you are reading your email, you're probably authenticating with either a password (with a normal mail client) or a cookie (with Webmail). Both of these are just replayable credentials, so an attacker who can decrypt your connection can impersonate you to the server and download all your email, not just the messages you are reading now As discussed above, an attacker who recorded your traffic in the past might still be able to recover your password, but this is a lot more work than just getting it off the wire in real time.

Signature Algorithms #

Of course, none of this does anything to authenticate the server, which is critical for protecting against active attack. For that we need the server to have a certificate with a PQ algorithm and the client to refuse to trust certificates that either (1) are signed with a classical algorithm or (2) contain keys for a classical algorithm. Importantly, it's not enough for the server to stop using a PQ classical [Fixed 2024-04-15] certificate, because the server doesn't have to be part of the connection at all. In fact, even if the server doesn't have a PQ certificate, attack is still possible because the attacker can just forge the entire certificate chain.

As described in my previous post, the first thing that has to happen is that servers have to deploy PQ certificates. Without that, there's not much the clients can do to defend themselves. In this case, I would expect there to be a huge amount of pressure to do that ASAP, despite the serious size overhead issues with PQ certificates noted by Bas Westerban and David Adrian. After all, it's better to have a slow web site than one that's not secure or that people can't connect to.

For the same reason, I would expect there to be a lot less concern about the availability of hardware security modules (HSMs) for the new PQ algorithms or whether the algorithms in question have gone through the entire IETF standards process [Added link 2024-04-15]. Those are both good things, but having PQ safe certificates is more important, so I would expect the industry to converge pretty fast on a way forward.

Once there is some level of PQ deployment, clients can start distrusting the classical algorithms (before that, there's not much point). However, as with key establishment: if the client distrusts classical algorithms than it won't be able to connect to any server that doesn't have a PQ certificate, which will initially be most of them, even in the best case. This is frustrating because it means that you have to choose between failure to connect or having protection against active attack. What you'd really like is to have the best protection you can get, i.e.,

Only trust PQ algorithms for sites that have PQ certificates (so you aren't subject to active attack).
Allow classical algorithms for sites without PQ certificates (so you at least get protection against passive attack).

Actually, there are three categories here:

Sites which are so sensitive that you shouldn't connect to them without a PQ certificate (e.g., your bank).
Sites which are known to have a PQ certificate and so you shouldn't accept a classical certificate (probably big sites like Google).
Sites that aren't that sensitive and so you'd be willing to connect to them with a classical certificate (e.g., the newspaper).

The problem is being able to distinguish which category a site falls into. Usually, we don't try to draw this kind of distinction, and just let the site tell us if it wants TLS, but this isn't a usual situation, so it's worth exploring some inconvenient things.

PQ Lock #

The most obvious thing is to have the client remember when the server has a PQ certificate and thereafter refuse to accept a classical certificate. Unfortunately, this idea doesn't work well as-is, because server configurations aren't that stable. For instance:

A site might roll out PQ and then have problems and disable it.
A site might have multiple servers and gradually roll out PQ certificates on one of them.
A site might be served by more than one CDN with different configurations.

Note that in cases (2) and (3) the client will not generally be aware that there are different servers, as they have the same domain name, and IP addresses aren't reliable for this purpose (and, in any case, are likely under control of the attacker because DNS isn't very secure). An in case (1) it's actually the same server.

In any of these situations you could have a situation where the client contacts the server, get a PQ certificate, and then come back and get a classical certificate, so if the client just forbids any use of classical after PQ, this would create a lot of failures. Fortunately, we've been in this situation before with the transition to HTTPS from HTTP, so we know the solution: the server tells the client "from now on, insist on the new thing," and the client remembers that.

With HTTP/HTTPS, this is a header called HTTP Strict Transport Security (HSTS) and has the semantics "just do HTTPS from now on with this domain". It would be straightforward to introduce a new feature that had the semantics "just insist on PQ from now on with this domain". In fact, the HSTS specification is extensible, so if you wanted to also insist on HTTPS (a good idea!), you could probably just add a new directive saying "also require PQ". It would also be easy to add a new HTTP header that said "if you do HTTPS, require PQ", as HTTP is nicely extensible and unknown headers are just ignored.

One of the obvious problems with an HSTS-like header—and in fact with HSTS itself—is that it relies on the client at some point connecting to the server while not under attack. If the attacker is impersonating the server then they just don't send the new header. They can even connect to the real server and send valid data otherwise, but just strip the header. This is still a real improvement, though, as the attacker needs to be much more powerful: if the client is ever able to form a secure connection to the true server, then it will remember that PQ is needed and be protected against attack from then on, even if it's not protected from the beginning.

Preloading #

It's possible to protect the user from active attack from the very beginning by having the client software know in advance which servers support PQ. There is already something that browsers do with HSTS, where it's called "HSTS preloading". Chrome operates a site where server operators can request that their sites be added to the "HSTS preload list". The site does some checking to make sure that the server is properly configured and then Chrome adds it to their list. In principle, other browsers could do this themselves, but in practice, I think they all start from Chrome's list.

In principle, we could use a system like this for PQ preloading as well, but there are scaling issues. The HSTS preload list is fairly sizable (~160K entries as of this writing), but this only represents a small fraction of the domains on the Internet. For example, Let's Encrypt is currently issuing certificates for more than 100 million registered domains and over 400 million fully qualified domains. If we assume that sites which have moved to PQ are aggressive about preloading—which they should be for security reasons—we could be talking about 10s of millions of entries. The current Firefox download is about 134 MB, so we're probably looking at a nontrivial expansion in the size of a browser download to carry the entire preload list, even with compact data structures. On the other hand, it's probably not totally prohibitive, especially in the early years when there is likely to not be that much preloading.

There may also be ways to avoid downloading the entire database. For instance, you could use a system like Safe Browsing which combines an imperfect summary data structure with a query mechanism, so that you can get offline answers for most sites, but then will need to check with the server to be sure. The Safe Browsing database has about 4 million entries—or at least did back in 2022—so you probably could repurpose SB-style techniques for something like this, at least until PQ certificates got a lot more popular.^[6] The privacy properties of SB-style systems aren't as good as just preloading the entire list, so there's a tradeoff here, so it would be a matter of figuring out the best of a set of not-great options.

Of course, browser vendors don't need to wait for servers to ask to be preloaded; they could just add them proactively, for instance by scanning to see which sites advertise the PQ-only header, or even which sites just support PQ algorithms. Obviously there's some risk of prematurely recording a site as PQ-only, but there's also a risk in allowing non-PQ connections in this situation, The higher the proportion of servers that support these algorithms, the more aggressive browser vendors can be about requiring PQ support, and the more readily they can add servers to the list, even if the server hasn't really directly signaled that it wants to be included.

Site Categorization #

There are other indicators that can be used to determine whether a site is especially sensitive and so needs to be reached over a PQ-secure connection or not at all. This could happen both browser side or server side based on a variety of indicia such as requiring a password or being a medical or financial site. One could even imagine building some kind of statistical or machine learning model to determine whether sites were sensitive. This doesn't have to be perfect as long as it's significantly better than static configuration.

Reducing overhead #

Obviously, we would be in a better position if it weren't so expensive to use PQ signature algorithms. Mostly, this is about the size of the signatures. As noted in Bas's post, there are a number of possible options for reducing the size overhead, these include:

All of these mechanisms are designed to be be backward compatible, meaning that the client and the server can detect if they both support the optimization and use it, but can fall back to the more traditional mechanisms if not. The first two mechanisms work with existing WebPKI certificates, and would work with PQ certificates as well, requiring only that the client and server software be updated to support the optimization.

The last mechanism ("Merkle tree certificates") replaces existing WebPKI certificates, and so would require servers to get both a PQ WebPKI certificate and a PQ Merkle tree certificate, and conditionally serve the right one depending on the client's capabilities. This is obviously more work for the server operator (the same for the browser user). On the other hand, if server operators are already going to have to change their processes to get both PQ and classical certificates, it would be a convenient time to also change to get a Merkle tree certificate.

HTTP Public Key Pinning #

Obviously, in addition to recording that the server supported PQ algorithms you could remember the server's PQ signature key and insist that the server present that in the future (this is how SSH works). In the past the TLS community explored more flexible versions of this approach with a technique called HTTP Public Key Pinning. HPKP was eventually retired, in part due to concerns about how easy it was to render your site totally unusable by pinning the wrong key and in part because mechanisms like Certificate Transparency seemed to make it less important.

One might imagine resurrecting some variant of HPKP for a PQ transition as a stopgap during a period where sites are prepared to deploy PQ but CAs can't issue them yet. This wouldn't be quite the same because the server would have to authenticate with its classical certificate but then pin the PQ key, which would be accepted without a certificate chain, which HPKP doesn't support. My sense is that we could probably manage to get some issuance of PQ certificates faster than we could design a new HPKP type mechanism and get it widely deployed, but it's probably still an option worth remembering in case we need it.

What about TLS 1.2? #

One challenge with the story I told above is that PQ support is only available in TLS 1.3, not TLS 1.2.^[7] This means that anyone who wants to add PQ support will also have to upgrade to TLS 1.3. On the one hand, people will obviously have to upgrade anyway to add the PQ algorithms, so what's the big deal. On the other hand, upgrading more stuff is always harder than upgrading less. After all, the TLS working group could define new PQ cipher suites for TLS 1.2, and it's an emergency so why not just let use people use TLS 1.2 with PQ rather than trying to force people to move to TLS 1.3. On the gripping hand, TLS 1.3 is very nearly a drop-in replacement for TLS 1.2. There is one TLS 1.2 use case that it TLS 1.3 didn't cover (by design), namely the ability to passively decrypt connections if you have the server's private key (sometimes called "visibility"), which is used for server side monitoring in some networks. However, this technique won't work with PQ key establishment either, so it's not a regression if you convert to TLS 1.3.

Non-TLS systems #

Much of what I've written above applies just as well to many other interactive security protocols such as IPsec or SSH,^[8] which are designed along essentially the same pattern. Any non-Web interactive protocol is likely to have an easier time because there will be a fairly limited number of endpoints you need to connect to, so you can more readily determine whether the other side has upgraded or not. As a concrete example, SSH depends on manual configuration of the keys (the server's key is usually done on a "trust on first use" basis when the client initially connects). Once that setup is done, you don't need to discover the peer's capabilities. By contrast, a Web browser has to be able to connect to any server, including ones it has no prior information about.

There is a huge variety of other cryptographic protocols and our ability to recover from a CRQC would vary a lot. Especially impacted will be anything which relies on long-term digital signatures, as they are hard to replace. A good example here is cryptocurrency systems like Bitcoin which rely on signatures to effect the transfer of tokens: if I can forge a signature from you then I can steal your money. The right defense against this is to replace your classical key with a PQ key (effectively to transfer money to yourself), but we can assume that a lot of people won't do that in time, and as soon as a CRQC is available, any future transaction becomes questionable.

The situation around Bitcoin seems to actually be pretty interesting. The modern way to do Bitcoin transfers is to transfer them not to a public key but the hash of a public key (called pay to public key hash (p2pkh)). As long as the public key isn't revealed, then you can't use a quantum computer to forge a signature. The public key has to be revealed in order to transfer the coin, but if you don't reuse the key, then there is only a narrow window of vulnerability between the signature and when the payment is incorporated into the blockchain (which doesn't depend on public key cryptography). However, according to this study by Deloitte, about 25% of Bitcoins are vulnerable to a CRQC, so that's not a great situation.

What if the PQ algorithms aren't secure? #

All of the above assumes that we have public key algorithms that are in fact secure against both classical and quantum computers. In that case, our problem is "just" transitioning from our insecure classical algorithms to their more-or-less interface compatible PQ replacements. But what happens if those algorithms turn out to be ~~secure~~ insecure [Corrected 2024-04-15] after all. In that case we are in truly deep trouble. Obviously the world got on OK for centuries without public key cryptography, but now we have an enormous ecosystem based on public key cryptography that would be rendered insecure.

Some of those applications may just get abandoned (maybe we don't really need cryptocurrencies...) but it would obviously be very bad if nobody was able to safely buy anything on Amazon, use Google docs, or that your health care records couldn't be transmitted securely, so there's obviously going to be a lot of incentive to do something. The options are pretty thin, though.

Signature #

We do have at least one signature algorithm which we have reasonably high confidence is secure: hash signatures, which NIST is standardizing as "SLH-DSA". Unfortunately, the performance is extremely bad (we're talking 8KB signatures). On the other hand, slow and big signature algorithms are better than no signature algorithms at all, so there are probably some applications where we'd see some use of SLH-DSA.

Key Establishment #

While the signature story is bad, but the key establishment story is really dire. The main option people seem to be considering is some variant of what I've been calling intergalactic Kerberos. Kerberos is a security protocol designed at MIT back in the 80s and in its original form works by having each endpoint (user, server) share a pairwise symmetric^[9] key with a key distribution server (KDC).

A high level view of Kerberos

At a high level, when Alice wants to talk to Bob, she contacts the KDC using a message encrypted with her pairwise key K_a and tells it that it wants to contact Bob. The KDC creates a new random key R_ab and then sends Alice two values:

R_ab
A copy of R_ab encrypted under Bob's key (K_b), i.e., E(K_b, {Alice, K_ab}). In Kerberos terms this is called a "ticket".

Alice can then contact Bob and present the ticket. Bob decrypts the ticket and recovers K_ab. Now Alice and Bob share a key they can use to communicate. Note that this all uses symmetric cryptography, so it's not vulnerable to attacks on our PQ algorithms. You can wire up this kind of key establishment mechanism into protocols like TLS (TLS 1.2 actually has Kerberos integration, but it wasn't ported into TLS 1.3) and use them in something approximating the usual fashion, albeit in a much clunkier fashion.

Merkle Puzzle Boxes #

It turns out that there actually sort of is a public key system that doesn't depend on any fancy math and so we can have reasonable confidence in how secure it is. In fact, it's the original public key system, invented by Ralph Merkle. This post is already pretty long, so if you're interested check out the Wikipedia page. The TL;DR is that it's probably not that practical because (1) public key sizes are enormous and (2) it only offers the defender a quadratic level of security (if the defender does work N the attacker does work N² to break it), which isn't anywhere near as good as other algorithms. There seem to be some quantum attacks on puzzle boxes (though I'm not sure how good they are in practice), but there is also a PQ variant.

This kind of design has a number of challenges. First, it's much harder to manage. In a public-key based system clients don't need to have any direct relationship with the CA, because they just need the CA's public key. In a symmetric key system, however, each client needs a relationship with the KDC in order to establish the shared key. This is obviously a huge operational challenge.

The basic challenge with this kind of design is that the KDC is able to decrypt K_ab and hence any traffic between Alice and Bob. This is because the KDC is providing both authentication and key establishment, unlike with a public key system like the WebPKI where the CA provides authentication but the endpoints perform key establishment using asymmetric algorithms. This is just an inherent property of symmetric-only systems, and it's what we're reduced to if we don't have any CRQC-safe asymmetric algorithms.

One potential mitigation is to have multiple KDCs and then Alice and Bob use a key derived from exchanges with those KDCs. In such a system, the attacker would need to compromise all of the KDCs in use for a connection in order to either (1) impersonate one of the endpoints or (2) decrypt traffic. Recently we've started to see some interest in symmetric key type solutions along these lines, including a draft at the IETF and a recent blog post by Adam Langley.^[10] My sense is that due to the drawbacks mentions above, this kind of system isn't likely to take off as long as we have PQ algorithms, even if they're not that efficient. However, if the worst happens and we don't have asymmetric PQ algorithms at all, we're going to have to do something, and symmetric-based systems will be one of the options on the table.

The Bigger Picture #

As I mentioned in the previous post, we shouldn't expect the PQ transition to happen very quickly, both because the algorithms aren't all that we'd like and because even with better algorithms the transition is very disruptive. However, because the Internet is so dependent on cryptography and in particular public key cryptography, there would be enormous demand to do something if a CRQC were to be developed any time soon. When compared to the alternative of no secure communications at all, a lot of options that we would have previously considered unattractive or even totally non-viable would suddenly look a lot better, and I would expect the industry to have to make a lot of tough choices to get anything at all to work while we worked out what to do in the long term.

This distinction does matter for some attacks, but even if it's days, the situation is really bad. ↩︎
Unless the server decides to defer to the client, of course. ↩︎
Thanks to David Benjamin for help with the history of this technique. ↩︎
This is a new feature of TLS 1.3. In TLS 1.2, the security of the handshake depended on the weakest common key establishment algorithm, which left it vulnerable to attacks if the weakest algorithm was breakable in real-time. ↩︎
Again with the caveats above about preferences ↩︎
The worst case is when about 1/2 of the sites want to be preloaded; once you get to well over 50%, you can instead publish the list of non-preloaded sites, though this is logistically a bit trickier, as you'd need a list of every site. You can get this list from Certificate Transparency, though, which is what CRLite does. ↩︎
Obviously, there's an element of "we're trying to avoid maintaining TLS 1.2 and we want people to upgrade" going on here, but there's also a small technical advantage here: although TLS 1.2 and TLS 1.3 both authenticate the server by having the server sign something, in TLS 1.2 the signature only covers part of the handshake (specifically, the random nonces and the server's key), which means that the signature doesn't cover the key establishment algorithm negotiation. This means that an attacker who can break the weakest joint key establishment algorithm can mount a downgrade attack, forcing you back to that weakest algorithm. However, we could presumably address this by remembering that both key establishment and authentication are PQ only. ↩︎
Note: QUIC uses the TLS 1.3 handshake under the hood, so it has roughly the same properties as TLS 1.3 ↩︎
In original Kerberos, a DES key. ↩︎
Langley's design actually assumes that PQ algorithms work but are too inefficient to use all the time, so you use it to bootstrap the symmetric keys with the KDC. ↩︎

Design choices for post-quantum TLS

2024-03-30T00:00:00Z

It's a cruel irony that just as encryption is finally becoming ubiquitous, quantum computers threaten to tear it all down.

Firefox HTTPS usage

The technical details aren't that important (see here for some background), but the TL;DR version is that many of our cryptographic algorithms are designed to be difficult to break using "classical" computers (which is to say the kind we have now) but may not be difficult to break if you have a quantum computer, which takes advantage of quantum mechanical effects,^[1] then it might be possible to efficiently break these algorithms.

I say might because the situation is somewhat uncertain in that while people have built quantum computers, they are currently quite small, nowhere near what you would need to mount an attack on a modern cryptographic algorithm. There's a lot of money being invested in developing quantum computers, but nobody really knows when we'll have what's called a cryptographically relevant quantum computer (CRQC), which is to say one which could mount practical attacks on the cryptosystems in wide use, or whether it's possible to build one at all.

There was the time Blueshell had a humor fit at Pham’s faith in public key encryption, and Ravna knew some stories of her own to illustrate the Rider’s opinion.

— Vernor Vinge, "A Fire Upon The Deep"

However, if a CRQC were to exist, the impact would be catastrophic, potentially rendering nearly every existing use of cryptography insecure. Specifically, it would break the "asymmetric" algorithms we use to authenticate other Internet users and to establish cryptographic keys, so an attacker would be able to impersonate anyone and/or recover the keys used to encrypt data. A CRQC probably won't have that big an impact on the actual "symmetric" encryption used to encrypt the data itself, but if you have the key you can just decrypt it with a regular computer, so that's not much in the way of comfort.

For that reason, researchers have started developing what's often called post-quantum (PQ) cryptographic algorithms which are designed to resist attack by quantum computers, or more properly, for which there are no known quantum algorithms which would allow you to break them (which isn't to say that those algorithms don't exist). After a fairly long competition, NIST published new standards for post-quantum key establishment (ML-KEM) and digital signature (ML-DSA)^[2] and protocol designers and implementors are starting to look at how to adapt their protocols to use them.

In this post, I want to look at the challenges around that transition, focusing on the situation for TLS and the WebPKI, though some of the same concerns apply to other settings.

Why not just convert right now? #

The obvious question is why not just convert now, as we did when changing from older algorithms like RSA to newer ones based on elliptic curves (EC). The reason is that the new PQ algorithms are not clearly better than the EC algorithms that dominate the space now. Specifically:

In many cases, performance is worse,: in terms of CPU, key, ciphertext, or signature size. For instance, ML-KEM is faster than X25519 (the most popular current EC key establishment algorithm) but the keys are much bigger, over 1000 bytes compared to 32 bytes. The situation is much worse for signatures, where there really isn't any standardized algorithm which isn't a big regression from EC-based signatures in one way or another, and due to the large number of signatures that need to be carried in a typical protocol exchange, the size issue is a big deal, especially as there appear to be compatibility issues. These posts by Bas Westerban from Cloudflare and David Adrian from Chrome does a good job of covering the state of play of the various algorithms, but in general none of them has a better overall performance profile than EC.
We're not sure that they're secure.: There has been quite a bit of security analysis on the particular EC variants that are in wide use and while there has been a lot of work on the problems underlying ML-KEM and ML-DSA, my understanding is that there is still real uncertainty about how secure these systems are against classical computers. Daniel J. Bernstein (DJB) has been one of the biggest advocates for this view, but much of the industry is sort of antsy about the PQ algorithms.^[3]
We don't know if or even when we'll get a CRQC.: Current quantum computers are very far away from being cryptographically relevant and of course progress is hard to predict. The Global Risk Institute has produced a report with estimates on when we will have a CRQC, with the results shown below:

Global Risk Institute Estimates for a CRQC

For these reasons, industry has generally been pretty cautious about rolling out PQ algorithms.

Threat Model #

Because classical key establishment and digital signature are based on the same underling math problems, the impact of a CRQC on these algorithms is also the same—which is to say very bad. However, the security impact is very different.

Key Establishment #

When you encrypt traffic, you want that traffic to remain secret for the valuable lifetime of the data. For instance, if you are encrypting your credit card number, you want it to remain secret as long as that credit card is still valid. Lots of information has very long lifetimes during which people want it to remain secret; presumably you wouldn't be happy with people learning your medical history 6 months from now.

When you encrypt traffic using keys derived via an asymmetric key-based establishment protocol—as with TLS—this means that you need that key establishment algorithm to also be secure for the lifetime of the data. In this context, that means that data that is being sent now using keys established with EC algorithms—which is to say most of it—might be revealed in the future if someone develops a CRQC. An attacker might even deliberately capture a lot of traffic on the Internet, betting that eventually a CRQC will be developed and they can decrypt it (this is called a "harvest now, decrypt later" attack).

For this reason, doing something about the threat of a CRQC to the security of key establishment is a fairly high priority, because every day that you use non-PQ algorithms you're adding to the pile of data that might eventually be decryptable. This is especially true because transitions can take a really long time even in the best case. For example, TLS 1.2 first added support for modern AEAD algorithms such as AES-GCM in 2008, but Firefox and Chrome didn't even add support for TLS 1.2 until 2013, and AEAD cipher suites didn't outnumber the older CBC-based ciphers until 2015. So, even in the best case, we're still going to be sending a lot of non quantum safe traffic for years to come.

Negotiated cipher suites over time. From Kotzias et al., 2018

Digital Signature #

By contrast, a digital signature algorithm only needs to be secure at the time you make decisions based on the validity of the signature; in TLS this is at the time the connection is established. If a CRQC that breaks your signature algorithm is developed 30 second after your TLS connection is established, your data remains secure as long as you established a key using some non-vulnerable method (of course, your next connection won't be secure, so you'll want to do something about that).

Signatures for Object Security #

Note that the situation is different for signatures in object-based protocols like e-mail, because people want to be able to validate the signature long after the message was sent. Thus, having a PQ signature does help, even if paired with a classical signature, because it allows the signature to survive subsequent development of a CRQC.

It's also possible to allow a classical algorithm to survive the development of a CRQC by timestamping the signature to demonstrate that the classical signature was created prior to the development of the CRQC. For instance, you could arrange to register a hash of the signed document with some blockchain type system. You can then present the signed document paired with the timestamp proof (note that the timestamp service doesn't need to verify the signature itself; it's just vouching that it saw the document at time X.). The relying party can verify that the signature was made prior to the development of the CRQC, in which case it is presumably trustworthy.

For this reason, doing something about digital signatures is generally considered to be a lower priority, although of course it will be really inconvenient if a CRQC is built and we have no deployment of any PQ signature algorithms, as everyone will be scrambling to catch up. It's of course possible that someone—most likely some sort of nation state intelligence agency—already has a CRQC and isn't telling, but even then that's a lot less bad than having your communications be vulnerable to anyone who can get a QC shipped to them overnight as long as they have Amazon Prime.

This asymmetry in the threat model is convenient, because, as noted above, nobody is that excited about the PQ signature algorithms, whereas the PQ key establishment algorithms seem fairly reasonable—assuming of course that they're secure. As a result, people are focusing on key establishment and mostly keeping their fingers crossed that the signature situation will improve before it becomes an emergency.

Cryptographic Algorithms in Transport Security Protocols #

For the purpose of this post, I want to focus on transport security protocols like TLS. These aren't the only kind of cryptographic protocols in the world, but they illustrate a lot of the issues at play, in particular how we transition from one set of algorithms to another.

It's clearly impractical to just wholesale switch over from the old algorithms to the new algorithms at some point in time (what's often called a "flag day"). It took years (decades, really) to deploy everything we have in the ecosystem and any big change will also take time. Instead, TLS—and most similar protocols—are explicitly designed to have what's called algorithm agility, the ability to support more than one algorithm at once so that endpoints can talk to both old and new peers, thus facilitating a gradual transition from old to new.

The diagram below provides a stylized version of the TLS handshake. The client sends the first message (ClientHello), which contains a set of "key shares", one for each key establishment algorithm that it supports.^[4] For Elliptic Curve algorithms, this means one key share for each curve. When the server responds with its ServerHello message, it will pick one of those groups and send its own key share with a key from the same group. Each side can then combine its key share with the other side's key share to produce a secret key that both sides know.^[5] This shared key can then be used to derive keys to protect the application data traffic.

Something kind of like the TLS handshake

Of course, we also need to authenticate the server. This happens by having the server present a certificate and then signing the handshake transcript (the messages sent by each side) using the private key corresponding to the public key in its certificate. But as noted above, there are multiple signature algorithms, so the ClientHello tells the server which signature algorithms the client supports so that it can pick an appropriate certificate. Of course, if the server doesn't have a certificate that matches any of the client's algorithms, then the client and server will not be able to communicate.

Note that there are actually several signatures here because the certificate both has a key for the server and is signed by some key owned by the CA. These keys may have different algorithms, and both have to be in the list advertised by the client. Moreover, the CA may have its own certificate and that signature also has to use an appropriate algorithm and then there are CT SCTs (I refer you again to David Adrian's post, which quantifies these).

Post-quantum algorithms fit neatly into this structure. Each PQ algorithm is treated like a new elliptic curve (even though they really don't have anything in common cryptographically) and signature algorithms just act the same (although, as noted above, the result is a lot larger). Even better, all of the generation and selection of key shares is done internally to the TLS stack,^[6] so it's possible to roll out new key establishment algorithms just by updating your software without any action on the user's part (this is how EC was deployed in the first place). Of course, this is a lot easier if your software is remotely updatable or at least updates regularly; if we're talking about the software in a lightbulb, the situation might be a lot worse.

By contrast, in order to deploy a new signature algorithm you need a new certificate, and even though certificate deployment is partly automated now, it's not so automated that people expect new signature algorithms and the corresponding certificates to just pop up in their servers. Moreover, some servers are not set up to have multiple certificates in parallel. Given these deployment realities, the performance gap, and the threat model difference mentioned above, it shouldn't be surprising that there's a lot more activity around deploying PQ key establishment than around signatures.

The Current Deployment Situation #

In the past few years, we have seen a number of experimental deployments of PQ algorithms, primarily for key establishment.

Key Establishment #

Most of the key establishment deployment has been in what's called a "hybrid" mode, which is to say using two key establishment algorithms in parallel.

A classical EC algorithm like X25519
A PQ algorithm like ML-KEM

For instance, Chrome recently announced shipping an X25519/Kyber-768 (Kyber is the original name for what ~~is now ML-KEM~~ became ML-KEM after some modifications [Updated 2024-03-30]) hybrid and Firefox is working on it as well.

The way that these hybrid schemes work is that you send key shares for both algorithms, then compute shared keys for both, and finally combine the shared keys into the overall cryptographic key schedule that you use to derive the keys used to encrypt the traffic. There are a number of ways to do this, but the way it's done in TLS 1.3 is simple: you just invent a new algorithm identifier for the pair of classical and post-quantum algorithms and the key share is the pair of keys. Similarly, the combined algorithm emits a new secret that is formed by combining the secrets from the individual algorithms. This works well with the modular design of TLS, because it just looks like you've defined a new elliptic curve algorithm, and the rest of the TLS stack doesn't need to know any better.

The advantage of a hybrid design like this is that—assuming it's done right—it is resistant to a failure of either algorithm; as long as one of the two algorithms is secure then the resulting key will be secret from the attacker and the resulting protocol will be secure. This allows you to buy some fairly cheap insurance:

If someone develops a CRQC the connection is still protected by the PQ algorithm.
If it turns out that the PQ algorithm is weak after all, then the traffic is still protected with the classical algorithm.

Of course, if the PQ algorithm is broken, then the traffic isn't protected in the event that someone develops a CRQC, but at least we're not in any worse shape than we were before, except for the additional cost of the PQ classical [Updated 2024-03-30. oops.] algorithm, which, as noted above, is comparatively low.

All of this makes a rollout fairly easy: clients and servers can independently add support for PQ hybrids to their implementations and configure their clients to prefer them to the classical algorithms. When two PQ-supporting implementations try to connect to each other, they'll negotiate the hybrid algorithm and otherwise you just get the classical algorithm. Initially, this means that there will be very little use of hybrid algorithms, but as the updated implementations are more widely deployed, you'll have more and more use of hybrid algorithms until eventually most traffic will be protected against a CRQC. This is the same process we historically used to roll out new TLS cipher suites as well as new versions of TLS, like TLS 1.3.

Of course, it won't be safe for clients or servers to disable support for the classical algorithms until effectively all peers have support for the PQ hybrids; if you disable support for them too early, then you won't be able to talk to anyone who hasn't upgraded, which is obviously bad. For many applications, this is a well-contained problem: for instance you can disable classical algorithms in your mail client as soon as your mail server supports the PQ hybrids. However, the Web is a special case because a browser has to be able to talk to any server and a server needs to be able to talk to any browser, so Web clients and servers are typically very conservative about when they disable algorithms. The standard procedure is to offer both new and old concurrently and then measure the level of deployment of the new algorithm and only disable the old algorithm when there are almost no peers who won't support the new algorithm. Unless there is some strong sign that CRQC is imminent, I would expect there to be a very long tail of clients and servers—especially servers—that don't support PQ hybrids, in part because PQ hybrid support is not present in TLS 1.2 but only TLS 1.3, and there are still quite a few TLS 1.2 only servers. This will also make it hard for browsers to disable the classical algorithms, even if they want to.

If a viable CRQC is developed, then it will be necessary for everyone else to switch over to post-quantum key establishment algorithms on an expedited basis, but that's not enough. If you accept classical algorithms for authentication, the attacker will be able to impersonate the server. This means that after the CRQC exists, you will also need to have everyone switch to PQ signature algorithms.

Signature #

By contrast, there has been very little deployment of PQ algorithms for signature, largely for the reasons listed above, namely that:

It's a lot harder to deploy a new signature algorithm than a new key establishment algorithm.
It feels less urgent because a future CRQC mostly affects future connections rather than current ones.
The signature algorithms aren't that great. And by "not that great" I mean that replacing our current algorithms with ML-DSA would result in adding over 14K of signatures and public keys to the TLS handshake. As a comparison point, I just tried a TLS connection to google.com and the server sent 4297 bytes.

Before we can have any deployment, we first need to update the standards for signature algorithms for WebPKI certificates. From a technical perspective, this is fairly straightforward (aside from the performance and size issues associated with the certificates) in that you just assign code points for the signature algorithms. However, unlike the situation with key establishment, this is just the start of the process.

On the Web, certificate authority practices are in part governed by a set of rules (the baseline requirements (BRs)) managed by the CA/Browser Forum, which has historically been quite conservative about adding new algorithms. For instance, although much of the TLS ecosystem has shifted to new modern elliptic curves in the form of X25519, the BRs still do not support those curves for digital signature. So, the first thing that would have to happen is that CABF adds support for some kind of PQ algorithm or a PQ hybrid (more on this below). This probably won't happen until there are commercial hardware security modules that can do the PQ signatures.

Once the new algorithms are standardized, then:

The CAs have to generate new keys that they will use to sign end-entity certificates.
Those keys (embedded in CA certificates) need to be provided to vendors so they can distribute them to their users.
Certificate transparency logs need to also get PQ certificates.
Servers need to generate their own PQ keys and acquire new certificates signed by the PQ keys at CAs and CT logs.

Note that this transition is much worse than adding a new signature algorithm would ordinarily be. For instance, servers who wanted to use EC keys to authenticate themselves didn't necessarily need to wait for CAs to have EC keys themselves, because the CA could sign a certificate for an EC key with an RSA key, as RSA was still secure, just slower. This meant you could have a gradual rollout, and things got gradually better as you replaced the algorithms. But the whole premise of the PQ transition is that we don't trust the classical algorithms, so eventually you need to have the whole cert chain use the new algorithms. It's of course possible to have a mixed chain, but that's more useful for experimenting with deployment than providing actual security against a CRQC. In fact, as you gradually roll out, things get slower, but you don't get the security benefit until much later, which is actually the wrong set of incentives.^[7]

Once all this happens, when an updated client meets an updated server, then the update server can provide its new PQ-only or PQ-hybrid certificate. Just as with key establishment, the client and server both need to support the classical algorithms until effectively every endpoint they might come into contact with has PQ support. This isn't a big deal for the client, but for the server it means that it needs to have both a regular certificate and a PQ certificate for a very long time.

However, unlike with key establishment, during this transition period neither client or server is getting any security benefit from using PQ algorithms. This follows from the fact that the security of the signature algorithm in TLS is only relevant at connection establishment time. There are two main possibilities:

Nobody with a CRQC is trying to attack your connections, in which case the classical algorithm was just fine
Somebody with a CRQC is trying to attack your connections, in which case they will just attack the classical key rather than the PQ key.

In order to get security benefit from PQ signatures in this context, relying parties need to stop trusting the classical algorithms, thus preventing attackers from attacking those keys. In the Web context, this means that Web browsers need to disable those algorithms; until that happens PQ certificates don't make anything more secure, but do make it more expensive, which is not a very good selling proposition.

For this reason, what I would expect to happen is wide deployment of client side support for PQ signatures but much less wide deployment of PQ certificates. The vast majority of clients are produced by a small number of vendors (the four major browser vendors) and this is a fairly easy change for them to make. By contrast, while servers are to some extent centralized on big sites like Google or Facebook or big CDNs, there are a lot of long tail servers who will not be motivated to go to the trouble. In particular, I would be very surprised if anywhere near enough servers adopted PQ-based signatures to make it practical to disable classical signatures absent from very strong pressure from the client vendors.

As a reference point, the first good attacks on SHA-1 were published in 2004, and SHA-1 wasn't deprecated in certificates until 2017. Moreover, even after Chrome announced that they would deprecate SHA-1, it still took three years to actually happen. The difference between SHA-1 and SHA-2 had had no meaningful impact on performance or on certificate size, so this was really just a matter of transition friction. This isn't an atypical example: the vast majority of certificates contain RSA keys and are signed with RSA keys even though ECDSA is faster (for the server) and has smaller keys and signatures.

There have been some recent changes to the WebPKI ecosystem to make transitions easier (e.g., shortening certificate lifetimes), but transitioning to PQ certificates has much worse performance consequences, so we should definitely expect the PQ transition to be a slow process.

Hybrids vs. pure PQ #

One of the big points of controversy is whether to mostly support hybrid systems that combine both classical and PQ algorithms or pure PQ algorithms. As noted above, the industry seems to be trending towards hybrids for key establishment, but the question of signatures is more uncertain.

Looming over all of this is the fact that the US National Security Agency and the UK GCHQ are strongly in favor of pure PQ algorithms rather than hybrids. In November 2023, GCHQ put out a white paper arguing for pure PQ schemes rather than hybrid:

In the future, if a CRQC exists, traditional PKC algorithms will provide no additional protection against an attacker with a CRQC. At this point, a PQ/T hybrid scheme will provide no more security than a single post-quantum algorithm but with significantly more complexity and overhead. If a PQ/T hybrid scheme is chosen, the NCSC recommends it is used as an interim measure, and it should be used within a flexible framework that enables a straightforward migration to PQC-only in the future.

Similarly, the NSA's Commercial National Security Algorithms 2.0 (CNSA 2.0) guidance contains some text that many read as saying they will eventually not permit hybrid schemes:

Even though hybrid solutions may be allowed or required due to protocol standards, product availability, or interoperability requirements, CNSA 2.0 algorithms will become mandatory to select at the given date, and selecting CNSA 1.0 algorithms alone will no longer be approved.

This isn't the clearest language in the world, but it seems like the best reading is they don't want to allow hybrids. On the other hand, at IETF 119 last week, NIST's Quynh Dang stated that NIST was fine with hybrids.

The specific timeline varies by product, but most relevant for this post, they say they want to have Web browsers and servers be CNSA 2.0 only by 2033:

CNSA 2.0 timeline

It's a bit unclear what this means in practice for the Web, even if you read it as "pure PQ only". Recall that the way that TLS works is that the client offers some algorithms and the server selects one; this means that it should be possible for servers constrained by CNSA 2.0 ("national security systems and related assets") to select pure PQ algorithms as long as enough browsers support them, which seems somewhat likely, even though AFAICT no browser currently supports them. However, it's much less viable for a browser to only support PQ modes unless you never want to connect to servers on the Internet which, as noted above, are not likely to all support pure PQ. Are even government systems going to be configured to disable hybrids in 2035?

The CNSA 2.0 guidance is relevant for two reasons. First, there are likely to be a number of applications which are going to feel strong pressure to comply with CNSA 2.0. It's of course possible that if vendors just decide to use hybrids, that NSA ends up giving in and approving that, but people are understandably reluctant to find out. Second, GCHQ and NSA offer a number of arguments for why PQ algorithms as opposed to hybrids. This post is already getting quite long, so I don't want to go through them in too much detail, but they mostly come down to it's more moving parts to have a hybrid (hence more complexity, cost, etc.) and if there is a good CRQC, then the classical part of the system isn't adding much if anything in the way of security.

Another concern about hybrids is performance. Obviously, hybrids are more expensive than pure PQ, but the difference isn't likely to be a big factor. PQ keys and signatures are much bigger, so the incremental size impact of having the classical algorithm is trivial. ML-KEM is quite a bit faster than X25519, but X25519 is already so fast that my sense is that people aren't worried about this. Similarly, ML-DSA is about twice as fast as EC for verification but looks to about 4x slower for signing,^[8] a bit misleading because in most uses of TLS it's the server that has to worry about performance and that's where the signature happens, so again the incremental cost of EC isn't that big a deal.

I'm not sure how persuaded I am by these arguments, but I think at best they are arguments at the margin. In particular, there's no real reason to believe that deploying hybrids is inherently unsafe, even if the classical algorithm is trivially broken. Assuming that we've designed things correctly, the resulting system should just have the security of the PQ part of the hybrid. I've seen suggestions that severe enough implementation defects against the classical part of the system (e.g., memory corruption) could compromise the PQ part. This isn't out of the question, of course, but modern software has a pretty big surface area of vulnerable code, so it's hard to see this as dispositive.

Inside Baseball: Code point edition #

For a long time, the IETF used to make it quite hard to get code point assignments, for instance requiring that you have an RFC. The idea was that we didn't want people using stuff that hadn't been reviewed and that the IETF didn't think was at least OKish. The inevitable result was that a lot of time was spent reviewing documents (for instance national cryptography standards) which the IETF didn't care about but were just needed to get code point assignments. Worse yet, some people would just use as-yet unassigned code points—this was easy because they're generally just integers—and if there was any real level of deployment, that code point became unusable whether it was officially registered or not.

The more modern approach is to make code point assignment super easy (effectively "write a document of some kind which describes what it's for") but to mark which code points are "Recommended" by the IETF and which are not. The "Recommended=Y(es)" ones need to go through the IETF process, but "Recommended=N(o)" code points are free for the asking. This has significantly reduced the amount of time that WGs spend reviewing documents for bespoke crypto and has generally worked pretty well. More recently the WG is adding a "Recommended=D(iscouraged)" for algorithms which the WG has looked at and thinks are bad.

Key Establishment #

As noted above, most of the energy in key establishment is in hybrid modes. They're easy to deploy now and seem safer than pure PQ algorithms, at least for now. In TLS in particular, what seems likely to happen is the following:

The TLS WG will standardize a set of hybrid algorithms based on ML-KEM on and recommend that people use them.
The IETF will assign a code point (algorithm identifier) for pure ML-KEM, but it won't be a standard and the IETF won't recommend (or disrecommend) its use.

The likely result is that there will be a lot of use of hybrids but people will be able to use pure ML-KEM if they want it. At some point, sentiment may shift towards pure ML-KEM, in which case the TLS WG will be able to take that document off the shelf and standardize it. However, as noted above, that isn't urgent even if there is a working CRQC: people can just burn a little more CPU and bandwidth and do hybrids while the hybrid → pure PQ transition happens.

Signatures #

The question of whether to use hybrids versus pure PQ for signature is still being hotly contested. As I mentioned above, it seems clear that servers will need both classical and PQ signatures for some time. The relevant question is exactly how they will be put together.

It seems likely that servers will have one certificate with a classical algorithm (e.g., ECDSA) as they do today and then have another certificate with a post-quantum algorithm. This could be in one of two flavors:^[9]

For a pure PQ algorithm (ML-DSA)
For both a classical (e.g., ECDSA) and a PQ algorithm (ML-KEM). As with key establishment, these would be packaged into a single key and a single signature that was the combination of the two algorithms, with the semantics being that both signatures have to be valid.

For a while my intuition was that it was easier to just do PQ: because the PQ algorithms were so inefficient, clients and servers would largely favor the classical algorithms unless it became clear that the classical algorithms were insecure, and so it wouldn't matter much what was in the PQ certificates. And if it became clear that the implementations had to distrust the classical algorithms—which is going to be a super rocky transition anyway given the likely level of deployment of PQ certificates—then the classical part of the hybrid isn't doing much for you.

Now, consider the opposite case where instead the PQ algorithm is what's broken. At this point, you want to distrust that algorithm and fall back to classical algorithms. By contrast, to distrusting the classical algorithms, distrusting the PQ algorithms is comparatively easy because everyone is going to still have classical certificates for a long time, so relying parties (e.g., browsers) will probably be able to just turn off the PQ algorithm, in which case you don't really need a hybrid certificate for continuity.

This is all true as far as it goes, but it's also kind of browser vendor thinking because have really good support for remotely configuring their clients, so it really is practical to turn off an algorithm within days for most users. However, this isn't true for all pieces of software, many of which take much longer to update, and for those clients and servers the world will be much more secure if the only two credentials they trust are classical (still OK) and PQ hybrid (now just as secure as the classical credential). Moreover, it's also possible that there will be a secret break of the PQ algorithm, in which case even browsers won't update (the only thing we can do for a secret CRQC is to stop trusting the classical algorithms). For these reasons, I've come around to thinking that hybrids are the best choice for PQ credentials in the short term.

The Bigger Picture #

Getting through this transition is going to put a lot of stress on the agility mechanisms built into our cryptographic protocols. In many ways, TLS is better positioned than many of the protocols in common use, both because interactive protocols are inherently able to negotiate algorithms and because TLS 1.3 was designed to make this kind of transition practical. Even so, the transition is likely to be very difficult. While TLS itself is designed to be algorithm agile, it is often embedded in systems which themselves are not set up to move quickly.

Many proprietary uses of TLS—such as applications talking back to the vendor—should be able to switch pretty quickly and seamless. For instance, Facebook can just update their app in the app store and their server and they're done.
The Web is going to be a lot harder because it's such a diverse system and there isn't much in the way of central control on the server side. On the other hand, the browsers are generally centrally controlled by the vendors, which means that most of the browser user base can change quickly. There is of course a long tail of browsers in embedded devices (TVs, kindles, etc.) which may be much harder to update.
Beyond these two cases, there is going to be a long tail of TLS deployments which are in much worse shape and which can't be easily remotely updated (e.g., many IoT devices). Depending on how the clients or servers these devices need to talk to behave, they may either be stuck in a vulnerable state (if the peers don't enforce PQ algorithms) or just unable to communicate entirely.

Unfortunately, a rocky transition is actually the best case scenario. The most likely outcome is that absent some strong evidence of weakening of classical algorithms as a forcing function, we have a long period of fairly wide deployment of PQ or hybrid key establishment and very little deployment of PQ signatures, especially if the PQ signature algorithms don't get any better. Even worse would be if someone developed a CRQC in the next few years—long before there is any real chance we will be ready to just pull the plug on classical algorithms—and we have to scramble to somehow replace everything on an emergency basis. Fingers crossed.

Acknowledgement: Thanks to Ryan Hurst for helpful comments on this post.

Lots of stuff in your computer (the transistors, LEDs, etc.) are based on quantum effects, but fundamentally there's nothing that your computer does that couldn't be done by clockwork. This is something different. ↩︎
The ML stands for "module-lattice", which refers to the mathematical problem that the algorithms are based on. ↩︎
The situation here is a bit complicated. NIST is standardizing three schemes: ML-KEM, ML-DSA, and SLH-DSA. ML-KEM and ML-DSA are based on lattices, which have a fairly long history of use in cryptography. SLH-DSA is based on hash signatures which are also quite old, but has unsuitable characteristics for a protocol like TLS. Quite a few of the initial inputs to the NIST PQ competition have subsequently been broken (see this summary by Bernstein), including SIKE, which turns out to be totally insecure, which is disappointing because it had some favorable properties in terms of key size. There have also been some improvements in attacking lattices in the past few years, though they are not known to break either ML-DSA or ML-KEM. In addition to algorithmic vulnerabilities, some of the implementations of Kyber (the predecessor to ML-KEM) had a timing side channel, dubbed "KyberSlash". All in all, you can see why people might want to engage in some defense in depth. ↩︎
I'm simplifying here a bit, in that the client can actually advertise curves it doesn't send key shares for, but we can ignore that for the moment. ↩︎
Simplifying again. Each side actually generates a secret value and then computes their key share from that secret value. The shared secret is computed from the local secret and the remote key share. ↩︎
Although of course users can reconfigure it, at least in some systems. ↩︎
See my post on how to successfully deploy new protocols, coming soon. ↩︎
The numbers I have here are from Westerban and are for Ed25519, which isn't in wide use on the Web, but, at least in OpenSSL, EdDSA and ECDSA seem to have similar performance. ↩︎
There is actually another option in which you have a single certificate with the classical key in the normal place (subjectPublicKeyInfo) and the PQ key in an extension. This certificate will be usable with both old and new clients, with new clients signaling that they supported PQ and then the server signing with both algorithms. This has the advantage of only needing a single certificate but otherwise is kind of a pain because it requires a lot more changes to TLS. In the naive way I've described it, it also involves sending a lot more data for every client, but there are ways around that. ↩︎

Sean O'Brien 100K Race Report (2024)

2024-03-13T00:00:00Z

On Saturday 1/27 I ran the Sean O'Brien (SOB) 100K in Southern California. I ran this same race back in 2021 and got my 100K PR, so I knew the course and felt like it was an opportunity to do better. My training had been going well and I was dropping PRs on my local courses, so I was looking forward to a strong race and taking off bunch of time, with an overall target of 12:00 to 12:25, so ~30-50 minutes off of 2021. This did not happen, though I did PR slightly.

It actually turned out to be a bit of a mixed result. On one hand, I finished about 7 minutes faster than last time (more on the "about" later), and much higher up in the standings (8th overall out of a starting field of 96) but all of the improvement was being more efficient at aid stations and I actually was a little over 2 minutes slower in the running part. My working theory is that it was warmer this year, and so times were slower, but this is a bit harder to verify than one might like.

To orient yourself, here is the course and the hill profile. The circles on the course are mile markers, so you start at the far right, go all the way to the left, around the loop counter-clockwise, then backtrack. There's an out-and-back down to Bulldog and then you backtrack to the finish. The circles on the profile are "climb score", Runalyze's estimate of how hard the climb was.

[Screenshots from Runalyze, 2021 data]

Overall Logistics #

I've been doing most of my training with Tailwind and Maurten drink mix, but KH races uses Gu Roctane, which I don't particularly like—especially because races have a tendency to offer the caffeinated version—so I decided to use drop bags extensively. To make this easier to manage I mapped out a regular eating schedule, that targeted 320-360 cal/hr, effectively:

1 500 ml bottle of Maurten 160 drink every hour, with 250ml each 30 min
Some mix of Maurten solid and Maurten gel aiming for ~100-200 cal/hr.

I use a 30 minute timer to manage all this, so I have to do something every 30 minutes. I started with Maurten solid and then moved onto a mix of regular gel and the caffeinated gels. This got a little complicated to manage due to Maurten's non-orthogonal lineup: Maurten's solid bar is 225 cal, so effectively I was eating 1/3 bar when the timer went off, which is fine. Ideally I would have just used Maurten 160 gels every hour for 320 cal/hr, but I wanted to take caffeine every 2 hrs after 6 hrs and Maurten's caffeinated gel is only 100 cal, so I decided to aspirationally add a Maurten 100 at the 30 minute mark, though I wasn't sure I could reliably do 360 cal/hr. This mostly worked out, especially once I got past the solid phase.

Everything laid out

To make all this easier I bagged up what I needed for each aid station in a ziploc (with two bags for Kanan, because you hit it twice). The way this works is you get to the AS, you (theoretically) dump out everything from your pack, and then shove in whatever is in the ziplocs in. I labeled the ziploc both with where it was needed and my 2021 time for the AS, so as soon as I picked up the bag I could see if I was ahead or behind schedule. This part worked well and was a lot easier than a pace sheet.

Start to Corral Canyon [7.3 mi, +2270/-846 ft, 1:20:43, -2:25] #

Race start was at 5:30 AM and sunrise at a bit after 7 so I expected to run the first 60-90 minutes in the dark. I got to the start with plenty of time and was able to drop off my drop bags and then just chilled in the car for a while, before heading over to the start line about 10 minutes early, planning to use the bathroom.

This is where things started to go wrong because there was a much longer than expected bathroom line: apparently the portapotties just never got delivered so we just had the park's bathrooms, which really weren't enough for 100 runners. For some reason, the RD decided not to delay the start even though a number of people—including me—were still waiting. I decided that it was better to use the bathroom than to be right at the start, and ended up missing the start by about a minute (not the first time this has happened to me, TBH). I think this was the right decision overall: a minute isn't much for a race this long, and I wasn't expecting to win, but the result is that I started essentially at the back of the race. There are some early sections of single track and so I spent quite a bit of time trying to get past people who were going a lot more slowly than me. It's important to conserve energy early, so I tried not to get too aggro, but it still slows you down.

New for this year there was a real water crossing 2 miles in (I had heard rumors about this but no details because I missed the briefing at the start), where you actually had to wade through almost knee deep water with a rope for stabilization. I'm never a huge fan of this, but it was already fairly warm (never a good sign) and my shoes dry quickly, so it wasn't uncomfortable. Eventually I made it past most of the people slower than me and then things opened up into fire roads so it wasn't a problem to get past people any more. I felt like I was running pretty comfortably, and, as with last time, opted to run as much as I could.

I finally hit Corral Canyon at 1:21, about 3 minutes ahead of 2021 (all times here are from my watch, not gun time), which seemed pretty good considering the start. I was trying to be conscious of aid station time, and was in and out in 1:05. This is about the best you can do if you're drinking regularly and using your own nutrition because you have to pour the powder into the bottles and then add water, but I see now it was 40s slower than last year, so I think that's just the price you pay for bringing your own nutrition.

Kanan Road [6.3 mi, +1010/-1444 ft, 1:06:55, -2:13] #

This next section is mostly rolling single track and fire road. I was feeling reasonably good on this section, but it was a bit hard to get into my rhythm, as there were a lot of rocky sections and stream crossings, and I actually tripped a couple of times, which wasn't great. Fortunately, the dirt was soft, so I didn't get hurt, but it's kind of discouraging. Other than that, this section went reasonably fast.

The first drop bag is at Kanan road, so I was able to grab my nutrition refill and check my time (about 4 minutes ahead) I lost some time here because I'd taped up the bag too much and had trouble untying it and then had to refill my nutrition but still got out reasonably quickly (3:57). Only after I left did I realize I still had my headlamp in my pack, but no way was I going back to drop it off. It's not that heavy, right?

Zuma Edison Ridge 1 [5.4 mi, +1260/-997 ft, 1:00:12, -0:58] #

This next section is a rolling descent on single track followed by a moderate climb on fire road to the top of the ridge line ad. The fire road was pretty smooth and as with last time, I felt good and pretty much ran this whole section. There is a nice moderate descent that was longer than I remembered and a bit rocky but I felt really comfortable on. By this point in 2021 my knee had already started to hurt, but everything was still good, so that felt pretty promising. The next aid station (Bonsall) is all downhill so I chugged some water, refilled my bottle, and just headed out. I forgot to hit my lap timer on this one, but I know that the aid was pretty fast.

Bonsall [3.4 mi, +0/-1706 ft, 26:34, -2:49] #

As noted above, this next section is a 3.4 mile descent down to the Bonsall aid station. Pretty much this whole thing is on fire road so I was able to take it pretty fast (~7:46/mi, 50s/mile faster than 2021). With that said, I was apparently overcompensating for it feeling short before, because I expected it to go really fast, and, well, it kind of didn't; I kept thinking "OK, we must be at the bottom", but I wasn't. On the plus side, I was passing people, which doesn't usually happen for me on the descent, so I was feeling like all that training for downhill was paying off.

I hit the aid station (second drop bag), swapped out my food, and filled my bottles. It was only at this point that it started to sink in that I had nearly 2 hrs of exposed mostly climbing, it was starting to get hot, and I only had two bottles. I compensated by chugging some water and salt caps and crossing my fingers. A while after I left the AS I realized I was still carrying my headlamp, but once again, I wasn't going back.

Zuma Edison Ridge 2 [7.76, +2910,-1184 ft, 1:56:17, +4:43] #

There's a long climb out of Bonsall back to Zuma Edison Ridge. This is actually two climbs, ~1600 ft, followed by a descent of around ~1000 ft and then another climb of ~1300 ft. As I rolled out of the aid station, someone came by me with 3 bottles and one bouncing in his pack and I started to think I had made a serious mistake in terms of fluid but it was too late to fix it.

This section is mostly hiking and there 3-4 people ahead of me, including a guy named Colton who I'd run part of the way with earlier and I'd been sort of going back and forth with (he eventually finished one place behind me). I was able to mostly keep them in sight, but not make much progress. This section is super exposed and I was really starting to feel the heat and actually worried that I wouldn't have enough. I didn't really think it would take me more than two hours (two bottles by my drinking schedule) but in the heat I really needed to be drinking more water than dictated by my calorie needs. Worse yet, my knee started to hurt (same place as last time!) whenever I ran, but as I wasn't doing much running, I just tried to ignore it.

I would say this section was harder than 2021: I felt like it was hotter and I felt like I was struggling more. Partway though the second climb, the eventual first woman passed me and she just looked a lot lighter on her feet, running parts that I only barely had enough energy to hike. So, I was pretty glad to finally get to the Zuma aid station, but this leg was about 5 minutes slower than 2021. I burned through the aid station this time and just kept going.

Kanan Road [5.4 mi, +1037/-1283 ft, 1:03:45, -2:40] #

At this point we're just backtracking down the backbone trail to a previous aid station. This means a ~600ft climb followed by a step descent and some rolling terrain. I started to feel somewhat better here and was trying to focus on moving well on the downhill. At this point, I passed Colton again, for the last time and just kept moving. At this point I figured I was probably around top 15. I made it to Kanan OK, grabbed my next nutrition refill, and finally, remembered to drop my headlamp into my drop bag.

Whatever was wrong with my knee seemed to have fixed itself, so I was less worried about not being able to finish, and I had a pacer meeting me at Bulldog (mile 50), so my approach was just to treat this like a 50 miler and figure the last 12 would take care of themselves. This really meant one more modestly hard segment back to Corral Canyon and then the long downhill to Bulldog which was pretty runnable, so I was really just counting down to Corral Canyon at this point.

Corral Canyon [6.4 mi, +1453/-974 ft, 1:30:55, +1:41] #

We're still retracing our steps back to the first aid station, so this is mostly on single track and generally uphill. There was definitely a fair amount of hiking here, but I was really trying to keep solid running where I could. By this point in the race I was starting to pass people doing the 50K (almost nobody seemed to be doing the 50 mile), which is kind of nice, but I imagine pretty unpleasant for them, given that I was running a lot faster after a lot further in. This part didn't feel that bad, but nevertheless I was glad to hit the aid station, and was looking forward to the long downhill to Bulldog.

Bulldog [5.9 mi, +486/-1946 ft, 1:03:19, -0:07] #

This section is a long out and back, with the aid station being at the bottom. Fortunately, this time I had a better picture of the course and I was prepared for the mile long climb to the downhill, so it wasn't as demoralizing that time. I was almost to the top of the climb when someone came tearing the other way. I asked him if he knew what place he was in and he said first, which was reassuring in terms of where I was at in the standings but also meant I could just count off people going the other way to see where I was.

I tried to push this downhill a bit within the limits of not falling, and felt more in control than last year, though actually the overall pace for this leg was nearly identical to 2021. I was most of the way down before I saw #2, who turned out to be Ian Sharman, who has 9 Western States Top 10 finishes, so I felt like things were going pretty well, even if he was probably having a bad day (I eventually finished around 83 minutes behind him).

Eventually I hit the bottom of the hill and it was onto the flat/rolling section, which I'd remembered as ~1 mile but is actually more like 2 miles. About a mile from the turnaround there is a concrete bridge/overpass over a small river, which you have to get over somehow. It's maybe 3 ft above the trail and someone had put a small stepladder so you could get onto it, but even so it was a bit of a struggle, which wasn't a really good sign in terms of my legs being fresh. By the time I had made it to the aid station, I counted off 6 men and 1 woman before me, which seemed pretty good. I grabbed my last nutrition bag, my headlamp, and headed back out.

Corral Canyon [5.8, +1906/-495 ft, 1:32:06, +6:42] #

My pacer Kate and I ran the flat mile or two modestly hard—the bridge was even worse on the way back because I sort of had to scoot down the two whole feet onto the ladder—and then just settled in for the long hike up to the top. I was trying to push this pretty hard but definitely wasn't feeling amazing. Still, it was pretty nice to see everyone behind me going the other direction.

I'd hoped to make up time on this segment, but actually I was almost 7 minutes down for this leg (still about 8 minutes ahead overall) by the time I hit the aid station. I actually thought I was more like 14 minutes ahead because I misremembered my target time (note to self: also do a pace sheet). It didn't really matter, though, because my plan was just to push the pace as much as I could on the way down.

Finish [7.3 mi, +833/-2277 ft, 1:27:27, +0:30] #

The way to the finish is some rolling single track followed by a really long descent, first on fire roads (remember, we're backtracking again, though I'd done this section entirely in the dark on the way out) and then on single track. At this point, I was hiking most of the climbs but trying to run the downhill as much as I could.

Unfortunately, due to the shorter day and the later start, I had to run a lot of this in the dark, unlike 2021, when I finished in the light. I did have a headlamp (Petzl Actik Core), but I was really wishing I had something brighter, especially when we got the single track. If I'd just carried my Lupine another 10 miles or so, I could have had it with me for this, which might have made a difference, as I wasn't able to go as fast as my legs would have supported because I couldn't see very well

After a long downhill there is a mile or so of uphill, which I knew about this time (pretty much right after the water crossing) and was actually looking forward to, both as a break from having to pick my way through things and an opportunity to push the pace some. I did that and was rewarded by getting to listen to Kate breathing a bit harder behind me. This felt a little longer than I expected, but I'd been doing plenty of climbing in training so I was comfortable with it.

After the peak of the hill, it's back to the single track descent followed by about a half mile of nice flat fire road, which gave me an opportunity to open up a little bit towards the finish. We were still passing people but they were not in the 100K so it doesn't really count.

Analysis #

As I mentioned at the top, it's hard to compare year to year, so this section is mostly me thrashing around trying to get a better sense of it. The chart below shows my performance against 2021 (watch time, not gun time):

Leg	Distance	Vert	Time	vs 2021	vs 2021 (cum)
Corral	7.29 mi	2,270/-846 ft	+1:20:43	-2:25	-2:25
Aid	-	-	1:05	+41	-1:44
Kanan	6.34 mi	+1,010/-1,444 ft	+1:06:55	-2:13	-3:57
Aid	-	-	2:37	-1:20	-5:17
Zuma	5.42 mi	+1,260/-997 ft	1:00:12	-58	-6:15
Bonsall	3.43 mi	+0/-1,706 ft	26:34	-2:49	-9:04
Aid	-	-	+2:56	-1:30	-10:34
Zuma	7.76 mi	+2,910/-1,184 ft	1:56:17	+4:43	-5:51
Aid	-	-	2:05	-3:22	-9:13
Kanan	5.40 mi	+1,037/-1,283 ft	1:03:45	-2:40	-11:53
Aid	-	-	3:26	+23	-11:30
Corral	6.37 mi	+1,453/-974 ft	1:30:55	+1:41	-9:49
Aid	-	-	?	-2:13	-12:02
Bulldog	5.91 mi	+486/-1,946 ft	1:03:19	-7	-12:09
Aid	-	-	3:22	-29	-12:38
Corral	5.84 mi	+1,906/-495 ft	1:32:06	+6:42	-5:56
Aid	-	-	1:51	-2:11	-8:07
Finish	7.32 mi	+833/-2,277 ft	1:27:27	+30	-7:37

As seems pretty clear here, I was just faster through Bonsall both on the running legs and in the aid stations, and then I lost a lot of time on the climb out of Bonsall and then again on the climb out of Bulldog, but was still about the same as 2021 on the rest of the legs and was better on the aid throughout.

The graph below compares my paces on each grade from 2021 to this year with one graph for each hour.

Speed versus grade, faceted by hour.

For the first 5 hours, I was just plain faster both on the climbs and the descents. In hours 5 and 6 (the climb out of Bonsall) I started to slow down, especially on the climbs. I recovered again on 7 and 8 when it was just straight running, and then struggled again on the climb out of Bulldog but was pretty solid towards the finish.

It's a bit hard to know exactly what to make of this, but my working theory was that it was hotter this year and so when I had to exert a lot of effort on the climbs, I slowed down but when I was able to just run comfortably, I was still faster because heat wasn't as much of a factor. It's of course possible I have gotten worse at climbing or I wasn't pushing as hard, but I don't think that's true. I was definitely pushing pretty hard on the climb out of Bonsall and I felt like I was pushing on the climb out of Bulldog and that was Kate's impression as well. I've generally been hiking pretty well this season, and as noted above, I was doing well on the climbs early in the race, so I don't think I've just suddenly gotten a lot worse in this area.

Beyond my own performance, there are some other reasons that suggest that this year was harder and that it was at least in part due to heat:

Runalyze's estimate of the weather is 72^o this year versus 63^o for 2021 (though more humid in 2021) and Garmin's somewhat confusing sensor (which seems to integrate skin and air) also shows things 5-10^o hotter in 2024.
The drop rate in 2021 was 3/33 (9%), whereas this year it was 23/96 (23.9%)
In 2021 there were 5 people under 12:00 and this year there were 4 even with a much larger field.
While Kate was waiting at the aid station, she kept hearing how people were underperforming because it was hot.
While the winner's time was the same, the median times were a lot worse (~28 minutes overall, 67 minutes including DNFs), as shown below:

Year	Notes	Mean Time	Median	Median excl DNFs	DNF rate
2024	Same as 2021, 2020 course	14:45:48	15:29:40	15:08:40	23/96 (24%)
2023	Short course (~2-3 miles)	13:44:00	14:04:51	13:42:59	4/94 (4%)
2022	Short course (~3-4 miles): reroute due to rockslide	13:37:04	14:01:46	13:45:56	7/69 (10%)
2021	In October instead of January	14:04:24	15:01:14	14:21:13	3/33 (9%)
2020		13:41:24	14:11:57	13:43:33	24/154 (16%)
2018		13:43:56	14:09:24	14:09:24	131 finishers, no DNFs listed
2017	Short course due to weather (~2 miles)	12:44:49	12:46:20	12:46:20	137 finishers, no DNFs listed

Figure thanks to Kate Hudson

It may also be the case that I and others aren't as heat adapted because the race was in the winter rather than the fall.

I do think I faded a bit in the last 13 miles or so. I don't have splits, but I estimated that the female winner was maybe 1-1.5 miles ahead of me at Bulldog and she finished 45 minutes ahead, so she must have put at least 20 minutes on me from there. That's consistent with how fresh she looked when I saw her earlier: I definitely think those miles would have been a lot faster if I had been fresh and running more than hiking (they would also have been faster in the light!).

Retrospective #

Times, aside I felt like I followed the game plan pretty well. I ran when I could and hiked when I felt like I had to. I think there were maybe a few places towards the end that I could have run if I had to, specifically the up part of the rollers at the beginning of Bulldog and after Corral Canyon, but I felt like I was hiking pretty fast, so I'm not sure I would have run it much faster; I think I was in part just limited by what I had left in the tank. I'm quite pleased that I was legit faster on the downhills most of the race. This is something I was working on and so it's nice to see that pay off. I'm not sure why I kept tripping, but I guess I still have more agility work to do.

Missing the start really sucked because of having to work my way through everyone. I think this was the right decision, as I definitely had to go and made it through the race without issue but I wish I'd made it to the toilets earlier, so I could have started with everyone else. I might have pushed a bit too hard at the start, but I think I did a reasonable job of holding back.

My nutrition strategy worked well. It was pretty easy to stick to an every 30 minutes schedule and I didn't have any major GI issues: I felt fine until after Corral Canyon and then just a little nauseated afterwards, and even then I was still able to eat, just not as many calories per hour as I wanted (mostly I ditched the extra Maurten 100 in the hour when I had caffeine.). Having a caffeinated gel on the half hour was easy to manage. The two things I might change here are:

I want to try to just do 360 cal/hr, so I could do a Maurten every 30 minutes
I should have brought an extra bottle for the Bonsall climb and just had electrolyte or swapped out another Maurten 160 bottle for a gel, because I think I did get dehydrated there.

As noted above, I wish I'd had a better light for the finish. I think I got optimistic because I finished in the light in 2021 and didn't properly account for the later start and earlier sunset.

Overall #

12:46:25 (gun time), 12:45:37 (hand time). 8th/73 overall, 7th/59 (male), 1st 50-59

A hard look at Certificate Transparency: CT in Reality

2023-12-25T00:00:00Z

This is part II in my series about Certificate Transparency (CT) and transparency systems. In part I, we looked at how to build a simple transparency system that guaranteed that each certificate was published and that each participant in the system has the same view of the list of certificates. This prevents covert misissuance of certificates and makes it possible—at least in principle—to detect when misissuance has occurred. In this post, I want to look at CT as it is actually deployed on the Internet.

Writing on the face of the moon, but nobody's looking. Image by Kate Hudson with components from Midjourney and Adobe AI.

[Update: 2023-12-25. After I posted this, I had a long discussion with Chrome's Emily Stark and Ryan Hurst (formerly Google Core Security and Google Cloud) on X/Twitter. I've made some revisions below in light of that discussion. Big thanks to Emily and Ryan for the critique and detailed discussion.]

Deployment Compromises #

In the previous post, we designed a greenfield system without worrying too much about deployment. Unfortunately for CT, the WebPKI was already well established—with all its faults—by the time CT was developed. You run into a number of challenges when you go to retrofit it to the existing WebPKI, starting with the fact that it was a lot of work for CAs and didn't bring them any value. Importantly, deploying CT doesn't make a CA's customers any more secure because the attacker can just try to get a certificate for those customers from another CA. What it mostly does it make it harder for your CA to misbehave, but that's not really a selling point, and after all, mistakes are something that happen to other people!

Google's plan for overcoming these deployment hurdles came in two parts:

(Eventually) Require CAs to use CT in order to be trusted by Chrome, thus forcing universal deployment of CT.
Make a bunch of technical compromises designed to make CT easier for CAs to deploy.

Obviously, part (1) of this plan kind of involved playing chicken with the CAs. Chrome is by far the most popular browser, but it wouldn't be for long if it didn't work with a lot of Web sites. In order to make requiring CT a credible threat, Google needed to get enough CAs onboard that the number of sites with certificates not published in CT was very small, thus making it possible to break them with making Chrome useless, hence the need for the technical compromises to make it more palatable. The remainder of this section talks about some of those compromises.

Transparency Logs #

Previously I talked about the CA publishing the Merkle tree of certificates, but there's no technical reason the CAs have to do it themselves; the certificates just have to be published somewhere. CT separates the job of running the CA from the job of publishing the certificates by creating the role of a transparency log, which is responsible for building the tree. The CAs don't have to operate a log (though some do) just register their certificates with the log.

This design has several advantages. First, it makes life easier for the CAs, who don't have to run logs. This may not seem like a big deal, but it turns out that running a log is a lot of work for reasons we'll get into below, and indeed very few CAs actually run their own logs today. Instead, some entity with a lot of operational resources and experience (i.e., Google), could run a log that supports multiple CAs, hopefully making it easier for the CAs to deploy.

Second, having a relatively small number of logs improves the scaling properties of the system somewhat: much of the overhead for the clients comes in the form of getting an authentic copy of the signed root (what CT calls a signed tree head (STH)), and if each CA has its own tree, that means one root for each CA. If there's just a small number of logs then you need a correspondingly smaller number of roots. Similarly, in order to ensure that no certificates have been misissued, sites need to have a copy of the database for every CA; it's easier if those databases are all aggregated into a small number of logs than to have to retrieve them independently.

Finally, the log design makes it possible to publish certificates even for CAs which don't participate because the log can just unilaterally ingest those certificates. Consider what happens if most CAs publish their certificates in CT but some don't, but Chrome wants to require CT. They could use the Google crawler to collect certificates for non-cooperating CAs and put them in the log, thus potentially making it easier to require CT. This doesn't help as much as you'd think because you still have the problem of how the client gets the inclusion proof for the certificate, but there are some (not great) options here.

Signed Certificate Timestamps #

The big problem with the design as I described it in part I is that it inserts a delay in the certificate issuance process: if you are going to provide the inclusion proof at the time of certificate issuance, then you need to collect all the certificates that go into the Merkle tree before you can issue the certificates to the site. If you publish one signed tree a day, this means that on average it will take 12 hrs between the certificate request and issuance, which also means that it takes on average 12 hours and up to a day at the worst case to bring a site online. This might have been acceptable if we were starting from scratch, but certificate issuance times are measured in ~~minutes~~seconds [Updated 2023-12-25. Per Ryan Hurst]. and so this would have represented an unacceptable regression, especially for sites which didn't have a valid certificate and so would have to wait up to 24 hours to deploy (not such a big deal the first time, but an absolute emergency if you had a live site and you let your certificate expire).

In order to address this issue, Google introduced a new concept, the signed certificate timestamp (SCT). An SCT is a signed promise that the log will add the certificate to their tree soon, even though they haven't yet. The figure below shows the issuance flow with SCTs.

Certificate issuance with SCTs

The way this works is that the CA produces what's called a "pre-certificate", which is a data structure that has all the information that would be in a real certificate. It then sends that to the log, which returns an SCT that covers the pre-certificate. The CA then takes the SCT and adds it to the certificate before issuing it to the site. This has the big advantage that the site doesn't need to know about CT; because the SCT is part of the certificate, it can use the certificate as before without changing anything, which is obviously a big deal for incremental deployment. In fact, the CA can deploy CT entirely on its own one day and sites will just automatically have CT-enabled certificates.

Because SCTs can be generated immediately by the log, CAs can deploy CT without significantly slowing down their issuance process; they just retrieve the SCT and it's the log's responsibility to eventually publish the pre-certificate in its own Merkle tree ("eventually" is doing a lot of work here, as we'll see below). The resulting certificate is immediately usable because the client checks for the SCT rather than checking the Merkle tree.

Trust is a bad word #

The good news is that CT with SCTs is minimally disruptive while also allowing the browser to enforce the use of CT. The bad news is that it has totally different and much weaker security properties from the system we started with. The problem is that the SCT is just a promise that the log will incorporate the certificate into their Merkle tree, rather than a proof that it actually did, so you're reduced to trusting the log not to lie.

Recall the security logic of a transparency system, as described in Part I:

The CA publishes every certificate (i.e., identity/public key pair) that it issues.
The owner of a given identity—and potentially other people—ensures that it recognizes every certificate that was published.
Relying parties check that a certificate is in the log before accepting it.

The use of SCTs breaks part (3) of this system, because the client is just checking that the log promised to incorporate the certificate, rather than that it actually did. Consider what happens if you have a malicious CA that colludes with a malicious log. The CA would misissue a certificate for example.com, along with an SCT from the malicious log, but the log would omit the certificate from its published tree. The client will accept the certificate because it has the SCT, but because the log never publishes the certificate, example.com has no opportunity to detect the misissuance.

What's happened here is that we've taken a system which was publicly verifiable and turned it into a system in which we have to trust the logs not to cheat by issuing SCTs for certificates they don't actually publish, potentially with some double checking, as described below [Updated 2023-12-25]. This is still better than where we started because a successful attack requires that both the log and the CA be malicious, but it's a much weaker set of properties from not having to trust the log at all.

This design also means that not anyone can run a log but instead logs have to be vetted to be trustworthy and to conform to browser policy. This trust decision has to be encoded into the browser which decides whether to accept a given SCT. At present, Chrome accepts logs from only six operators:

Google itself
Cloudflare
DigiCert
Sectigo
Let's Encrypt
TrustAsia

When Google originally launched the CT requirement in Chrome, they actually required that at least one of the logs be Google's log, which meant that the policy effectively came down to "we (Chrome) trust Google's log not to lie", but had some obvious problems from an openness perspective, as it meant that realistically CAs had to use Google's log. They have since changed the policy and now you can use any two accepted logs (for certificates valid for 180 days or less) or three logs (for certificates valid for more than 180 days). This means that in order to covertly misissue you need a malicious CA and two malicious logs to collude.

Update: 2023-12-25: Ryan Hurst points out argues that the requirement for policy compliance is more about ecosystem health than about the need to trust the logs (assuming I understand him correctly) and that Chrome's auditing allowed them to verify inclusion, and thus to relax their log policy. As noted below, I think this has some force for Chrome, but mainly because it's effectively making Google the guarantor that a certificate has actually been published.

Closing the Loop #

Because the source of the problem is that the client isn't verifying inclusion of the certificate (by checking the inclusion proof) but only that the log says it would include it (by checking the SCT), the obvious fix is to have the client somehow verify that the certificate actually was included. This turns out to be somewhat challenging and there have been a number of attempts, none of which really work.

The first problem is that we will not always be able to enforce inclusion in real time for the same reason that we need SCTs in the first place: the certificate might have just been issued very recently. For these certificates the client has to trust the SCT to establish the connection and at best can check that the certificate was subsequently included by the logs. This is actually worse than it sounds because the CA has complete freedom about what timestamp to put in its certificates, and so—assuming it can collude with two logs—it can always have a misissued certificate appear to be recent. The result is that the attacker will succeed in impersonating the server and at best the client will be able to detect the cheating at some later time when it determines that the certificate was never logged.^[1]

Verifying Inclusion #

Even once you are past the time when the certificate should have been logged, verifying that it actually was is tricky. For obvious performance reasons we don't want to have to download the entire database. The inclusion proof is nicely compact, but when the client contacts the log and asks for the inclusion proof, that tells the log which certificate the client is checking and hence which site the client is visiting; together with the client's IP address, this allows the log to track the client's activity. Obviously, this problem is worse if there are only a small number of logs and was even worse when Google had to be one of them.

In order to prevent this form of tracking, we need some way for the client to retrieve the inclusion proof anonymously. There are a number of possible options here (VPNs or proxies) or Private Information Retrieval. As far as I know, no log deploys any kind of PIR—it would probably be quite expensive—and while proxies or VPNs are technically feasible, they're not free to run. There are similar problems with clients reporting certificates which are not included but should have been. I'm not aware of any major browser which verifies certificate inclusion proofs [Update 2023-12-25] by default (Chrome had some ideas about using DNS,^[2] but seems to have abandoned them.^[3]), though see below.

Distributing Inclusion Proofs #

One way to minimize the privacy risk of retrieving the inclusion proofs is to have the server distribute them to the client. Of course, if you're not willing to wait for the next STH, then you still have to deal with SCTs, but at least after the STH was issued the server could somehow get a copy of the inclusion proof and send that to the client, thus preventing the client from having to retrieve the inclusion proof for older certificates. This seems like a good idea in practice but ran into several problems.

First, it was never really clear how you would distribute the STH to the server, which, after all, already has the certificate. One possibility is to incorporate the STH into a new certificate, which the server would then retrieve a day or two later and thereafter server to the client; this seemed kind of impractical when CT was originally designed, but in the intervening 10 years, automatic certificate issuance has become far more common (specifically, a protocol called ACME, originally developed for Let's Encrypt), and so it wouldn't be that hard to imagine modifying ACME to send an updated certificate. Importantly, this is something that could be deployed incrementally, because clients have to be able to fall back to SCTs anyway. However, it doesn't seem to be something that's happening.

There were also ideas about using what's called OCSP stapling. Because certificates have a long lifespan, they might be revoked while still otherwise valid. The OCSP protocol allows clients to check whether a certificate is still valid, but introduces latency and has its own privacy problems. For a while, there was interest in having servers pre-retrieve OCSP responses (they're signed by the CA) and give them to clients proactively, thus letting them skip the OCSP checks, and it would be straightforward for the CA to put the inclusion proof in the OCSP response. This has similar deployment properties to the new certificate idea, except that it requires servers to actually do OCSP stapling. However, at the end of the day browsers adopted a different set of mechanisms for handling revocation, centered around centrally distributed revocation lists, so OCSP stapling never really took off.

All of these ideas about providing inclusion proofs to the client were made more complicated by ambiguity about which STH the inclusion proof was supposed to apply to. In the system I described in part I, there was a new Merkle tree every day, but the way CT is actually designed is that there is an ever-growing Merkle tree and STHs are issued at whatever intervals are convenient for the log, as long as they aren't too far apart. This means that it's possible for the browser to have an STH for 5 PM but the server to have an inclusion proof for 4 PM. CT has a way of handling this with a mechanism called a "consistency proof" that bridges between these two versions of the tree, but retrieving the consistency proof requires contacting the log, which creates new privacy problems.

This is actually a solvable problem if the logs provide a more predictable mapping from certificates to STHs (a technique called STH discipline which Richard Barnes and I worked on), but by the time this was all worked out, there wasn't that much energy for changes to CT.

Gossip Doesn't Work #

Even if we did have some mechanism for verifying the inclusion proof, we still have the problem of getting consensus on the STHs. The original CT design assumed a flood fill technique (what they called "gossip") like I described in part I, but was frustratingly short on specifics:

All clients should gossip with each other, exchanging STHs at least; this is all that is required to ensure that they all have a consistent view. The exact mechanism for gossip will be described in a separate document, but it is expected there will be a variety.

Needless to say, this is some vigorous handwaving, and actually building a system like this is fairly hard. In particular, there's no obvious way for browser clients to discover and communicate with each other (see my post on ICE to see some of the challenges here), as this isn't something they otherwise normally do.^[4] Eventually the IETF did try to produce a document with some ideas, but it was quite complicated and the IETF abandoned it and as far as I know, no browser ever implemented gossip.

Another option to gossip is to have the software vendor just provide the STHs. This arguably is less secure than gossip because the vendor can lie, but as I noted previously, the vendor also controls software updates and the trust anchor list, so browser vendors are reasonably comfortable with designs that require trusting them, at least for now. This is something Richard Barnes and I looked at in concert with STH discipline, but ultimately it wasn't worth it without some way to actually get the inclusion proofs on the servers, which remained largely an unsolved problem. As things stand today, clients don't really do anything to retrieve or double-check STHs.

Update: 2023-12-25 Note that what I'm referring to here is that it's hard for clients to gossip. It's obviously not a problem for services which are verifying each certificate that was issued (monitors) to gossip, as discussed below.

Chrome CT Auditing #

Added 2023-12-25

As Emily Stark pointed out to me on X/Twitter, Chrome actually does some auditing, which I had somehow managed to miss. Specifically, it checks to see if Google is aware of a given SCT. Joe DeBlasio has a summary here:

No Safe Browsing protections -> no SCT auditing

Default Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and performs a k-anonymous lookup on an SCT. If that privacy-preserving SCT lookup reveals that the SCT is not known to Google but should be, the client uploads the certificate, SCTs, and hostname to Google (but no other information).

Enhanced Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and uploads the certificate, SCTs, and hostname to Google (but no other information).

This is an interesting design and gets around some of the problems that I've discussed above.^[5] The security properties it provides are:

Google can learn which certificates have been issued by other logs and do whatever checks it wants on whether they should have been issued.
Google can check that other monitors are seeing the same thing as it does (by gossiping between monitors, as in the previous section), thus allowing them to independently check for misissuance.
Under certain assumptions about the attacker's capabilities, Google will eventually learn about any certificate which wasn't logged. What I mean by "certain assumptions" is that (1) the attacker has to use the certificate reasonably often to have a high probability of report and (2) a powerful attacker might be able to impersonate the server to a client and then block the client's subsequent network access to Google so that it can't make the report.

This isn't nothing, but I think it also falls short of public verifiability in several respects. First, it still leaves clients vulnerable to accepting certificates which were never published; it just makes it possible—modulo the caveats in point (3) above—to detect the compromise after the fact. Second, it fundamentally depends on Google acting as the guarantor that certificates were published because they're the ones who run the auditing service.

Overengineering #

As a result of all this, CT has more or less given up on public verifiability. As soon as you allow for SCTs, clients have no way of ensuring that certificates have been logged before accepting them, and without some mechanism for verifying retrospectively that certificates were logged, there's not even any way for clients to detect that they accepted an unlogged certificate, and CT just reduces to a system where the clients trust the logs not to lie about whether they are going to publish a given certificate.

Updated 2023-12-25, in light of conversation with Emily and Ryan As a result of all this, CT provides fairly limited public verifiability. At the time of acceptance, clients have no way of ensuring that certificates have been logged before accepting them, because the certificate might have just been issued and not yet incorporated into a log. Chrome's CT auditing provides a partial mechanism for retrospectively detecting that unlogged certificate was accepted, but this really depends on trusting Google, because Google has to see a copy of every certificate to make this work.

~~If we're just trusting the logs, though~~ Why then do we need all the machinery of Merkle trees? The logs could just take in pre-certificates, issue SCTs, and publish the certificates on their sites as soon as possible (effectively immediately). This doesn't provide public verifiability, of course; instead the logs act as what's called a "countersignature", in which the signature from the logs isn't attesting that they verified the certificate's trustworthiness themselves, just that they've seen it. To a first order, the answer is that what we actually have is a countersignature scheme and that the Merkle tree machinery is unnecessary overhead, or, perhaps, more charitably, futureproofing against some future world where we solve the engineering problems described above.

The problem is that it's expensive futureproofing, both in terms of protocol complexity and in terms of operational brittleness. A fairly large fraction of the CT RFC is concerned with specifying the Merkle trees, the machinery of Merkle tree proofs, and the like. All of this could just go away if we were to just treat CT as a "countersign + publish" protocol, leaving a dramatically simpler protocol that would be a thin layer on top of HTTP.

Worse yet, CT logs turn out to be hugely operationally complex to run correctly. I haven't personally operated one, but the basic problem seems to be tight timing requirements combined with the immutability of the Merkle tree structure. Recall that an SCT is a promise to include the certificate into the Merkle tree, which has to happen within a finite period of time called the maximum merge delay (MMD) (which Chrome requires to be no more than 24 hours). The reason for this is so that the clients can check that the log fulfilled its promise in the SCT to actually put the certificate in the log. If the log just had to eventually put it in, then whenever the client checked it could just say "not right now", hence the MMD. But this means that if you have any kind of glitch (say a precertificate gets lost in some queue or you have some an outage of more than 24 hours), you're suddenly out of compliance. Running a big production service with no glitches is no easy task and it shouldn't be surprising that we've seen issues.

Some examples: In August, DigiCert's log was retired because they had a bit flip in one of the entries in the tree and just in November, Cloudflare's log had an outage in which they failed to include thousands of certificates within the MMD. Even Google has had outages and at least one resulted in an MMD violation.^[6] The difficulty of running a log is a direct result of the requirements introduced by the combination of SCTs and trying to maintain the infrastructure that would support public verifiability, even though public verifiability doesn't exist in practice. Running them would be far simpler if those requirements were relaxed, and, as far as I can tell, it would have no material impact on user security.

Why then, do we have this overengineered design? The history is a little fuzzy, and I wasn't there at the beginning, but my sense is that when CT was originally designed the intention was not to have SCTs and instead to have just Merkle trees and inclusion proofs delivered with certificates (more or less the design I described in Part I). Despite some challenges, this design probably could have been made to work in a greenfield setting, albeit at the cost of high issuance latency, but eventually the designers were forced to add SCTs for deployability reasons. By the time it was clear we would be stuck with SCTs indefinitely, there was a huge amount of inertia behind the Merkle tree design, which was widely deployed and people were reluctant to climb down from it and from the hope of future public verifiability. So, instead we have a system with the complexity of public verifiability with the security of countersignatures.

Despite all this, the CT RFC (both the original 2013 version and the 2021 update) still claims that logs don't need to be trusted:

Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new certificates are added to it. The logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance. Note that this is a general mechanism, but in this document, we only describe its use for public TLS server certificates issued by public certificate authorities (CAs).

I suppose at the time it was written (2013) this could be read as aspirational language in the hope that some way could be found to deal with the issues described above. From the perspective of 2023, however, it looks more like wishful thinking.

CT: Still Useful #

Despite everything I've said above about the limitations of CT verifiability, it's still proven to be exceedingly useful. There is a robust set of logs and quite a few services, and CT has helped detect a number of serious incidents, in several cases leading to CAs being distrusted. [Updated: 2023-12-25]

First, a lot of CA issues are simple mistakes rather than intentional misbehavior that the CA is trying to conceal. Forcing CAs to publish all of their certificates makes this kind of error easier for third parties to detect, which happens with some frequency. This benefit doesn't require browsers to check SCTs at all, just that CAs be required to log certificates. In addition, the requirement to log certificates means that it's possible to construct a database of all the valid certificates, which is a very useful research tool.

Second, CT requirements make it harder to cheat because not only does the CA have to intentionally misbehave, it has to collude with logs to do so. Obviously, finding one or more malicious logs is harder than just having the CA be malicious, especially given the relatively small number of logs, so CT provides a real security benefit even with no public verifiability.

Finally, CT is a really useful tool for gaining visibility into the overall state of the WebPKI ecosystem; because every certificate has to be published, CT makes it much easier to understand the system as a whole.

The Bigger Picture #

What we have here is yet another case of how the Internet is build on "good enough".

It's a commonplace that the WebPKI is a cobbled together mess and at the time that CT was designed, it was even moreso. At roughly the same time CT was published there was a fair amount of interest in replacing the WebPKI with something based on DNSSEC/DANE which looked like it might have a better attack profile, in particular because there weren't a large number of actors able to attest to a given name. In practice, though, DANE deployment for the Web totally stalled, largely because it was basically a forklift upgrade.

By contract, CT is yet another patch on top of the WebPKI, but was incrementally deployable. Imperfect though it is, it has gone a long way towards improving the system, both by making undetected misissuance harder and by making simple misbehavior easier to spot and address. I know there are still people who want to replace the WebPKI with something based on totally different principles, but in 2023, that looks fairly implausible.^[7]

Similarly, while CT is overcomplicated, hard to operate, and a lot more than we really needed, it's also what's deployed and people aren't really excited about changing it. In fact, while there was an extensive effort to produce a revision of CT ("Certificate Transparency v2"), eventually everyone just kind of ran out of energy and while it did get published as an RFC, as far as I know nobody implements it. If we were starting from scratch, we'd probably do it differently (see "good enough", supra), but that's not where we are, and it's easier to just stick with what we have.

None of this is to say that transparency and public verifiability aren't good ideas, and now that end-to-end encrypted messaging has become so popular there is increased interest in transparency for those systems. The requirements here are somewhat different and the result is a rather fancier system called "key transparency", which will be the subject of the next post in this series.

This is also the reason why clients requiring that servers provide inclusion proofs for sufficiently old certificates doesn't help. ↩︎
The reasoning here is that your DNS server already knows what sites you are visiting and so if you could also retrieve the STH over DNS, this would provide privacy. ↩︎
This state of knowledge paper by Meiklejohn, DeBlasio, O'Brien, Thompson, Yeo, and Stark provides a good survey of the alternatives and the present situation. ↩︎
Apple's recent deployment of Key Transparency for iMessage does gossip but this is much more natural because iMessage clients already talk to each other. ↩︎
As an aside, this has some undesirable privacy properties, similar to those of Safe Browsing, and worse if the client actually reports a suspicious certificate. ↩︎
See Andrew Ayer's excellent writeup of CT log failures, though Ayers is a bit more sanguine about failures than I am. ↩︎
Benjamin, O'Brien, and Westerban have a proposal to replace the combination of X.509 and CT with something called "Merkle Tree Certificates", but conceptually this is the same trust architecture as the WebPKI. ↩︎

A hard look at Certificate Transparency, Part I: Transparency Systems

2023-12-13T00:00:00Z

Identifying the communicating endpoints is a key requirement for nearly every security protocol. You can have the best crypto in the world, but if you aren't able to authenticate your peer, then you are vulnerable to impersonation attacks. If the peers have communicated before, it is sometimes possible to authenticate directly, but this doesn't work in many common situations, such as when you are given the address of a Web site and need to connect to it securely.

Nearly every major communications security protocol has the same basic authentication design:

Endpoints have human-readable identities (e.g., domain names, e-mail addresses, phone numbers, etc.)
A trusted authentication service attests to the binding between an identity and the endpoint's public key.
The endpoint uses its private key to prove it identity.

For example, in the HTTPS/Web context, sites are authenticated by having certificates which are issued by a certificate authority (CA).^[1] These CAs are in turn vetted by browser vendors, who decide which CAs their browsers will trust. This entire system is called the "WebPKI" (see here for more background on this.)

The key word in this system is trust: the endpoints need to trust that the authentication service doesn't falsely attest to a binding for the wrong person (technical term: "misissuing"). If an authentication service makes a mistake or deliberately cheats, then this could allow the attacker to impersonate a valid user of the system, which is obviously bad. This is not merely a hypothetical issue. In the WebPKI alone, there have been a series of high profile certificate authority failures, perhaps most famously in 2011 when the Dutch CA DigiNotar was subverted and issued a series of bogus certificates, including one for Google. The bottom line is that an authentication service of this type represents a single point of failure for the system as a whole. The WebPKI is especially bad here because there are a large number of CAs, nearly all of which can attest to any domain name, so there are multiple entities, each of which is a single point of failure.

There are a number of potential approaches for defending against this problem but the one that the community seems to have settled on is what's called a transparency system. The basic concept of such a system is that you retain the idea of a trusted authentication service but add on a layer in which it publishes the bindings it is attesting to so that anyone can check that it's not misissuing. The first transparency system, and still the most widely deployed, is Certificate Transparency (CT), designed by Ben Laurie, Adam Langley, and Emilia Kasper (all at Google at the time) in the wake of the DigiNotar incident. CT was designed to bring transparency to the famously mismanaged WebPKI. More recently, there has also been a lot of interest in CT-like (but fancier) systems for non-WebPKI applications, such as "key transparency" for messaging systems, but in this post I want to focus on CT.

As you can see from the diagram below, CT is a very complicated system, in part because it had to be retrofitted onto the existing WebPKI design and in part due to some technical decisions which in retrospect look like they were mistakes (I'll get into those in the next post in the series).

[Overview of Certificate Transparency from transparency.dev]

What I want to do in the rest of this post is to try to gradually build up to a sort of idealized version of CT from first principles. In a future post, I'll look at actually existing CT, some of the compromises that it made in the name of deployment, and the implications of those compromises.

Transparency Systems #

The basic idea behind a transparency system is not to prevent misissuance but to detect it. At a high level, this works as follows:

The CA publishes every certificate that it issues.
The owner of a given identity—and potentially other people—ensures that it recognizes every certificate that was published.
Relying parties check that a certificate is in the log before accepting it.

The figure below provides an overview of the verification pieces of this process in the Web context:

Conceptual overview of a transparency system

At some point, example.com gets a certificate (1234) from the CA, which publishes that certificate. Then, when Alice wants to connect to example.com, it presents that certificate (step 1). Alice then checks with the published certificate list to verify that the certificate is actually on the list (step 2). Separately, example.com periodically checks the list to be sure that only certificates it knows about are on the list.

There are a lot of moving pieces, so it's worthwhile working through the logic here for why this works.

Is it possible to prevent misissuance? #

While detecting misissuance is good, it would be better to prevent it entirely. Unfortunately, this turns out to be a very challenging problem because the authentication service has to determine who owns a given name (e.g., example.com), and that determination isn't directly verifiable by third parties. There are designs which bind name issuance to authentication (often using some kind of blockchain), but the problem with these systems is that they don't allow for any discretion on the part of the authentication service, so, for instance, if I register example.com and then lose my keys I still want to be able to reclaim it. This may require some kind of manual intervention. More on this here. If you're going to allow for discretion to handle this kind of case, then you need to worry about that discretion being abused.

Misissuance Detection #

Because every issued certificate is published, if the CA misissues a certificate, then it will also be published and can then be detected, either by the true owner of the identity or by a third party who notices something fishy (why is some CA I've never heard of issuing a certificate for Google?).

In the Web context, this is all somewhat harder than it sounds: if you're a big and well-operated site, then you may well know every certificate that you have requested, but that's not necessarily true for smaller sites.^[2] Similarly, third party verifiers won't necessarily be able to check that the issued certificates are what is expected. The result is that while you should expect that misissuance of high profile sites will likely be detected, misissuance of smaller sites could easily go unnoticed.

Managing Misissuance #

OK, so you've detected a certificate that was misissued, now what? The general story is that you report it. What happens then depends on how the certificate was misissued. In the simple case of unintentional misissuance—which definitely happens—you would expect the CA to revoke the certificate, investigate what happened, and if possible address whatever issue lead to the misissuance.^[3]

However, it's also possible that the CA is not well operated or the misissuance is more than a simple mistake. In this case, browsers might decide to distrust the CA, with the effect that all certificates issued by the CA. This is a disruptive step, but it does happen, even to large CAs. For instance, in response to a series of operational issues the browsers distrusted Symantec (very gradually) between 2016 and 2018.^[4]

Much of the value of a transparency system like this is that works together with the threat of distrust as an incentive to good behavior. As noted above, it's possible for misissuance for the names of small sites to go undetected, but once there is some evidence of some misbehavior—perhaps of a single site—the transparency system allows for easier investigation of the other certificates issued by the CA. It is also possible to use the transparency system to detect other kinds of CA misbehavior than misissuance which can then prompt further investigation.

Incompetence versus Malice #

If all we are worried about is mistakes by the authentication service, then just publishing all the certificates is mostly enough; even if the CA inadvertently issues a certificate to the wrong person, it will still be published and so the mistake can potentially be detected. But what if the CA is intentionally misissuing? In this case, it can just provide the certificate to the attacker without publishing it, in which case the fraud isn't readily detectable.

This is the reason for requiring the relying parties (clients) to enforce that the certificate has been published (point 3 above). This prevents attacks where the AS doesn't publish the certificate because the relying parties just won't accept it, making the attack pointless. If relying parties don't check for the presence of the certificate on the published list then nothing requires the CA to publish every certificate.

Partitioned Views #

The description above just covers the logic of a transparency system but doesn't tell you how one actually works and in fact I've glossed over an important technical problem, which is how to ensure that the published list of certificates is the same for everyone. The obvious thing to to do is for the AS to just publish the list of certificates it has issued on its Web site, but this isn't secure. Consider what happens if the AS gives different answers to different people, like so:

Partitioning attacks

In this scenario the attacker has obtained a misissued certificate from the CA (not shown), which creates two lists of certificates:

List 1, which has the attacker's certificate
List 2, which has the legitimate certificate

When example.com goes to check the list of certificates, the CA provides List 2, containing the correct certificate (1234) so everything looks OK. On the other hand, when Alice connects to the attacker (impersonating example.com), it presents the fake certificate (ABCD). Alice then connects to the CA, which provides List 1, containing ABCD everything looks OK here too, and the attack goes undetected.

The point here is that the authentication server needs to publish the certificate list in some way that everyone has the same view and that they can verify that they have the same view (technical term: consensus). As long as this is true, then we know that the owner of the identity has had a chance to check any certificate which the relying party might treat as valid.

The analogy I like to use for this kind of consensus (I'm not sure who originated it) is that the authentication server publishes each binding by using a giant laser to inscribe each binding onto the face of the moon. This allows anyone with a telescope to look up—at least during the night—and see what bindings have been created.

Writing on the face of the moon. Image by Kate Hudson with components from Midjourney and Adobe AI.

This is what is known as a "publicly verifiable" system in that it doesn't require trust. Anyone can see for themselves what is written on the face of the moon, so you aren't depending on the CA not to cheat.

Unfortunately, the giant laser is physically impractical, and so we need some other technology for providing consensus. Much of the complexity in transparency systems derives from this requirement.

Manufacturing Consensus #

As noted above, the basic challenge we have here is ensuring that every client has the same view of the certificate database.

The obvious thing to do is for people—really client software—to share copies of the database with each other so that you effectively flood fill the database to everyone and eventually everyone has a copy of the whole database. Alternately, if you have a piece of software like a browser which has an update channel, the vendor can send a copy of the database to all its users. Of course in this case you're trusting the browser vendor not to send a fake database, but as a practical matter you're also trusting them not to send you malicious updates anyway, so it's not clear how much worse this makes the situation. More on this in a future post. Whichever design you are using, if the attacker has mounted a partitioning attack as described above, then the site will eventually get a copy of the correct database from some other element, thus allowing for detection of misissuance when it sees a certificate it doesn't recognize.

One thing that's very important to realize is that it doesn't matter if some—or even most—of the endpoints in the system are malicious; if the flood fill system is working, then eventually^[5] each endpoint will talk to someone who isn't malicious, so they will eventually get a copy of every certificate. And because certificates are publicly verifiable (you just check the signature), it's easy to store every certificate that is valid and discard the ones that aren't. A malicious node can remove certificates from the database they send you, but they can't insert certificates that don't exist or prevent other endpoints from sending you valid certificates.

Moreover, it's not really required that everyone get a full copy of the database: consider the case where we have a fake certificate for example.com. If the operators of example.com see it, then they can publish it and report it to the browser vendors, who can then investigate, as described above. The point here is that the system doesn't need to work perfectly in order to detect attacks; it just needs to work well enough that (1) any relying party will be able to validate that a certificate has been published in the database and (2) the attacker cannot reliably prevent parties trying to verify database correctness from getting a copy of misissued certificates.

With the right data structure, it's also possible to make partition attacks easier to detect. For instance, if each CA publishes one database a day and signs the entire database, then any element which receives two databases for a single day can immediately detect that there has been cheating.

The problem, obviously, is that this kind of flood fill is incredibly inefficient: Let's Encrypt alone has about 300 million valid certificates; at 1K each, this would be a database of 300GB, not something you want to be storing on your phone, let alone having to send to everyone else you come into contact with—ignoring for the moment the question of how you're going to transmit the database around. Clearly, this simple system is not practical.

Of course, you don't actually need to send a copy of the database to everyone, you just need to verify that you have the same database as everyone else, which you can do by exchanging hashes of the database, but this doesn't get us very far because (1) you still need to keep a copy of the database on your computer and (2) the database isn't static, but instead new certificates are constantly being issued (Let's Encrypt issues over 3 million certificates a day). Addressing this requires some new technology, specifically something called a "Merkle Tree".

Background: Merkle Trees #

The idea behind a Merkle Tree is to allow a way to efficiently commit to a set of values without actually publishing any of the values.

As an intuition pump, suppose I run a streaming service which send movies over the Internet and I want people to be confident that they are getting the right movie and not some content generated by an attacker. In the real world, we just carry all the data over a TLS connection, but let's assume I'm too cheap for that. Instead, what I could do is send the hash of the content over the TLS connection and then let the client retrieve the rest over HTTP (there used to be a time when people really worried about the cost of encryption). The problem with this is that the hash is computed over the entire movie, but we obviously want people to able to verify that there hasn't been any tampering as they are watching it. The obvious solution here is to break the movie up into chunks—you want to do this anyway so that people can easily scroll forward or backward—and then send a hash for each chunk over the TLS connection. Then, when the client retrieves each chunk, they can verify the hash before they play it.

This still involves sending a fair amount of data over the TLS connection, though: suppose each chunk is 5s long, then a 2 hr movie will be 1440 chunks and require sending something like 46KB over the TLS connection. It turns out that there is a more efficient strategy, using one of the computer scientist's favorite tools, the binary tree. The basic idea is that we hash each chunk and then arrange the chunks in a binary tree, like so:

A Merkle tree

The leaves of the tree are the hashes of the individual chunks and then each interior node is the hash of its two children^[6] This way, the root of the tree includes the hashes of all of the leaves, so if any leaf changes then it would also change the hash of the root. This way, you can publish only the root hash over the TLS connection and anyone can verify the leaves by just hashing them up to the root.

Well, sort of. What I just described requires having all the chunks, but remember we want to be able to verify a chunk without other chunks. Fortunately, there is an easy way to arrange this: when you send a chunk, you also send enough nodes in the tree to let the receiver reconstruct the tree. Specifically, you send the nodes next to the nodes on path between your chunk and the root. For example, suppose I just sent chunk 1. The receiver can compute H(C1) for themselves, but they can't compute the parent node without knowing H(C2), so I have to send that. Similarly, they can't compute the root without knowing H ( H(C3) + H(C4) ) so I have to send that as well. I don't have to send H(C3) or H(C4) because they don't need that to compute the root.

The figure below illustrates what I'm talking about:

The co-path of a Merkle tree

The sender has to transmit everything in blue, specifically:

The chunk C1 itself so that the receiver can compute H(C1), though of course it was transmitting this anyway.
H(C2) so that the the receiver can compute the parent node H( H(C1) + H(C2) )
H( H(C3) + H(C4) ) so that the receiver can compute the root

The receiver computes everything in black for themselves and then compares it with the root hash it received over the secure channel. If everything checks out, then this proves that the tree was computed over C1 (and that it was in that position in the tree) and therefore that it's a legitimate chunk. The technical term here is an "inclusion" proof, because it proves that the chunk was included in the computation for the tree.

The key thing to realize is that the number of extra hashes that the sender has to include in order to let the receiver verify a chunk is less than the number of total chunks. Specifically, it's the depth of the tree, which is to say the logarithm base 2 of the number of chunks. In this case, that's 2 hashes, which is only half the number of chunks, but if there were thousands of chunks then this would be a huge difference.

A Transparency System with Merkle Trees #

It should now be apparent what we are going to do next, which is to put the certificates into a Merkle Tree. As a starting point, let's say that each CA takes all the certificates and makes them the leaves of the tree.^[7] With Let's Encrypt's 3 million certificates a day, this tree will be of around depth 22 for a day's certificates. The figure below provides an overview of how this fits together:

Certificate issuance with Merkle trees

When example.com wants to get a certificate, it contacts the CA as usual. The CA does whatever procedure it wants to validate the request and then waits for other certificate requests to come in. After some period (in this case daily), the CA generates all the certificates and then builds a Merkle tree out of them. It publishes the whole Merkle tree on the Internet and then sends each site it's certificate, as well as the inclusion proof that the certificate was included in today's tree. The inclusion proof is comparatively small; using Let's Encrypt as our reference point, it will be about 600-700 bytes.

When the client subsequently contacts the site, the site provides both its certificate and the inclusion proof.^[8] The certificate can be verified in the usual fashion, but the client also needs to verify the inclusion proof in order to ensure that the certificate was actually published. In order to do this, it needs both the inclusion proof itself and the root of the Merkle tree that was published at the time of certificate issuance. Instead of flood filling the tree itself, we instead arrange to flood fill the signed root of the tree (or, more likely for a browser, to distribute it in the update channel). The client verifies the signature on the root to ensure that it's valid and then checks the inclusion proof in order to be sure that the certificate was really included in the tree.

This is a big improvement in the amount of information the client needs to store and retrieve. The signed root itself is very small (~100 bytes) and then on each connection it needs to retrieve ~600-700 bytes of inclusion proof for each certificate, which is around the size of your typical certificate, so this perhaps doubles the overhead of the TLS connection, which isn't that bad.

Note that in order to verify that there are no unexpected certificates for its domain names, the site still needs to download the entire certificate database, or more likely use some service which does it for it. However, sites typically have significant resources, and the database isn't that big, so this is a much smaller burden than requiring every browser to retrieve a copy. Moreover, a service which does this kind of checking just needs to download the database once for all of its clients, which lets it amortize the cost.

Security Properties #

This system does a reasonable job of providing the security guarantees we asked for at the start.

Because the client verifies the inclusion proof for a certificate, it is able to ensure that it chains up to a signed root. While the CA can technically make more than one tree with different contents, that requires signing two tree roots, which then have to published somehow in order to be useful. As there is supposed to be only one root per day, as soon as any endpoint sees two different roots for the same period, it knows that the CA is cheating and can prove it to any third party just by publishing both signed roots.

If we're doing simply peer-to-peer flood fill, not every client will be able to see both roots, but it's likely that one will. If clients are getting their copy of the signed root from their vendor, then the situation is even simpler: every client from the vendor will have the same root and as long as vendors check that their roots match and sites/services that want to check the database verify that their roots match the vendors roots, there's no real way to publish two roots without being immediately detected.

The result is a system that is publicly verifiable in that everyone has the same view of the certificates that have been published. This isn't perfect in that you still have to actually detect misissuance, which isn't always straightforward for the reasons I discussed above, but at least it's not possible to have covert misissuance. This means that misissuance for big sites will probably be detected, and if any kind of misissuance is detected it's much easier to investigate because you have a permanent record.

Next Up: Real World Certificate Transparency #

At the beginning, I said that I was going to try to build an idealized version of Certificate Transparency, and that's what we have here. There are still a fair number of moving pieces, but the result has strong and fairly straightforward security properties. Unfortunately, CT as actually deployed involved quite a few technical compromises and the result was something more complicated and with quite different security properties. I'll be talking about those compromises and their consequences in the next post.

Yes, yes, I know it's technically a "certification authority", but at this point, can we just agree that it's "certificate authority". ↩︎
It's also not always possible to outsource this job to a CDN or hosting provider, because you might have your site hosted across more than one service, so no single service can check that it recognizes every certificate. For instance, suppose your site is both on Cloudflare and Fastly; both services will have certificates for your domain and if Cloudflare goes to check for certificates that weren't issued to it, it will find the ones issued to Fastly. ↩︎
The processes used to validate domains for certificate issuance are far from perfect, so even a well-operated CA can still misissue. ↩︎
Note that because certificates are signed by the CA, anyone can verify that they really issued it, without the cooperation of the CA after the fact. The certificate itself plus the claim by the domain's operator is prima facie evidence that something is wrong. ↩︎
"Eventually" is doing a lot of work here, but this isn't the system we're going to build, so I'm just going to handwave past it. ↩︎
Technical note: you actually don't want to use exactly this structure because because it creates ambiguity between an interior node with children H(A) and H(B) and a leaf node with value H(A) + H(B), but that's easy to fix. ↩︎
Actual CT uses one big tree that grows over time, but this is conceptually easier to describe. ↩︎
For deployment reasons, we'd actually like the inclusion proof to be included in the certificate, so we don't need to modify the TLS stack. This is technically possible but doesn't matter at the moment. ↩︎

Adventure Run Report: Northern Yosemite 50

2023-10-29T00:00:00Z

After a kind of disappointing—but still the right call—decision to DNF at Teanaway 100, I found myself with a big pile of fitness, nothing planned for the rest of the year, but not really ready to just call it a season and start thinking about 2024. There weren't any races left I wanted to do, so instead I decided to try one of the adventure run loops that I had been eyeing for the summer but had to put off because the record snows in the 2022/2023 season kept the Sierras impassable late into the season, specifically another Leor Pantilat route that he called the Northern Yosemite 50.

My stuff ready to go.

Fortunately, my former training partner Chris Wood (now sadly reduced to running loops around Central Park in NYC) was in town, so we were able to do it together. Chris was actually already in Yosemite Valley, so we drove out separately and stayed at the Willow Springs Resort (a bit rustic but friendly and reasonably nice), which is about 30 minutes away from the start of the route at Annett's Mono Village. The "village" itself is basically a paid RV campground, but there is a big parking lot on the lake which seemed to be free. There was a "No overnight parking" sign, but we didn't expect to be there too far into the next morning in the worst case, so just left a note saying we were out trail running and hoped it would be OK.

The route is a big lollipop of just around 50 miles and 10000 ft of climbing, starting at Twin Lakes in the Hoover Wilderness at around 7000 ft, then quickly climbing above 9000 and mostly staying above there until the last 5 miles or so, with a high point of 10300 ft. Pantilat did it 15:28 and so I figured we were looking at at least 16 hrs and probably more this, which is a pretty long day this late in the season (sunset is around 6:00), so we decided on a 5 AM start, which mean that both the beginning and end would be on headlamp.

Start to the Loop [7.15 mi, +2246/-157 ft, 2:22:16, 19:56/mi, 15:41/mi GAP] #

The first 7 miles or so are the "stem" of the lollipop, a steady climb of about 2500 feet. It was really cold at the start (~45 F) so I was in gloves and a jacket and Chris was in a warm shirt and gloves, both of which were pretty much the uniform for the rest of the day as it never really warmed up. We got a little scare right as we were passing through the campground at the start when we saw a black bear rummaging through the garbage cans. The bear seemed more interested in trying to find food than in bothering us but we gave it a wide berth anyway.

As usual for the start of a run, we were fresh, and the trail itself is in pretty good shape for the Sierras and was still easy to find in the dark, so went pretty smoothly. In any case, we got to the junction quickly and were definitely thinking that this was going to be a fast day. As it turned out, we were shortly to be punched in the face by reality.

To the PCT [8.47 mi, +846/-997 ft, 2:50:17, 20:06/mi, 18:27 GAP] #

This next segment is comparatively flat and pretty early on we passed Peeler Lake, which is spectacular:

The view of Peeler Lake

40+ miles to go but at least it warmed up

This section is a bit interstitial in that it's pretty flat but you know you have some big climbs ahead of you. We would have expected to be able to move pretty fast on this segment, but due to a combination of the terrain and trying to take it conservatively we actually slowed down a fair bit. There were two factors here. First, even though a lot of this was smooth trail , it was also frequently really narrow single track cut into a meadow which I found hard to run without hitting my legs against the side. It was also somewhat gently rolling and were very deliberately walking anything that went uphill at all.

It had finally started to warm up to mid 60s and I was starting to be able to feel my hands again. It never got much warmer than this, and so we managed to stay pretty well hydrated. We'd started out with plenty of fluid (2l for me and 2.5l for Chris), with a target of about 500ml/hr, which meant that we had to start filtering water in this segment. Fortunately, there was water everywhere, whether in lakes or streams, so from here on in we kept to about 1l each. We only had one filter (Hydrapak 42mm), and were both using sports drink—you have to filter into the bottle and then add the powder, not the other way around—so the whole filtering/mixing thing slowed us down.

On the PCT [14.94 mi, +3258/-3793 ft, 5:32:15, 22:14/mi, 18:32/mi GAP] #

Finally we hit the junction for the Pacific Crest Trail. From here it's a sharp downhill to the low point of the loop (~7600ft) followed by two steep climbs, first to around 9500 ft and then above 10000 ft. The first of these is 1795 ft over 2.77 mi, for an average of 12.3%, so we made pretty extensive use of our poles.

I was really starting to feel the altitude and was definitely ready for the half-way point, which is basically at the dip between the next two climbs. We hit the halfway at just under 9 hrs, so it seemed like we were still on track for a <18 finish, especially as the last 7-10 miles were downhill. This is where I was planning to start with the caffeine and so I sucked down a Maurten Gel CAF 100. These take about 30 min to kick in but after that I started to feel a lot better. From here on, it was caffeine every 2 hrs to the finish.

From the pass at about 26 miles, it's a long downhill to around 30, where we leave the PCT again. This was another one of those sections where you would have hoped to be moving a lot faster, but in practice it was all pretty rocky and/or rutted single track so instead was a lot of hike/jogging where you'd run a bit and then have to walk to avoid some rocks, so this turned out to be a slog. At this point, Chris and I were both really hoping for the next climb to start, both so we could get it over with and because I actually find it more fun to go up in this kind of terrain because you wouldn't be running anyway, so it's not as frustrating that you can't.

Chris was also feeling altitude and had a bad headache, so when we stopped around here to filter water, he took some ibuprofen. There's been a movement away from ibuprofen in ultra, but the concern here is mostly about stress on the kidneys, and with only 20 miles to go in the cold, this didn't seem like that big a concern.

Last two Climbs [10.21 mi, +2864/-1234 ft, 3:48:21, 22:22/mi, 18:08/mi GAP]. #

We finally hit the bottom and then it was time for the last big push As you can see from the elevation profile, it's about 2100 feet over 6.4 miles, but it's really more like 850 ft over 4.4 miles (very gentle) and 1300 ft over 2 miles (quite steep), so there was a lot of hiking up shallow slopes and waiting for the real climbing to begin.

Throughout the whole approach to the pass, we could see dark clouds gathering ahead of us. The weather reports had been for some light rain in the mid afternoon, but that was for Yosemite generally and of course any weather forecast in the mountains has to be treated with some skepticism, so we mostly just crossed our fingers and pushed on. It never really rained on us, but by this time the sun had started to go down again and we were starting to get cold again.

Dark clouds over the pass

These dudes do not look very happy.

From the first pass, it's a steep descent and then the final climb of 1000+ feet over 2 miles. We'd expected to do some of this climb on headlamp, but actually we needed light a bit earlier, towards the end of the descent. I was carrying my ridiculously bright Lupine Neo (~170 lumens but still blinding on the second step out of 4), so for a while it was just me leading the way with Chris not even needing his own light.

Climbing in the dark is nice and peaceful, even if you're also getting cold and a touch of altitude sickness, and we were still happy to hit the top of the pass, telling ourselves it was just an easy cruise in. Of course, it's really an easy cruise of around 11 miles in the dark, which isn't actually so easy.

Back to the Start [10.99 mi, +591/-3609 ft, 4:10:55, 22:50/mi, 22:08/mi GAP] #

Conceptually, this last segment comes in two pieces:

Around 4 miles back to the junction of the loop
The 7 or so miles to the start, which we'd already been on

With typical runner psychology, our thinking here was that we "just need to get to the junction" because from there it's straightforward. In practice, however, this turned out to be one of the trickiest sections because (1) it was in the dark (2) the trail was really rocky (3) the trail was faint in places it was covered in snow. We got off-trail a number of times and had to spend a long time trying to figure out where it was. The process here should be familiar:

Watch shows you're off trail
Go in some direction to see if you can find it.
Watch shows you're going in the wrong direction
Pull out the phone with the better map (optional)
Finally spot a section of rock and dirt that looks more heavily used and head towards it
Obsessively look at your watch for the next two minutes to see if you're really back on trail

This obviously takes some time and caused us to really slow down in this segment. This is also where I started to fall off my nutrition; I had been pretty religiously doing 500ml of either Maurten or Tailwind + a gel or a bar every hour, but as we got closer to the finish I started thinking I didn't need to drink as much and didn't want to stop to filter. We had been drinking so much earlier that I was still well hydrated, but I got behind on my calories a bit. Fortunately with only a few hours to go I still had some buffer.

Finally, we hit the trail junction and the last descent. To be honest, this seemed a lot easier coming up, and we had both remembered it as being quite smooth and theoretically runnable, but in practice it wasn't really that runnable, so there was a lot more hike/jogging than was really ideal. The last 3 miles or so are genuinely runnable, even on headlamp, and we did run those, especially the last 1.5 miles, which are pretty much fire road.

It wasn't all smooth sailing, though: about .5 miles out Chris rolled his ankle on a rough piece of ground/rock/whatever. He walked it off but then did it again in another 200m or so. At this point our priority was avoiding injury (he's racing JFK 50 in less than a month) so we jogged it in nice and easy, at least until we got back to the campground where—again!—we saw a bear. Two, actually, a cub and what we assumed was its mother:

Fortunately, not cocaine bears.

We did the usual thing where we gave them space and made a lot of noise and fortunately they didn't chase us. From here it's an easy jog to the finish, the car, and a five hour drive home to Palo Alto.

Retrospective #

Map of the course. From Gaia GPS

Map of the course. From Runalyze

This was rather harder than I expected. For comparison, when I did Tenaya last year I averaged 19:54/mi as opposed to 21:43/here. I attribute that to several factors:

We had to do a lot more of this in the dark. I did Tenaya in midsummer and it was light almost the whole way. We were at least a minute faster (20:53) for the first 35 miles and clearly slowed down a lot as it got darker.
This was much rockier. Tenaya had a lot of smooth downhill sections (e.g., the run down from Glacier Point) where you could really open up, but there's basically nothing like that here.
With two of us, the filtering takes twice as long. If you have to filter every 2 hrs and it takes 5 additional minutes to filter, then that's almost an additional minute right there.

The main thing I would really change is that I wish I had brought warmer gloves, because the tips of my fingers were cold for the last 5 hrs or so. It was never so cold that I was really worried about damage, but it also wasn't pleasant. I have a lightweight pair of waterproof mittens that I wore at Desolation Wilderness, and I wished I'd brought those.

With that said, this was overall a pretty good day. This was really long but we finished strong and uninjured. I managed my nutrition well and managed to maintain about 300 cal/hr except for the last couple hours and I never bonked or felt thirsty. The altitude got to me a bit but I was able to manage it OK, even above 10000 ft. Given how I felt going into this, especially after Teanaway, I'm going to call it a success.

Overall: 51.8 mi, 9790 ft, 18:44:03, 21:43/mi

Maybe someday we'll actually be able to search the Web privately

2023-10-02T00:00:00Z

The privacy of Web search is tragically bad. For those of you who haven't thought about it, the way that search works is that your query (i.e., whatever you typed in the URL bar) is sent to the search engine, which responds with a search results page (SERP) containing the engine's results. The result is that the search engine gets to learn everything you search for. The privacy risks here should be obvious because people routinely type sensitive queries into their search engine (e.g., "what is this rash?", "Why do I sweat so much", or even "Dismemberment and the best ways to dispose of a body)", and you're really just trusting the search engine not to reveal your browsing history.

In addition to learning about your search query itself, browsers and search engines offer a feature called "search suggestions" in which the search engine tries to guess what you are looking for from the beginning of your query. The way this works is that as you start typing stuff into the search bar, the browser sends the characters typed so far to the search engine, which responds with things it thinks you might be interested in searching for. For instance, if I type the letter "f" into Firefox, this is what I get:

Everything in the red box is a search suggestion from Google. The stuff below that is from a Firefox-specific mechanism called Firefox Suggest which searches your history or—depending on your settings—might ask Mozilla's servers for suggestions. The important thing to realize here is that anything you type into the search bar might get sent to the server for autocompletion, which means that even in situations where you are obviously just typing the name of a site, as in "facebook"^[1]

Your privacy in this setting basically consists of trusting the search engine; even if the search engine has a relatively good privacy policy, this is still an uncomfortable position. Note that while Firefox and Safari—but not Chrome!—have a lot of anti-tracking features, they don't do much about this risk because they are oriented towards ad networks tracking you cross sites, but all of this interaction is with a single site (e.g., Google.) There are some mechanisms for protecting your privacy in this situation—primarily concealing your IP address—but they're clunky, generally not available for free, and require trusting some third party to conceal your identity.

This situation is well-known to most people who work on browsers—and to pretty much anyone who thinks about it for a minute—of course you have to send your search queries to the search engine, if it doesn't have your query, it can't fulfill your request. But what if it could?

This is the question raised by a really cool new paper by Henzinger, Dauterman, Corrigan-Gibbs, and Zeldovich about an encrypted search system called "Tiptoe".^[2] Tiptoe promises fully private (in the sense that the server learns nothing about what you are searching for) search for the low low price of 56.9 MiB of communication and 145 core-seconds of server compute time. Let's take a look.

Background: Embeddings #

In order to understand how Tiptoe works, we need some background on what's called an embedding. The basic idea behind an embedding is that you can take a piece of content such as a document or image and convert it into a short(er) vector of numbers that preserves most of the semantic (meaningful) properties of the input. They key property here is that two similar inputs will have similar embedding vectors.

As an intuition pump, consider what would happen if we were to simply count the number of times the 500 most common English language words appear in the text. For example, look at this sentence:

I went to the store with my mother

This contains the following words from the top 500 list (the numbers in parentheses are the appearance on the list with 0 being the most common):

the(0)
to(2)
with(12)
my(41)
went(327)

We can turn this into a vector of numbers by just making a list where each entry is the number of times the corresponding word is present, so in this case it's a vector of 500 components (dimension 500), as in:

1 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

That's a lot of zeroes, so let's stick to the following form which lists the words that are present:

[the(0) to(2) with(12) my(41) went(327)]

Let's consider a few more sentences:

Number	Sentence	Embedding
1	I went to the store with my mother	`[the(0) to(2) with(12) my(41) went(327)]`
2	I went to the store with my sister	`[the(0) to(2) with(12) my(41) went(327)]`
3	I went to the store with your sister	`[the(0) to(2) with(12) your(23) went(327)]`
4	I am going to create the website	`[the(0) to(2) going(140) am(157) website(321) create(345)]`

As you can see, sentences 1 and 2 have exactly the same embedding, whereas sentence 3 has a similar but not identical embedding, because I went with your sister rather than with my (mother, sister). This nicely illustrates several key points about embeddings, namely that (1) similar inputs have similar embeddings and (2) that embeddings necessarily destroy some information (technically term: they are lossy). In this case, you'll notice that they have also destroyed the information about where I went with (your, my) (mother, sister, friend). By contrast, sentence (4) is a totally different sentence and has a much smaller overlap, consisting of only the two common words "the" and "to"^[3]

Once we have computed an embedding, we can easily use it to assess how similar two sentences are. One conventional procedure (and the one we'll be using for the rest of this post) is to instead take what's called the inner product of the two vectors, which means that you take the sum of the pairwise product of the corresponding values in each vector (i.e., we multiply component 1 in vector 1 times component 1 in vector 2, component 2 times component 2, and so on). I.e.,

$$ P = \sum_i V_1[i] * V_2[i] $$

The way this works is that we start by looking at the most common word ("the"). Each sentence has one "the", so that component is one in each vector. We multiply them to get 1. We then move on to the second most common English word (which happens to be "and"). Neither sentence has "and", so in both vectors this is a 0, and 0*0 = 0. Next we look at the third-most common word ("to"), and so on. We can draw this like so, for the inner product of S1 and S2.

$$ \begin{matrix} the \\ and \\ to \\ ... \\ with \\ ... \\ my \\ .... \\ went \\ \end{matrix} \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ \end{bmatrix} \cdot \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ \end{bmatrix} = (1 + 1 + 1 + 1 + 1) = 5 $$

By contrast, if we take S1 and S3 we get:

$$ \begin{matrix} the \\ and \\ to \\ ... \\ with \\ ... \\ your \\ ... \\ my \\ .... \\ went \\ \end{matrix} \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 1 \\ ... \\ 0 \\ ... \\ 1 \\ ... \\ 1 \\ \end{bmatrix} \cdot \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ ... \\ 0 \\ ... \\ 1 \\ \end{bmatrix} = (1 + 1 + 1 + 0 + 0 + 1) = 4 $$

This value is lower because one sentence has "your" and the other has "my" but neither has both "your" and "my". Finally, if we take S1 and S4, we get:

$$ \begin{matrix} the \\ and \\ to \\ ... \\ with \\ ... \\ my \\ .... \\ went \\ \end{matrix} \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ ... \\ 1 \\ \end{bmatrix} \cdot \begin{bmatrix} 1 \\ 0 \\ 1 \\ ... \\ 0 \\ ... \\ 0 \\ ... \\ 0 \\ \end{bmatrix} = (1 + 1 + 0 + 0 + 0) = 3 $$

What you should be noticing here is that the more similar (the more words they have in common) the embedding vectors are, the higher the inner product. The conventional interpretation is that each embedding vector represents a d-dimensional vector where n is the number of components and that the closer the angle between the two vectors (the more the point in the same direction) the more similar they are. Conveniently, the inner product is equal to the cosine of the angle, which is 1 when the angle is 0 and 0 when the angle is 90 degrees, and so can be used as a measure of vector similarity. Personally, I don't think well in hundreds of dimensions so I've never found this interpretation as helpful as one might like, but maybe you will find it more intuitive, and it's good to know anyway.

Normalization #

I've cheated a little bit in the way I constructed these sentences, because using this definition sentences which have more of the common English words (e.g., longer sentences) will tend to look more similar than those which do not. For instance, if instead I had used the sentences:

S5: I have been to the store with my sister

S6: I have been to the store with your sister

Number	Sentence	Embedding
2	I went to the store with my mother	`[the(0) to(2) with(12) my(41) went(327)]`
5	I have been to the store with my sister	`[the(0) to(2) with(12) have(19) my(41) been(60)]`
6	I have been to the store with your sister	`[the(0) to(2) with(12) have(19) your(23) been(60)]`

You'll notice that sentences 2 and 5 have four words in common (the, to, with, my), whereas 5 and 6 have five words in common (the, to, with, have, been), even though they (at least arguably) have quite a different meaning (who I went to the store with) rather than just differing in grammatical tense (have been versus went).

The standard way to fix this is to normalize the vectors so that the the larger the values of components in aggregate, the less the value of each individual component matters. For mathematical reasons, this is done by setting magnitude of the vector (the square root of the sum of the squares of each component) to 1, which you can do by dividing each component by the magnitude. When we do this, we get the following result:

Sentence Pair	Un-normalized Inner Product	Normalized Inner Product
S2 and S5	4	0.73
S2 and S6	5	0.55

This matches our intuition that sentences 2 and 5 are more similar than sentences 2 and 6.

Real-world Embeddings #

Obviously, I'm massively oversimplifying here and in the real world an embedding would be a lot fancier than just counting common words. Typically embeddings are computed using some fancier algorithm like Word2vec, which itself might use a neural network. However, the cool thing here is that however you compute the embedding, you can still compute the similarity of two embeddings in the same way, which means that you can just build a system that depends on having some embedding mechanism and then work out that embedding separately. This is very convenient for a system like Tiptoe where we can just assume there is an embedding and work out cryptography that will work generically for any embedding.

Tiptoe #

With this background in mind, we are ready to take a look at Tiptoe.

Naive Embedding Based Search #

Let's start by looking at how you could use embeddings to build a search engine. The basic intuition here is simple. You have a corpus of documents (e.g., Web pages) $D_1, D_2 ... D_n$. For each document, you compute a corresponding embedding for the document $Embed(D_1), Embed(D_2), ... Embed(D_n)$. When the user sends in their search query $Q$ you compute $Embed(Q)$ and return the document(s) that are closest to $Embed(Q)$, which is to say have the highest inner products.^[4] Naively, you just compute the inner product of the embedded query against every document embedding and then take the top values, though of course there are more efficient algorithms.

The figure below shows a trivial example. In this case, the client's embedded query is most similar to $Embed(D_4)$, and so the server sends $D_4$ (or, in the case of search, its URL) in response.

This is actually a very simplified version of how modern systems such as ColBERT work.

Of course the problem with this system is the same as the problem we started with, because you have to send your query to the server so it can compute the embedding. There are two obvious ways to address this:

Compute the embedding on the client and send it to the server.
Send the entire database to the client

The first of these doesn't work because the embedding contains lots of information about the query (otherwise the search engine couldn't do its job). The second doesn't work because the embedding database is far too big to send to the client. What we need is a way to do this same computation on the server without sending the client's cleartext query or its embedding to the server.

Naive Tiptoe: Inner Products with Homomorphic Encryption #

Tiptoe addresses this problem by splitting it up into two pieces. First, the client uses a homomorphic encryption encryption system to get the server to compute the inner product for each document without allowing the server to see the query.

The client then ranks each results by its inner product, which gives it a list of the results that are most relevant (e.g., results 1, 3, 9). The indices themselves aren't useful: the client needs the URL for each result, so it uses a Private Information Retrieval (PIR) scheme to retrieve the URLs associated with the top results from the server.

The reason for this two-stage design is that the URLs themselves are fairly large, and so having the server provide the URL for each result is inefficient, as most of the results will be ranked low and so the user will never see them. The server can also embed the type of preview metainformation that typically appears on the SERP (e.g., a text snippet) if it wanted to, but because PIR is expensive, you want the results to be as small as possible. Once the client has the URLs, the it can just go directly to whichever site the user selects.

I already explained PIR in a previous post, so this post will just focus on the ranking system. This system uses some similar concepts to PIR, so you may also want to go review that post. You may recall from that post that a homomorphic encryption scheme is one in which you can operate on encrypted data. Specifically, if you have two plaintext messages $M_1$ and $M_2$ and their corresponding ciphertexts $E(M_1)$ and $E(M_2)$ then the encryption is homomorphic with respect to a function $F$ if

$$ F(E(M_1), E(M_2)) = E(F(M_1, M_2)) $$

So, for instance, if you were to have an encryption function which is homomorphic with respect to addition, that would mean you could add up the ciphertexts and the result would be the encryption of the sum of the plaintexts. I.e.,

$$ E(A) + E(B) = E(A + B) $$

Homomorphic encryption allows you to give some encrypted values to another party, have it operate on them and give you the result, and then you can decrypt it to get the same result as if they had just operated on the plaintext values, but without them learning anything about the values they are operating on.

We can apply homomorphic encryption to this problem as follows. First, the client computes the embedding of the query giving it an embedding vector $V$ and each element of it $i$, $V_i$. The client then encrypts each element of $V$ with a homomorphic encryption system. Call this $E(V)$ and each element $E(V_i)$. The client sends $E(V)$ to the server.

The server iterates over each URL $U_j$ and its corresponding embedding value $D_j$ and computes the inner product of $D_j$ and $E(V)$. Specifically, for each element $i$, it computes the pairwise product $I_{j, i}$:

$$ E(I_{j,i}) = D_{j,i} * E(V_i) $$

It then sums up all these values, to get the encrypted inner product for URL $j$.

$$ E(I_j) = \sum_i E(IP_{j,i}) = \begin{matrix}E(V_1 * D_1) \\ + \\ E(V_2 * D_2) \\ + \\
E(V_3 * D_3) \\ + \\
E(V_4 * D_4) \\ + \\ E(V_5 * D_5) \end{matrix} $$

Written in pseudo-matrix notation, we get:

$$ \begin{bmatrix} E(V_1) \\ E(V_2) \\ E(V_3) \\ E(V_4) \\ E(V_5) \\ \end{bmatrix} \cdot \begin{bmatrix} D_1 \\ D_2 \\ D_3 \\ D_4 \\ D_5 \\ \end{bmatrix} \rightarrow \begin{bmatrix} E(V_1 * D_1) \\ E(V_2 * D_2) \\ E(V_3 * D_3) \\ E(V_4 * D_4) \\ E(V_5 * D_5) \\ \end{bmatrix} \rightarrow \sum_i E(V_i * D_i) $$

The server then sends back the encrypted inner product values to the client (one per document in the corpus). The client decrypts them to recover the inner product values (again, one per document). It can then just pick the highest ones which are the best matches and retrieve their URLs via PIR (effectively, "give me the URLs for documents 1, 3, 9", etc.). It then dereferences the URLs as normal. Because this is all done under encryption, the server never learns your search query, the matching documents, or the URLs you eventually decide to dereference (though of course those servers see when you visit them). Importantly, these guarantees are cryptographic, so you don't have to trust the server or anyone else not to cheat. This is different form proxying systems, where the proxy and the server can collude to link up your searches and your identity.

Ciphertext Size Matters #

For instance:

If each value in the embedding vector is a 32-bit floating point number and the embedding vector has dimension 700ish, then the embedding values for each document is around 2800 bits.
If we naively use ElGamal encryption, then each ciphertext will be around 64 bytes (480 bits).

This is an improvement of a factor of 7 or so, but at the cost of doing $N$ encryption operations, which is quite a lot.

Clustering #

Let's take stock of where we are now. The client sends a relatively short value, consisting of $T$ ciphertexts where $T$ is the number elements in the embedding vector. The server responds with $N$ ciphertexts, where $N$ is the number of URLs in its corpus and has to do $T*N$ multiplications. Depending on the homomorphic encryption algorithm, this might or might not be an improvement on the total communication bandwidth, but it's still linear in the number of documents, which is quite bad.

It's not really possible to reduce the number of operations on the server below linear. The reason for this is that the server needs to operate on the embedding for each document; otherwise the server could determine which embeddings the client isn't interested in by which ones it doesn't have to look at it in order to satisfy the client's query. However, it is possible to significantly improve the amount of bandwidth consumed by the server's response.

The trick here is that the server breaks up the corpus of documents into clusters of approximately $\sqrt N$ size (hence there are approximately $\sqrt N$ clusters). These clusters are arranged so that they have nearby embedding vectors, and hence the documents are are theoretically similar. The server publishes the embedding vector for the center of the cluster, and this allows the client to request only the inner products for the closest cluster. This reduces the amount of data that the server by a factor of $\sqrt N$ to order $\sqrt N$. There's just one problem: if the client only queries one cluster, then doesn't the server know which cluster the client is interested in?

We fix this by having the client send a separate encrypted query for each cluster, like so:

$$ \begin{bmatrix} E(0) & \color{red}{E(V_1)} & E(0) \\ E(0) & \color{red}{E(V_2)} & E(0) \\ E(0) & \color{red}{E(V_3)} & E(0) \\ E(0) & \color{red}{E(V_4)} & E(0) \\ E(0) & \color{red}{E(V_5)} & E(0) \\ \end{bmatrix} $$

In this diagram, each column represents one cluster (and hence there are $\sqrt N$ columns), and each row is a different embedding component. The column corresponding to the cluster (column $q$) of interest (in red) contains the encryption of the client's actual query embedding vector, whereas the rest of the columns just contain the encryption of 0 (the encryption is randomized so that they are not readily identifiable).

The server takes each column of the client's query and computes the inner product for each document the corresponding cluster, as before. I.e., for document $j$ in cluster $c$, it computes $E(I_{c, j})$. Then, however, the server adds up the inner product values across the clusters, with one report for the the sum of the values for 1st URL in each cluster, one for the the sum of the inner products for the 2nd URL, and the cluster, and so on, so that the server still only returns the same number of of ciphertexts as before. I.e., it reports:

$$ E(I_j) = \sum_c E(I_{c, j}) $$

Ordinarily the sum of these would be useless, but the trick^[5] here is that because the other columns—corresponding to the cluster that is not of interest—are the encryption of 0, their inner products are also zero, which means that the result sent back to the client only includes the inner products for the column of interest (column $q$).

The resulting scheme has much better communication overhead:

The server sends the list of the centers of the embeddings ($\sqrt N$).
The client sends a list of $d$ encrypted components for each cluster ($d \sqrt N$).
The server sends a single encrypted inner product value for each document in the cluster ($\sqrt N$).

This is dramatically better than the naive scheme in which the client sends $d$ values and the server sends $N$, although at the cost of pushing some of the transmission cost onto the client, for a total transmission that scales as a factor of $(d+2)\sqrt N$. Of course, that's still pretty big and the constant factor is also pretty big (~512 bits per document for ElGamal). The Tiptoe paper uses some clever tricks to bring the size down some (see below for cost numbers) but the end result is still fairly large (see cost below).

Performance #

As should be clear from the previous section it's possible to build privacy-preserving search, but how well does it actually do? This actually comes down to two questions:

How good are the answers?
How much does it cost?

Accuracy #

First, let's take a look at accuracy. Obviously, a private search mechanism will be no better than a non private search mechanism, because if it were you could just remove the privacy pieces and get the same accuracy. However, realistically we should expect worse accuracy, just on general principle (i.e., we are hiding information from the server). In this specific case we should expect worse accuracy because the server is just operating on the (encrypted) embedding of the query, rather than the whole query, and computing the embedding destroys some information.

The metric the authors use for performance is something called "MRR@100", which stands for "mean reciprocal rank at 100". The way this works is that for each query you determine which result people would have ranked at number 1 and then ask what position the search algorithm returned it in. You then compute a score that is the inverse of that position, so, for instance, if the document were found in position 5, then the score would be $1/5$. The "mean" part is that you average out the results over the document corpus. The "at 100" part is that if the search algorithm doesn't return the result in the top 100 values, you get a score of zero. In other words:

$$ MRR = \frac{\sum_i^N \begin{cases} \frac{1}{Rank_i} & \text{if } R_i \leq 100 \\ 0 &\text{otherwise} \end{cases} } {N} $$

Note that this score really rewards getting the top result, because even getting it in second place only gets you a per-document score of $1/2$.

The results look like this:

Source: Tiptoe paper.

The graph on the left provides MRR@100 comparisons to a number of algorithms, including:

A modern search algorithm (ColBERT)
Two somewhat older systems (BM25 and tf-idf)

As you can see, ColBERT performs the best and Tiptoe gets pretty close to tf-idf but is still significantly worse than BM-25. The "embeddings" is the result if you don't use the clustering trick described above. Notice here that "embeddings" does very well, and in fact is better than BM25, so the clustering really does have quite a significant impact on the quality of the results.

The graph on the right shows the cumulative probability that the best result will be found at an index less than $i$ (i.e., that it is found in the top $i$ results). The dotted line shows the chance that the best result is in the cluster Tiptoe receives at all; which reflects the best result Tiptoe could deliver even if it always picked the best result out of the cluster (about 1/3 of the time).

On the one hand, this is a fairly large regression from the state of the art, but on the other hand, it means that there is a lot of room for improvement just by improving the clustering algorithm on the server. Obviously, there's also room for improvement in terms of ranking within the cluster. With the current design the client just gets the inner product so all it can do is rank them, but there might be some things you could do, such as proactively retrieving the first 10 documents or so (there is a very steep improvement curve within the first 10) and running some local ranking algorithm on their content.

Cost #

So how much will all this cost. The answer is "quite a bit but not as much as you would think". Here's Figure 8, which shows the estimated cost of Tiptoe for various document sizes:

Source: Tiptoe paper.

The server CPU cost is linear in the number of documents in the corpus and would require around 1500 core seconds for something like Google.

The communication cost is sublinear in the number of documents but has a very high fixed cost of around 55 MiB for a query on a corpus the size of the Common Crawl data set (~360 million documents) and around 125 MiB for a Google sized system (~8 billion documents). Tiptoe uses a number of tricks to frontload this cost; most of the communication isn't dependent on the query, so that the client and server can exchange it in advance without it being in the critical path. The server also has to send the client the embedding algorithm, which can be quite large (e.g, 200+ MiB) but that is reused for multiple queries and so can be amortized out.

Using Amazon's list price costs, the overall cost is around 0.10 USD/query for a system the size of Google. Google doesn't publish their numbers but 9to5Google estimates it at .002 USD/query. This is 50 times less, which is a big difference, but actually that probably overstates the difference because Google isn't paying list price for their compute costs, so the difference is probably quite a bit less. In either case, this is actually a smaller difference than you would expect given the enormous improvement in privacy.

The Bigger Picture #

The lesson you should be taking home here is not that Tiptoe is going to replace Google search tomorrow. Not only are private search techniques like this more expensive than non-private techniques, they are inherently less flexible. Google's SERP is a lot more than just a list of results. For instance here's the top of the search page for "tiptoe":

Note that the first entry is actually a dictionary definition, the info-box on the right, and the alternate questions. The first website result is below all that. Obviously, one could imagine enhancing a system like Tiptoe to provide at least some of these features, though at yet more cost.

There are two stories here that are true at the same time. The first is about technical capabilities: in most cases, private systems are inherently less flexible and powerful than their non-flexible counterparts. It's always easier to just tell the server everything and let it sort out what to do, both because the server can just unilaterally add new features without any help from the client and because it's often difficult to figure out how to provide a feature privately (just look at all the fancy cryptography that's required to provide a simple list of prioritized URLs). This will almost always be true, with the only real exception being cases where the data is so sensitive that it's simply unacceptable to send it to the server at all, and so private mechanisms are the only way to go. However, I think the lesson of the past 20 years is that people are actually quite willing to tell their deepest secrets to some computer, so those cases are quite rare.

The other story is about path dependence. Google search didn't get this fancy at all once; the original search page was much simpler (basically a list of URLs with a snippet from the page) and features were added over time. If we imagine a world in which privacy had been prioritized right from the start, then we would have a much richer private search ecosystem—though most likely not as powerful as the one we have now. The entry barrier to increased data collection for slightly better features would most likely be a lot higher than it is today. But because we started out with a design that wasn't private, it led us naturally to where we are today, where every keystroke you type in the URL/search bar just gets fed to the search provider.

I'm not under any illusions that it will be easy to reverse course here: even in the much simpler situation of protecting your Web traffic in transit, it's taken decades to get out from under the weight of the early decisions to do almost everything in the clear and we're still not completely done. Moreover, that was a situation where we had the technology to do it for a long time, and it was just a matter of deployment and cost. However, the first step to actually changing things is knowing how to do it, and so it's really exciting to see people taking up the challenge.

Acknowledgement #

Thanks to Henry Corrigan-Gibbs for assistance with this post. All mistakes are of course mine.

Firefox, at least, does make some attempt to omit pure navigational queries, so if you type "http://" in the Firefox search box, this gets sent to the server, but "http://f" does not. ↩︎
Disclosure: this work was partially funded by a grant from Mozilla, in a program operated by my department. ↩︎
In a real-world example, one might well prune out these common not-very-meaningful words. ↩︎
Note that you might use a different algorithm to compute the embeddings on the documents as on the queries, for instance if you are doing text search over images. For the purposes of this post, however, this is not important. ↩︎
Note that this is basically the same trick that PIR schemes use. ↩︎

Desolation Wilderness Seven^H^H^H^H^HTwo Summits

2023-09-05T00:00:00Z

My two races this season were to be Broken Arrow Skyrace and then a hundred to be named later. I'd originally planned to do Whistler Alpine Meadows 100 but then it was cancelled in February and I spent a long time procrastinating but finally settled on Teanaway Country 100. Teanaway is about the opposite of UTMB: a tiny low-key race (59 entrants so far), but with pretty similar topline stats, with 32000 feet over 100 miles.

I've had several solid training blocks this year, but I wanted to try to get in one more adventure run this summer. Unfortunately, due to last winter's ridiculous snow season, most of the routes I was interested in doing in the Sierra were snowed in in midsummer, so I didn't start looking seriously till a few weeks ago, eventually deciding to take a crack at the Desolation Wilderness Seven Summits Loop, which I first saw on Leor Pantilat's fantastic site. As the name suggests, this route covers the seven named summits in the Desolation Wilderness. Technically speaking, the fastest known time for this is just to hit the peaks however, but there's a common loop linked above. The loop is 29 miles long with 10000+ ft of climbing including a fair amount of off-trail terrain, so I figured it would be a nice scaled down warmup for Teanaway. I'd actually intended to do a slightly longer variant of about 40 miles/15kft the week of August 13, but then I got sick and so had to defer to last weekend, and with only two weeks to Teanaway, decided to stick to the normal version.

Logistics #

This loop starts at a parking lot off US 50 en route to Tahoe a bit East of Kyburz. I stayed at the Sierra Inn On the River, which is conveniently situated about 15 minutes away. I was planning to start at about 5:30-6 AM (sunrise is at about 6:40), so I was able to sleep in till 4:30 and then drive over.

My stuff laid out for the next day. I ended up not bringing the remote control.

Desolation Wilderness requires permits which are self-issued at the trailhead—overnight stays require a separate permit—but even though the parking lot is at an official trailhead, I was unpleasantly surprised to see that there wasn't any kind of kiosk either at this trailhead or on the trailhead on the other side of the highway. This actually isn't the trailhead you enter the Wilderness from; instead you run down the highway for a few miles, so I figured I'd just head out and hope there was a kiosk at the other trailhead.

Start to Trailhead [3.3 mi, +249ft/-774ft] #

The first two miles or so is downhill on 50, and even though it was starting to get lighter, I did this on headlamp (Petzl Actik Core), both to make sure of my own footing and for visibility. I took this pretty easy at 8:15/mile so I could warm up.

There was no bathroom at the start, and predictably I'd only run a mile or so before I really needed to go. Fortunately, the Pyramid Creek trailhead is right along the highway and has flush toilets. They also have a pay parking lot but still no place to issue your own permit. I walked to the start of the trailhead and found a sign saying that there was permit issuance at the Wilderness boundary about a quarter mile up, so I went down the trail a bit hoping to find it, but despite going past the sign for the boundary and up to the top of a little ridge, I never found it and just gave up and headed back down the road. I did manage to lose my sunglasses, though, not, as it turned out, that I needed them.

Pyramid Peak Trail 10.33 [7.03 mi, +4262ft/-4196ft] #

This route involves a climb to the top of Pyramid Peak followed by a bunch of traversing of the high country, tagging the rest of the peaks, and then a descent to the bottom. The Pyramid Peak Trail doesn't actually have a real official trailhead, so much as a small parking area across the highway from a cut-out in the embankment. There were two cars there already and apparently it gets full later, but as I was on foot, it wasn't a problem for me.

The first summit is a monster climb right from the start, ascending almost 4000 feet in 3.3 miles. I didn't even bother to try to run any of it, but just pulled out my poles and started hiking. This is kind of an unofficial trail and isn't really marked but is in OK shape and so I was mostly just able to follow the tread pattern, occasionally checking the GPS to make sure I was on the right route.

The footing is pretty reasonable but it's still slow going because it's so steep. It also was starting to get windy so I decided to throw on my rain jacket. I have the Inov-8 Raceshell half-zip and I bought a size up with the idea that I could put it on over my pack so that you can get it on and off quickly, but this works a lot better in theory than practice, as it's a pullover and gets caught on the bulge of the pack, so I fought with it for a few minutes and then finally just took my pack off. The jacket is comfortable and breathes well, though.

Eventually, the trail just kind of ends and you get to the final 500ft or so of climb, which are just one giant talus pyramid. I forgot to take a photo here, but this shot gives the idea:

[Source: Charles Jenkins]

There didn't seem to be any obvious trail up to the top, so I just started to scramble up. As I was doing so, I saw what looked like a runner at the top starting to come down and then I ran into two hikers. They told me that it was really windy at the top (it was already quite windy where I was) and that it was safer to stay towards the right (the way they had come down). I followed their advice and sure enough it started to get quite bad to the point where I wasn't that comfortable just standing up and had to use my hands more than usual. This last 500 feet of climbing and maybe a half mile probably took me like 30+ minutes and I almost turned back once because it was so sketchy.

I finally made it to the top and found somewhere that was a little sheltered and managed to take some photos. I didn't really want to stand too much on the rock ledges surrounding the hollows people had opened up at the top (presumably for shelter), and it wasn't really that clear, but there are still some great views.

This last one really lets you see the rock slope you have to descend. Sketchy!

At this point, you're supposed to head down the back side of Pyramid Peak and head offtrail to Aggasiz Peak, but when I looked down it was pretty unclear where the trail was and I really wasn't thrilled about the idea of being exposed to that much wind for the next 10 or so miles, so I made the—in retrospect correct—decision to turn back.

As is commonly the case, coming down that rockpile was actually worse than going up: you've got gravity trying to pull you down and because you're facing forward, you can't really use your hands, so I slipped and fell on my ass a bunch of times. Because I was trying to stay out of the wind I veered way off course and ended up kind of skirting the edge of the peak and then had to bushwhack my way back to the trail. From there it was a pretty straightforward descent to the bottom and I was able to run a fair bit of it.

Back to the Car 12.24 [1.91 mi, +443ft/-39ft] #

From the bottom, I needed to climb another 500 feet or so on 50 to get back to the car, which gave me some time to regroup. At this point I was about 11 miles (though 4000+ ft) and 5 hrs in, so I had plenty of time and even though the whole route was out of the question it seemed silly to drive all the way here for what was basically a medium long run. I decided the right thing to do was to head up the trail in the opposite direction to Ralston Peak. By this point I had gone through most of my fluid, so I stopped off at the Pyramid Creek parking lot to use the bathroom and refill my bottles (I didn't have extra water in my car). From there, it's an easy run back to the car.

One nice thing about doing the route this way is that your car is a sort of impromptu aid station, so I decided to change my shoes. I do most of my running in Salomon Sense Ride 5s, but I started the day in a pair of Salomon S/LAB Ultra 3s (what I used for UTMB). I like Ultra 3s but when I put them on for the first time in months on Friday morning I didn't feel like they were giving me quite as much support as I wanted I was kind of disappointed in the traction I was getting on the loose rock, so I decided to swap them for the Sense Rides, in part so I could compare them back to back on similar terrain.

I was also starting to get a bit of a hot spot on my right heel was starting to hurt and sure enough when I took my sock off, I had a blister that had formed and popped. There's only one thing you can really do at that point, which is to tape it up, and fortunately I had some strips of kinesio tape, so I slapped one on, carefully pulled my sock back over it so it didn't peel off, and put the Sense Rides on.

By this time it had really started to rain so I swapped out my wind pants (warmish but not waterproof) for a pair of Raidlight rain pants (the old version of these). I also grabbed my waterproof mittens which go on nicely over my regular gloves. With that, I was ready to head up to Ralston Peak.

Ralston I [6.86 mi +3159ft/-2943ft] #

The Ralston climb is pretty straightforward: 2700ish feet up over a bit more than three miles. It starts out as fire road but you quickly come to a single track trail marking the wilderness boundary, where I also found a kiosk for you to register for a permit (finally). I took a moment to do that and headed up.

The climb to Ralston is a lot easier than Pyramid. The footing is about the same, except for the top, but it's only about 900fpm rather than 1300, and that makes a big difference. Of course, that's in equivalent conditions and by now it was really starting to rain and I was getting pretty cold. Starting from the bottom when I was in a rain jacket alone, I gradually ended up in glove liners, rain gloves, and rain pants, and I would have put on my arm warmers too but I wasn't able to get them on under my rain jacket (because of the cuffs) and wasn't willing to take the jacket off in order to put then on.

Partway up Ralston right after I put my pants on. Not quite above the treeline

The trail situation is a little confusing as there is a spur trail to the top but also a trail that bypasses the peak, and it appears that when Leor Pantilat did this he actually went cross-country. I opted for the spur trail, which is still pretty passable, with only a bit of climbing over rocks at the very end.

Even with all this stuff on, and working hard, I was starting to get cold as I got near the top and it got windier. A lot windier, though not as windy as Pyramid. I don't have any pictures from the summit however, or rather, I have this:

Me on the summit of Ralston Peak. You can get a sense of the wind in this clip.

This isn't really white out conditions in that you can see around you just fine at least to see the trail in front of you, etc; it's just that I'm at the top of a mountain and so everything you would otherwise be able to see is miles away and visibility is a lot less than that.

The run down is pretty easy: it's steep but good footing and as soon as you got off the peak there was more wind cover and I started to warm up again. By the time I was close to the bottom I was closing in on 19 miles and 7500 ft and runner brain took over and I started to think "maybe I should do just a bit more", so I decided to turn around at the wilderness boundary and go up "some of the way".

Ralston II [3.59 mi, +1207ft/-1348ft] #

My original plan was just to go up about .5 miles to make it a round 20 miles, but as I started to get closer to the turnaround I was like "maybe 21", then "maybe 22", and finally "maybe 9000 ft total". All this seemed fine and then my GPS started to act up and was getting stuck at a given elevation before jumping 50-100 feet. 9000 feet did come eventually at about 1.8 miles, and so I turned around and headed down, somewhat regretfully, as I was feeling quite good, but two factors pushed me to play it safe: (1) I had to race a hundred in two weeks and I really didn't want to dig myself too deep a hole (2) that it was still going to be cold and rainy at the top and I didn't want to take a chance on getting hypothermic.

I made it down to the car with no issues. As before, this isn't super fast terrain and I didn't want to fall, so I just took it easy and focused on my footing. It was still raining pretty hard, so then I got the fun of having to get out of my wet clothes while trying to stay modestly dry. As usual, by the time I had my clothes on I was super cold and had to run the heater on full for the next hour or so of the drive back, but otherwise I felt fine.

Nutrition #

I did this all on Maurten, which is what I plan to mostly use for Teanaway, as my stomach can be a bit finicky and I've found Maurten works pretty well. This was a lot intensity effort which is easier on your stomach, but I never really felt any stomach distress.

The table below shows what I brought and what I used.

	Brought	Consumed	Calories
Maurten 160 drink	10	6	960
Maurten Solid	3	1.5	338
Maurten Gel 100	3	2	200
Maurten Gel CAF 100	4	2	200
Maurten 320 drink	2	0	0
Spring Speednut gel	1	0	0
Total	-	-

As usual, I overpacked quite a bit, carrying more calories out than I consumed. Some of this is attributable to not being out on the trail as long as I expected, but it's also less calories/hr than I did at Tenaya last year. In part this is because I got distracted in the first 90 minutes and didn't eat or drink much of anything and then also kind of lost focus on my nutrition at the top of Pyramid. Generally, I did OK but not great once I got to Ralston. With that said, I also clearly brought too much stuff; it's good to have some for emergencies, but you don't need to have enough of everything for emergencies. In retrospect I should have probably dropped the Spring gel and one of the Maurten 320s, which would have given me a reasonable buffer even if I had been out longer and eaten according to plan.

This is the first time I had tried using Maurten Gel CAF (100 mg caffeine) on something extended like this and I think that went well. It's easier than having to juggle caffeine pills and you can just take one every 2-3 hrs. I brought salt tablets (you can see them in some of the pictures above) but you don't need them in these cool temperatures.

Retrospective #

Map and profile via Runalyze

Obviously this didn't go as intended, which I attribute about 20% to not being prepared and 80% to weather. I should have taken more time to really recon the course and realize that the approach to Pyramid was iffy I would have been more ready for it and felt better when I hit the top. On the other hand, if the weather hadn't been as bad, I would have been a lot more comfortable at the top and more willing to try to find my way down the back half of Pyramid. As it is, I think I made the right decision not to go it alone, especially in light of how rainy it got later. I have good gear and experience in the mountains so I think I would have been fine, but being out that far alone^[1] in bad weather is no fun. Moreover, while I did want to do an adventure run, this was primarily a training exercise and a strategy checkout, and from that perspective, it didn't matter that much which sections of the trail I ran.

Other than course recon, I was prepared pretty well. I had the right gear—though if I had kept going around the loop I might have been pretty sad about not having my rain pants and rain gloves—and everything worked well. I did get to try out some options and I've now concluded that the "pull the jacket over the pack" thing isn't going to work so I'll be going back to a normal sized zip-up jacket. Based on this experience I'm not planning to race in the Ultra 3s: the traction on the Sense Ride 5s is better and I like having the more modern bouncy foam instead of the more solid Ultra 3 foam; Salomon seems to have really dialed in the ride now on the newer foam so it feels stable and yet bouncy.

Fitness wise, this actually went quite well. This is an absurd amount of vert over 22 miles, over 25% more than Teanaway and UTMB. Obviously it's not as long as either, but feeling like I'm not even really that tired at 22 miles and 10 hrs is about what I would want. Usually after something this long I would be like "when will I be done" but this time I had to really restrain myself from going all the way to the summit on the second lap.

Overall: 22.7 mi, 9308 ft, 9:48:52

And I do mean alone. I only saw three people on the trail the whole day, at the top of Pyramid. ↩︎

Private Access Tokens, also not great

2023-08-29T00:00:00Z

In my post on Chrome's Web Environment Integrity (WEI) proposal I briefly mentioned Apple's Private Access Tokens (PAT) mechanism, which, as Tim Perry observes, is already deployed. The stated use case for Private Access Tokens is to reduce the need for CAPTCHAs (the little puzzles you get asked to solve to prove that you are a human).

This is a good objective because (1) CAPTCHAs suck (I can never decide whether the post holding up the stoplight is part of the stoplight!) and (2) they increasingly don't work because captcha solving bots have gotten very good and humans aren't getting any smarter.

Source: Searles, Nakatsuka, Ozturk, Paverd, Tsudik and Enkoji "An Empirical Study and Evaluation of Modern CAPTCHAs"

This is of particular relevance for Apple which is also leaning in hard to privacy technologies like iCloud Private Relay, which conceals your IP address. The problem here is that a lot of anti-abuse mechanisms rely heavily on IP address reputation. it's hard for those technologies to build up a reputation—either positive or negative—for your IP address. This is especially true if you are also browsing with settings that reduce the effectiveness of cookies, for instance if you are using Tor Browser or any regular browser in Private Browsing Mode/Incognito mode because it also prevents the site from building up reputation via the cookie. (See Matthew Prince's post on this for more background.)

One response by sites is just to show CAPTCHAs whenever they see a "new" user who doesn't have a cookie or with an IP address that doesn't have a reputation—or has a bad reputation— or is used by an anonymity service. This is obviously annoying to users and not really what sites want either, because they want people to visit their site, not bounce off the CAPTCHA. What you really want is some way to attach a positive reputation to someone without tracking them.

Privacy Pass #

When you look at the problem this way, the broad shape of a solution presents itself, at least if you're a cryptographer: you need anonymous tokens. The basic idea here is that you solve a CAPTCHA and in return get an anonymous token which lets you prove that you solved it so you can skip the CAPTCHA next time. This is what is specified in the IETF's Privacy Pass protocol. In Privacy Pass, tokens are issued by working with a pair of entities called the "Attester" and the "Issuer", and are consumed by the "Origin" (the Web server) as shown below:^[1]

[Source: Privacy Pass Draft]

In this scenario, the Attester is responsible for ensuring you solved the CAPTCHA—or enforcing whatever other properties one might be interested in, as we'll see shortly—and then conveys some kind of attestation to the the issuer that it has done so.^[2] The issuer then issues an anonymous token (see here for an overview of how this works) to the client. The client can then use the token to prove to the Origin (the actual site) that it is approved. It can also be used for other forms of anonymous authentication, for instance iCloud Private Relay uses a similar technique to allow users to anonymously prove that they are customers.

Obviously, I'm oversimplifying here and a huge amount of work has gone into trying to make Privacy Pass have the right security and privacy properties. There are also still some pieces which need work,^[3] but for the purpose of this post we can ignore the details and assume that it functions as advertised.

Private Access Tokens #

The important thing to realize here is that Privacy Pass is a generic technology which just transports the fact that you satisfied the attester. The important operational question, however, is what you had to do to satisfy the attester. The original design of Privacy Pass was built around the idea that what you did was solve a CAPTCHA, but Privacy Pass is agnostic on this point, and in principle the attester can demand anything. This brings us to Private Access Tokens, Apple's implementation of Privacy Pass using Apple as the attester, as shown below:

[Source: Apple]

Based on the description in the video, Apple is checking for the following properties:

This is a valid piece of [Apple] hardware
The user's iCloud account is in good standing (i.e., you have to be signed in with an Apple ID).
[Optional] performs rate limiting to limit the use in bot farms

If these checks pass then you will be able to get a token from the issuer.

iOS Browser Engines #

One thing that a lot of people don't know is that Chrome and Firefox on iOS are quite different from Chrome and Safari on desktop. The reason for this is that Apple requires everyone to use their WebKit browser engine (the thing that actually renders the Web page) on iOS; in fact you have to use the copy of WebKit built into iOS. Chrome and Firefox each have their own engines (Blink and Gecko respectively), but they aren't allowed to use these on iOS. As a result, both Chrome and Firefox on iOS behave have a lot more like Safari—at least from the perspective of how they interact with the Web—than they do like their desktop counterparts. This is not true for Android, where these browsers use the same engine as on desktop.

As I understand the situation, this will just work if you are on Safari but doesn't work on other browsers such as Chrome and Firefox, at least on desktop. This is partly because Apple doesn't seem to provide generic APIs that allow you to to use Private Access Tokens but instead only makes them available via their own networking APIs (WebKit and URLSession). This means every browser on iOS because Apple requires you to use their browser engine on iOS. However, on desktop Firefox and Chrome use their own networking stacks, so this doesn't work for them, really,^[4] though I suppose Apple could provide APIs that those browsers could use. Of course, those browsers could also negotiate their own deal with attesters.

Policy: Browsers, Issuers, Attesters, and Origins #

This is a complicated system with four separate players and that makes it hard to sort out the various policies in play:

The Origin server (i.e, the Web site) gets to decide which Issuers they accept.
The Issuer gets to decide what Attesters it trusts and which policies it expects them to enforce.
The Attester gets to decide what policies they actually enforce.
The Browser gets to determine which Attesters and Issuers they are actually willing to work with.

The result is that what policies you are actually subject to is determined by the interaction of the preferences of all of these parties, with the Browser and the Origin being the most important, because the Origins know what they are demanding and the Browser knows which Issuers and Attesters they will work with. The Origins can always find new Issuers/Attesters, and the Browsers can always blocklist them.

In the actual existing Apple system, the Attester and Browser Apple and Apple's policy is that you need to have an Apple device and an iCloud account. The current issuers they have announced are Cloudflare and Fastly. Moreover, Cloudflare and Fastly can also act as the origin servers (web sites) in this case, which means that if you use them to serve your Web site they can automatically consume PAT. Because of the way the crypto is designed, it's fine to have the Issuer and the Origin be the same, as they cannot link the client's behavior; in fact the Issuer, Attester, and Origin can all be the same.

The General Equilibrium #

From a technical perspective, this is all pretty reasonable stuff, but the thing to understand is that this is a generic system which is compatible with any policy the Attesters and Issuers want to enforce. As we saw with WEI, the question is then what policies they will choose to enforce. The policy enforced by the combination of Apple's attesters and the issuers they have chosen is that you paid Apple for a device and have an iCloud account. This is very different from "the person solved a CAPTCHA" because that policy works just as well for people who don't have Apple devices.

This is actually a pretty reasonable proxy for "is a person and not a bot", but the bigger picture consequences aren't great, as I don't really want to live in a world where everyone who hasn't bought an Apple device has to solve CAPTCHAs all the time. Of course, most people don't use Apple devices and many of those still use Chrome or Firefox, so that limits how aggressive sites can be about requiring repeated CAPTCHA solving for people who don't have those devices. But what happens if similar functionality gets added to Android^[5] and Windows and now suddenly the vast majority of devices have some kind of PAT-like functionality? In that case, sites will be able to be much more aggressive about requiring CAPTCHAs or just refuse to serve other users at all, as they will only be annoying a fairly small fraction of their users.

Of course, the situation will become even worse as AI gets better at solving CAPTCHAs. The basic problem here is that we don't really have a good, cheap, signal for "is a human" that doesn't require somehow buying into some bigco ecosystem, whether it's buying a device from a given manufacturer, having an account with some big service, or both. But the consequence of that is risking making using the Internet a lot harder for people who don't want to do one of those things.

Stepping back, I worry about the equilibrium steady state: the more that people are able to authenticate these technologies the more attractive it is for sites to basically require them, to increase the level of scrutiny (as in WEI), and provide a massively inferior experience to those who can't. Ironically, this is actually a direct consequence of Privacy Pass being well-designed so that it's seamless and provides a good level of privacy, because that makes it seem less objectionable to require, as opposed to (say) making everyone log in with a Google account.^[6] At the end of the day, though, the risk is further entrenching the existing big players.

This split architecture is intended to be flexible but is a bit confusing pedagogically. ↩︎
As I understand the situation, despite this somewhat confusing diagram, the browser talks to the issuer through the attester. ↩︎
In particular there are a concerns about metadata smuggling by using different keys to sign different people's tokens, and there are efforts to address that. ↩︎
This is a feature of a lot of Apple's networking technologies, which they like to bake into the operating system. This is very convenient for small shops but less so for big implementors like browsers who would prefer to control networking themselves. ↩︎
Chrome does have a similar technology called Private State Tokens but as far as I can tell it's not tied into a Google-operated attestation system the way that PAT is. ↩︎
I owe this observation to Kate Hudson. ↩︎

The endpoint of Web Environment Integrity is a closed Web

2023-08-18T00:00:00Z

Chrome's Web Environment Integrity (WEI) proposal for remote Web browsing attestation is being justly criticized from a broad variety of perspectives (Mozilla Standards Position, Brave, EFF). I certainly agree that WEI is bad news, and I'll get to that part eventually, but first I'd like to situate it in the broader context, both of the Web and the Internet, starting with some history.

The Bell System #

The first communications network available to regular people was the telephone. Of course, the telegraph already existed, but regular people didn't have telegraphs: you went down to the telegraph office to send messages. By contrast, you could have a telephone in your home and use it to call other people who had phones in their homes. Miraculous!

Bring your own phone #

I didn't know until I started writing this post that it was sort-of possible to buy your own phone and install it but you had to first transfer the phone to AT&T and then rent it back from them.

From the early 1900s until 1983, telephone service in the United states was essentially a monopoly (the Bell System) operated by AT&T. The telephone network included not only the wires and switches that the phone company operates today but also the wire in your house and the phone in your hand, all the way up to your ear. Customers rented phones from a subsidiary of AT&T called Western Electric, and they generally looked something like this:

[Source: Wikipedia]

If you wanted to connect something else not made by Western Electric to the phone network, you were mostly out of luck. This doesn't just mean no cooler looking phones, but also no cordless phones, answering machines, or modems; basically anything other than a Western Electric brick. Unsurprisingly, there was not a huge amount of innovation in this market, though Western Electric would sell you a somewhat cooler looking "Princess Phone":

[Source: Wikipedia]

It's important to understand that there wasn't any real technical obstacle to connecting your own phone to the AT&T network. Regular telephones (what people used to call POTS for "plain old telephone service") are actually quite simple devices to build, mostly consisting of analog signals over two copper wires; you just weren't allowed to, by which I don't just mean that AT&T would be mad at you but that it was actually prohibited by the FCC:

No equipment, apparatus, circuit or device not furnished by the telephone company shall be attached to or connected with the facilities furnished by the telephone company, whether physically, by induction or otherwise except as provided in 2.6.2 through 2.6.12 following. In case any such unauthorized attachment or connection is made, the telephone company shall have the right to remove or disconnect the same; or to suspend the service during the continuance of said attachment or connection; or to terminate the service.

That changed in 1968 with the Carterfone decision in which the FCC struck this provision and allowed consumers to connect their own equipment^[1] to the network as long as it did not cause harm to the network itself. This opened the door for customers to attach their own equipment to the phone network and more importantly for innovation that didn't come out of New Jersey.

Naturally, the first things people wanted to install were local improvements to their experience that worked with standard voice phones on the other end (cordless phones, answering machines, etc.), but the Carterfone decision also implicitly allowed the use of the phone network for data transmission—effectively encoded in sound,^[2] because that's all the phone network could carry—which meant fax machines and eventually modems (originally for primitive computer networking like BBSes and eventually for the Internet). Of course, you were still tied to the phone network, which—at least until 1984—was entirely owned by AT&T, but as long as you were calling someone with a compatible system and could cram your data into an 8 kHz channel, you could do anything you wanted without getting permission from the phone company.^[3] If you were really fancy, you could even get the phone company to sell you a leased line that would carry data, but that's not something regular people did.

In which the phone company was sort of right #

Ironically, while the phone company was wrong about consumer devices like Carterfone presenting a threat to the telephone network, they were sort of right about the threat of letting anybody interconnect. The basic problem is that the telephone network was designed under the assumption that all the constituent parts were operated by the same people and that those people were trustworthy. When this is not true the security of the system breaks down.

Probably the best publicized example of this is the widespread exploitation of the phone network by phreaks for free phone calls—especially long distance—and general exploration of the phone system. The details of this kind of exploitation are out of scope of this post, but the general problem was that the system wasn't designed to be robust to compromised endpoints, or even, famously, to someone who could inject the right tones into the network. Less famously, the network is still vulnerable to impersonation attacks in which the caller generates a fake number and the callee's network just trusts its representation. These attacks are finally being fixed by a set of technologies known as STIR/SHAKEN.

From the perspective of someone who works on Internet protocols, all of these issues just look like design flaws in the system: we just assume that other components of the system are malicious unless proven otherwise. But from the perspective of the original designers, these were closed systems consisting of trusted elements, and when one of the elements misbehaved then you had problems.

The Internet #

At around the same time all this was happening, the first primitive computer networks were being constructed (the first ARPANET nodes went online in 1969). From nearly the beginning, the ARPANET and then the Internet was conceived of as an open system, a "network of networks" in which each network was independent.^[4] All that was required to be part of the Internet was to (1) speak the right protocols and (2) find someone willing to connect with you and route your traffic.^[5] And the protocols were of course public, being published in the earliest Requests For Comments (RFCs). This applied not just to the basic protocols like IP itself, but also to the application protocols on top like e-mail (SMTP, RFC 822) and remote access (Telnet). From very early on there were multiple implementations of these systems that would talk to each other; as long as your implementation could send and receive the right messages, everything would work right.

Electronic Mail: The Original Killer App for the Internet #

As an example, let's look at the original Internet communications app: electronic mail.

When the Internet was first developed, personal computers were uncommon and instead what people mostly had was access to bigger computers (e.g., owned by their company or university) in what's called a "time sharing" system, which just meant that multiple people could use the same computer at once, with everyone having their own account and workspace.

The diagram above shows how mail works in this environment. Each computer has a single system process called a mail transfer agent (MTA), which is responsible for sending and receiving e-mail with other computers. The historical program was called Sendmail. In order to use the system, the user logs into the system (more on this below) and then uses a program called a mail user agent (MUA) (traditionally just a program called "mail").

Alice can send mail to Carol using the MUA, which contacts the MTA^[6] and asks it to send it to Carol. The MTA then contacts the MTA—using a protocol called SMTP—on Carol's computer and asks it to deliver it. Carol's MTA then stores it on the disk in Carol's mail file (this is just a single big file with all the messages in it). Carol can then use her MUA to read her messages.

Importantly, both the MTA and MUA are readily replaceable: the system administrator can replace the MTA (other popular MTAs include postfix and qmail) and users can choose their own MUAs (writing new MUAs was a very popular pass-time in the early days of the Internet). In fact, two users on the same computer can run different MUAs without interfering with each other. What makes this work is that both the protocol that the MTAs use to talk to each other and the interface between the MUA and MTA are stable and well-defined. The end result is that people are able to customize their own e-mail experience, including the look and feel, filtering, etc.

Remote Mail #

Back in the really old days, you would log directly into the server, either by using a terminal directly connected to it or over a modem. In either case, you're running the MUA directly on the server, which, recall you are sharing with others. That computer is just displaying stuff on your screen. This typically looked something like this (if you were lucky):

Mailbox is '/usr/mail/mymail' with 15 messages  [Elm 2.4PL22]
        ->   N     1   Apr 24   Larry Fenske   (49)    Hello there
             N     2   Apr 24   jad@hpcnoe     (84)    Chico?  Why go there?
             E     3   Apr 23   Carl Smith     (53)    Dinner tonight?
             NU    4   Apr 18   Don Knuth      (354)   Your version of TeX...
             N     5   Apr 18   games          (26)    Bug in cribbage game
              A    6   Apr 15   kevin          (27)    More software requests
                   7   Apr 13   John Jacobs    (194)   How can you hate RUSH?
              U    8   Apr 8    decvax!mouse   (68)    Re: your Usenet article
                   9   Apr 6    root           (7)
             O    10   Apr 5    root           (13)

       You can use any of the following commands by pressing the first character;
       d)elete or u)ndelete mail, m)ail a message, r)eply or f)orward mail, q)uit
       To read a message, press <return>.  j = move down, k = move up, ? = help
        Command : @

[Source: ELM user's guide]

This is from a relatively modern UNIX mailer called ELM.

This was fine back in the day, but as people started to get more powerful personal computers, it became increasingly unsatisfactory, for a number of reasons, but principally because it was slow and ugly. Slow because every time you wanted to do anything it required a round trip to the server. This included when you were composing an email and every character you typed had to go up to the server before it was echoed on your screen. Ugly because it was only this kind of text-based display and people (1) wanted a GUI and (2) wanted to be able to display rich content such as emails containing images.^[7]

POP versus IMAP #

The major conceptual difference between POP and IMAP is that POP is designed for a scenario where the user downloaded all of their new messages and then deleted them from the server. This works fine if you only have one mail client but if you have multiple devices (say a laptop and a phone) then once one device has downloaded the messages, they won't be available for the other device, which is obviously bad. By contrast, IMAP is designed to leave all of the messages on the server, which means that multiple devices can be used to access the same mail account. IMAP also has support for storing a lot of state (e.g., folders, read versus unread, etc.) on the server, thus providing a more seamless experience for the user.

The obvious fix is to run the MUA on the user's machine and instead have it retrieve the mail from the server and display it locally. In principle, the MUA could just log in as Alice, download all the messages, and process them locally, but that would be inconvenient and slow; what you want is some network protocol that allows you to retrieve messages one at a time. The first popular such protocol was called Post Office Protocol (POP) but POP has been to some extent superseded by Internet Message Access Protocol (IMAP). In either case, there is some program running on the mail server machine which runs POP or IMAP. The MUA on the user's machine contacts that server and uses the relevant protocol to retrieve the user's messages, as shown in the figure below:

Importantly, nothing had to change on Carol's side in order to allow Alice to read her mail remotely like this. atlanta.org just had to install an IMAP server^[8] and then Alice could download an appropriate MUA and use it to talk to the server. Moreover, it's possible for some people on atlanta.org to use remote mail and some to read their mail by logging in as before, as we see Bob doing in the picture above. Of course, the mail provider can choose to offer remote only service without offering the ability to run programs on their servers at all. This is an important operational and security advantage and is how most big mail providers (e.g., Gmail) operate now. However, all of this is invisible to the other side.

Moreover, once atlanta.org has installed an IMAP (or POP) server Alice is free to use any MUA she wants as long as it speaks IMAP (or POP). Because the protocols are published anyone can just write their own MUA that conforms to the protocols. Again, this is critically important because it allows for new mail software to innovate and for Alice to choose the interface and features she likes the best (or even to write her own mail software!). You want all the images suppressed or rendered in black and white? Simple matter of programming? No problem. You want to read your email in a different font? Sounds good. You want it read out loud to you in the voice of Malcolm Tucker? Simple matter of programming. The client is in total control of how things are rendered because it's an open, interoperable system.

In principle, of course, it was always possible to build a totally closed mail system—Microsoft Exchange was like this to some extent—once an interoperable ecosystem had been developed it had a tremendous advantage because it was easy to unilaterally roll out a new mail client or server without changing every other part of the system. Even mail systems which had proprietary elements were still forced to speak standard protocols to some extent, especially for the mail format and delivery parts of the system.

Other Applications #

Of course, e-mail isn't the only application that can run on the Internet. The way the Internet protocols was designed is inherently flexible. providing transport protocols that can carry any kind of traffic, so if you want to build a new application and it can run over IP (these days, TCP and UDP), you can carry it over the Internet, with no need to stuff it into an 8 kHz voice channel. Moreover, you don't need any cooperation from the network itself; you just need to upgrade the endpoints to support your new application, which is a huge deployment for advantage. The result of these design choices was an explosion of innovation, starting in around 1992 with the Web and that is still happening today.

The Web #

This brings us to the topic of the Web which is probably still the most important single application on the Internet. With all that, it's technically just another networked application.

When the Web was designed, it was built on similar principles to the Internet as a whole, with published—though initially without really clear specifications—interoperable protocols that anyone could implement. More or less independent implementations of Web clients and servers started to appear quite soon after Tim Berners-Lee's initial announcement of the Web and everyone just expected that they would talk to each other. In fact, that's what it meant to be part of the Web. Here's how we described this in Mozilla's Web Vision (Emphasis mine):

A key strength of the Web is that there are minimal barriers to entry for both users and publishers. This differs from many other systems such as the telephone or television networks which limit full participation to large entities, inevitably resulting in a system that serves their interests rather than the needs of everyone. (Note: in this document "publishers" refers to entities who publish directly to users, as opposed to those who publish through a mediated platform.)

One key property that enables this is interoperability based on common standards; any endpoint which conforms to these standards is automatically part of the Web, and the standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same Web.

As of the mid 2000s, the Web was the dominant paradigm for application delivery: if you wanted to build some kind of networked application—and often a non-networked one—you stood up a Web site. This paradigm was so powerful that it even started to absorb standalone applications like e-mail. A full account of this phenomenon would be too long to include in this post, but it seems clear that a huge part of it is due to how easy it is to deploy Web applications to users; there's nothing for them to download or install, they just go to your Web site and the application runs right in the browser. Better yet, when you release a new version you don't need to update the user, they just get the new version whenever they go to your site again.

As with other interoperable applications, the design of the Web allows the client to control how content is rendered and how the user interacts with it. Some important examples of this kind of user control include:

Accessibility features such as screen readers
Automatic password and credit-card form-fill
Ad blocking
Translating Web pages into a different language
"Reader" modes
Downloading pieces of the page (e.g., images) or the whole page
Developer tools which allow the user to inspect the Web page contents

The Web differs from e-mail in one very important respect, which is that the Web allows the server to run programs on the user's computer and those applications can talk back to the server. The vast majority of Web pages have some dynamic content in the form of JavaScript. By contrast, e-mail content is largely static. This makes the Web a much more powerful deployment platform but also limits the ability of the the client to strictly control every aspect of the user's experience.

A good example of this phenomenon is Web-based mail systems like Gmail. The diagram below shows the high level architecture of this kind of system.

Conceptually, this is exactly the same architecture we had before, with a MUA talking to a server, except that instead of being a standalone app, the MUA is a JavaScript program running in the browser. However, there's one big difference: because the Webmail service controls both the Webmail server and the Javascript based MUA they don't have to use a standardized protocol like IMAP; they can just build a proprietary protocol. And because deploying new JS code on the Web is so close to frictionless, they can change it whenever they want. So even though it's all running on a standardized substrate of the HTTP and HTML/JS/CSS, systems like this are actually fairly closed because all the important stuff is happening in the downloaded JS code rather than in the standardized pieces.^[9]

Even so, the browser itself still maintains a fair amount of control over how the application behaves. Aside from the examples above, such as Firefox Picture-in-Picture or add-ons like such YouTube Enhancer which modify the behavior of popular sites such as YouTube even though they are to a great degree JS applications.

Mobile Apps and App Stores #

In the early 2000s it looked like the Web model had totally won and native apps were toast but that changed in 2008 with the opening of the iOS app store.^[10] The app store standardized the process of downloading, installing, and updating mobile applications—at least on iOS—resulting in a system with almost as frictionless as the Web and with a number of important technical advantages. The result was a rapid takeoff of the use of mobile apps to the point where they are the dominant mode of mobile usage.

[Source Wikipedia]

Because of the app store, mobile apps have many of the deployment advantages of the Web but are far less open. Just like a Web app, the vendor controls both the client and the server, but unlike on the Web, there is no browser intermediating the app's interaction with the user, and so there's no opportunity to modify the behavior of the app, e.g., for ad blocking or translation. Of course, the operating system could in principle decide to do this kind of stuff—and the mobile OSes do do some technical enforcement of their policies—but the platform just isn't engineered for this kind of user agent the way the Web is.^[11] As a practical matter, then, if you want to use some network-based service that hasn't gone out of their way to open their interfaces you're mostly going to be using their app without any real opportunity to control your own experience except in ways designed into the app. This is why, for instance, you have to have five different apps on your Roku, one for each streaming service (including separate ones for Disney and Hulu, even though they are owned by the same company!), rather than a single app which will work with any streaming service.

Closed versus Open #

There are a number of reasons why application vendors might prefer closed versus open systems:

Flexibility.: If you control both ends of the system, then you can evolve it much more quickly because you don't need to wait for anyone else to change. This is the argument made by Jonathan Rosenberg and also in this post by Moxie Marlinspike on why Signal isn't federated.
Barriers to entry.: In an open system a potential competitor can enter the market by standing up a new endpoint (e.g., a new client) without having to displace the entire ecosystem. As a concrete example, when Google launched Chrome they didn't have to displace every Web server in the world because Chrome automatically worked with them.
Control.: If you control the clients then you know that they behave the way you want them to. To some extent this is just a matter of system stability and not having to deal with potential problems from broken clients, but it's also a way to enforce your preferences when they might differ from those of the users.

The important point for the purposes of this post is "control". There are a number of situations in which the user's preferences and those of the site aren't in alignment, such as:

Ad blocking.: Sites and apps make money by showing ads, but users don't like to see ads, which is why they often run ad blockers. Obviously, the providers would prefer that users actually saw the ads.
Access to content (digital rights management).: Web pages can of course play audio and video, but historically the providers of that content have been very concerned about unauthorized downloading and reproduction. In an open system, however, nothing stops the client from storing the raw media.

Encrypted Media Extensions #

This last issue was responsible for the one major case in which the Web has deviated from the principle of openness, namely HTML Encrypted Media Extensions (EME). In the early days of the Web, media was largely played through Adobe Flash, which had Digital Rights Management (DRM) mechanisms designed to prevent exporting content. These mechanisms took in encrypted media and decrypted and displayed it, but were designed to resist user tampering to exfiltrate the media.

Starting in the early 2010s browsers gradually started to deprecate Flash, both in response to concerns about security and as more and more of its capabilities started to be added to the Web platform. One of those capabilities was the ability to play video, but the large video streaming services (especially Netflix) were concerned about people using the browser to save media and so were unwilling to use the HTML5 <video> tag as-is. Instead they proposed a new technology called Encrypted Media Extensions (EME), in which a closed DRM Content Decryption Module (CDM) was embedded in the browser to decrypt and display the media.

EME was highly controversial but eventually every major browser included it. I can't speak for other browsers, but I was at Mozilla when they decided to implement EME in Firefox and the conclusion was that given that other browsers were going to implement EME it was better to have people able to watch videos—which we knew they wanted to do—in Firefox than that they switch to another browser. The implementation of EME in Firefox was designed to limit the capabilities of the CDM, so that it had limited access to the user's computer and couldn't be used to track users.

Back to Web Environment Integrity #

This all brings us back to WEI, which is a proposal for attestation for the Web. For more background on attestation see here, but briefly the idea with attestation is that you have some "trusted" piece of hardware on the user's device (in this case "trusted" means "not controlled by the user but rather by the manufacturer", so it's trusted by the web site, not by the user) which is able to vouch for the software that runs on the user's computer. Most modern mobile devices and many if not most laptop devices now have such a piece of hardware.

The motivation for the proposal is described as follows:

Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.

Users want to know they are interacting with real people on social websites but bad actors often want to promote posts with fake engagement (for example, to promote products, or make a news story seem more important). Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment.

Users playing a game on a website want to know whether other players are using software that enforces the game's rules.

Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users. The bank's internet interface could protect those users if it could establish that the requests it's getting actually come from the bank's or other trustworthy software.

The high level idea is that there would be a JS API that the site could call which would cause the browser to ask the OS—and presumably transitively the aforementioned trusted hardware—to attest to some properties of the browser^[12] The spec is silent on what is being attested to and the Explainer is pretty fuzzy:

The proposal calls for at least the following information in the signed attestation:

The attester's identity, for example, "Google Play".

A verdict saying whether the attester considers the device trustworthy.

These two pieces of information basically serve to guarantee that the code is running on some device made by a manufacturer that the Web site trusts. This already means that we don't have a completely open system: because it's not possible to build a new piece of hardware yourself that will be able to provide the correct attestation: you instead need to have some closed third party module. You probably also need a trusted and locked-down operating system, because otherwise the OS can tamper with the behavior of the browser, so good luck if you want to run Linux!

Moreover, this attestation isn't very useful in and of itself: the first three use cases are ones in which the browser connecting to the server is controlled by the attacker, and so all they demonstrate is that the attacker was able to afford a single device made by such a manufacturer. However, they could be running any software they want on it. They don't even need to be using the device to run their browser. They can use a single trusted device to generate an arbitrary number of attestations up to the performance of the device—and modern hardware is very very fast—so the effectiveness of this limited attestation seems fairly low. In order to effectively address these use cases, you need the attester to provide more information.

The explainer goes on propose two other types of information:

The platform identity of the application that requested the attestation, like com.chrome.beta, org.mozilla.firefox, or com.apple.mobilesafari.

Some indicator enabling rate limiting against a physical device

The basic intuition behind rate limiting is that it prevents the kind of large-scale attacks I mentioned above in which the attacker has a lot of browsers connected to a single trusted device. This might be useful in terms of preventing ad fraud attempts where the attacker pretends to have a large number of devices representing a large number of legitimate users, though it could be tricky to set the rate limits correctly: some people do a lot of browsing and you don't want them to suddenly run up against a rate limit. So at best this multiplies the attacker's costs by making them buy more trusted devices.

Rate limits, do not, however, address the game anti-cheating use case because the problem isn't that the user is doing an unreasonable number of attestations but rather that they are running cheating software on a legitimate device. The only way to address this is to have the attestation cover the software itself, in this case the Web browser. This is where the proposal to indicate the identity of the application (e.g., com.chrome.beta) comes in. Presumably the relier would have a list of browser software that it trusts behaves correctly and would reject any requests from other pieces of software, or at least flag them for special handling (and inconvenience). This means that if you want to run something other than a major browser or even build your own, you're totally out of luck.

Moreover, in order for this to work, the software—and probably the operating system—needs to be unmodified and not to have affordances that allow the user to adjust its behavior in an undesired fashion. This is an incredibly strong condition because a browser is a very complex and configurable piece of software. For instance Firefox has hundreds of configuration parameters that users can set, some supported and some unsupported; it's very likely that some of them would let users modify behavior in ways the site wouldn't want. Beyond configuration, most browsers allow you to install extensions/add-ons which substantially change the behavior of the browser, so any add-ons need to be part of the trusted list. The WEI proposal says that this should be fine because:

Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation.

I don't see how this can be the case, though. I suppose it's possible that as a technical matter, you could get an attestation (e.g., "This is a version of Firefox with unknown modifications" or "This is a version of Firefox with the 'I am cheating at this game'" add-on), but the site clearly can't treat this attestation as meaningful without defeating the security guarantees of the system.

Of course, you might decide to abandon the anti-cheating use case—and any others that don't involve pretending to be a lot of different devices—but that would be much more limited system than this, more similar to Apple's Private Access Tokens, which are supposed to just attest to the device itself (this is also bad, but not as bad as WEI). However, if you want to ensure that individual users' machines behave in some specific way, you need the attestation to cover the software on the user's machine, not just to attest that they had some limited amount of control of a trusted device.

I know a lot of people care about cheating in games, but it's a bit of a niche use case. However, the elephant in the room here is advertising: a lot of people use ad blockers and many sites try to detect this case and refuse service to them. One potential application of WEI is forcing users to prove that they're not running an ad blocker. The explainer doesn't list this as a use case, but also doesn't really disclaim it and once remote attestation exists there is going to be a huge financial incentive to deploy it for this purpose. Obviously, preventing ad blocking in the browser would require attesting to the whole browser stack, not just that the browser is running on a trusted device, as if the user controls their browser they can just disable ad display, since ad blocking is typically a modification, or sometimes a feature, of the browser.

The bigger picture #

The basic property of an open system like the Internet and the Web is that you can only be assured of the properties of the elements you directly control. The elements that belong to other people work for them and not you. In a closed system, by contrast, the software on the end user device works for the provider, not for them, whether it is officially owned by the user (as in mobile apps) or it actually belongs to the provider (as with the old Bell System monopoly).

WEI and similar attestation technologies represent an attempt to impose an alien model, that of a closed system, onto the open system of the Web. As with any closed system, the net impact will be that users don't control their own experience of the Web but rather have only the experiences that sites are willing to let them have. That seems bad.

Ironically, the Carterfone didn't actually plug into the wall socket. Instead, it used an acoustic coupler that tied into the phone handset. However, the decision was broad enough to allow for electrical interconnection. ↩︎
Yes, I'm simplifying here, because the phone network just carries analog signals in a given frequency and amplitude range. ↩︎
Obviously, the phone company could tell that this wasn't voice traffic, they just had to pass it through anyway. ↩︎
The jargon in routing is "autonomous system". ↩︎
I'm simplifying a bit because for some time there were actually restrictions on commercial use, but these were gone by the early 1990s. ↩︎
Actually, back in the day, it just executed sendmail directly. ↩︎
And yes, I do I know about X, but remote X is not the answer. ↩︎
In principle Alice could have installed one just for herself, but that's not how it's typically done. ↩︎
See this 2011 presentation by VoIP pioneer Jonathan Rosenberg (JDR) and this Internet Draft by Tschofenig, Aboba, Peterson, and McPherson for an argument that this phenomenon meant the end of application-layer standards. ↩︎
Ironically, Steve Jobs initially didn't want an app store and instead had in mind something more like what you'd now call a Progressive Web App but demand for real apps was overwhelming and here we are. ↩︎
In addition, because of the way that the Web evolved, many JS applications operate by changing elements on the Web page (e.g., "now render this new piece of HTML") which means that the browser can generally figure out what the page is doing; a property called "semantic transparency". In principle, those applications could just write pixels onto an HTML canvas but that's more difficult and not the standard approach. ↩︎
This might also involve calling out to some server, but everything here is rooted in the trusted hardware on the device. ↩︎

How NATs Work, Part IV: TURN Relaying

2023-07-17T00:00:00Z

As discussed earlier there are some configurations where it is not possible to establish a direct connection between two endpoints. For instance, if Alice has a NAT with address-dependent mapping and Bob has a NAT with address-dependent filtering, then the packets from Alice will never match any filter on Bob's NAT and will just be dropped. Similarly, the packets from Bob will not match any mapping on Alice's NAT and will be dropped. The only way to send data between these two endpoints is with the assistance of a server, as shown in the blue path in the diagram below.

There are any number of possible protocols one might use to send data through a server. For instance, you could connect through a VPN or even send each individual packet as an HTTP request to the server. However, the IETF has standardized a specific protocol which is designed to be used with ICE, Traversal Using Relays Around NAT (TURN).

TURN #

Conceptually, TURN is an application layer relay protocol: the TURN client (i.e., the user's device) sends packets to the TURN server addressed to the other side and the server forwards them, as shown below:

In this example, Alice is communicating with Bob through her TURN server (generally each client will have an associated TURN server, as described below):

When she wants to send a packet to Bob, she sends it to the server's address (198.51.100.1) but with a label telling the server to forward it to Bob. The server removes the label and sends the packet to Bob.
When Bob wants to send a packet to Alice, he sends it to the TURN server, which forwards it to Alice. The packet will arrive at Alice's machine with the TURN server's IP address, so the TURN server has to add a label telling Alice that it originally came from Bob. Otherwise Alice wouldn't be able to distinguish between packets from Bob and Charlie when they come through the TURN server.

It's important to see that there is an asymmetry here: Alice has a relationship with the TURN server and is explicitly communicating with it. From Bob's perspective, however, it's just as if the packets came from the TURN server, and unless he has some external knowledge, he has no way of seeing that he's actually communicating with Alice through the TURN server, rather than the server itself (because from an IP layer perspective that's actually what's happening).

The opacity of the TURN server from Bob's perspective has an important consequence, which is that the server has to keep state in order to distinguish multiple endpoints that Alice is talking to. Consider what happens if the server has two clients, Alice and Charlie. The packets from Alice and Charlie are labeled with where to send them, but the packets from Bob are not, so do they go to Alice or Charlie? The only way for the TURN server to know is to keep some state. For instance, it can assign outgoing packets from Alice one port and packets from Charlie a different port, so that when Bob replies it can look up incoming port and know where to send it. If this sounds familiar, it's because this is exactly what a NAT does and for the same reason: it has more than one client sharing the same external IP address, in this case the address of the TURN server. All application relays have to do something like this, because otherwise they wouldn't be able to talk to unmodified peers, which is a hard requirement for incremental deployment.

Allocations and Permissions #

In order for Alice to send and receive data from Bob, TURN requires that she explicitly create state on the relay (unlike a NAT where the state is implicitly created by sending packets). This is done using two transactions, allocating an address and creating a permission, as shown below:

The first thing Alice does is to allocate an address (really a port, because the server probably only has one address, or maybe one each for IPv4 and IPv6) on the TURN server that she will be using to send and receive packets. The TURN server replies with the address and port that has been allocated. Alice can immediately send this entry to peers so they know what it is.

Alice can use this address to send to multiple peers, as described above, but it's not yet associated with any individual peer. In order to actually send packets, Alice needs to next create a permission entry for a specific peer. Until Alice has created a permission for a given peer, packets to from that address will just be dropped by the TURN server. With ICE Alice learns peer addresses because those peers send their candidates and then Alice would create a permission for each candidate address before sending packets to it.

Note that this is effectively an address-independent mapping with an endpoint independent filtering policy: Alice uses the same address and port to talk to everyone but the TURN server blocks incoming packets from anyone that Alice hasn't explicitly identified. This analogy isn't perfect because the permission is explicitly created and Alice can't even send packets to those endpoints either before sending a permission request, but it's close enough as a mental model. However, this isn't port-dependent filtering; the TURN server will accept packets from any port once a permission has been created for a given address. This produces better results with endpoints which have address-dependent mappings.

To put this all together, here is what TURN looks like as part of an ICE transaction, showing a complete connectivity check.

The initial part of this example is the same as the previous one: Alice contacts the TURN server, gets an allocation, and send it to the signaling server. That signaling server forwards it to Bob, who sends back his own candidate. At the same time, Bob also tries to do a connectivity check to Alice's candidate, just as he would any other candidate. However, this fails because Alice hasn't created a permission for Bob. Once Alice creates that permission, then she sends her own check to Bob, which succeeds, as does Bob's in the other direction. Note that there is a race condition here: it's possible for Alice's permission request to complete before Bob's connectivity check arrives, in which case that packet would get delivered, even though Alice hadn't send a connectivity check to Bob. Either way, ICE will eventually succeed.

You should notice that Bob doesn't need to be aware of the fact that Alice's candidate is actually from a TURN server; it just sends to it as if it were any other candidate. In ICE, candidates are actually labeled by type, but this isn't necessary for ICE to work.

I can't believe it's STUN #

Believe it or not, TURN is actually an extension for STUN: TURN data is encapsulated in STUN packets. For instance, you do allocation by sending a STUN message of type "Allocate" and you send packets by sending a message of type "Send". This is actually not quite as strange a design decision as it might initially appear, for several reasons:

You really really want to run TURN over UDP rather than TCP (see below).
Because UDP is unreliable you need some transaction mechanism to allow the client to make requests from the server, retransmitting those requests when lost. STUN already has this.
ICE implementations already have STUN stacks. As one nice side effect, though the TURN server will actually tell you your server reflexive address, so you don't need to do a separate request to a STUN server to learn it.

If one were designing this protocol today, you would probably base it instead on some protocol that added reliability to UDP (e.g., QUIC), but TURN was originally designed in 2010, so things were different back then.

Channels #

One real drawback of using STUN is bloat. Sending a single packet with a Send (outgoing) or Data (incoming) indication adds 36 bytes of overhead. Here's an example packet diagram, based partly on the one from the STUN RFC:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|0 0|     STUN Message Type     |         Message Length        |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
|                         Magic Cookie                          | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header
|                                                               | |
|                     Transaction ID (96 bits)                  | |
|                                                               | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type=XOR-PEER-ADDRESS |            Length=8           | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer
|0 0 0 0 0 0 0 0|    Family     |         X-Port                | | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                X-Address (32 bits for IPv4)                   |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type=Data             |            Length             |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data
|                       Variable data ....                      |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Most of this is overhead. First, every packet has a fixed 20 byte header, which mostly acts to identify it as STUN and tell you what message type it is (e.g., Send indication). Then you have the peer address and the data encoded in an inefficient tag-length-value format. None of this overhead really mattered for STUN's original application, where you just sent a few messages, but when you have to absorb it for every packet you're sending (at a rate of maybe 20-50 per second) it adds up quickly. The remote address and port is also sort of redundant because there are only a few addresses in use, so you could compress them by just sending a short address ID.

TURN includes a mechanism called "channels" which does exactly this. The client can send a request to the TURN server to allocate a two-byte channel ID to a given remote address and port (the same information as would be needed for a permission). Once the channel is allocated, packets can then be sent or received by just prefixing them with the channel ID and length,^[1] like so:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Channel Number        |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                       Application Data                        /
/                                                               /
|                                                               |
|                               +-------------------------------+
|                               |
+-------------------------------+

If you're a real protocol engineering nerd, you might ask how you distinguish a message containing channel data from a STUN message, as they are carried on the same host/port quartet. The answer is that STUN message types always have the first two bits as zero and channel IDs are required to be between 0x4000 and 0x4fff.

You might also wonder at this point why STUN conveniently has a range of message types which can't be allocated: the reason is that when STUN was designed people wanted to make sure that it could be easily demultiplexed (i.e., distinguished) from RTP and RTCP, which always have the first bit of the first byte set to 1.^[2] There has actually been quite a bit of hackery around easily demultiplexing various types of messages in real-time multimedia. Some of this was due to intentional design and some was just fortuitous design choices that people—by which I partly mean me—took advantage of. For instance, DTLS has record types as the first byte, but these are always low numbers and so easy to distinguish from RTP and RTCP. At this point there are actually five separate types of protocol message which can be carried over the same host/port quartet: (1) STUN (2) ZRTP (3) DTLS (4) TURN channels and (5) RTP/RTCP. Someone had to write a whole RFC to systematize how to do it.

No incoming connections? #

One side effect of the requirement to create a permission for a specific peer address is that it is not possible to use TURN to run a generic server behind a NAT or firewall. A typical server, such as for Web or mail has a fixed address and port which anyone can use to connect to it, but because TURN requires that the TURN client create a specific permission for each peer, arbitrary clients on the Internet cannot just connect.

This limitation is not an oversight but rather a deliberate design choice. Recall that it's common for firewalls to enforce an "outgoing connections only" security policy. Without this limitation it would be straightforward for clients to bypass this policy by just connecting to a TURN server on the Internet. The TURN designers were concerned that if TURN enabled this kind of policy bypass enterprise administrators would respond by blocking TURN entirely (recall from the previous section that TURN is trivial to identify.) The idea was that if TURN could only be used for outgoing connections, then administrators would be more likely to allow it through the firewall.

What about when STUN or UDP is blocked? #

Despite the "no-incoming" compromise embodied in the permissions design, it is still sometimes the case that STUN over UDP is blocked. The reasons for this vary, but include:

Firewalls that block all UDP traffic.
Firewalls that do so-called "deep packet inspection" and block any packets from protocols they don't recognize

Data from the initial deployments of QUIC suggest that somewhere around 5% of clients can't use an arbitrary new UDP-based protocol, though it's unclear how often this is due to UDP blocking or just to blocking unrecognized protocols. In order to get around this kind of blocking, it is also possible to run TURN over TCP as well as over TLS. If you have a firewall which just blocks UDP, then running TURN over TCP will often work. If you have a firewall which blocks unknown protocols then running TURN over TLS^[3] might work.^[4] The idea here is that there are other protocols that firewall administrators want to support (e.g., HTTP or HTTPS) that run over TCP and/or TLS and if they haven't configured their firewall rules too strictly, then TURN may also work.

It's important to understand that it's still quite easy to recognize TURN in these situations:

By default STUN uses a different port number than HTTP
If TLS isn't used you can just look at the TCP packets to see if something is STUN.
When TLS is used, the TLS ALPN extension indicates that TURN is in use.

Again, this is by design and reflects an attempt to take a compromise approach to blocking of TURN in which network operators can block TURN if they want to but in cases where they just configured their rules in a way that incidentally blocks TURN (in some cases before TURN was even designed), then TURN should work. The history of new protocol development is full of this sort of uneasy compromise: on the one hand we want to deploy new stuff and there are lots of network elements which are very hostile to that, often unintentionally. On the other hand, a situation in which the applications are just at constant war with the administrators is a recipe for breakage.

With that said, in the past few years attitudes towards network-based blocking have changed a fair bit, including technologies like DNS over HTTPS, QUIC, and TLS Encrypted Client Hello which are intended to make it harder to selectively block traffic unless you have control of one of the endpoints. If TURN were being designed today, I'm not sure the same choices would be made.

Why not TCP #

While it's possible to run TURN over TCP, you really don't want to if you can avoid it because performance will generally be bad. Covering this topic fully is out of scope for this post (though stay tuned for my long-delayed posts about transport protocol performance), but here is a brief sketch to help you build some intuition.

Head-of-line Blocking #

The first problem derives from the fact that TCP delivers packets to applications in order. However, this means that if a packet is dropped, then every packet received after that is held by the receiving TCP implementation until that packet is received, as shown in the following diagram:

In this case, the sender sends packet 1 which arrives at the receiver and is delivered to the app immediately. However, Packet 2 is dropped and so packets 3 and 4 are just buffered until Packet 2 is retransmitted, at which point all three are delivered. For more on this topic see my introductory post about transport protocols. This phenomenon is called head-of-line blocking (HOLB).

HOLB is fine for applications where everything happens in order but less good for audio and video (A/V). A/V consists of a series of independent pieces of media, short sound snippets of 20-50ms in the case of audio, and frames in the case of video. In order to have a good experience, these need to be played out at regular intervals or the media will look and/or sound choppy. Of course, the network doesn't deliver them at exactly the right time, so the receiving implementation delays them a little bit in what's called a jitter buffer before playing them out.

The key word here is "a little bit": media latency of more than 200 ms or so is intensely undesirable. However, it's not uncommon for TCP implementations to wait far longer than this for retransmission, during which all the media would be delayed. In these cases, it's better to just drop the missing frame and play the next frames at the appropriate times. Fancier implementations use packet loss concealment techniques to fill in the missing data, but even if you just play the next frames it's better than waiting. With UDP, packets are delivered to the application at the time of receipt, but the TCP logic is all in the operating system, so there's no way to get any data until all earlier data is received.

Rate Control #

The second problem is that TCP is designed to adapt its sending rate to match network conditions, in part by buffering data until it thinks it's safe to send. The problem here is that unless the media sender is also adapting its rate to network conditions, then it's sending data to TCP faster than it can be transmitted, which creates buffering and/or packet loss. Rate control for real-time protocols is a complicated topic, but the TL;DR is that you really only want to have one rate control regime, which should be at the media layer, and then the network protocols just transmit whatever they are asked to right away. Sending over TCP prevents that. Obviously sending over TCP is better than not being able to make a call at all, but if at all possible you want to send your media over UDP.

TURN Server Deployment Scenarios #

In ICE, both sides will generally have TURN servers, in which case each side will offer relayed candidates. Depending on the properties of each network, ICE might end up using neither relayed candidates, have one of the sides talk directly to the other side's relayed candidate, or have the traffic go through both relays. In general, because TURN's mapping and filtering model are fairly permissive, it will generally not be necessary to go through both TURN servers unless both sides have really unfortunate networking configurations.

Note that with WebRTC generally both sides will use the same TURN server. When TURN was first designed, real-time communications over IP mostly meant people with softphones or hardware IP phones. Those devices were associated with some provider, whether it was an enterprise system or a consumer VoIP provider. In either case, the provider would supply the TURN server (recall from part III that running TURN servers isn't cheap). If someone from provider A is calling someone from provider B—though SIP federation was never as common as people were hoping—then you might have a situation where each user had a different TURN server. By contrast, most WebRTC deployments are in settings where there is only one provider and so everyone uses the same TURN server.

Note that most conferencing systems are deployed in a star configuration in which each participant sends their media to a central media conferencing unit (MCU) or switched forwarding unit (SFU).^[5] Because these servers are both on the open Internet, it's much less likely you will need to use a TURN server. Because you don't need to get through a NAT or firewall on the server side, it should work even if you have a really uncooperative NAT. The main time you would need a TURN server in this environment is if you were behind a firewall which blocked all media (e.g., because it blocked UDP). Note that if the MCU/SFU and TURN server are operated by the same entity, there is an opportunity to integrate them closely, though I don't know if people actually do this.

Final Thoughts #

Out of the whole IETF NAT traversal protocol suite, TURN probably feels the oldest, even though it was designed at about the same time. It's a bespoke application relaying protocol built on top of a protocol which was originally designed for a totally different job, namely discovering your reflexive IP address. In the modern era, we'd probably build something fairly different and more like MASQUE, which is a generic UDP proxying protocol built on top of HTTP/3 and QUIC. On the other hand, STUN and TURN are a lot simpler than QUIC, they get the job done, and they're already built in browsers and softphones, so I imagine we'll be using them for some time.

You could actually omit the length field as well if you restricted yourself to UDP and only sent one packet per UDP datagram. ↩︎
The reason for the magic cookie is to ensure that it could easily be demultiplexed from any protocol, whether it had this distinguishing first byte or not. The cookie is just a fixed 4 byte value that is at the same position in every STUN packet. It's unlikely that it will be in the same position in other protocols and so helps identify STUN. ↩︎
Note that it's not necessary to run TURN over TLS in order to protect the media, which needs to be encrypted anyway. ↩︎
It's also possible to run turn over DTLS, but this isn't much more likely to work than regular TURN. ↩︎
These are different, but the difference doesn't matter for these purposes. ↩︎

Broken Arrow Triple Crown Race Report

2023-07-10T00:00:00Z

This year has turned out to be light on racing in part because I was kind of wiped out after last year and in part because I had signed up for the Broken Arrow Skyrace in Tahoe in June. Broken Arrow isn't actually one race but a race festival that takes place over three days. All of the races are relatively short compared to what I usually do (the longest is nominally 46 km/29 mi, but they offer what's called the "Triple Crown" which consists of the following three races over three days, listed as:

Race	Distance	Vert
Vertical Kilometer (VK)	4.8 km/3 mi	914 m/3000 ft
46K	42.5 km/26.5 mi	2774 m/9100 ft
23K	21.75 km/13.5 mi	1443 m/4700 ft

The 46K is supposed to be two loops of the 23K, but you'll notice that the distance and vert don't quite line up and of course the distances don't actually match the names. This is in part because of rerouting due to the huge amount of snow that dropped in the Sierra this summer (also preventing me from doing the warmup adventure run in the Sierras that I had planned). In the event, the 23K got totally rerouted on race day anyway.

Anyway, naturally I decided to do the Triple Crown, both because it sounded fun and because I wasn't really willing to drive to Tahoe for a 46K. Also, they gave out a massive amount of swag. My overall plan was to push the VK moderately hard, race the 46K, and then see what I could do on the 23K.

Flagstaff #

The race start is at Palisades Tahoe (6253 ft) and goes up from there, so you're at significant altitude the whole time. I've gone directly from sea level to altitude and raced before, with mixed results (OK at Tahoe 100K, awful at Tushars 70K) but often people actually feel worse on the second or third day at altitude (see Corinne Malcolm's excellent article on altitude adaptation at iRunFar.com), and so I didn't want to try to race three days in a row without any adaptation, so I decided to spend two weeks in Flagstaff (altitude ~7000 ft) beforehand.

On balance, I think this was a good choice. As usual, I felt lousy the first few days at altitude but by the time I had been there a couple of weeks I was feeling mostly adapted. I flew back on Wednesday and on Tuesday, my friend Kate, my son (3200m PR: 10:52), and I went to the Grand Canyon to do the Bright Angel–Tonto–South Kaibab loop. This was a bit of a hot dry slog on the way up, but I generally felt OK, so I figured I was ready for Broken Arrow, which of course is actually cold and snowy rather than hot and dry.

VK (results, finish video) #

Kate and I drove out to Tahoe Thursday morning where we were staying with Lisa and Stephen who were both doing the 46K. Kate was doing the VK and the 23K, so I was the only one doing the Triple Crown. We got there around 6 PM, but fortunately the race didn't start until 10 AM, so we were able to go out and grab some pasta and still get enough sleep.

The profile for the VK is shown above. Looks gentle, but that's just a trick of perspective because it's stretched out; it's actually about 1000 feet per mile.

I'd never done a VK before, so I wasn't sure what to expect. The pros do it in about 30 minutes (winning time was 39) so I was expecting an hour or so, which means you're going at a fairly high intensity right from the start. On the other hand I knew I had to save for the 46K the next day, so it's a bit of a balancing act.

The initial climb was quite steep but on trail with good footing so I was moving pretty fast. I decided to start about midway through the field, which in retrospect was a bit of a mistake, as I immediately had to make my way through people moving slower than me. I was of course hiking at this point, but so was basically everyone else. Quickly, though, the climb turned into a snow slope, where things were quite a bit more challenging. At this point in the day, the snow was already quite slippery and even with poles(LEKI Fx.One Superlight^[1]), I slipped a fair bit. The trick seems to be to step where others have stepped, where the snow is packed and you have a little more traction. It's very hard to pass people on this section because there are only a few lines up the slope and if you get outside the packed down areas you're slipping a lot. There were a couple places where super helpful volunteers had carved out snow steps and those were a lot easier.

Once you get over the first climb, there's a downhill of about half a mile, starting with snow and then moving onto rocky trail. This was the first part of the race where you had to run downhill on snow. I was a bit unstable and managed to trip and fall on the transition to dirt, jamming my 2nd and 3rd fingers on the left hand (but fortunately not breaking either of them like I did to my right 3rd finger in the Grand Canyon at the beginning of May).

From there on it's another climb mostly on trail until you drop off on a sort of fire road. I passed quite a few people on this stretch as the footing was good and so it's just a matter of your ability to power up the climb, something I'm good at. After the fire road, there's maybe 400 m of a fairly rocky (as in almost scrambling) traverse, at which point you get the the "stairway to heaven", which is this sketchy looking metal ladder that you really do not want to fall off of:

There was actually a bit of a backup at the ladder and I had to wait for some others to get over it. In retrospect I should have stowed my poles at this point because they get in the way of climbing and the finish is right after the ladder.

The ladder is obviously single file, and so at this point I figured the finish order was fixed, but there are actually some snow steps and a short flattish stretch of snow before the finish and someone passed me right after the steps before I realized I should sprint, which I tried to do, which resulted in slipping and falling again, but I eventually made it to the line.

Unlike other races, however, the VK just finishes at the top of the hill so there's not much of a finish line, just the arch and a few race staff standing around to give you your medal. Even the finish line drop bags are about a half mile away. I opted to wait around for Kate to finish, but I hadn't brought a jacket and it was super windy, so when she got to the top I was getting cold. We then headed down to the drop bags at the "Siberia" aid station to get our drop bags with jackets. From there it's about a mile to the top of the gondola for the ride down.^[2]

That afternoon, Tailwind Nutrition was having a "meet and great" with ultra great Courtney Dauwalter to introduce their new Courtney-inspired flavor Dauwaltermelon. Back when I did Tahoe 100K in 2018, while my family was waiting for me at the finish line, Courtney rolled through en route to her second place overall at Tahoe 200, and spent a few minutes talking to my then 11 year old son, which he found really inspiring, so I got a chance to thank her for that. Courtney went on to absolutely shatter the women's Western States Endurance Run record the next weekend.

Kate and Courtney talking about ultra

I had brought a pair of the Kahtoola NANOspikes for the snow but didn't use them, in part because it never got super bad and in part because I didn't want to take the time to put them on. However, the trip down to the gondola was mostly snow so I did try them out and they seemed to help a bit, though they're Kahtoola's lightest and shortest spikes and the snow was about 6 inches deep, so they're not magic.

Overall: 1:07:02, 142/395 finishers, 7/39 M50-59

46K (results) #

The 46K was on day two and my plan was to push the pace a bit and then try to hang on for day 3.

As I said earlier, this is two loops, arranged as follows:

A runnable rolling but gradually uphill section, partly on the Western States Trail.
A series of steep climbs on dirt and snow up to the Snow King aid station.
A semi-rocky traverse followed by a climb up to KT-22 where it rejoins the VK course.
From the top of the VK course there's a gradual descent on snow followed by a series of very steep descents.
A climb of about a quarter mile and 400 feet, again on snow.
A fast descent of about 1.5 miles on snow, followed by a mile on dirt road back more or less to the start.

And then you do it all over again. Simple. I didn't really know what to expect on this timewise, but I was thinking something like 7 hours.

After the VK, I was kind of worried about traction, so on Friday afternoon I dropped by Alpenglow Sports and bought a pair of the slightly more aggressive Kahtoola EXOspikes.^[3] They're not that heavy and I figured I could carry them in my pack. Lisa was also doing the 46K and broke the rule about not buying new stuff for a race to get a pair of purple Hoka Torrents.

Lap 1 #

After having to fight my way through people on the VK, I decided to start out more towards the front. This turns out to have been a good plan because you first run across a parking lot and then there is a short section of fire road for a total of maybe 400 m and then you're into single track, so there was kind of a rush for position. I hadn't really warmed up—I usually don't before ultras as you can just warm up in the first few miles—and so I probably wasn't as fast as I should have been and things got bunched up in the single track. It didn't help that there was a low of snow runoff so you were literally running through a stream a lot of the way (no chance of keeping your feet dry!). Eventually I settled into my position, as usual being passed some on the downhills and passing people on the climbs.

After about 3.5 miles, you hit the first climb, which is a steep dirt section, so it was time to pull out the poles. The "trail" part of this climb was pretty rough anyway, so it didn't make much difference if you took a slightly different line and I pulled to the left of the line of climbers and passed a number of people en route to the top. After this, it's another climb mostly on snow up to the Snow King aid station, where I made my first mistake of the day.

As I mentioned, I had broken my finger in the Grand Canyon about 6 weeks before and while I was finally out of a splint, I was still supposed to "buddy tape" the broken finger to the next finger. Anyway, I'd started out wearing gloves but it was starting to get hot and so I wanted to take them off, but then I had to retape the finger and the coban I had been using didn't want to re-stick once it got wet, so I had to get one of the medics to do it with some medical tape. All of this must have taken like 3-5 minutes and I know a lot of people passed me. As they say, when you're stopped you're going infinity minutes per mile.

From Snow King it's a short downhill followed by a bunch of up and down (but mostly up), including a knife edge traverse over a bunch of scree. I took this really tentatively and a bunch of people passed me, but after the Canyon I was mostly focused on making sure I didn't fall and hurt anything, so I was willing to live with it. The climb up to KT-22 is steep and rocky, so I started passing people again.

From here it's the VK course and once I hit the snow traverse I decided it was time for the spikes. They're easy to get on, so it probably only took a minute or two. I do think this helped some as I felt like I was passing some people who were slipping, but it wasn't dramatic the way (I imagine) it would be with crampons. Everything was smooth to the top of the VK and I felt a bit more comfortable on the ladder this time, though I wasn't looking forward to having to do it two more times (the next loop and then the 23K).

The descent from the top of Washeshu Peak starts out straightforward: it's rock and then snow, but then right when I was expecting a nice flattish descent down to the gondola (and then what? not sure) there was a marshal telling me to take a left turn onto, well, I guess you'd call it a slope, but it was straight down and I remember saying something to the effect of "holy shit". The whole slope is something like -15%, and was about mid-calf deep in snow, so I spent the first part of it just desperately trying not to fall until I saw some of the chutes where people had been glissading. I took the hint and sat down and sledded down them (cold!). This got me to the bottom pretty fast and then I turned and saw something else I wasn't expecting: a 400 foot climb. I trudged up the climb, which actually wasn't so bad and then it's a short downhill to the aid station. I stopped and took off my spikes, as they didn't seem to help much on the snowy downhill, and I never used them again. This whole section was also deepish snow for another 1.5 miles or so and then it was onto fire road back to the start.

Split: 3:11:09

Lap 2 #

I wasn't feeling real good about having to do all this again, but I blew through the half-way aid station (split 1: 3:11:24) and headed back out for loop 2. There was definitely more power hiking on the Western States Trail this time, but I still managed to run a fair bit of it. By the time I got to Snow King again I was quite tired and was glad to see that they had Coke (caffeine + sugar = performance) which I used to fill up one of my bottles.

Once I got past Snow King, this loop seemed a lot easier, probably due to some combo of the caffeine and knowing that I was over halfway done. Also, as mentioned above, I'm a lot better on the steep climbs than I am on descents, so once we got past the opening rollers, I knew I just needed to push through those sections fairly hard and then survive the downhill. I did spend some time talking to one of the other runners who was doing her first trail race but had been a collegiate 10K runner and had done a lot of mountaineering and she gave me some tips on how to descend in the snow (heels first!), which seemed to help some.

Things were pretty uneventful from here: I made it to the top and felt a lot more comfortable on the glissading portions and on final the snowy downhill. I didn't need the poles on the downhill but at this point my coordination was starting to go and I couldn't quite get them into the quiver (the typical thing is that one end doesn't quite make it in), so I ended up just folding them and carrying them. By the time I hit the fire road I was mostly alone so I settled in at a comfortable but not all out pace, remembering that I had to race again on Sunday. Coming through the final stretch to the finish I just focused on trying to finish strong.

Split: 3:31:26

I had a bit of time before Lisa and Stephen finished, so I decided to go back to the VRBO and shower and change, but still made it back in time.

All of us after the finish of the 46k

Analysis #

Segment	Overall	Division	Time
Snow King	136	103	4
Siberia	175	130	8
High Camp	177	135	8
Village	184	139	9
Snow King	169	128	8
High Camp	155	117	7
Finish	167	127	9

The chart below tells about the pattern you would expect from the narrative about (though I hadn't actually looked at the chart before I wrote it.) Specifically:

I was doing well on the climbs but badly on the downhills.
I lost a lot of time screwing around at Snow King. Several of people who were ahead of me passed between Snow King and Siberia on the first loop.

With that said, things were tight: 4th was 6:25:27 (17 minutes behind me) and I was less than 10 minutes behind 7th. It's possible I went out a bit hard and faded, but my sense is I was actually stable and that I ran a solid, but conservative race. Probably the biggest loss is between High Camp and the Finish on the last downhill, where if I'd just been better on snow I might not have lost as much time or place.

Overall: 6:42:35, 167/542, 9/46 M50-59

23K (results, finish video) #

My initial plan for the 23K had just been to kind of hold on, but given that I actually felt OK after the 46K, I knew the course, and the 46K start time was fairly late (8:00) so I could get some rest my coach Emily Torrence and I decided it was worth going for it.

Kate and I lined up at the start only to hear the RD announce that because of very high winds at the summit they were rerouting the course from the original 23K loop to be twice the 11K loop and that they would be starting the race at 9:30 to give them time to set things up. In retrospect we should have just gone back to the VRBO to chill out, but instead we ended up just sitting in chairs out front of one of the local restaurants for the next 90 minutes.

Eventually, though, we lined up at the start. The 11K course followed some of the same sections of the WS trail but skipped a bunch of the rollers in favor of the climb to KT22 and then a fast descent on snow back down to the road, then to the finish and repeat. Given the 46K experience, I figured it was a good idea to start near the front and push the pace at the beginning so I didn't have to fight past too many people.

The first loop went quickly (only 10K afer all). After the first mile you're basically climbing the entire time up to KT22 and then it's straight back down. The downhill snow section was steep and slippery with fewer snow chutes on this course so I mostly had to just try to stay on my feet and get down as fast as possible. After the 46K I felt a lot more comfortable with the glissading this time and managed to navigate it reasonably well. Then it was onto the road and the second loop.

Split: 1:18:01

With only 11 km (officially, it was really more like 10 km, though ~2400 ft), to go in the weekend, I felt like it was safe to push the pace more on the last lap, and I ran more of the trail portions. Of course, I still had to hike the main climb, but really let myself take some chances on the final snow descent (full send!). The final mile long stretch of road is moderately steep and while I pushed the pace as fast as I felt comfortable consistent with being reasonably sure I wouldn't fall, two men and one woman passed me on this stretch. I was able to keep one of them—a man in a red shirt that I'd been back and forth with all day—in sight but the other two dropped me.

At the bottom of the road the course turns flattish and then there are a few turns and then into the shoot. As soon as I hit this section I knew that it was more about power than about the ability to run downhill and I could see that I was gaining on the man in red in front of me, and I eventually caught him right as we entered the chute. I was actually expecting a sprint finish as I went on by, but he didn't respond so I ended up comfortably beating him by five seconds.

Overall: 2:38:58, 169/671, 5/56 M50-59

Analysis #

Overall I think this was my best race of the three both in terms of results and how I felt: my place was highest both overall and in my division and I almost felt stronger going into lap 2 than lap 1, and this is confirmed by the even splits. I'm still doing a lot better on the climbs than the descents, but that gap seems to have narrowed from the 46K. You always look a bit worse in the finish videos than you feel inside, but I'm moving well and passing people at the very end is generally good.

Segment	Overall	Division	Time
Snow King	164	3	34:15
Village	183	8	1:18:01
Snow King	160	4	1:53:38
Finish	169	5	2:28:58

Overall #

Broken Arrow also keeps Triple Crown standings, computed by the sum of all your times. This tends to really overweight the 46K, where I was just OK, but even so my result isn't bad. I was 37/100 overall and 4th/17 in M50-59, with a time of 10:28:38. Third was 10:22:15, which seems plausibly in reach if things had turned out differently.

Generally, this seems like a successful weekend. I had never had three days of racing before and was worried that I would be super tired but I seem to have gotten stronger as the weekend went on and wasn't even that tired after the 23K. I attribute this to a combination of a strong training block right before—including the two weeks in Flagstaff—and really paying attention to nutrition and recovery post-race on Friday and Saturday. The snow was definitely a real obstacle and I clearly would have been quite a bit faster if I'd had more practice on snow, but I felt like I got the hang of it after a few days and while people were still passing me it wasn't anywhere near as bad. I think I also handled nutrition well both during the race and after: I never had much GI distress (thanks, Maurten!) and only felt bonky a bit midway through the 46K, which Coke fixed up. That may also have just been the "I've got to do this loop another time???" feeling.

I'm not sure if I'd do Broken Arrow again: it's a generally well-run event and I had a good time, but I think on balance I more gravitate towards the longer events, especially those where you're covering a lot of ground rather than repeating the same part of the course. On the other hand, it was a great experience and I definitely recommend giving it a shot if you've been mostly racing standard trail ultras.

P.S. I'd been having some trouble with the engagement on my poles and the LEKI guys at the expo just swapped out the gloves. Great customer service. ↩︎
The Web site actually says you might need to run down, but that didn't happen. ↩︎
I also tried on a pair of the NNormal Kjerags. I've been looking for a new pair of race shoes and I'd heard good things about the Kjerags, but they're way too wide in the forefoot for me. This was actually kind of surprising, because NNormal is a partnership between Kilian Jornet and Camper and the shoes that Salomon made for Kilian were all narrow. ↩︎

How NATs Work, Part III: ICE

2023-07-02T00:00:00Z

The Internet is a mess, and one of the biggest parts of that mess is Network Address Translation (NAT), a technique which allows multiple devices to share the same network address. This is part III in a series on how NATs work and how to work with them. In part I I covered NATs and how they work, and part II covered the basic concepts of NAT traversal. If you haven't read those posts, you'll want to go back and do so before starting this one, which describes the main standardized technique for NAT traversal, Interactive Connectivity Establishment (ICE).

As you may recall from part II, there are many circumstances where two endpoints (clients) want to communicate directly rather than through a server. However, your typical Internet client is also behind a NAT or firewall, which means that you can't just publish your address and have people connect to you as they would with a Web server. Instead, you need some NAT traversal mechanism. When the IETF originally set out to address the problem of NAT traversal, the idea was that you would characterize the NAT (i.e., figure out what its behavior was) and use that information to publish an address that would work via a signaling server. Once each side has the other side's address, it can try to transmit to it, as in the diagram below:

Unfortunately, that there was too much diversity in NAT behavior to make this work reliably, so we needed something else. Enter ICE.

Multiple Addresses #

Recall that the client will generally have multiple addresses, as shown in the diagram below [Updated for clarity 2023-07-02]:

In this case, the client has two addresses:

The host address (10.0.0.3:1111): which is the one assigned to its own network interface and which it is directly aware of.
The server reflexive (srflx) address (192.0.2.1:5678): on the outside of the NAT. The client can typically only learn this by connecting to the STUN server and asking it what address it sees.

Now what happens if two clients with this kind of topology want to talk to each other. There are two main scenarios, as shown in the diagram below.

The clients can be on different networks (probably the normal case on the Internet)
The clients can be on the same network (as is common in Enterprise or gaming scenarios, for instance if you have multiple players in the same house and hence the same network)

Clients on different networks

Clients on the same network

The reason that this matters is that neither the host address nor the server reflexive address will work all the time. For obvious reasons, if Alice and Bob are on different networks and Alice sends Bob her host address, Bob won't be able to address it from his own network (in this case, they actually share the same address range, but those addresses are actually on different networks, so there might be another host with Alice's address on Bob's network). On the other hand if they are on the same network and Alice sends Bob her server reflexive address, this may not work if the NAT doesn't support hairpinning.

What you want is for the media to take different paths (shown in red) depending on the topology: if Alice and Bob are not [corrected, 2023-07-02] on the same network, the media should flow between the server reflexive addresses (on the outside of the NAT) and if they are on the same network it should flow between the host addresses (on the local network interfaces). The problem is determining which of these address pairs to use, because it's not practical to determine which scenario you are in.^[1] If neither address is guaranteed to work, the only option is for each side to send both addresses. In this case, Alice would send Bob two addresses (ICE calls these "candidates"):

1.0.0.3:1111 (host)
192.0.2.1:1234 (server reflexive)

Bob would send Alice:

1.0.0.2:1111 (host)
198.51.100.1:5678 (server reflexive)

Once Alice sees Bob's addresses, she tries to transmit to both of them, as shown below:

In this case, Alice and Bob are on different networks, so Alice's attempt to transmit to Bob's host candidate (10.0.0.2:1111) doesn't work, but her attempt to transmit to his server reflexive candidate (198.51.100.1:5678) does, though it goes through two layers of translation along the way. If we drew Bob's side of the exchange, it would look similar.

If you look at this diagram closely, you will notice something potentially surprising: Alice only sends two packets, even though their are four pairs of addresses (host/host, host/server reflexive, server reflexive/host, and server reflexive/server reflexive). Why doesn't Alice try to send from her server reflexive address? The answer is that there is no way for her to do so. Alice can only send packets from her host address: if they go through the NAT, it will translate them into the server reflexive (or maybe some other address) and if they don't go through the NAT they won't be translated, but Alice can't control this. In either case, Alice just needs to send one packet to each address from the other side.

Connectivity Checks #

Sending to both of Bob's addresses lets Alice get traffic through, but we obviously don't want to have to send two copies of every packet (or worse, if Bob has more addresses, as discussed below). What we need is a mechanism for Alice to determine which of the packets got through and then she can only send on that address pair. As you might expect if we read my post on reliable transports, we do this by having Bob acknowledge Alice's packet in what's called a connectivity check.

Instead of sending media to Bob, Alice sends a STUN check^[2] to Bob (much like she would if she were trying to learn her address from a STUN server) and waits for the response. If Bob doesn't answer, she can infer that that address pair won't work. If he does, then she knows that this is a valid address pair and can then use it to send media (Alice knows which checks worked and which ones didn't because the check and the acknowledgment contain an identifier, which I haven't shown in the diagram to keep things simple).

This process is shown below:

I'm obviously simplifying quite a bit here. In particular, because packets can get lost, Alice has to retransmit her STUN checks for a while; otherwise a single packet on a valid address pair might get lost. For instance, if packet 2 got lost, and Alice didn't retransmit, then Alice would be left with no valid pairs.^[3] Moreover, as discussed in the next section, there are reasons besides network failure why one of the packets might be dropped.

Bidirectional checks #

First, as discussed in part II, if Bob doesn't transmit at all but just responds to Alice's checks, then Alice's checks may never get through. If Bob's NAT has address/port-dependent filtering, then it will drop any incoming packets on a given NAT binding until Bob has sent an outgoing packet; this requires Bob to initiate his own checks, as shown below:

To walk though this a bit, Alice starts by sending a check (msg 1) but because Bob has address/port filtering NAT, it filters out the packet. When Bob initiates his own check (msg 2), it creates a binding on his own NAT on the way out and gets delivered to Alice (this works even if Alice also has address/port dependent filtering because her outgoing packet created a binding). Alice receives the packet and sends an ACK (msg 3) which is able to traverse Bob's NAT because of the aforementioned binding. At this point, Bob knows that the pair B:b -> X:x works and that it's safe to transmit on that address pair.

When Alice's client retransmits its check (msg 4) it is able to get through Bob's NAT (again because of the outgoing binding created by message 2). Bob receives it and sends an ACK, and at this point Alice knows that the pair A:a -> Y:y works and it's safe to transmit on it. Note that this would have worked perfectly well if Bob had transmitted first (just flip the diagram around), and of course each side is retransmitting anyway.

At this point you might ask why Alice needs to do a second round of connectivity checks after receiving; after all, she knows that Bob can successfully transmit on the Y:y -> X:x path and she can receive it. However, she does not know that messages on the return path (X:x -> Y:y) work. For instance, Bob might have a firewall that blocks all incoming UDP packets, in which case Alice's ACK would be blocked (which she wouldn't learn about) as well as her own connectivity checks. If she sends her own checks, then she will learn that that path doesn't work and can try something else. In practice, however, this scenario is reasonably uncommon and it's quite likely that when Alice received Bob's check that her check in the reverse direction will also work.

Relayed Candidates #

As mentioned in part II, there are situations in which it is not possible for Alice and Bob to directly send traffic to each other, for instance if both of them have NATs with address-dependent mapping. In that case, getting a successful connection requires using a relay, which is just a public server on the Internet that will forward traffic to and from a machine, like so:

In standard ICE, clients speak to the relay over a protocol called Traversal Using Relays Around NAT (TURN). Because the TURN server is on the public Internet and not behind a firewall or NAT, it will almost always be possible for the client to connect to it—assuming that it's possible for the client to connect to any other network element at all. Note, however, that the client may have to use TCP if the local network blocks UDP.

It's quite cheap to run a STUN server because it just has to respond to a small number of packets per client, and there are a number of free public STUN servers. However, a TURN server has to be able to relay all of the media between the clients, which can be quite a bit of bandwidth. For this reason TURN servers are usually not free but rather are provided by the calling service people are using. Because a modest fraction (single digit percentages) of people cannot connect without a TURN server, this means that there is a certain minimum cost to running a video calling service even if you prioritize peer-to-peer media.

Picking the best path #

At a high level, then, there are (at least) three potential paths data can take between Alice and Bob, as shown below:

It's also quite possible that there will be multiple viable paths. As noted above, a path through a relay will almost always work, but it's also quite common that it's possible to have a direct path between Alice and Bob.

These paths are not all created equal. Latency is a key performance property for real-time voice and video. If the delay between you speaking and the other side hearing you is too long it creates a really jarring experience. If you've ever been on such a call you may have noticed that you and the other person end up interrupting each other a lot because the pauses in the conversation that leave room for the other person to talk get delayed as well, with the result that both people try to talk at the same time. In general, shorter (fewer hops) network paths will have better latency, both because more hops will often mean more meters of cable/fiber to traverse and because the hops themselves take time.^[4] In particular, if you can send media directly rather than going through a relay, you really want to do that, both for performance and cost reasons.

Lots of Candidates #

This is really the simplest possible scenario. In practice the client might have many more addresses. For instance, the client might have:

Both a WiFi interface and a mobile phone interface, each of which will have their own address.
Both IPv6 and IPv4 addresses.
A VPN, which has its own address.
Multiple NATs between it and the Internet (e.g., if it is served by a carrier grade NAT), each of which will have its own server reflexive IP addresses.
On or more relayed connections through TURN relays.

What ICE does is (approximately) to try the combination (Cartesian product) of all of the candidates from Alice and all of the candidates from Bob until it identifies a set of candidates that work (the "valid set"). Of course, some candidate pairs will not be possible (e.g., mixed IPv4 and IPv6), but it's still possible to have quite a few compatible candidates and hence quite a few candidate pairs. As a concrete example, the machine I am writing this on has two interfaces (wired and wireless), each with local IPv4 and IPv6 addresses, but not IPv6 connectivity, so that gives me 4 host candidates, 2 server reflexive candidates (for v4 only), plus at least one relayed candidate. If I'm connecting to another similar machine, we're potentially looking at something like 15 IPv4 pairs (remember, you don't pair up the server reflexives locally) plus 4 IPv6 pairs. It's a lot!

Peer-Reflexive Candidates #

You may recall from part II that some NATs have address and port-dependent mappings, in which case the candidate gathering process will find a different external mapping (the server reflexive address) for a given internal address/port than is observed by the peer (the peer reflexive address). What this looks like to the peer is that it receives a check from an address that it doesn't have a candidate for. Fortunately, there is enough information in the STUN check to determine what is going on, and the endpoint responds by synthesizing a remote peer reflexive candidate, pairing it to its local candidate, and starting checks to it. The other side doesn't have to do anything special here, because—as with server reflexive candidates—it automatically sends requests from the peer reflexive address just by sending to the peer.

Prioritizing Checks #

A naive implementation of ICE would just send all the connectivity checks at the same time. This turns out not to work well because you can overload the Internet link or the NAT, causing them to drop packets, thus making ICE take longer to converge. Instead, you need to space out the checks over some time. However, you also want ICE to find a viable path as soon as possible because while ICE is running the user is just sitting there waiting—depending on the design maybe listening to ringtone.

In order to optimize the time to convergence, ICE uses a prioritization scheme designed to provide two main properties:

The most direct candidate pairs are checked first.: As discussed above, you want media to traverse the most direct path. ICE is designed so that it also checks the most direct paths first. I'm actually not so sure about this design decision—in particular, the host/host paths often will not work—but it's what ICE does.
Checks are roughly synchronized between both sides.: Remember that in many cases, in order for Alice's checks on a given candidate pair to succeed, Bob also needs to run a check in order to create a binding in his NAT. If Alice checks that candidate pair first and Bob checks that pair last, then (at best) Alice's check won't succeed till the very end of the ICE process. At worst, by the time Bob's check runs Alice's NAT binding will have timed out and both checks will fail. This isn't that likely in most networks; in practice the ICE process would just be slower than ideal.

Of course, synchronization is only loose. Let's look at the case where both sides run checks again:

Recall that in this scenario Alice runs her checks, which fail but open a binding in her NAT, allowing Bob's check to succeed. Eventually, Alice would retransmit her checks, but this might take some time because retransmits, like the checks themselves, need to be paced to avoid overflowing the network. Because it's very probable that Alice's check will work, ICE includes an optimization called triggered checks in which an endpoint immediately (well, mostly immediately) schedules a check in the reverse direction upon receiving a check. This allows Alice to quickly discover that the path that is likely to work actually does work in the common case where it is valid.

Multiple Media Paths/Frozen #

There's an additional complication. When ICE was first designed it was standard practice to use different address pairs for different streams of media. For instance, if you had an audio and video call, you would use different ports for them. Moreover you needed twice as many ports because the media protocol that is in use here (Real-time Transport Protocol (RTP)), has an associated control protocol that is used for measuring packet delivery and that also used its own ports. In other words, a simple two person A/V call could need as many as four separate address/port pairs, which means that you need four times as many candidate pairs (two each for audio and video), and hence four times as many checks. ICE's term for these flows is "components".

This may be hard to visualize, so imagine a simplistic case in which we only have host and server reflexive candidates and we only want to establish two components. If we go back to our example above, Alice would have the following candidates:

Type	Address	Usage
Host	1.0.0.3:1111	Audio
Server Reflexive	192.0.2.1:1234	Audio
Host	1.0.0.3:1112	Video
Server Reflexive	192.0.2.1:1235	Video

And Bob would have:

Type	Address	Usage
Host	1.0.0.2:1111	Audio
Server Reflexive	198.51.100.1:5678	Audio
Host	1.0.0.2:1112	Video
Server Reflexive	198.51.100.1:5679	Video

Looking at it from Alice's perspective, she has four candidate pairs to check (recall that Alice doesn't need to pair her srlfx candidates with Bob's candidates).

Local	Remote	Type	Usage
10.0.0.3:1111	10.0.0.2:1111	Host ↔ Host	Audio
10.0.0.3:1111	198.51.100.1:5678	Host ↔ Srflx	Audio
10.0.0.3:1112	10.0.0.2:1112	Host ↔ Host	Video
10.0.0.3:1112	198.51.100.1:5679	Host ↔ Srflx	Video

In order to optimize these checks, ICE takes advantage of the observation that NAT behavior is likely to be consistent, so if a set of candidates works for the audio component then a set of similar candidates (though of course with different addresses) is likely to work for the video component. In order to exploit this, ICE initially only checks one set of candidate pairs for each type and sets the others as frozen. If the first candidate pair succeeds, then ICE unfreezes the others. This avoids doing redundant checks in parallel. In this case, at the start of ICE, we would have a situation like this:

Local	Remote	Type	Usage	State
10.0.0.3:1111	10.0.0.2:1111	Host ↔ Host	Audio	Checking
10.0.0.3:1111	198.51.100.1:5678	Host ↔ Srflx	Audio	Checking
10.0.0.3:1112	10.0.0.2:1112	Host ↔ Host	Video	Frozen
10.0.0.3:1112	198.51.100.1:5679	Host ↔ Srflx	Video	Frozen

ICE would first check the pairs listed as "checking"^[5] Then if the audio host ↔ host candidate pair works, ICE would unfreeze the corresponding video candidate pair.

Local	Remote	Type	Usage	State
10.0.0.3:1111	10.0.0.2:1111	Host ↔ Host	Audio	Succeeded
10.0.0.3:1111	198.51.100.1:5678	Host ↔ Srflx	Audio	Checking
10.0.0.3:1112	10.0.0.2:1112	Host ↔ Host	Video	Checking
10.0.0.3:1112	198.51.100.1:5679	Host ↔ Srflx	Video	Frozen

The result of this is that once you determine that a given type of candidate pair works, you start checking the rest of the pairs of that type; as with triggered checks the idea here is to converge to a working set of candidate pairs as fast as possible.

As I said above, I'm simplifying a bunch and there's more to candidates being "similar" than just the types of the candidates. For instance, if I have both wired and WiFi network interfaces, each of those would have a candidate. If the wired candidate pairs succeed, I would just unfreeze those but not the wireless pairs. The way this is captured in ICE is by assigning each candidate a "foundation" that characterizes the candidate (based on IP address, type, etc.). The foundation of a candidate pair is the pair of local and remote foundations.

This is clearly not a great situation but, remember we're not building from scratch. VoIP systems are built out of technologies designed back in the 1990s when people had different ideas about how to design networking protocols (and in particular when NATs and firewalls were less ubiquitous). Eventually, the IETF worked out how to multiplex multiple flows on the same address/port quartet using a pair of technologies called RTCP-mux and BUNDLE). This actually represents years of engineering work to retrofit the protocol mechanisms without causing backwards compatibility issues, but fortunately it mostly works now, so if you're on a modern system you're back to only needing a lot of checks rather an absurd number.

Selecting Pairs #

OK, we're almost to the end now. Alice and Bob are running checks, some of which succeed and some of which fail. As noted above, it's quite common for more than one candidate pair to succeed for each path because the host ↔ srflx candidate pair will often work and one of the relayed candidate pairs will almost always work. This means you have multiple paths that might work, so now what?

You could just have each side independently pick its favorite candidate pair and send on it, but this turns out to be bad idea. Remember that many NATs time out their bindings after a short period (10-30 seconds) of inactivity and that it's outgoing packets that keep the binding alive. If Alice and Bob use different paths, then Alice may not be sending the packets that keep the binding open for Bob's incoming packets. If Alice and Bob use the same candidate pair, then the path will be symmetrical and the binding will stay alive. This means we need some mechanism for picking which pair the endpoints will use.

In modern ICE, this works by having one endpoint (the "controlling")^[6] side pick which pair to use. The controlling endpoint runs checks for each component until one succeeds that it wants to use (the actual logic here is unspecified, but typically you'd do something like wait until one of the direct pairs worked or they had all failed and one of the relayed pairs had succeeded) and then it sends another check on the same pair with the USE-CANDIDATE flag (this is called "nominating" the pair). When the (controlled) peer sees that flag it knows to use that candidate pair going forward. When the controlling side's check succeeds—which should always happen if the pair is already successful—then it knows it is safe to use the pair as well and from here forward both sides will just use that pair.

Of course, it might take some time for the controlling endpoint to run enough checks to feel comfortable picking one, and you want to have media start flowing right away. To accommodate this, ICE allows endpoints to start sending media as soon as they have a valid pair, even before one has been nominated.^[7] This shortens setup latency while allowing time for the controlling endpoint to nominate the optimal pair. Usually this will happen quickly enough that you don't need to worry about the bindings timing out. It does mean, however, that the path the media takes may change as the ICE checking process proceeds.

Trickle ICE #

Classic ICE is a sequential process:

Gather all your candidates and send them to the other side.
Receive the other side's candidates
Run checks

This all works fine if candidate gathering is fast, but what if it's not? For instance suppose you are behind a firewall which blocks UDP and you have to use TCP to connect to the relay server? If the firewall just drops the packets without sending you errors, you're waiting for the candidate gathering process to time out. This might take several seconds (potentially more, depending on your timers) to discover. In the meantime, people are just waiting, which isn't ideal.

To deal with this, the Google Hangouts team invented a technique called trickle ICE,^[8] in which each side sends candidates as soon as it has them, so that they "trickle" in over time. This creates some additional complexity because you have to incrementally pair new local or remote candidates, but has the potential to significantly decrease the time to connection establishment. This is especially useful in the context of WebRTC, when the Web site doesn't necessarily know in advance which of the various STUN or TURN servers it is offering will actually be reachable by the client.

Backwards Compatibility #

As described above, ICE has been through a number of iterations, and so it's possible that a modern endpoint will end up talking to an older endpoint. For example:

An endpoint that supports RFC 8445 ICE might need to talk to an endpoint that supports RFC 5245 ICE.
An endpoint that supports trickle ICE might talk to a non-trickle endpoint.
An endpoint that supports component multiplexing (BUNDLE) might talk to one that does not.

In the classic SIP softphone setting, there's no real way to know what the peer supports, so you need to send ICE information that is compatible with the other endpoint.^[9] For instance, if you support trickle but you don't know what the other side supports, then you need to gather all the candidates you will need anyway, but you can say in your message that you support trickle, and so the other side can use it (this is called "half trickle").

Similarly, if you support component multiplexing, but you don't know if the other side does, then you may need to gather candidates for all the components, even if the other side is going to throw most of them away. This can get quite expensive, however, and the default for WebRTC is what's called "balanced" mode, in which you gather candidates only for the first stream of each type (e.g., the first audio channel). If the other peer supports bundling components, then this works fine, and if it doesn't, then only the first stream connects. Of course, actually designing something that fell back gracefully in this situation instead of just freaking out because there were no candidates available for the later components took some doing.

The situation is a bit better if you know you are doing a call that is WebRTC on both ends—e.g., because both ends are browsers or one end is a modern conference server—for two reasons. First, the WebRTC specifications (specifically JSEP) require support for multiplexing (both BUNDLE and RTP/RTCP) and for trickle ICE, so you know you have a modern endpoint on the other side. Second, the server can use JS APIs to determine the capabilities of each endpoint, so it has a better chance of getting an interoperable configuration.

Security #

The threat model for ICE is confusing for a number of reasons:

A full network attacker will generally be able to manipulate packets (e.g., drop them, send them with a bogus IP, etc.) and so you have limited protection against such an attacker.
If you use media encryption between the endpoints—as was uncommon back in 2010 when ICE was first designed but is mandatory in WebRTC—then even an attacker who sees all the packets has limited abilities.
In the WebRTC case, the Web site actually invoking the APIs may be an attacker, though they probably do not control the network.

In general, then, we have three main objectives:

That an attacker who can't see your packets can't interfere with connection formation or reroute traffic to themselves.
That an attacker who can see packets can't just forge arbitrary content (more on this below).
That a non-network attacker driving the WebRTC API (or a SIP peer, though this is a weaker attacker) can't force you to connect to someone besides themselves by providing their address in a candidate.

Most of these attacks are prevented by two security mechanisms found in STUN:

Each STUN message is cryptographically protected (via an authentication tag that prevents tampering with the message) with a username and password exchanged along with the ICE parameters.
Each STUN check has a unique 96-bit transaction identifier which must be echoed in the response.

These two mechanisms work together.

Because the credentials are not known to network attackers, they are unable to forge requests or responses. This is not a complete defense because—as noted above—a full network attacker can take a valid packet and send it from a fake IP address, thus causing the receiver to think it came from somewhere else (as in a peer reflexive address) but they can't tamper with the contents, but it prevents a number of attacks. The username mechanism also prevents cases of ambiguity in which a STUN check arrives at another endpoint which just happens to be doing STUN. Because the username will be different, it will not respond to the check.

However, the username and password mechanism does not prevent attacks by a Web site using WebRTC, because that site knows the username and password. However, because the transaction ID is unpredictable—and importantly, not revealed to the site's JavaScript—it can't forge a response to any check it doesn't receive. Thus, ICE establishes that the receiver of the traffic has consented to receive it.

Final Thoughts #

It's important to remember how we got here. In part I I wrote:

NATs provide a particularly good example of the way the Internet evolves, which is to say workaround upon workaround. The reason for this is what Google engineer Adam Langley calls the "Iron law of the Internet", namely that the last person to touch anything gets blamed. The people who first built and deployed NATs had to avoid breaking existing deployed stuff, forcing them to build hacks like ALGs and unpredictable idle timeouts. Now that NATs are widely deployed, new protocols have to work in that environment, which forces them to run over UDP and to conform to the outgoing-only flow dynamics dictated by the NAT translation algorithms.

As we can see with ICE, it's not just a matter of working with existing NATs but of working with all the previously deployed systems that were deployed before ICE was available, as well as working with previous versions of ICE. The result is a system of extreme complexity which almost nobody really understands, which has to run before even the first byte of media is delivered. And yet, it mostly works, as you can see for yourself if you use any WebRTC-based calling system such as Meet or Teams.

The astute reader may have noticed that in the "different network" scenario, Alice and Bob's server reflexive addresses have different IPs whereas in the "same network" scenario they have the same IP address. You might think you could compare the addresses to determine which situation you were in. Unfortunately, this isn't dispositive because Alice and Bob might be behind a carrier grade NAT which had a pool of multiple IP addresses that it assigned from. Because of the way that IP addresses are assigned, it's not generally possible to determine whether two addresses belong to the same network. ↩︎
When all you have is a hammer, everything looks like a nail. ↩︎
Technical note: Bob doesn't retransmit his ACKs; he just responds to Alice's retransmissions. This is a pretty typical reliability design because otherwise you end up worrying about whether ACKs were delivered and having ACKs of ACKs, which is a mess. ↩︎
This is of course not always true, but it's a good rule of thumb. ↩︎
I'm simplifying the algorithm here as they would actually start in Waiting and then move to In-Progress. ↩︎
Don't make me explain how we decide which is which. ↩︎
In the original version of ICE, there was instead something called "aggressive mode" in which the controlling endpoint would send USE-CANDIDATE on multiple pairs and the controlled endpoint would pick the highest priority one, but that was removed in favor of this rule. ↩︎
This idea, documented in XEP-0176 appears to be originally due to Joe Beda. Thanks to Justin Uberti for helping me track this down. ↩︎
You might even be talking to an endpoint that doesn't support ICE, but for all the reasons we've discussed here, that's basically not going to work. ↩︎

Defending against Bluetooth tracker abuse: it’s complicated

2023-05-08T00:00:00Z

Bluetooth-based tracking tags like AirTags and Tiles are fantastically useful for finding lost stuff like your keys, your bike, or your cat. Unfortunately, they are a dual use technology which is also easy to use for surreptitiously tracking other people. This isn't a complicated attack to mount: you get a tracking tag and pair it with your own phone, plant it on your victim, and then use the find my stuff feature to monitor their location. This unpleasant fact isn't news: there have been concerns about misuse of these technologies for years, especially after the release of AirTags (see my earlier post for some initial thoughts).

On Tuesday Google and Apple published a set of guidelines for how trackers should behave to reduce the risk of unwanted tracking. This post takes a look at that document and the bigger problem space.

Background: Bluetooth Trackers #

Because these tracking systems are non-interoperable, they don't necessarily all work the same way. However, Apple provides some detail about how the system works, and back in 2021 Heinrich, Stute, Kornhuber, and Hollick reverse engineered the system and published a paper in PoPETS describing how it works as well as some vulnerabilities.

The obvious design for this kind of system would be to just have each tag have a single fixed identifier which it broadcast periodically over Bluetooth Low Energy (BLE). As a practical matter, the tag doesn't actually broadcast unless it's out of range of one of the devices its owner has paired it with; if it's in range, then the owner device can find it directly. Whenever the tag was within range of a participating device (e.g., a phone), that phone would then upload the device tag and its own position to some central server. When you lost your device, you would then contact that server and request its last known location, as shown in the diagram below:

This system has some obvious security and privacy issues:

The service can track the position of any tag (and in fact all tags) just by looking at the database.
In fact, anyone can track a tag if they know the identifier, so if you see it once, you can just query the database.
Even without access to the database, an attacker can reidentify a given device. For instance, if you had a receiver at the entrance to a store, you could see when the same person came by again (this is a similar set of issues to those with license plates.

The second and third attacks can be addressed by just having a rotating identifier. I.e., each tag $i$ has a secret value $SK_i$ which it shares with its owner at the time of pairing with the device. Instead of broadcasting $SK_i$ directly, it uses it as the seed for a pseudorandom function (PRF) to create a rotating identifier $ID_{i,t}$ where $t$ is the current time and broadcasts that instead. Each identifier will be used for a fixed time (say 15 minutes) and then the tag generates a new identifier and broadcasts that. The device owner knows $SK_i$ and can use it to generate $ID_{i,t}$ so it can still query the central service just by asking for the IDs for recent times, but someone who just observes a single ID can't query the service for the locations of other IDs for the same tag (and of course they already know the location at the time of observation).

Rotating IDs #

This also partly solves the problem of the service tracking the tag, because it also cannot link up multiple identifiers, so all it has is a set of locations. However, if there are comparatively few tags then the service can infer people's behavior just by looking at the unlinked locations. E.g, if I see two IDs on Highway 101 traveling in opposite directions (inferred from the lane they are in) and them some other ID getting off on a Southbound exit, I can infer that there was a single device that was going South and then exited, but it's less information. In addition, when someone queries for the location of their tag, then the service provider gets the IDs for a range of time periods, which it knows all correspond to the same device, and can then link up the motion of the tag during that time range.

Apple's design (the best documented) addresses this by having the locations where the tags are detected encrypted to the device owner. This works similarly to the rotating ID system except that instead of generating a rotating ID, the tag generates a rotating private/public key pair: $(Priv_{i,t}, Pub_{i,t})$. The tag broadcast $Pub_{i,t}$ just as it would the ID, but then when a device sees the broadcast, it uploads the location encrypted under that public key. When the device owner wants to find the tag, it queries the server using the public key^[1] (just as it would have before with the tag) and gets the encrypted value. Because it shared $SK_i$ with the tag, it can generate $Priv_{i,t}$ and can decrypt the encrypted location, as shown in the figure below:

Privacy Properties #

This system has significantly improved privacy properties. As with a simple rotating identifier, an attacker can't track a tag using multiple observations over an extended period. And because the reports are encrypted, the service provider is not able to directly determine the actual location of the device. However, that doesn't mean that the service provider doesn't learn anything. In particular:

If two owners both query the location of lost tags which are reported by the same device, than it allows the service to infer that the owners were at one point in the same location (this attack is reported in the Heinrich et al. paper).
If two devices both report the location of the same tag then the provider can infer that those devices were in the same location at the time of the report.
If the service provider has an independent way of learning the location of a reporting device—for instance by IP location or because the owner uses some location-based service—and then the owner queries for its location, the service gets to learn information about the owner's movements (because that is where they probably lost the tag). This attack is exacerbated by the fact that you want to query multiple keys (one for each time range), so the service might learn multiple locations for the same tag and be able to link them.

The root cause of all of these issues^[2] is that the service gets to learn the identity of reporting devices when they make reports, as well as potentially of the device owner when they query for location. This part of Apple's design isn't very clearly documented, but presumably the rationale for identifying the endpoints is to prevent abuse (e.g., forged location reports) by requiring that they be genuine Apple devices (see Section 9.4 of Heinrich et al.). It should be possible to address this issue using standard anonymity techniques such as Oblivious HTTP,^[3] though it doesn't appear Apple does that.

Unwanted Tracking #

The privacy mechanisms described above are about preventing other people from learning the location of your tags, but the way you use a system like this to track someone else is to attach one of your tags to something of theirs and then query the system to see where your tag is. This is a much harder problem to solve because the whole point of the system is that the tag isn't attached to you (that's why you're looking for it!) and there's no real technical way to distinguish the case where I accidentally left my keys in your car from the one where I maliciously stuck an AirTag to your car to track you.

Instead, the countermeasures that Apple and others have designed seem to center around making this situation detectable. Specifically:

If AirTags are away from their owners for "an extended period of time" they make a sound when moved.
If your iOS device detects that an AirTag that doesn't belong to you moving with you, it will notify you on the device and then you can try to find it and figure out what's going on.

Once you have detected a tag that appears to be following you, AirTags also include a feature that lets you partially identify the owner of the tag, as long as you can physically access the tag.

[Source: Apple]

My personal experience is that these features are both fairly hit and miss. In terms of the sound notification, the speaker in AirTags is pretty quiet and the noise is kind of intermittent. We use AirTags to keep track of our cats, but it's paired to my wife's phone not mine. After she had been out of town for several days, I finally noticed the AirTags making sound and took them off the cat's collars, but the first time this happened I probably heard the sound about three or four times—and who knows how many times I didn't hear it—before I figured out what it was. We're all constantly surrounded by stuff beeping so it's easy to get habituated to it.

Similarly, I've had the "someone is moving with you" trigger a number of times—most recently Saturday—such as when someone accidentally left their AirPods around, but that also takes a while to trigger and is easy to ignore. I imagine both of these features would work a lot better if you were really worried about being tracked, but at least in my experience there are a lot of false positives, which makes the whole system less useful than one might like.

The Apple/Google Draft #

On Tuesday, Apple and Google published a document describing guidelines for how trackers ought to behave in order to make unwanted tracking easier to detect.

Today Apple and Google jointly submitted a proposed industry specification to help combat the misuse of Bluetooth location-tracking devices for unwanted tracking. The first-of-its-kind specification will allow Bluetooth location-tracking devices to be compatible with unauthorized tracking detection and alerts across iOS and Android platforms. Samsung, Tile, Chipolo, eufy Security, and Pebblebee have expressed support for the draft specification, which offers best practices and instructions for manufacturers, should they choose to build these capabilities into their products.

Mostly this document provides detailed specifications of the behaviors I've described informally above. For instance, here's the portion describing how the audible alerts should work:

   After T_(SEPARATED_UT_TIMEOUT) in separated state, the accessory MUST
   enable the motion detector to detect any motion within
   T_(SEPARATED_UT_SAMPLING_RATE1).

   If motion is not detected within the T_(SEPARATED_UT_SAMPLING_RATE1)
   period, the accessory MUST stay in this state until it exits
   separated state.

   If motion is detected within the T_(SEPARATED_UT_SAMPLING_RATE1) the
   accessory MUST play a sound.  After first motion is detected, the
   movement detection period is decreased to
   T_(SEPARATED_UT_SAMPLING_RATE2).  The accessory MUST continue to play
   a sound for every detected motion.  The accessory SHALL disable the
   motion detector for T_(SEPARATED_UT_BACKOFF) under either of the
   following conditions:

   *  Motion has been detected for 20 seconds at
      T_(SEPARATED_UT_SAMPLING_RATE2) periods.

   *  Ten sounds are played.

   If the accessory is still in separated state at the end of
   T_(SEPARATED_UT_BACKOFF), the UT behavior MUST restart.

Not a full specification #

What this document is not, however, is a complete specification of a tracking system. In particular, it doesn't cover any of the fancy (well fancy-ish) cryptography I described above. Instead, it describes a Bluetooth container for the messages, with the following contents:

Bytes	Description	Requirement
0-5	MAC address	REQUIRED
6-8	Flags TLV; length = 1 byte, type = 1 byte, value = 1 byte	OPTIONAL
9-12	Service data TLV; length = 1 byte, type = 1 byte, value = 2 bytes (TBD value)	REQUIRED
13	Protocol ID (TBD value)	REQUIRED
14	Near-owner bit (1 bit) + reserved (7 bits)	REQUIRED
15-36	Proprietary company payload data	OPTIONAL

As far as I can tell, the cryptographic pieces would go in the "proprietary company payload data" portion, though it's actually not clear to me precisely how this works in the case of AirTags. As Heinrich et al. describe, the BLE payload is quite small (31 bytes for the ADV_NONCONN_ID PDU) but the BlueTooth standard requires a 4-byte header for manufacturer-specific data, so Apple had to do do some tricky engineering to get the P-224 public key (28 bytes) into the remaining 27 bytes of the packt (they repurpose part of the MAC address to do this). It's not quite clear to me how Apple plans to stuff the public key into the 21 "proprietary payload" bytes, but presumably they have some plan in mind. Any readers who know how this is supposed to work should reach out. Maybe they plan to send two packets?

The key point here is that this isn't enough of a specification to provide interoperability between systems. For instance, it wouldn't tell you enough to build your own tags which worked with Apple's tracking network; it's just supposed to be enough to tell you how to build your tracking tags so that they are detectable. Note the careful phrasing here: the document doesn't tell you how to detect tracking tags, it just tells you how to build tags which are trackable and you are left to infer how to detect them.

Detecting Tracking Tags #

With that said, this document does help explain something confusing about the description I provided above, namely how devices are to detect that a tag is following them if the identifier it broadcasts changes every 15 minutes. The answer appears to be that the BLE address doesn't change.

An accessory SHALL rotate its resolvable and private address on any transition from near-owner state to separated state as well as any transition from separated state to near-owner state.

When in near-owner state, the accessory SHALL rotate its resolvable and private address every 15 minutes. This is a privacy consideration to deter tracking of the accessory by non-owners when it is in physical proximity to the owner.

When in a separated state, the accessory SHALL rotate its resolvable and private address every 24 hours. This duration allows a platform's unwanted tracking algorithms to detect that the same accessory is in proximity for some period of time, when the owner is not in physical proximity.

The "resolvable" address refers to the BLE network address (MAC address). In other words, when in the separated state, the tag sends out beacon packets where the MAC address is constant for 24 hours even if the public key rotates every 15 minutes (and remember that the public key encryption piece isn't specified here). So presumably what you are supposed to do as a device is look for any tag (identified by MAC address) that has been following you for a while and if so alert the user. But how long a period is "a while". Who knows? That's up to you.

Why not just rotate the address every 24 hours all the time? Two reasons: (1) it prevents triggering the detection algorithm as long as it has a trigger at more than 15 minutes and (2) it make the tag less trackable in cases where it is traveling with its owner (see rotating IDs above. There is also a "near-owner" bit in the advertisement that says that the tag is near its owner and that detecting devices shouldn't treat it as tracking them.

Once a tag is detected, it is also possible to connect to it directly and query its information (manufacturer, product type, etc.), as well as to cause it to play a sound. It is also possible to retrieve the device serial number as long as you can demonstrate close proximity, either via an NFC connection or some user action on the device itself (pressing a button, etc.)

The Broader Threat Model #

My bigger concern is that this document seems be limited to a fairly narrow threat model, which is to say tracking by naive attackers who take an off-the-shelf tag and attach it to their victim. The Apple/Google document describes a set of behaviors that companies ought to build into their trackers to mitigate this threat, but unfortunately, this isn't the only threat.

It's already possible to buy relatively compact GPS trackers that don't depend on using Bluetooth to talk to other devices (see this older post for more on this topic.). However, these trackers are expensive (about $300, plus a subscription), have battery lifetimes measured in days or (at best weeks), and are several centimeters across, so are somewhat hard to conceal. By contrast, tracking tags like Tiles or AirTags have a combination of features that makes them more attractive for surveillance.

They are compact (thus easy to hide)
They are cheap (thus easy to obtain)
They have long battery lifetimes (and thus are suitable for long-term surveillance)

These features are made possible by the existence of a widespread network of devices (phones, etc.) which can report the position of a lost tag. That network allows the use of much cheaper and energy efficient technologies than a tracker like the Garmin inReach, which needs both a GPS receiver and a satellite transmitter. It's that network that creates the risk, not the tracking tags themselves. Specifically, if the attacker can obtain a tag which can successfully be located with the tracking network but which doesn't conform to the behaviors specified in this document, then the detection mechanisms that this document anticipates will be less effective if not completely useless.

There are at least two possible ways for an attacker to obtain such a tag:

Modifying an existing tag.: The stock tags made by each manufacturer are cheap and generally reasonably well-engineered, so it's convenient for the attacker if they can just buy them and disable the anti-tracking features. For example, in his thorough AirTag teardown, Adam Catley observes that it's possible to disable the speaker in an AirTag and suggests that the tag be modified to check to see if the speaker is actually making noise. Depending on the design of the tag, it might be possible to rewrite the firmware to violate the requirements in this document, for instance by rotating the MAC address frequently to evade detection (oddly: this document says "The accessory SHOULD have firmware that is updatable by the owner", which is the opposite of what you want here.)
Building an entirely new tag.: Even if the stock tags are hard to modify, once it's public information how these devices are built it's possible to make your own tags that don't have any anti-tracking features at all. In fact, this already exists in the form of OpenHaystack built by the same team as that published the PoPETS paper I've been relying on for most of this analysis. OpenHaystack is designed to run on commodity hobby hardware like the BBC micro:bit which is quite a bit bigger than an AirTag but obviously it would be possible for someone to engineer something compact and cheap, perhaps using the AirTag design as a starting point. Note that it doesn't really help that the specific design of any individual system is secret: there are tens of millions of these devices out there, and it just takes one person to reverse engineer a tag and publish the results.

Either of these attacks requires more sophistication than just buying an AirTag through Amazon, but the would-be stalker doesn't have to have that sophistication themselves; they just need some third party to start making and selling tags that are suitable for surveillance. If such devices become widely available, then the countermeasures Apple and Google are proposing will become much less effective. There's already a market for "stalking apps," so this seems like a real risk.

What you really want here is for it not to be possible to make a tag which participates in the tracking network without implementing the specified anti-tracking behaviors. This is a hard job under any circumstances (though see some handwaving ideas below), but is made much harder by specifying a design in which tracking detection pieces are specified at one level (the BLE layer) and the official "find my device" functionality is implemented in a proprietary layer that sits on top of that. That makes it very easy for an attacker to build their own tag that complies with the (reverse engineered) proprietary pieces but then violates the rules at the BLE layer. I can understand why Apple and Google, who each presumably have some proprietary design, want to avoid standardizing that piece, but the result is that the problem of detecting unwanted tracking is much harder.

Attestation #

The most straightforward approach is if we assume that "official" devices behave correctly and then have some mechanism for detecting official devices. The standard approach here is to have what's called an "attestation" mechanism in which each legitimate device has some secret embedded by the manufacturer which can be used to prove that it's legitimate (e.g., by signing something). See ([here](/posts/verifying-software for more on this.) Devices would then require tags to prove they were legitimate before reporting their location to the network. Of course, this secret has to be embedded in tamper-resistant hardware to prevent an attacker stealing the secret and making their own fake devices.

Actually building a system like this in such a way that the attestation doesn't itself become a tracking vector (e.g., by having each device have a single attestation key which can then be tracked) is challenging cryptographically (this is also an issue with the WebAuthn public key authentication system), but there are some approaches that sort of work, or at least are somewhat better than the naive design.^[4]

However, even if you know for sure that you are talking to a legitimate device, that doesn't necessarily tell you that it's acting as its supposed to. As a simple example, you might have a device which sent the right BLE data but whose speaker had been disabled (or which was wrapped in sound-absorbing material). A fancier attacker might take a legitimate tag and proxy its signals to the device by putting it in a radio-absorbing case and then receiving and retransmitting whatever signals it sent, as shown below:

In this example, the tag is in the separated state, so it is supposed to keep a constant MAC address (though presumably still rotate its public key). However, the attacker captures this message and rewrites the MAC address so it looks like it a different device, fooling the detection algorithm.

This kind of cut-and-paste attack is possible to address by having the proprietary pieces that the network relies on enforce the correctness of the anti-tracking pieces (e.g., by signing the expected MAC address), but in order for this to work, they need to be aware of each other, which, as I said, isn't specified anywhere in this document. The point here is that successfully designing anti-tracking mechanisms requires analyzing the system as a whole, not just looking at one piece at a time. In particular, it's necessary to understand how the as-designed functionality works in order to build anti-tracking countermeasures which can't be separated from that functionality. And of course, in the case of the audible alerts, in some cases that may not be possible to do.

Worse yet, we already have a giant installed base of devices which don't have any kind of attestation, and presumably vendors want them to continue to work. This means that even if we were to deploy a system with this kind of attestation today, attackers could still exploit it by pretending to be one of those old devices.

The Status of this Specification #

This is slightly off topic from the technical content of this post, but I think it's important to observe that this isn't an IETF specification. There has been some confusion on this point, in part due to Apple's misleading PR statement:

The specification has been submitted as an Internet-Draft via the Internet Engineering Task Force (IETF), a leading standards development organization. Interested parties are invited and encouraged to review and comment over the next three months. Following the comment period, Apple and Google will partner to address feedback, and will release a production implementation of the specification for unwanted tracking alerts by the end of 2023 that will then be supported in future versions of iOS and Android.

Whats an RFC? #

RFC stands for "Request For Comments", and dates from the prehistory of the Internet when there wasn't a real standards process and people would just publish memos describing protocols. The IETF loves its traditions and "RFC" is now an important brand (so much so that other organizations such as the Rust Project now publish standards "RFCs" even though they have no connection to the IETF process. To make matters worse, there are also RFCs published in the same series as IETF RFCs that aren't standards, including those published in what's called the Independent Stream, which don't have any standards status and are just approved by a single Independent Submissions Editor.

That's pretty carefully worded, but it certainly gives the impression that Apple and Google want to standardize this work. The quote from Erica Olsen from the National Network to End Domestic Violence (NNEDV) is even more explicit, referring to these as "new standards" (and of course this is in Apple's press release, so it's not like they aren't aware of the context). Of course, there are other meanings to "standard" than "document produced by some Standards Development Organization", but in this context, the best you can say about this press release is that it's misleading in a way that is very convenient for Apple and Google, who would no doubt like the protective cover of appearing to standardize something while in fact acting unilaterally to address a problem they created by acting unilaterally.

Needless to say "two big companies submit a specification, take comments for three months, and then do whatever they feel like" is not the way that the IETF standards process works. The IETF lets anyone "submit" a specification by posting an Internet-Draft (ID) which is what Apple and Google have done, but those don't have any formal status. Some IDs will be adopted by the IETF as part of the standards process and some of those will actually be standardized and become RFCs. This process takes much longer than three months and involves achieving "rough consensus" of the IETF Community, not just a few vendors. I know that this sounds like standards inside baseball, but there is an important point here. One of the functions of standards is to ensure that there is widespread review from a variety of stakeholders, who might have a different viewpoint (for instance that actual interoperability is useful, or that you need a different set of tradeoffs between privacy and functionality), but the way that that works is that you need buy-in from those stakeholders before the standards are finished.

One critique you often hear is that the standards process is too slow and that this is why industry actors need to ship first and standardize later. The three month comment period seems to reflect that attitude (it's certainly true that the IETF can't standardize anything in three months). However, the decision by Apple and Google (and others!) to ship these technologies without real public review is one reason why we now are in a situation where they are being actively misused, something people have been expressing concerns about for two years. Apple/Google could have brought this work to IETF—or some other standards body—at any point during that time, but they chose not to do so, so arguments about how the situation is now too urgent to go through a real multistakeholder process don't really move me.

I regularly work with a lot of people from Apple and Google and those companies know how to bring work to IETF when they want to. This isn't it.

Final Thoughts #

As I said two years ago, this is a classic dual-use technology. It's really convenient to be able to find your stuff when you lost it, but tracking tags just don't know whether they are attached to your stuff or other people's stuff. Trying to make it visible when you are being tracked via this method is probably about the best you can do, but it's also clear that it's a highly imperfect defense. Deploying this kind of defense is made even harder by having a large installed base of devices from multiple mutually incompatible networks, meaning that anything we do has to be backward compatible. It took us years to get into this hole; it will take a lot more than three months to get out.

[2023-05-08: Updated title.]

Actually a hash of the public key. ↩︎
Heinrich et al. also report an issue in which attacker is able to leverage temporary control of the user's device to steal $SK_i$ and afterwards can track the user. Apple has reportedly solved this by making the keys harder to learn, but this is a generically hard problem in an open system. ↩︎
The way this would work would be that the device encrypt the report as described above and then encrypt it yet again for the service. It would connect to a proxy, authenticate as a valid device, and then send the doubly-encrypted report. The proxy would then strip off the reporter's identity and send it to the service, which would remove the outer encryption layer and store it, just as before. ↩︎
Note that this would most likely not all fit into a single packet, but you could imagine that the reporting device would ask the tag to attest in a separate message before reporting its position to the service. ↩︎

How NATs Work, Part II: NAT types and STUN

2023-04-17T00:00:00Z

The Internet is a mess, and one of the biggest parts of that mess is Network Address Translation (NAT), a technique which allows multiple devices to share the same network address. This is part II in a series on how NATs work and how to work with them. In Part I I covered NATs and how they work. If you haven't read that post, you'll want to go back and do so before starting this one. This post starts to discuss NAT traversal, covering the different types of NATs and how to build peer-to-peer applications that still work from behind NATs.

As IP addresses became increasingly scarce, more and more of the client devices on the Internet started to move behind NATs. I don't have any real data here, but pretty much every consumer level WiFi router I've ever used is also a NAT, sharing a single externally assigned IP address amongst all the devices behind it. By contrast, servers typically have stable public IP addresses.^[1] This arrangement works reasonably well in client-server situations because the client initiates the connections, and so doesn't need an address/port pair that's stable for more than the life of the connection. However, it doesn't work for peer-to-peer applications.

Peer to Peer Applications #

Although much of the Internet is client-server, there are a number of more or less important peer-to-peer (P2P) applications in which data flows directly between end-user machines rather than via a server (as in e-mail, Web, etc.). Some examples are:

1-1 video calling
File distribution (BitTorrent or IPFS)
Some Web3/blockchain systems
Games

In principle, P2P systems have a number of advantages, including:

Reduced cost: because you don't need to pay for a server somewhere. This is an especially big deal for high-bandwidth applications like video calling or file sharing.
Reduced latency: because you don't need to send traffic up to the server and then from the server to the other side, which will generally be slower than sending it directly.
Censorship resistance/avoiding centralized control: because there's no central server to attack.

In practice, some of these advantages often come with disadvantages, which is why you see a lot of client/server applications and not a decentralized Web, but there is still a fair bit of P2P. The application I'm most familiar with is voice and video over IP: it's moderately expensive to run a centralized system like Meet or Zoom where you have to process all the media, but much cheaper to run one where the endpoints just talk to each other.^[2]

P2P Challenges #

The way that a Web server works is that the server operator knows the IP address of the server and publishes it in the DNS. The port number is just 443 or 80 depending on whether the traffic is encrypted or not. Unfortunately, this won't work for P2P systems for two fairly obvious reasons (and also a number of non-obvious ones, as we'll see below):

Machines behind the NAT don't know their own IP address. If your machine has a public IP address, you can just look at how its configured and know what to publish in the DNS. In managed systems, the operators have some mechanism for assigning addresses and storing the data in the DNS. But when you connect your laptop to the WiFi, the IP address that the laptop sees is likely in some private range, e.g., 10.0.0.*, which isn't useful for other people to connect to unless they happen to be on your network.
Public IP addresses and ports aren't stable. In general, the NAT will only have a single public IP address, so that's reasonably stable (though see here), but the port is not. As I mentioned previously, the NAT creates a binding in response to outgoing traffic and then deletes it when there isn't any traffic. As a result, even if you knew the mapping of internal to external ports at some time in the past, that mapping may no longer be valid.

For these reasons, clients can't just publish their IP addresses like a server does (there is also the question of where you would publish them, but put that aside for a moment). Instead, you need some kind of server to help them.

Background: Voice over IP Architecture #

Just for convenience, let's focus on voice over IP. The diagram below shows what you might call the "reference architecture" for a voice or video over IP system like you might build with WebRTC:

Video Conferencing Topologies #

Ironically, despite all the work that has gone into NAT traversal, many video conferencing systems, the media doesn't actually go directly but rather goes through the server. The reason for this is that if you have many people in the call, then the sender needs to send a copy of their media to each other person, which means that if there are N people in the call, and their video is M megabits/second, they need to send (N-1) * M megabits/second of media, which can quickly overrun a consumer Internet link. Instead, it's conventional to use a star topology where the user sends their media to a server which replays it to everyone else in the call. This is expensive for the server, of course, but cheaper for the user. Some conferencing systems do send media directly for smaller conferences to minimize costs. Sending media directly also currently works better with end-to-end encryption for video, though that's a problem that's being actively worked on because you'd like to have end-to-end encryption even in large conferences where a mesh design isn't practical.

In a system like this, Alice and Bob both connect to a signaling server which is responsible for orchestrating the calls. In the case of a traditional VoIP system like you would design with SIP, Alice and Bob would each have a device or an app (often called a "softphone") that had the actual calling logic, presented the user interface, etc., and would exchange SIP messages via the server. In a WebRTC system such as Google Meet or Microsoft Teams, there is a Web server which hosts the Web app and carries messages back and forth between the Web browsers, even though much of the actual calling logic is built into the browser.

In either case, you would ideally like the media (i.e., the actual voice and video) to go directly between Alice and Bob (though see below). There are two main reasons for this. First, it is cheaper: real-time video involves transmitting a lot of data and if Alice sends all that data to the server and then the server sends it to Bob, then the server operator has to pay for all that data transmission. Second, it generally takes longer for the data to go from Alice to the server and then the server to Bob, than it would for Alice to send the data to Bob directly, especially if, as is relatively common, Alice and Bob are geographically close and the server is not. But now we have to contend with NATs.

STUN #

As noted above, the first problem we have is that the client machine may not know its own IP address. The NAT knows, of course, but there's no universally deployed protocol for it to tell the client. Instead, the client has to measure it directly. The standard protocol for this is called Session Traversal Utilities for NAT (STUN). STUN works by having the client talk to some server on the Internet (unsurprisingly called a STUN server). Typically, this server will be provided by the calling service, and configured into the clients somehow. For instance, WebRTC provides an API to tell the Web client which STUN server to use.

In order to discover its IP address, the client sends the server a STUN Binding Request, and the server responds with the IP address and port that the server saw (technical term: reflexive address) like so:

This is how the original version of STUN, published in 2003, behaved. Unfortunately, it is impossible to make things foolproof because fools are so ingenious. As you may recall from the discussion of Application Layer Gateways (ALGs) in Part I, some NATs will rewrite messages coming in from the Internet, rewriting the external (reflexive) address to the internal (host) address. If you have such a NAT, what you will instead see is a flow like below, where the client gets a response that just contains its own local address rather than the external one.

This is not useful! Unfortunately, we have to traverse the the NATs we have, not the NATs we wish we have, so a way around this was needed. The second version of STUN, published in 2008, added a new way to return the reflexive address in what is called the XOR-MAPPED-ADDRESS attribute. This attribute worked by XORing the host and port with other values from the packet. This is pretty weak sauce as encryption goes but it's usually good enough to break up the simple-minded pattern matching that NAT ALGs were using at the time (the idea here isn't to avoid NATs which know about STUN and want to rewrite values, but just to prevent accidental breakage). This is mostly how STUN works today.

One thing that may not be immediately obvious is that you need to do the STUN queries from the same address and port that you want to receive media on. The reason for this is that each port you send from will have a different NAT binding, and so if you know the binding for port A this doesn't tell you about the binding for port B.^[3] This is the same reason why you can't just have the Web server send you your reflexive address and use that: you're contacting the Web server from a different port (and when this stuff was designed, TCP rather than UDP) and so the binding that the Web server sees doesn't help you for your media. Instead, what you do is allocate a port to use for media, discover the reflexive address with STUN, and send that reflexive address to your peer, and then subsequently use that port to send and receive media.

NAT Types #

If only things were that simple. There are in fact NATs for which this will work, but many where it will not. There are two basic problems:

NATs which use different mappings for different remote addresses (and ports). Note: As a convenience, I am going to start saying "address" when I mean "address and port", because the alternative is clunky. For instance, if Alice sends packets to both Bob and Charlie, Bob and Charlie might see different reflexive addresses (or more likely ports, as your typical consumer NAT only has one IP address) even if Alice uses the same local address and port. These NATs are said to have address-dependent mappings or address and port-depending mappings, depending on which differences trigger variation. The alternative is called endpoint-independent mapping (these terms come from RFC 4787).
NATs which have consistent mappings but filter packets from addresses that the client hasn't sent to. For instance, Alice might send a packet to Bob, creating a mapping, but if Charlie sends a packet to Alice on the same reflexive address, the NAT would drop it. If Alice then sends a packet to Charlie, he will see the expected address, and if he responds to this packet, the NAT will deliver it. These NATs are said to have address-dependent filtering or address and port-dependent filtering. The alternative is endpoint-independent filtering.

The bottom line here is that there are a lot of different types of NAT, and depending on what kind of NAT you (and the person on the other side) have, you need to do different things in order to establish a connection.

How to get through a NAT #

As a notational convenience, I'm going to describe NATs using the following abbreviations:

Behavior	Abbreviation
Endpoint-Independent Mapping	EIM
Address-Dependent Mapping	ADM
Address and Port-Dependent Mapping	APM
Endpoint-Independent Filtering	EIF
Address-Dependent Filtering	ADF
Address and Port-Dependent Filtering	APF

A NAT is defined by the pair of mapping and filtering behaviors, so, for instance, EIM:APF is a NAT that has consistent mappings across addresses but filters based on address and port.

I'm also going to simply addresses and ports by writing them as A:a, A:b, etc. where the first letter is the address and the second is the port. Alice's local address will always be A:a and Bob's will be B:b. The STUN server's will be S:s.

EIM:EIF ↔ EIM:EIF #

A NAT which has endpoint-independent behavior for both mapping and filtering is the easiest type to traverse: it's basically like having a public IP address except that the binding may not be stable over long periods of time. You can traverse this kind of NAT by just having each side publish its address and the other side can send directly, as shown in the figure below:

This diagram shows about the simplest possible NAT traversal scenario. It starts with Alice deciding to call Bob. She uses the STUN server to discover her reflexive address by sending a Binding Request from A:a. The STUN server responds with her reflexive address: X:x. Alice then sends a message to the signaling server to initiate the call (the details of this depend on whether you are doing WebRTC, SIP, etc. In SIP this would be an INVITE).

The signaling server notifies Bob of the incoming call. When he decides to accept it, then he will also contact the STUN server to discover his reflexive address (Y:y). His response to the signaling server to answer the call will include this address. At this point, Alice and Bob know each other's addresses and can start sending media to each others reflexive addresses, as shown in the final block. Because the NATs have endpoint-independent mapping, the same binding will be in effect when the peer sends a message as they did for the STUN server, even though the message from the peer comes from a different IP address. Similarly, because they have endpoint-independent filtering, the NAT will accept an incoming packet directed to the reflexive from any source.

This is already a pretty complicated process, but it's conceptually fairly simple: each side discovers its address and sends it to the other side. If all NATs had endpoint-independent behavior for both mapping an filtering, then we could just stop here. Unfortunately they do not.

EIM:EIF ↔ EIM:APF #

Now let's look at the next most complicated case, in which Alice has the same NAT as before, but Bob has a NAT with endpoint-independent mapping but address and port-dependent filtering, as shown in the figure below. To keep things simple, I've omitted the opening phases where each side discovers their address and sends it to the other side, just showing the media phase. Note that the early phases look the same for every NAT type, which is part of what makes things difficult.

Unlike in the previous setting, when Alice sends her first packet of media to Bob, his NAT discards it. Because Bob's NAT has address and port dependent filtering, it has an access control entry only for the STUN server, but not for Alice's address, so when Alice's packet arrives, the NAT just drops it. By contrast, because Alice's NAT has address-independent mapping and filtering (as in the previous example), the packet is delivered correctly to Alice.

You might think at this point that we're just going to have media flowing one way (from Bob to Alice), but that's not what happens: when Bob sends his first media packet to Alice, it creates a new access control entry in his NAT for Alice's address, so that when Alice's second packet (either a retransmit or reflecting a later part of the media stream) arrives, it is delivered correctly:

From this point forward, you have two-way media.

The following table representing Bob's NAT's state might help visualize what's happening here.

Event	Mapping	Access Control List
Start	-	-
Address discovery	B:b ↔ Y:y	S:s
Packet 2 sent	B:b ↔ Y:y	S:s, X:x

Initially, Bob's NAT doesn't contain any mappings. After he sends a Binding Request to the STUN server, the NAT creates a mapping from B:b to Y:y and an access control entry for that mapping associated with just the STUN server. Thus, when Alice's packet 1 comes in, it is associated with a valid mapping, but is rejected because it doesn't match a valid access control entry. When Bob sends his first media packet (number 2), a new access control entry is added to the same mapping (recall that Bob can always send outgoing packets and they just add the appropriate access control entries). Then when Alice's packet 2 arrives, there is an appropriate access control entry and it can be delivered.

Obviously, this introduces a little latency before media starts flowing, but given that the Internet is already subject to packet loss anyway, this isn't necessarily that big a deal, especially with voice and video applications which will be sending packets every 20 milliseconds or so. It's potentially a slightly bigger issue for reliable transport protocols if they only send one packet at a time and have long retransmit timers, but even then the connection will eventually be established; it just takes a little while.

EIM:APF ↔ EIM:APF #

Now let's look at what happens when both Alice and Bob have NATs with endpoint-independent mapping but address and port-dependent filtering. This actually behaves identically to the previous scenario:

As before, the first packet from Alice to Bob is dropped by Bob's NAT but on its way out it establishes the access control entry in Alice's NAT in the opposite direction, thus allowing the next inbound packet to pass through the NAT. Here's Alice's table:

Event	Mapping	Access Control List
Start	-	-
Address discovery	A:a ↔ X:x	S:s
Packet 1 sent	A:a ↔ X:x	S:s, Y:y

All of this happens before the first packet from Bob arrives, and so even though Alice does have address and port-dependent filtering, the right access control entry is in place before that packet is received, and so the packet is just delivered.

One important feature to notice about all the scenarios we have seen so far is that they don't depend on knowing what kind of NAT the other side has: Alice and Bob just start transmitting and eventually the right access control entries will be established and the packets will flow properly. Now let's look at a scenario where that isn't true: when one side has address and port-dependent mapping as well as filtering.

EIM:EIF ↔ APM:APF #

Suppose we have a situation where Alice has the address-independent mapping and filtering but address and port-dependent filtering as before, but Bob has both address and port-dependence for both mapping and filtering. This produces the situation shown below:

As with the previous scenario, the first packet from Alice to Bob is dropped by Bob's NAT. This actually happens for a slightly different reason than in the previous examples. In those, there was a valid mapping for Alice's packet, but no corresponding access control entry. However, in this case, because Bob's NAT has address and port-dependent mapping, the packet from Alice (X:x) to Y:y doesn't match any mapping at all.

When Bob sends his first packet (2) to X:x, it creates a mapping for X:x but on a different outgoing port Y:y'. At this point, his NAT has the following mapping table:

Local Address	Remote Address	External (Reflexive) Address
B:b	S:s	Y:y
B:b	X:x	Y:y'

Packet 2 is still deliverable to Alice because her NAT has endpoint independent mapping and filtering. However, when Alice sends her next packet, it still goes to Y:y and not Y:y', and so just gets dropped. This one-way communication will persist throughout the connection: every packet Bob sends uses the X:x ↔ Y:y' mapping and every packet Alice sends goes to Y:y, so none of them will ever be delivered. Most likely, eventually one of Alice or Bob will get tired of not being able to communicate and hang up.

This scenario is actually recoverable, but it requires some cleverness on Alice's part. What Alice has to do is look at the source address of packets that Bob is sending her (the peer reflexive address) and if it differs from the one that Bob sent her over the signaling channel (the server reflexive address), try sending packets to that address instead, as shown below:

The first two packets here are the same as before, but for the third packet, Alice switches from sending to Y:y to sending to Y:y'. This corresponds to a mapping on Bob's NAT (and also an entry in his access control table) and so the packet will be delivered as expected. From here on, things work normally.

This technique works, but it requires care to use correctly. For instance, consider what happens if an attacker sends a bogus packet from a different address:

If Alice is naive, she will notice that Bob seems to have switched his address and just switch to sending to the attacker at Z:z. Importantly, this attack can be mounted by an attacker who cannot read packets en route from Alice to Bob; he just needs to know the address and port Alice expects packets on. In the best case, if encryption is in use, then the attacker won't be able to read the packets but he will have disrupted the connection. In the worst case, if encryption is not in use—and when all this stuff was designed, VoIP encryption was fairly rare—the attacker will be able to listen in on the Alice → Bob side of the call. Depending on Bob's NAT configuration (e.g., if it's actually endpoint-independent), the attacker may even be able to do so without noticeably disrupting the call, by forwarding the packets to Bob. There are a number of defense against this form of attack, as we'll see in the next post.^[4]

EIM:APF ↔ APM:APF #

Let's look at one more case, in which Bob has the same APM:APF NAT as before but Alice has a NAT that does address and port-dependent filtering. This produces the result shown below:

As in the previous example, Alice's packet gets dropped by Bob's NAT because there is no corresponding mapping for X:x, only one for the STUN server. However, unlike the previous example, Bob's packet is also dropped, because there is no corresponding access control entry. As you'll recall from above, Alice has the following mapping and access control entries:

Mapping	Access Control List
A:a ↔ X:x	S:s, Y:y

However, because the incoming packet is coming from Y:y' and not Y:y, Alice's NAT discards it. And because Alice never gets packet 2, she is unable to change the destination of her packets to Bob's peer reflexive address Y:y' and so just keeps transmitting packets to Y:y which Bob's NAT drops because it does not have a corresponding mapping. Similarly, Bob keeps transmitting packets to Alice, which her NAT drops because it doesn't have the corresponding access control entry.

What we have here is deadlock: Bob can't receive packets from Alice until she adjusts the address she is sending to, and Alice can't receive packets from Bob (thus learning about the new address) until she has sent one to the new address (thus creating the access control entry). The result is both sides transmitting and neither side receiving. This is not a recoverable situation.

Relays #

Getting out of this hole requires the use of a relay server. More on this later, but briefly a relay is some server on the public Internet that Bob can send his traffic through. Because this relay is something that Bob explicitly uses and has a relationship with—unlike his NAT, which just does whatever it does—it can have deterministic properties which facilitate NAT traversal. For instance, the most common relaying protocol, Traversal Using Relays Around NAT (TURN), provides endpoint-independent mappings and so effectively fixes the problem we see in this section.

As with STUN servers, it's conventional for the calling provider to provide a TURN server—indeed, they are typically the same endpoint. However, TURN is much more expensive to provide than STUN, so ideally if its possible for two endpoints to communicate without using TURN, you want them to do so. Fortunately, most client pairs can communicate without TURN, so it's still cheaper to operate a calling service that tries to send data peer-to-peer than one that sends everything through a central conferencing server, as long as you use non-TURN where possible. We'll discuss how to do this in the next part of this series.

Hairpinning #

There's one more scenario I want to cover here, which is what's called "hairpinning". Consider the case where Alice and Bob are actually on the same network, as shown below:

Recall that the NAT has two addresses, the internal address (10.0.0.1) which Alice and Bob communicate with and the external one (192.0.2.1) that is used communicate to the outside world. Just as in the scenarios before, Alice and Bob can connect to the STUN server and get their server reflexive addresses. For example, Alice might get 192.0.2.1:1111 and Bob 192.0.2.1:2222 (naturally, these use the NAT's external address). The problem comes when Alice tries to send a packet from inside the network to Bob's external address. If the NAT handles this properly, it will deliver this packet (technical term: hairpinning) but some NATs do not do so, and will just drop the packet. In this case, Alice and Bob will not be able to communicate.

Of course, Alice and Bob can communicate directly using their local addresses in the 10.0.0.* space, but it's hard for them to detect this case because many different networks use those addresses (that's the point of RFC 1918 addresses, after all). They could look to determine if they have the same server-reflexive address, but that might or might not be a reliable indicator, depending on what kind of NATs are in use. For instance, Alice and Bob might have their own NATs but also be behind a carrier grade NAT that causes them to have the same address. In this case, they will probably not be able to communicate directly.

Ideally, NATs would properly support hairpinning (this is what RFC 4787 recommends), but, as we've seen throughout this series, NAT behavior is inconsistent and the endpoints have no good way of asking the NAT what it does.

What a mess #

Back in 2003 when STUN was first being developed, the idea was that you would characterize your NAT. RFC 3489 had a whole algorithm you used that involved multiple STUN queries and tried to determine what your network configuration was (remember that you can't ask it any questions, you have to measure). The RFC described a whole menagerie of different NAT types ("full cone", "restricted cone", "port restricted cone", and "symmetric"),^[5] with the idea that you would classify your NAT according to one of these types. Based on what kind of NAT you had, you could then provide an appropriate address to the other side—or, in the case of the worst type ("symmetric NAT") potentially declare failure. This turned out not to work very well, in part because the ecosystem was just a lot more complicated than people expected. In the words of the revised STUN RFC:^[6]

STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.

Instead, the IETF devised a solution which was intended to work with any NAT type by the time honored technique of trying a lot of stuff and seeing what works. That solution is called Interactive Connectivity Establishment (ICE), and I'll be covering it in Part III.

They may also be NATted, but that's an operational convenience, because you still need a stable public IP. ↩︎
There are also reasons why centralized videoconferencing systems are good, but that's another post. ↩︎
Except that it it won't be the same as for A, at least for the same server. ↩︎
Note that some of the obvious defenses don't work. For instance, you can't just "latch" to the first packet you see because the attacker might be faster. Similarly, you can't just compare the peer reflexive address to the address Bob sent over the signaling channel because if Bob has address and port-dependent mapping, then the true peer reflexive address will also not match. ↩︎
This was before people came up with this "endpoint-independent", "address-dependent", etc. taxonomy. ↩︎
Which also includes a totally different expansion for STUN. In RFC 3489, STUN stood for "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)" and now it stands for "Session Traversal Utilities for NAT". The IETF loves its acronyms (and backronyms). ↩︎

Everything you never knew about NATs and wish you hadn't asked

2023-04-03T00:00:00Z

The Internet is a mess, and one of the biggest parts of that mess is Network Address Translation (NAT), a technique which allows multiple devices to share the same network address. In this series of posts, we'll be looking at NATs and NAT traversal. This post is on NATs and the next one will be on NAT traversal techniques.^[1]

Background: IP addresses and IP address exhaustion #

You may recall from previous posts that the Internet is a packet switching network which works by routing self-contained messages (datagrams):

Writing IP Addresses #

IPv4 addresses are 32 bits, hence 4 bytes. It's conventional to write them in what's called "dotted quad" format, which consists of writing each byte value (from 0 to 255) separately, followed by a dot. For instance, 10.0.0.1 corresponds to the bytes 0x0a 0x00 0x00 0x01. Because IPv6 addresses are so much longer, writing them is unfortunately kind of a pain, and you end up with goofy stuff like 2607:f8b0:4002:c03::64 (for google.com) where the :: means that everything in between is a 0.

Each packet has a source and destination address, which are just numbers, and each device has its own address, which is how packets get sent (routed) to it and not to other devices. In the original version of the Internet Protocol (IP version 4 or just IPv4), these addresses were 32 bits long, which means that there are a total of 2³² (about 4 billion) possible addresses. There are rather more than 4 billion people on the planet and many of them have more than one device, so it's not actually possible for each device to have a unique address.

This problem has been known about for more than 30 years, and the the Internet Engineering Task Force (IETF), which maintains most of the main networking protocols on the Internet, has an official fix, which is for everyone to upgrade to a new version of IP called IP version 6 (IPv6). IPv6 has 128 bit addresses, which, at least theoretically, means that there are plenty of addresses. Unfortunately, for reasons which are far too long—and depressing—to fit into this post, the transition to IPv6 has not gone well, with the result that over 25 years after IPv6 was first specified, significantly less than half of the Internet traffic is IPv6. The graph below shows Google's measurements of the fraction of its traffic that is IPv6, reflecting client-side deployment. Server-side deployment is also fairly bad, with ISOC reporting that about 44% of the top 1000 sites support IPv6.

[Source: Google]

This is, needless to say, not good. As a comparison point, TLS 1.3 shipped in 2018 and at this point ISOC's numbers show 79% support among the top 1000 sites. At some level this is a slightly unfair comparison because transitioning to IPv6 means changing your network connection whereas transitioning to TLS 1.3 just requires updating your software, but in any case, we're nowhere near full IPv6 deployment, even though we no longer have enough IPv4 addresses. Actually, addresses have been scarce for quite some time, as shown in the timeline below:

[Source: Michael Bakni via Wikipedia]

IP addresses are centrally assigned, with the overall pool being managed by the Internet Assigned Numbers Authority (IANA) which provides them to Regional Internet Registries (RIRs), which then hand them out to network providers, on down to hosts.^[2] IANA allocated its last block to the RIRs back in 2010, but addresses were already starting to get scarce before then. As you can see on the chart above, an immediate transition to IPv6 in which we just turn off IPv4 is implausible today but was out of the question in the early 2000s back when deployment was effectively zero. Another technical solution was needed, one that would be incrementally deployable rather than simultaneously replacing big chunks of the Internet (technical term: forklift upgrade). And the Internet delivered in the form of NAT.

Network Address Translation (NAT) #

The basic idea behind NAT is simple: you can have multiple machines share the same address as long as there is a way to demultiplex (i.e., separate out) traffic associated with one machine from traffic associated with another. Fortunately, such a mechanism already existed: ports.

Port Numbers #

Consider the case where you just have two computers, a client and a server, but where there are two simultaneous users on the client. This feels like an odd situation in 2023 when basically all computers are individual, but all of this stuff was designed back in an era when multiple users timesharing on the same computer was the norm. If both users want to connect to the same server, they will have the same IP address, so how does the server tell them apart?

The answer is to have another field, the port number, which is is just a 16-bit integer that can be used to distinguish multiple contexts on the same device (IP address). Port numbers have two main uses:

on clients: to distinguish multiple similar processes connecting to the same server.
on servers: to distinguish multiple different services. Conventionally, services will have specific assigned port numbers, such as 80 for HTTP, 443 for HTTPS, etc.

Port numbers don't exist at the IP layer but rather at the TCP or UDP layers, but virtually all the traffic we'll be talking about uses UDP or TCP, so that's usually not an issue.

NAT #

Port numbers allow two users on the same machine to share an IP address. The intuition behind NAT is that you can use the same mechanism to allow two machines to share an IP address, as long as you can ensure that they won't also try to use the same port.^[3] The basic way to do this is by having the network gateway device (e.g., your WiFi router) do the work. The basic scenario is shown below:

In this example, Alice and Bob are both on the same network and have addresses 10.0.0.3 and 10.0.0.2 respectively. The WiFi router has two addresses, one on the inside which it uses to talk to Alice and Bob (10.0.0.1) and one on the outside which it uses to talk to machines on the Internet (192.0.2.1).

When Alice wants to talk to the server, she sends a packet from her IP address and uses local port 1111 (this is usually written 10.0.0.3:1111), as shown above. This packet gets sent to the WiFi router, which rewrites the source address and port to 192.0.2.1:1234 and sends it along to the server. When the server responds, it sends the packet to 192.0.2.1:1234 (this is the only address that it knows), which routes it back to the WiFi router. The router duly rewrites the destination address to 10.0.0.3:1111 and sends it to Alice. The story is the same for Bob (he even uses the same port number!) except that the packets he sends are from 192.0.2.1:5678. In order to make this work, the router needs to maintain a mapping table of which external ports correspond to which internal machines. Each entry in the table is called a "NAT binding" and associates the external address and port to the internal one.

From the server's perspective, this looks exactly the same as if there were a single machine with address 192.0.2.1 talking to it; NAT is just something that happens unilaterally on the client side. This is a very important feature because it enables incremental deployment. A network that can't get enough IP addresses can use NAT without any change on the servers. Perhaps less obviously, it doesn't require changing the clients either: they just use their ordinary IP addresses and the NAT translates them.^[4]

NAT isn't magic, of course, and it can't create IP addresses out of nowhere; what it does is stretch them by using the port number as an extension of the IPv4 address space. In fact, we used to joke about the IPv7 packet header, in which the IPv4 address fields were the "high order" bits of the address and the transport port fields were the "low order" bits:^[5]

It's still possible to run out of ports on the NAT device if it has enough clients behind it, but because the NAT can use the same port to talk to two different server at the same time (though this turns out to be bad news for reasons we'll get into below) and there are around 65000 possible ports, you need a lot of clients to want to concurrently talk to the same server before this becomes a problem. As a general matter, NATs will reuse ports once they are no longer active, so that NAT bindings aren't stable over time: port 1234 might be Alice now but Bob in 20 minutes.

As a practical matter, you don't usually use NAT for servers, at least not this way, though it's not technically impossible. In particular, HTTP(S) URIs have a port number field, so you can say (for instance) https://example.com:4444 to indicate that the client should use port 4444 but this just isn't common practice, partly because the result is ugly and partly because there are other mechanisms for sharing multiple servers on the same client, such as TLS Server Name Indication (SNI).

RFC 1918 Addresses #

Of course, even if they are behind a NAT, each client still needs its own IP address, so how does this help? The answer is that these addresses don't need to be globally unique but just locally unique within a given network. This means that the local address of a machine on your network might be the same as one on my network, but they get translated to different addresses on the public Internet.

The IETF has reserved a number of address blocks for "Private" usage in RFC 1918. These addresses are never supposed to appear on the public Internet and so it's safe to use them on your network, as long as you translate them to a routable address on the way out to the Internet. The example above uses addresses from one such address block: 10.0.0.0/8, which means "all the addresses with the 8-bit prefix 10, i.e., 10.0.0.0 to 10.255.255.255 inclusive. This block has around 16 million possible addresses in it, so you can have a very large network behind a NAT.

Maintaining NAT Bindings #

Internally, a NAT needs to keep a mapping table that stores the bindings between internal and external addresses. In the example above, you would have a table something like:

Internal Address	External Port
10.0.0.3:1111	1234
10.0.0.2:1111	5678

Note that the external address is constant, so we don't need it in the table. Some larger NAT systems (see carrier-grade nat below) have multiple external IP addresses, but we don't need to worry about that right now.

When the NAT receives a packet on the outgoing interface, it needs to do a table lookup. If a binding already exists for the packet, then the NAT just uses the entry in the table. If no binding exists, it creates a table entry with an unused port and forwards the packet. In this example, I've described what's called an "address-independent" NAT in which you have a single binding for a given local address/port combination, no matter what the remote address is. There are also "address-dependent" NATs, which use a different binding. This will become relevant when we talk about NAT traversal in Part II.

When the NAT receives an incoming packet on the external interface, it also does a table lookup. If a table entry exists, it forwards the packet as expected, but if no entry exists then there's no way of knowing which host the packet is intended for; the sensible thing to do in this case is to just drop the packet. The result of this is that most consumer NATs only really support flows in which the machine behind the NAT speaks first to initiate the flow. This is usually conceptualized as an "outgoing-only" set of semantics and corresponds well to TCP connections, in which the client sends the first packet (a SYN). Indeed, some NATs rely on the TCP SYN to create bindings, and will just drop mid-connection TCP packets that correspond to unknown flows. This doesn't work with UDP so you just have to look at the first outgoing packet, ignoring whatever markings it has.

This "outbound connections only" semantic is often viewed as a security feature because it means that even if you have devices behind the NAT that have "open TCP ports", meaning that they listen on those ports for connections, external attackers may not be able to connect to them. This kind of device is surprisingly common, especially for things like printers or scanners which you want to be accessible to anyone on the local network, so a NAT is really providing a valuable function here. However, it's important to realize that unlike a firewall, which is explicitly designed to block certain kinds of connections, many NATs just do this as a sort of accidental side effect of their architecture—although others do so explicitly, as we'll see later—so it's not a guaranteed property that you should rely on.

Binding Lifetimes #

This brings us to the obvious question of when the NAT should delete bindings. Cleaning up old bindings is an important function because otherwise the NAT would quickly use up its available port space. There are a number of ways to manage this:

Keep the binding open until the connection is torn down,: either by a TCP FIN or a TCP RST. This doesn't work with many UDP-based protocols, which either don't have messages indicating connection closing (such as RTP) or where those messages are encrypted (such as QUIC or DTLS 1.3). This method also isn't sufficient even for TCP, because the client might have shut down without sending a FIN, for instance if it crashed or the user put their laptop to sleep.
Use a timeout: and tear down connections which are idle for too long. This guarantees that eventually the resources will be released, because if the client shuts down, it won't be sending packets. However, "too long" is just a heuristic. Network protocols are often designed so that if there is no data flowing they don't send any packet (TCP is this way), in which case you may just be tearing down a connection right as the client was about to send something. More modern protocols incorporate "keepalive" packets to keep the NAT bindings open, but remember that the idea here is that a NAT should work with protocols that were designed before the NAT was deployed, so this is not an ideal solution.
Delete the least-recently-used connections: once some maximum number of connections is reached and a new one needs to be allocated. This has many of the same problems as the timeout but is a slight improvement in some respects because it doesn't delete old connections unless the table is full.

It's of course also possible to use more than one of these mechanisms at once. For instance, you might look at the TCP control packets to drop TCP connections but use timers as a backup for client shutdown and for other protocols.

Non-TCP/UDP Protocols #

Of course, TCP and UDP are not the only protocols which it is possible to run on the Internet. The IP datagram's "next protocol" field is an 8-bit value and only about half of these are assigned so in principle it's possible to introduce new protocols that run directly over IP. In practice, however, NATs make this extremely problematic because the port field is not in the IP header but rather in the header of the protocol that sits above IP (e.g., TCP or UDP), which means that the NAT needs protocol-specific logic for each new protocol.

A good example here is SCTP, a TCP-like protocol that introduces a number of new features like multiplexing on the same connection. SCTP was intended to run over IP, just like TCP, and SCTP's header actually has the source and destination ports in the same location as TCP and UDP, as shown below:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port Number        |     Destination Port Number   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Verification Tag                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Checksum                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Firewalls #

The situation is actually much worse than I'm making it out here, because network security devices like firewalls are often configured to reject any traffic that they don't understand. Even if a new protocol magically worked with NATs without modification, it would be blocked by many firewalls.

You might think, then, that a NAT which just always rewrote whatever bytes were in location for the source/destination port fields for UDP or TCP would work fine with SCTP, but that's not correct. It's true that it would rewrite the fields, but that would just create another problem, because the SCTP packet also includes a checksum (the last field in the header shown above) which is computed over the entire packet and is designed to detect any change to the packet, including the port numbers. This means that any NAT which rewrites the source and destination port also needs to rewrite the checksum, otherwise the checksum verification will fail at the receiver and the packet will be discarded.^[6] The SCTP checksum is in a different place than the TCP (or UDP checksum) and is computed using a different algorithm, so even if you just went ahead and used the TCP rewriting code—which isn't a good idea for other reasons—you'd just end up damaging some other part of the packet. The bottom line, then, is that it's not safe for NATs to just rewrite packets they don't understand (even though in some cases it might be safe), and instead NATs need to be modified in order to support each new protocol, which means that any such protocol starts out broken on a huge fraction of clients, making it very hard to get traction.

Fortunately there is a well-known solution to this problem, which is to run your new protocol over UDP. The UDP header is comparatively lightweight, consisting of 8 bytes, 4 of which are the host and port, which you'd need anyway. The other two are a two-byte length field, which you'd generally want and a kind of outdated checksum, which only takes up two bytes, so there's not that much overhead.

 0      7 8     15 16    23 24    31  
+--------+--------+--------+--------+ 
|     Source      |   Destination   | 
|      Port       |      Port       | 
+--------+--------+--------+--------+ 
|                 |                 | 
|     Length      |    Checksum     | 
+--------+--------+--------+--------+

If you run your protocol over UDP, then NATs will generally work mostly correctly—again with the caveat that the NAT doesn't know when a connection stops and starts—you start out from a position of things mostly working rather than them mostly failing (when QUIC was first rolled out, Google found that around 95% of connections succeeded.) Of course, 95% isn't 100%, and experience with new protocols such as QUIC and DTLS (with WebRTC) suggests that any new protocol will experience some blockage; in practice this means that you need to arrange some way to fall back to an older protocol such as HTTPS if your new UDP-based protocol fails. There are a number of possible approaches here, including trying both in parallel (a technique often called Happy Eyeballs), trying the new protocol first and seeing if it fails, or trying the old protocol first and then in the background trying the new protocol.

For this reason, the only really practical way to deploy new transport protocols on the Internet is over UDP,^[7] and this is what recent protocols such as QUIC (running directly over UDP) or WebRTC data channels (SCTP running over DTLS running over UDP) do.^[8] This principle was forcefully enunciated by voice over IP pioneer Jonathan Rosenberg (JDR) in an IETF session where someone was presenting a mechanism for running SCTP over NATs. JDR's response was something to the effect of:

There are some hard truths in the world and this is one of them. TCP and UDP are the new waist of the IP protocol stack.

In this context, "waist" refers to a famous analogy for the IP protocol suite illustrated by this image from a talk by IPv6 designer Steve Deering:

[Source: Steve Deering]

The idea is that IP can run on any kind of transport (radio, copper, whatever) and that you can run lots of protocols on top of it, but that IP is the common element hence the narrow "waist" of the hourglass. Rosenberg's point (which I agree with) is that this place is now occupied by UDP (and to a lesser extent TCP). Arguably, the situation is worse than this: it's so common to deploy new technologies over HTTP that I've seen arguments that HTTP is the new waist, but we're not there yet!

Application-Layer Gateways #

NAT works quite well for simple protocols which just consist of one connection (e.g., HTTP). However, there are some protocols which have a more complicated pattern. As an example, the File Transfer Protocol (FTP) is part of the original protocol suite and was widely used for downloading data prior to the dominance of the Web and HTTP. FTP had an unusual (to modern eyes) design which used two connections:

A control channel: which the client used to give instructions to the server.
A data channel: which was used to actually transmit data.

A download using FTP [edited from "UDP" — 2023-04-17] looks like the following:

The client would first connect to the FTP server and then issue instructions about what file to download. The server would then connect to the client (by default using the port number one lower than the one the client used, but the client can provide a port number) and send the file.

Of course, this won't necessarily work if you have a NAT, because the port number probably won't be right; even if the client uses the default, the NAT might not have two adjacent ports spare. Instead, the NAT would use what's called an application-layer gateway (ALG) and rewrite the client's request, like so:

An aggressive ALG #

Sometimes ALGs aren't so careful, however. The FTP ALG only works because the NAT knows about FTP, but what about unknown protocols? One possible implementation is to just pattern match by replacing any occurrence of the IP address (e.g., 10.0.0.1) or the IP address and port (e.g., 10.0.0.1:1111) with the NAT's address and port (and maybe even make a new NAT binding to go along with it.) This is a general mechanism but also a brittle one. In one hilarious case, Adam Roach (another VoIP pioneer) was trying to download a Linux disk image and kept getting checksum errors.

He eventually tracked it down by comparing the right image and the one he was getting and found a 4 byte difference, where the right value corresponded to his public IP address and the value he was getting was his internal address. What was happening was that the ALG in the NAT was just rewriting anything that looked like his external IP into his internal IP, regardless of where it was in the data stream. Not good!

Note that the NAT mostly doesn't interfere with the client's data: it just knows enough about FTP to know where the port number is, create the appropriate incoming NAT binding, and then replace it on the control channel. This of course won't work as well on unknown protocols and won't work at all on encrypted ones (in fact, any tampering with an encrypted protocol will generally just cause some kind of failure). At this point FTP is mostly gone (due to a combination of being insecure, being superseded by HTTP, at least in the case of Web browsers, concerns about the quality of the implementations), and newer protocols don't adopt this pattern because they want to work well with NATs. The reason that ALGs of this kind were needed was to avoid breaking existing protocols when NATs were first introduced, but now that NATs are widespread, the opposite dynamic is in play and new protocols have to avoid breaking when run over existing NATs.

Carrier-Grade NAT #

Initially, NATs were largely deployed at the boundary of consumer or enterprise networks (where they are now ubiquitous). However, as IP address space got more and more scarce, ISPs found themselves in the position where they were not able to get enough IP addresses for each customer to have one. The solution, of course, was to have a giant NAT (usually called carrier-grade nat (CGN) which multiplexes multiple subscribers onto the same IP address. Of course, the customer may still have their own NAT, so with CGN you can have multiple layers of NATting and address rewriting, which of course couldn't possibly go wrong.

In a CGN scenario, the addresses assigned to subscribers can either be from unroutable address space (either from RFC 1918 or from the new RFC 6598 block), or can be IPv6 addresses. In the latter case, subscribers would just have IPv6 addresses and the NAT would rewrite things to IPv4 on the way out the door, in a technique called NAT64. This scenario isn't as simple as with IPv4 because the network also needs to rewrite IPv4 addresses in DNS A records to IPv6 AAAA records (a technique called DNS64) so that the IPv6-only clients can send to them; this comes with its own problems, but that's a topic for another post.

The IETF and NAT #

For a long time, the IETF was basically in denial about NAT, for two major reasons:

Any packet rewriting (let alone ALGs) violates the end-to-end design of IP in which packets just go untouched from A to B.
It was seen as a technique to extend the lifetime of IPv4 when everyone should just be transitioning to IPv6 (sharpen the contradictions!)

The general attitude at the time was that standardizing NAT behavior would just encourage it and instead one ought to ignore NATs and hope they would go away, when the IPv6 rapture finally arrived. You can see this attitude as late as 2012, when RFC 6598 was published with the following statement:

A number of operators have expressed a need for the special-purpose IPv4 address allocation described by this document. During deliberations, the IETF community demonstrated very rough consensus in favor of the allocation.

While operational expedients, including the special-purpose address allocation described in this document, may help solve a short-term operational problem, the IESG and the IETF remain committed to the deployment of IPv6.

This all worked out about as well as you would think: NATs are everywhere and we still don't have anything like full deployment of IPv6. To make matters worse, in the absence of any guidance, NAT behavior became extremely variable and idiosyncratic, leading to ever more complicated workarounds. Eventually, in 2007, the IETF published RFC 4787 document describing how NATs ought to behave; by that time there were of course a huge number of NAT deployments which didn't follow these guidelines, though they're hopefully useful for developers of newer devices.

Final Thoughts #

NATs provide a particularly good example of the way the Internet evolves, which is to say workaround upon workaround. The reason for this is what Google engineer Adam Langley calls the "Iron law of the Internet", namely that the last person to touch anything gets blamed. The people who first built and deployed NATs had to avoid breaking existing deployed stuff, forcing them to build hacks like ALGs and unpredictable idle timeouts. Now that NATs are widely deployed, new protocols have to work in that environment, which forces them to run over UDP and to conform to the outgoing-only flow dynamics dictated by the NAT translation algorithms. Of course, there is a whole class of applications that don't fit well into that paradigm, in particular peer-to-peer applications like VoIP and gaming. In the next post we'll look at techniques to make those work anyway, even with existing NATs.

Yes, I know I still have two unfinished series, one on transport protocols and one on Web security. I got a bit distracted, and, in the case of the transport protocol series, a bit carried away with one of the posts, but I do plan to get back to them. I'm already partway through Part II, so I should have that up relatively soon. ↩︎
In theory IANA could just assign numbers directly, but this allows for regional governance. ↩︎
Technically this mechanism is known as "Network Address/Port Translation" (NAPT) but as this is the most common approach, NAT is the common term. ↩︎
I've omitted one detail, which is that you need to give the clients all new addresses from the RFC 1918 space, but in modern networks, the client addresses are centrally assigned by the local network, so this is typically straightforward. ↩︎
We actually had shirts made, with the front saying "32 + 16 > 128", with the joke being that the 32 bit address + 16 bit port of IPv4 was better than the 128-bit IPv6 address. Cafe Press seems to have lost the design though. ↩︎
At one point there was a draft to make SCTP work better with NATs, but it doesn't seem to have ever been standardized. ↩︎
A big reason to have a new transport protocol is to have your own rate limiting and reliability mechanisms, and that doesn't work if you run them over TCP, which has its own mechanisms. ↩︎
NATs aren't the only reason to deploy new protocols over UDP. It's also helpful that you can implement new UDP-based protocols entirely in application space rather than by modifying the operating system. ↩︎

Architectural options for messaging interoperability

2023-03-10T00:00:00Z

As I mentioned in some previous posts, the EU Digital Markets Act (DMA) requires interoperability for number independent interpersonal communications services (NICS), which is to say stuff like messaging (what we used to call "Instant Messaging") as well as real-time media (voice and video calling). Specifically Article 7 says that:

2.   The gatekeeper shall make at least the following basic
     functionalities referred to in paragraph 1 interoperable where
     the gatekeeper itself provides those functionalities to its own
     end users:

(a) following the listing in the designation decision pursuant to Article 3(9):
    (i) end-to-end text messaging between two individual end users;
    (ii) sharing of images, voice messages, videos and other attached
    files in end to end communication between two individual end
    users;

(b) within 2 years from the designation:
    (i) end-to-end text messaging within groups of individual end
    users;
   (ii) sharing of images, voice messages, videos and other attached
   files in end-to-end communication between a group chat and an
   individual end user;

(c) within 4 years from the designation:
   (i) end-to-end voice calls between two individual end users;
   (ii) end-to-end video calls between two individual end users;
   (iii) end-to-end voice calls between a group chat and an individual
        end user;
   (iv) end-to-end video calls between a group chat and an individual
        end user.

The European Commission (specifically the Directorate General for Communication (DG COMM)) has been holding a series of workshops on how to structure the compliance requirements for the DMA. Last week, I attended the workshop on messaging interoperability to serve on a panel along with Paul Rösler (FAU Erlangen-Nürnberg), Stephen Hurley (Meta), Alissa Cooper (Cisco), and Matthew Hodgson (Element/Matrix). (video here; my presentation starts at 13:24:10; slides here). Nominally the panel was about the impact of end-to-end encryption on interoperability (see here for some earlier thoughts on this), but in the event it turned into more of an overall discussion of the broader technical aspects.

The rest of this post expands some on my thinking in this area. Note that while I work for Mozilla, these are my opinions, not theirs.

Overview of Technical Options #

At a high level, there are three main technical options for providing this kind of interoperability, in ascending order of flexibility for the competitor product:

Gatekeeper-provided libraries.: The gatekeeper provides a software library (ideally in source code form, but perhaps not) which implements their interfaces. The competitor builds their app using that library and doesn't have to know—and maybe doesn't get to see—any details of those interfaces.^[1]
Gatekeeper-specified interfaces.: The gatekeeper publishes a set of interfaces (Web APIs, protocols, etc.) that competitors can use to talk to its system. The competitor implements those APIs themselves—or maybe someone writes an open source library to implement them—and talks to the gatekeeper's system that way.
Common protocols.: The gatekeeper implements interfaces based on some common—preferably standardized—protocol. The competitor implements that protocol and uses it to talk to the gatekeeper.

We'll take a look at each of these options below.

Requirements Scope #

The big question lurking in the background of the entire workshop was the scope of the requirement that the EC would levy on gatekeepers. I'm not a legal expert, but the above quoted text seems to require that the gatekeepers make this functionality available but not dictate any particular means of doing so. In particular, they might opt to just publish some libraries or specifications that anyone who wants to interoperate with them must conform to (the EU technical term here is "reference offer"). The Commission would then be responsible for ensuring that this reference offer was compliant, which is to say that:

It provides the required functionality.
It is sufficiently complete to implement from.

For reasons that will occupy most of the rest of this post, this is not really an ideal state of affairs, and it would be easier for competitors (technical term "access seekers") if there were some single set of interfaces (protocols) that every gatekeeper. However, the tone of the workshop is that the Commission is not eager to require a single set of standards at this stage and that there's some question about exactly what the DMA empowers them to require in this area. For the purposes of this post, I'm going to put that question aside and focus on the technical situation as I see it.

Interoperability is Hard #

The first thing to realize is that interoperability is really difficult to achieve, even when people are trying hard. The basic problem is that protocol specifications tend to be fairly complicated and it is difficult to write one that is sufficiently precise and complete that two people (or groups) can independently construct implementations that interoperate. In fact, some standards development organizations require demonstration that every feature has two independent implementations that can interoperate in order to advance to a specific maturity level (in IETF, "Internet Standard", though as a practical matter, even many widely deployed and interoperable protocols never get this far, just because it's a hassle to advance them). Part of the process of refining the protocol is finding places where the specification is ambiguous and modifying the specification to clarify them.

Over the past 10 years or so, I've been heavily involved in the standardization and interop testing of at least three major protocols (and a number of smaller ones):

In each case, we discovered issues with just about every implementation, in many cases leading to interoperability failure.

A full description of how interop testing works is outside the scope of this post, but at a high level each implementor sets up their own endpoint and you try to make them communicate; in most cases this will initially be unsuccessful. If you're lucky, one of the implementations will emit some kind of error, but sometimes it just won't work (e.g., you just get a deadlock with neither side sending anything). What you do next depends on precisely what went wrong. As an example, if a message from implementation A elicited an error from implementation B, then you look at the message and the error it generated and try to determine if the message was correct (in which case it's B's fault), if it was incorrect (in which case it's A's fault), or if the specification is ambiguous (in which case it needs to be updated). Once the implementors have decided on the correct behavior, then one (or sometimes both!) of them change their implementations, and you rerun the test, hopefully getting a little further before things break. This process repeats with increasingly more difficult scenarios until everything works.

There are several important points to remember here:

The specification is frequently unclear; even when there is a best reading, it's often not entirely obvious.
Even when the specification is clear, implementors make mistakes, leading to interoperability problems.
Interop testing is a high-bandwidth process that requires close collaboration between implementors. In particular, it's vital to be able to understand what the other implementation didn't like about what your implementation did, rather than just knowing that it didn't work.

This last point is especially important: if you just send a message to the other side and get an error, then you're left scrutinizing your code over and over to see if you did something wrong, even when it turns out the problem is on the other side.

When I was working on WebRTC and trying to get interoperability between Firefox and Chrome, I spent quite a few days in Google conference rooms with Justin Uberti, the tech lead for Chrome's WebRTC implementation, doing just what I described above. It also helped that both Firefox and Chrome were open source, so we were able to look at each other's code and figure out what must be happening. Getting this to work would have been approximately impossible if all I had had was a copy of Chrome and no insight into what was happening internally, or if we hadn't been right next to each other. This problem is especially acute for cryptographic protocols, where any error tends to lead to some sort of opaque failure such as "couldn't decrypt" or "signature didn't validate". If you can't see the intermediate computational values (e.g., the keys or the inputs to the encryption), you're back to trying to guess what you did wrong (and good luck if it's the other side!).

More recently, the IETF has developed something of a system for this (thanks to Nick Sullivan from Cloudflare for kicking this process), starting with TLS 1.3 and now with QUIC. Basically, everyone gets in the same room (to the extent possible) and stands up their implementation and other people try to talk to it.^[2] There's a lot of back-and-forth of the form of "Hey, I'm getting error X when I talk to your implementation, can you take a look". The end result of this is an interoperability matrix showing which implementations can talk to each other and with which tests. For instance, here's the interop matrix for one of the later QUIC drafts:

Each cell is a single client/server pair, with the client down the left and the server across the right. The letters indicate which tests worked, with the color indicating how well things are going, the darker the better.

This is all an enormous amount of work, and it's important to remember that this is a best-case scenario in that the people writing the specification are trying very hard to make it as clear as possible and generally the implementors are trying to be helpful to each other. The situation with messaging is quite different: the gatekeepers could have provided interoperable interfaces at any time but chose not to. Instead, they're just being required to provide them by the DMA, so their incentive to make it work is comparatively low. Moreover, they may not even have their own internal documentation; in my experience it's quite common for engineering organizations to just embody their interfaces in code with minimal documentation which is insufficient to implement from.

The first 10% is often easy #

It's often relatively easy to get things to sort of work in simple configurations (what is sometimes called the "happy path"). For instance, the first real public demonstration of WebRTC interop between Chrome and Firefox was in early 2012, at a point where it just barely worked and needed handholding from Justin and myself. Firefox didn't work with Google Meet until 2018, which required changes on both sides. A particular issue was around multiple streams of audio and video (see here for background on the "plan wars of 2013").

In a similar vein, during the workshop Matthew Hodgson showed a demo of Matrix interoperating with WhatsApp via a local gateway,^[3] which serves as a good demonstration that interop is possible, but but as he mentioned himself, shouldn't lead anyone to conclude this is a trivial problem. Sending messaging back in forth is probably the easiest part of this problem, it's all of the details (group messaging, media, ...) that will be the hard part to get right and are also essential to it being ready for real users.

It gets better #

Note that the scenario I'm talking about here is mostly what happens with early protocol development and deployment. Once there are widespread open source implementations that are fairly conformant, you can just test against those implementations and debug them directly when you have a problem; of course, that's not likely to be the case for messaging interoperability, at least initially, and especially if the gatekeepers just publish their specs without any reference implementation.

The surface area is enormous #

The number of different protocols that need to be implemented in order to build a complete messaging system along with voice and video calling is extremely large. At minimum you need something like the following:

Messaging
- A protocol for end-to-end key establishment (e.g., MLS, OTR, Signal)
- The format for the messages themselves (e.g., MIME)
- A transport protocol for the messages (e.g., XMPP)
Voice and video. Everything above plus
- Media format negotiation (e.g., SDP)
- NAT traversal (e.g., ICE) if you want peer-to-peer media
- Media transport (e.g., RTP/SRTP)
- Voice and video codecs (e.g., Opus, AV1, H.264, etc.)

Every one of the things I've named above is a very significant piece of technology, often running to hundreds if not thousands of pages of specifications.^[4]

As a concrete example, let's look at WebRTC. At the time WebRTC was being designed, there was an existing ecosystem of standards-based voice and video over IP that used Session Initiation Protocol (SIP) for signaling and RTP/SRTP for media. Those protocols were in wide use but often not on an interoperable basis. Although many of the people who designed WebRTC had also been involved in building that ecosystem, there was also a feeling that many of those protocols were due for revision, so there was a fair amount of updating/modification. By the time the overarching protocol specification document JavaScript Session Establishment Protocol (JSEP) was published in 2021, the set of relevant documents had grown to 10s of RFCs running to thousands of pages. Moreover, these RFCs themselves depended on other previously published RFCs defining stuff like audio and video codecs (for instance, the specification for the mandatory to implement Opus audio codec is 326 pages long, though at least part of that is a reference implementation).

Of course, these are specifications for general purpose systems and so you could almost certainly build a single system that had less complexity. For instance, a lot of the complexity in WebRTC is around media negotiation: suppose that one side wants to send two streams of video and one stream of audio, but the other side only wants to receive one stream of video. An interoperable system needs to specify what happens in this case, but if you have a closed system you can just arrange that your software never gets itself into that state. There are quite a few other cases like this where you can get away with a lot less in a closed environment, but even then there will still be quite a bit of complexity.

At the same time, it's increasingly possible for small teams to quickly build quite functional voice and video calling systems. This apparent contradiction is explained by realizing that there are widely available software libraries (for instance, the somewhat confusingly named WebRTC library) that implement most of these specifications and provide an API that hides most of the details. The result is that as long as you're willing to take whatever that library implements, it's possible to build a functional system, but you're pulling in the transitive closure of all the specifications it depends on. The same thing is true for other protocols such as TLS, XMPP, Matrix, etc.

The key point to take home here is that actually having interoperability between the gatekeepers and competitive products requires nailing down an enormous number of details, even if those details are hidden behind software libraries. To the extent to which this uses the existing interfaces and protocols, then this is a somewhat more straightforward problem, but if a gatekeeper has built a largely proprietary system from the ground up, then the effort of specifying it in enough detail that someone else can build their own interoperable implementation—not to mention the effort of building that implementation—is likely to be very considerable.

It has to be implemented on the client #

If you want to have end-to-end encryption of the communications, then this means that much of the complexity has to be implemented on the client. Specifically:

You need to have end-to-end key establishment so the key establishment protocol needs to run on the client.
Text messages are encrypted and so they need to be constructed on the sender's client software and decrypted on the receiver's.
Similarly, audio and video need to be encoded and decoded on the client.

This is different from (for instance) e-mail, which is typically not end-to-end encrypted, or non-E2E videoconferencing systems, in that you can centrally transcode the media. For instance, if Alice can only send audio with the Opus codec and Bob can only receive with G.711, then the central system can transcode it, but if the data is end-to-end encrypted, that's not possible (the whole point of end-to-end encryption is that the central system can't modify the content). Instead, you need to ensure that every client has the necessary capabilities. It is possible to implement some of the system on the server. For instance, because the transport is generally not end-to-end encrypted (though it should be encrypted between client and server), you might be able to gateway transports between systems, such as if you want to connect an XMPP client to a system that isn't natively XMPP.

Gatekeeper Libraries #

Technically, gatekeepers don't need to actually publish their interfaces to achieve interoperability. Instead, they could just build a software library that implements their system. The idea here is that if I build EKRMessage and I want it to talk to WhatsApp, I just download their library and build it into EKRMessage. There will be some set of functions that I need to call (e.g., sendMessageTo() to send a message) to implement the interoperability.

The obvious advantage of this design is that it hides^[5] lot of complexity from the new implementor: the gatekeeper doesn't need to document the details of any of their protocols in the kind of excruciating detail I mentioned above; they just build that into their software. Of course now they have to document the library, but that's usually a lot easier (after all, this is why people use libraries). This kind of library can be a huge force multiplier: as I mentioned above, the existence of Google's WebRTC library has made it much easier for people to build powerful A/V apps. However, if every gatekeeper has their own library, this is a lot less attractive, as Alissa Cooper from Cisco pointed out in her workshop presentation. To just briefly sketch a few of the problems with this approach:

Code bloat. Each competitor application will need to build in a copy of every gatekeeper's library, which is extremely inefficient. As an example, the WebRTC.org library is over 800K lines of code. Imagine that times 5.
Code architecture. Each library is going to have its own particular API style, which is going to make architecting your app different. As a concrete example, consider what happens if one library is asynchronous and event-driven and another is synchronous and uses threads. Building an app that uses both cleanly is going to be architecturally difficult (typically you end up trying to force fit one control flow discipline into the other).
Portability. If the gatekeeper provides their library in binary (compiled) form, then it will only be usable on the specific platforms the gatekeeper builds it for. Even if they provide source code, that often will not work on one platform or another without work (portable code is hard!). Of course, someone could port the library, but if they aren't able to upstream them to the gatekeeper's source, then the porting work needs to be repeated whenever the gatekeeper makes changes. In addition to questions of platform, we also have to think about questions of language: if the library is written in Java and I want to write my application in Rust, I'm going to have a bad day.
Dependency. The competitor's application is dependent on the gatekeeper's engineering team, with little ability to fix defects—and all software has defects—and mostly has to wait for the gatekeeper to do it. This is true even if the library is nominally open source, because it's a huge amount of effort to find and fix problems in other people's code. Additionally, whenever the gatekeeper changes their library, you just need to update, even when it's a big change.
Security. The competitor is taking on the union of all the vulnerabilities in each library they bring in. This creates problems whenever a defect is found because every competitor needs to upgrade (this is always a problem with vulnerabilities in libraries, of course, which is one reason why people try to minimize rather than maximize their dependencies). Effectively, the security of the competitor's app becomes that of the weakest of the gatekeepers they interoperate with, which is obviously bad.

All of these problems of course exist any time you take a dependency on another project, which is why engineers are careful about doing it. However, in most of those cases the provider of the dependency wants you to use their code—you may even be paying them—and so is motivated to help. That's not really the case here. The bottom line is that I think this is a pretty bad approach, so I'm not going to spend much more time on it in this post.

Common versus Gatekeeper-Specific Interfaces/Protocols #

The big question here is whether gatekeepers will use (or be required to use) a common set of protocols/interfaces or whether they would be able to just dictate their own interfaces that anyone who wanted to interoperate with them would have to use. Often this was phrased as whether the gatekeepers would be required to implement "standards", but "standards" can mean anything from "this is what everyone does" to "this is ratified by the International Telecommunications Union (ITU)", so I'm not sure how helpful that term really is. The key question is whether everyone is going to do more or less the same thing or whether connecting to each gatekeeper will require doing something new. As I said above, I think this has some obvious technical advantages.

Implementor Complexity #

The biggest advantage of a common set of protocols/interfaces is that it makes life much easier for access seekers/competitors. If you need to build to entirely different interfaces for each gatekeeper, it's going to be a lot of work to add a new gatekeeper, which obviously doesn't promote interoperability on the broad scale, and is likely to lead to lower service quality because you have to spread your effort out across all the implementations. Alissa Cooper had a great slide showing what this looks like, where every competitor has a little—or actually not so little—copy of every gatekeeper's system in their app:

This model, where an app speaks a bunch of different protocols but tries to present a unified user interface (what Matthew Hodgson was calling a "polyglot app") used to be reasonably common back in the early days of instance messaging, where there were multiple open (XMPP, IRC) or semi-open (AIM), messaging systems. This means we know it's possible but we also know it's a lot of work. By contrast, with a single set of protocols/interfaces each app only has to have a single implementation that it can use everywhere and can focus on making it really good.

Clearer Specifications #

As described above, one big barrier to interoperability is lack of clear specifications. It's just incredibly hard to write an unambiguous document, and it's even harder when you're documenting some pre-existing piece of softwarethat never really had a written specification—as is most likely the case for many of the systems in this space—it's just way too easy to implicitly import assumptions about how your system actually behaves without clearly documenting them.

Standards development organizations like IETF and W3C have gotten a lot better at this over the years and have developed a set of practices that contribute to specification clarity. These include:

Early implementation and interop testing.
Automated test harnesses, both for interoperability and for conformance (e.g., WPT).
Widespread review using code collaboration tools (e.g., Github) that make it easy for people to report small issues.
Formal review and analysis for the most security critical pieces (for instance, TLS 1.3 had at least 9 separate papers published on its security before it was published).

These practices aren't a panacea, of course, and many IETF and W3C specs are still impenetrable, but in my experience the ones where the community really agreed they were important (TLS, QUIC, etc.) are reasonably clear. The main idea here is about getting as many eyes on the problem and from as many different perspectives as possible. This is only possible in an environment of collaboration across many organizations and it's hard to see how it will work when gatekeepers just publish specifications and throw them over the wall to competitors.

Developer Experience #

As discussed above, much of the experience of developing a protocol implementation is trying to interpret the specifications and figure out why your implementation is misbehaving. This is obviously much easier if there are open source implementations and a community of other implementors you can work with. If instead we're going to have gatekeeper published interfaces, then the gatekeepers will need to provide quite a bit of support to developers who want to talk to their systems. At minimum, this looks something like:

Detailed specifications: that really are complete enough to implement, ideally including example protocol traces and "test vectors" for the cryptographic pieces.
Public test servers: that developers can talk to. These need to be separate from production servers because testing in production is too dangerous. Moreover, they need to have a much higher level of visibility (at minimum very detailed logs) so that developers can see what is going wrong.
Live support: from engineers who understand how things are implemented and can help with debugging when log inspection fails.
Stable interfaces: that remain live once published, so that developers aren't constantly having to update their code.

Without this level of support it's going to be extremely difficult for competitors to make their code work in any reasonable period of time, let along update them as the gatekeeper makes changes.

Deployment Issues with Multiple Gatekeepers #

Most of the scenarios people seem to be considering involve one or more competitors interoperating with a single gatekeeper, e.g., Wire and Matrix talking to WhatsApp. This is a good first step and it's of course not straightforward, but it's really playing on easy mode, because the competitors have a real incentive to do whatever it takes to interoperate with any gatekeeper. What happens when someone on gatekeeper A wants to talk to gatekeeper B? If everyone just publishes their own protocols, then one of the gatekeepers has to implement the other side's version. It's not clear to me that this is required by the DMA. And if it is required, who will have to do it?

This issue is particularly acute in group message contexts. As a number of panelists mentioned, group messaging is now the norm and 1-1 is just a special case of a small group. Once you have large groups, you have the possibility of a group which involves more than one gatekeeper. Consider the case shown in the diagram below:

In this example, Alice and Charlie are on iMessage and WhatsApp respectively. Bob is on EKRMessage and is able to individually communicate with them because that client implements those interfaces. As noted above, this is inconvenient, but will work.

Now what happens when Bob wants to create a chat with Alice and Charlie? He can send and receive messages to each of them individually, but if neither WhatsApp nor iMessage implements compatible interfaces, then when Alice or Charlie sends a message, the other side can't receive it. Importantly, unlike the simple 1-1 case between gatekeepers, this looks to Bob like a defect in his messaging system, not like noncooperation by the gatekeepers. There's not much that Bob's client can do about it: it could presumably decrypt the messages and reencrypt them, but this destroys end-to-end identity, which is undesirable.

The point here is that in order to have interoperable messaging work well in group contexts, basically everyone has to implement the protocols of anyone who might be in the group.^[6] This will sort of work if there are a pile of protocols, but obviously it would be a lot easier and cheaper if instead everyone implemented something common.

Having a common protocol is even more important in videoconferencing situations: video tends to take up a lot of bandwidth and sending an individual copy of the media to each receiver can easily overrun consumer Internet links. Instead, large conferences typically use what's called a "star" configuration in which each endpoint sends one copy of the video to a central server (a media conferencing unit (MCU)) which then retransmits it to each receiver. But if a group with N gatekeepers means that I need to send in N different formats, then this will be dramatically less efficient. However, this is even true to some extent for messaging: the new IETF Messaging Layer Security (MLS) protocol was designed to work well in large groups, but won't work as well if you have to do pairwise associations.

Identity #

Identity presents a special problem for reasons I've discussed previously. Those posts have more detail, but briefly each endpoint needs to be able to discover and verify the identity of every other endpoint. As with everything else, this can be done either with a common protocol or with pairwise implementations of gatekeeper protocols. However, the situation is more complicated here because many messaging systems use overlapping namespaces.

In particular, it's quite common to use phone numbers (E.164 numbers) as identifiers, as (for instance) both iMessage and WhatsApp do. This raises a number of questions:

When someone from iMessage sends a message to someone from WhatsApp, how does their identity appear?
How do messaging apps know which service to use when given a bare E.164 number?
What happens if someone has an account on two phone-number using services.

There are several possible approaches to addressing these issues (as discussed in the above-linked posts) but we're going to need to have some kind of answer, and if each system is left to solve it itself, there is likely to be a lot of confusion.

I did want to call out one particular risk: it's natural—at least to some—to want this to be as seamless as possible, for instance by using phone number identifiers and automatically identifying the right service to use, but this increases the attack surface area so that multiple providers can assert a given identity. There are potential ways to mitigate this (see previously), but they would actually need to be specified and deployed. This is also an area where it would be advantageous to have a single solution everyone agreed on, both because it's hard to get this right, and because it would make it easier to address questions of who owned which identity.

Timeline #

One of the big concerns that I've seen raised about having a system based on common protocols is that the DMA sets a very ambitious timeline and that standards can take a long time to develop. There certainly is some truth in this, but the good news is that many of the pieces we need already exist (indeed, we often have several alternatives):

Function	Protocols
End-to-end key establishment	MLS, OTR, Signal (and variants)
Identity	X.509, Verifiable Credentials, OIDC
Messaging format	MIME, Matrix
Message transport	XMPP, Matrix
Media format negotiation	SDP
NAT Traversal	ICE
Media Transport	SRTP
Voice encoding	G.711, Opus
Video encoding	VP8, AV1

Some of these pieces are in better shape than others—I'd really prefer not to use SDP if I can avoid it!—and they don't all fit together cleanly, so it's not just a simple matter of mixing and matching, but it's also not like we're starting from scratch either. Moreover, the pieces that are earliest in the timeline are also the ones that are the best understood.

My sense is that the best way to proceed is to have what might be called a hybrid approach: use standardized components where they exist and temporarily fill in the gaps with proprietary interfaces specified by the gatekeepers while working to develop standardized versions of those functions. Once those versions exist, then we can gradually replace the proprietary pieces. The highest priority here should be getting to common formats for the key establishment and everything inside the encryption envelope (messages, voice, video), because those are the pieces where incompatibility causes the biggest deployment problems, as discussed above; fortunately, these are also some of the most baked pieces and—at least in the case of voice and video—where I expect there is a lot of commonality just because there are only a few good codecs.

I do think it's true that it's probably easier to get to some level of interoperability—especially at the demo level—by just having gatekeepers publish interfaces, but it's a long way from something to real reliable interoperability (we learned this the hard way with WebRTC), and there's going to be a long period of refining those interfaces and the corresponding documentation. That's time that could be spent building out common protocols instead, with a much better final result.

Final Thoughts #

Having multiple non-interoperable siloes is clearly far from ideal and it's exciting to see efforts like the DMA to do something about that. We know it's possible to build interoperable messaging systems and we've got multiple worked examples going back as far as the public switched telephone network and e-mail. Even WebRTC is partially interoperable in the sense that multiple browsers can communicate on the same service but not on different services. To a great extent our current situation is due to a particular set of incentives for gatekeepers not to interoperate; the way to get out of that hole is to give them the incentives to build something truly interoperable.

Some current bridging systems actually rely on the user having a copy of the gatekeeper's app on the local system and remote control that app. This doesn't seem like a very good solution for reasons which should be obvious. ↩︎
For client/server protocols, people will often stand up a cloud server endpoint. For extra credit, you can have an endpoint which will publish connection logs so that the other side can see your internal view on what happened. ↩︎
I don't think that local gatewaying is a good technical design because it requires terminating the encryption from the gateway in the local server and then re-encrypting it to the user's client, which destroys a lot of information, such as end-to-end identity. This can be a useful prototyping technique, but I don't think it's a great way to build a production system. ↩︎
Though the IETF's practice of using 72-column monospaced ASCII does make things longer. ↩︎
In the "information hiding" sense of avoiding the consumer having to think about it, rather than keeping it secret, though of course they might also want to keep the details secret. ↩︎
Technically you can get away with less than a full mesh, by having some kind of tiebreaker for each pair, but it's going to be fairly close to a full mesh. ↩︎

Network-based Web blocking techniques (and evading them)

2023-02-09T00:00:00Z

Via Joseph Lorenzo Hall, Patrick Breyer, and EDRI, I see that the EU's Internet Filtering requirements (sometimes called "chat control") are continuing to move forward. The legal language is a bit hard to wade through, but it appears to require Internet Service Provider (ISPs) to block specific content on Web sites, identified by URL.

Article 16 lays out the scope of blocking order:

The competent authority shall also have the power to issue a blocking order requiring a provider of internet access services under the jurisdiction of that Member State to take reasonable measures to prevent users from accessing known child sexual abuse material indicated by all uniform resource locators on the list of uniform resource locators included in the database of indicators, in accordance with Article 44(2), point (b) and provided by the EU Centre

And then Article 18 lays out requirements for user notification and redress:

Where a provider prevents users from accessing the uniform resource locators pursuant to a blocking order issued in accordance with Article 17, it shall take reasonable measures to inform the users of the following:

(a) the fact that it does so pursuant to a blocking order;

(b) the reasons for doing so, providing, upon request, a copy of the blocking order;

(c) the users’ right of judicial redress referred to in paragraph 1, their rights to submit complaints to the provider through the mechanism referred to in paragraph 3 and to the Coordinating Authority in accordance with Article 34, as well as their right to submit the requests referred to in paragraph 5

Unfortunately, as EDRI observes, this kind of filtering is not really technically practical in today's Web. In this post I talk about the technologies which are used for Web filtering, as well as some of the privacy and security technologies which make that sort of blocking harder. This post is intended to be self-contained, but you might find previous posts on tracking and browser privacy features (tracking and blocking are closely related) and IP concealment useful background.

Get EG in your mailbox #

If you like what you're reading here, you can, as they say "smash that subscribe button" to get the newsletter version delivered right to your mailbox.

Threat Model #

In many security situations there's pretty broad consensus on who is the attacker (e.g., the person trying to steal your credit card number), and who is the defender (the person who doesn't want their credit card stolen), and traditionally in the design of security protocols we think of the network as the attacker and the job of the protocol to be to defend you against the network. However, in this situation, the entities trying to block certain content usually think of themselves as the defenders, either because they are trying to block content which is illegal (such as Child Sexual Abuse Material (CSAM)) or because they want to control the use of their own network (e.g., to protect it against malware-infected machines or to stop their employees from exfiltrating company secrets in what's called Data Leak Prevention (DLP)), and the endpoint trying to evade filtering as the attacker.

Debates in this area tend to quickly devolve into questions about the legitimacy of various kinds of blocking and how sympathetic participants are to them. In my experience such debates don't usually get very far and I don't propose to engage with them here;^[1] the purpose of this post is just to lay out the technical situation of that is and is not possible given the current and anticipated future state of the Web.

Note that it's not always the case that the interests of the user and the interests of the blocker are opposed. For instance, consider the case where the network wants to block access to sites which host frauds or malware: the user presumably doesn't want to download malware, and so would potentially benefit from the network preventing access. intended to protect the user from fraud and malware. However, these technologies are value neutral: the same mechanisms that might allow the network to block access to CSAM or malware also allow it to block access to Facebook or to Google search; the same goes for technologies for evading blocking.

Endpoint Status #

The most common and familiar situation is when the endpoint isn't really trying to evade blocking but also isn't actively cooperating with it, as is the case with most consumer devices. The software on the device usually implements some set of default protections (e.g., HTTPS), as discussed below, but they're ones that are suitable for full-time use, rather than fancy ones that would be expensive, inconvenient, or slow. They might also contain some filtering mechanisms, though usually ones that the vendor has judged users will want (e.g., Safe Browsing) and in many cases these can be disabled:

Another quite common case is one in which the device is managed, for instance, one used by employees of a company but which actually belongs to the company and where the company controls the software on the device (e.g., via Mobile Device Management (MDM). For obvious reasons, it's much easier for the network to control the behavior of managed devices. Most consumer devices are of course unmanaged; this didn't always used to be true for mobile devices, where it was common for carriers to install various kinds of software before selling them, but Apple's direct sales, their insistence on a standard software load, and the subsequent changes in industry practice mean that in many of not most cases smartphones are not meaningfully under control of the carriers. Many work devices are managed, but not all; of particular concern to many enterprises is what's called bring your own device (BYOD), in which people use their own devices for work purposes; unsurprisingly, employees are often unwilling to allow their employers to control the software on these devices and so in many cases they will be unmanaged.

On the other side of the spectrum, we have endpoints which are deliberately trying to avoid monitoring. This could be something the user wants, for instance because they are in a jurisdiction that restricts Internet access and are using something like a VPN or Tor. It could also be because there is malware on their machines. In many cases, that malware will want to talk to its command-and-control (CNC) servers. However, this software only needs to be able to talk some prearranged set of servers and thus doesn't need to speak standard protocols—though it might impersonate them!—and might share secret information with those servers. This makes evasion easier.

Blocking Techniques #

The difficult part of blocking traffic isn't really the blocking itself but rather knowing what traffic to block. It's fairly straightforward to just disconnect the Internet, but that makes the network useless. What you want is selective blocking in which you block only the traffic of interest and allow the rest of the traffic to pass through (conversely, many anti-blocking techniques are designed to degrade the visibility necessary for selective blocking, thus forcing the network into a position of blocking all traffic or none of it). There are a number of ways to get the information of what content the endpoint is trying to access.

DNS-Based Blocking #

One very common place to do blocking is at the DNS layer (see my series on DNS for background here). DNS-based blocking is very technically straightforward because the client directly asks the DNS server for the contact information (IP address) of the Web server it's trying to contact, so it's easy to add a filtering step. Moreover, there are a number of DNS providers (e.g., Umbrella/OpenDNS or Cloudflare) which offer filtered DNS servers. Umbrella will even let you configure which sites you want blocked. The DNS server has a number of options if a blocked domain is requested, including returning an error to the client or returning a bogus IP address which can then be blocked; in either case, the client will not be able to contact the ultimate server.

Network-imposed DNS-based filtering works because the network typically provides the DNS server used by endpoints (notifying them about it via DHCP). However, it's also possible for users to configure their devices to use a different server or for endpoint software to do its own resolution via a non-network resolvers. For instance, it's quite common for people to configure their devices to use Google Public DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1),^[2] and Firefox is increasingly using DNS over HTTPS in a mode which bypasses the local resolver in favor of a "trusted recursive resolver" that has agreed to comply with Mozilla's policy requirements around user security and privacy. Obviously, malware can do the same.^[3]

Historically, if the user just pointed their device at a public resolver, the network could still do DNS filtering by intercepting the communication to the resolver. However, if DNS traffic is encrypted to the server, that prevents this kind of filtering. Ultimately, if networks want to enforce DNS-based filtering in these circumstances, they need to prevent connections to the public DNS resolvers, which, given that they run DNS over HTTPS, brings us back to the same problem of blocking Web traffic, at least for unmanaged endpoints; for managed endpoints, it's generally possible to just disable encrypted DNS; in fact Firefox does this automatically if it thinks the endpoint is managed.

Even where DNS-based blocking is effective, it's a fairly limited mechanism. Specifically:

It can only block on domain name and not URI.^[4] For instance, if you want to block https://example.com/contraband and not https://example.com/totally-cool, that's not possible because the browser just asks for the address of example.com.
It usually can't provide any notification to the user of what happened; the server can just make it look like the name doesn't exist or the server isn't offline. It's of course possible to provide the address of a server controlled by the network, but if the client is trying to connect via HTTPS, then this will result in a connection failure (more on this later), not a comprehensible message to the user.

On this second point, I've seen proposals for allowing the server to send back a more detailed error message telling the endpoint that a site was blocked, for instance.

  {
  "c": ["tel:+358-555-1234567", "sips:bob@bobphone.example.com",
        "https://ticket.example.com?d=example.org&t=1650560748"],
    "j": "malware present for 23 days",
    "s": 1,
    "o": "example.net Filtering Service"
  }

This is in theory possible, but there are several obstacles that prevent unilateral deployment by ISPs or enterprise networks. First, no existing Web client supports this new message, so at present they will just show a failure as described above. Second, if the browser uses the operating system resolver (as, for instance, Firefox does when it's not using DoH; Chromium uses its own resolver), then it will only be able to get this message once the operating system is updated to support it, which is likely to take a very long time. Finally, the browser would need to figure out some way to present the information so that it's clear what's happening and that it can't be used to fool the user into accepting the error message as coming from the valid site ("please enter your social security number here!"); this problem is presumably soluble if there is enough interest otherwise.

IP Filtering #

If you're not doing DNS-based filtering, your next opportunity to filter is at the IP layer. IP-layer filtering is exactly what you think it is: the network blocks connections to certain IP addresses. There are a number of possible alternatives here (drop the packets, send a TCP RST, BGP poisoning) but they all amount to the same basic idea, which is to render certain IP addresses inaccessible. Unlike DNS-based filtering, it's not straightforward for clients to just opt out of IP-based filtering: the network has to be able to see the server's IP address to deliver the packets, so if you want to bypass it, you need to get a new network.

Ignoring the Great Firewall #

In general, once the network has identified your connection for blocking, that's it but in at least one case, this was easy to avoid. China famously uses a blocking system often called the Great Firewall, which operated in part by sending TCP RSTs when it detected things it didn't like. This is cheaper technically than blocking all the packets. Some time back, Clayton, Murdoch, and Watson discovered that clients could just ignore the TCP RSTs, in which case the traffic would continue to flow. I don't know if this is still true.

On the other hand, IP-based filtering is even less precise than DNS-based filtering. Obviously, it can't see the specific resource you are connecting to, but it can't even always tell which Website is being accessed: it's very common for multiple Web sites to share the same IP address (for instance, every Github Pages site seems to have the same IP, as does every Substack that has an address ending in substack.com), and so you can't IP block one site without blocking others. Even in situations where there isn't IP sharing, but where many sites share the same hosting provider, the hosting provider can readily change which IP addresses correspond to which sites, making it hard for the blocker to keep up. Thus, IP blocking is good for blocking access to big sites which don't share infrastructure, such as Google or Facebook, but not so good for smaller sites.

Like DNS-based filtering, IP-based filtering isn't able to provide any feedback to the user about what went wrong: it just looks like a network failure. Unlike DNS-based filtering, I haven't even seen credible proposals for how to add such a function and most of the obvious avenues seem fairly unattractive to browser makers.

Content Analysis #

The next major approach is to inspect the application layer traffic (e.g., HTTP or TLS), and filter based on that. This is a very powerful technique when applied to HTTP because it allows you to see all of the data being exchanged, including the URL being requested and all of the content being returned, so you can do some fairly fancy filtering. For instance, you could not only check the URI but scan the returned content for malware or CSAM.

However, this sort of filtering is increasingly impractical because the vast majority of Web traffic is now encrypted, as shown in the figure below:

[Source: Let's Encrypt]

When the traffic is encrypted, the network can't see the content of the HTTP connection, which means it can't see either the URL or the response—this is the point of encryption!—so the amount of filtering possible is quite limited.

The main piece of information that the network can see is the hostname of the Web server. This is carried in two places in the TLS handshake:

In the Server Name Indication (SNI) field of the client's first message (the ClientHello). (This is the field that allows you to have multiple servers on the same IP).
In the server's Certificate message, although this may not be unique, as a server may have a certificate that covers multiple sites. For instance, there is a single "wildcard" certificate for *.github.io that works for any site ending in .github.io.

In TLS 1.3, the server's Certificate message is encrypted, which means that the only information about the server's identity available to the network is in the SNI in the ClientHello. You shouldn't be surprised to hear that there is now work underway to encrypt the ClientHello message to conceal the SNI, using a technology called (surprise!) Encrypted Client Hello (ECH). ECH hasn't been widely deployed yet, but it's under active development by browser vendors and some server operators, such as Cloudflare. If ECH is in use, then the network will not be able to use TLS to distinguish between any of the servers on the same IP address, reducing the filtering granularity to that of IP blocking.

Browsers and MITM Proxies #

MITM proxies are a difficult problem for browsers: generally you want to allow users to add their own trust anchors to permit so-called "Enterprise CAs" in which the enterprise has its own private names that it issues certificates for but it doesn't want to have publically accessible. This is still somewhat common, though arguably less necessary in the era of free certificates. However, it would be possible for browsers to detect and prevent the use of these enterprise CAs for any site which also had a public certificate, thus more or less preventing MITM proxies from working. However, the consequence of this would be to break the browser on any network which had such a proxy, which is obviously not a desirable outcome. The result is that we're in a not-great equilibrium that is hard to get out of without causing a lot of breakage.

MITM/Intercepting Proxies #

Many enterprise networks use what's called a "man-in-the-middle" or "intercepting" proxy. This is a network device which sits in between the client and the server, impersonating the server to the client and the client to the server. It decrypts the traffic between client and server, inspects it, and then re-encrypts it. "But wait" I can hear you say. "Isn't the whole point of TLS to prevent this kind of attack?!" Ordinarily yes, but the organizations who deploy these proxies also install their own trust anchors on the client, which allow the proxy to issue certificates which are acceptable to the client.

Obviously, this doesn't work in consumer settings where the network doesn't control the client. Of course, one could imagine a nation requiring users to adopt a new trust anchor, enabling them to intercept any connection, but this obviously has extraordinary risks in terms of surveillance. In the one case where a country went as far as trying it (Kazakhstan), browsers responded by explicitly blocking the trust anchor, so you couldn't install it.

Even in an enterprise, MITM proxies aren't really a great system: they're expensive to operate and because they have access to the plaintext of the connection, present a security and privacy risk to users of the system. There is also evidence that the implementation quality of these proxies is less good than that of browsers, which creates additional risks.

In order to address some of these issues, enterprises will sometimes (often?) configure their proxy to selectively decrypt traffic. The idea here is that the proxy looks at the SNI field and only decrypts traffic so some destinations (e.g., Facebook but not your bank). These enterprises (and the vendors who sell these devices) are worried about ECH because it has the potential to make this sort of selective decryption impossible. I don't believe that this is likely to be a problem in practice, however: if you are able to install your own trust anchor, you should also be able to configure the browser to disable ECH. Moreover, ECH information is delivered over DNS, so as long as you can control DNS (or, in the case of Firefox, disable DoH, which happens automatically when it detects a new trust anchor) you can just suppress the use of ECH.

I did want to flag one point here about this kind of selective decryption, which is that it only works if you are dealing with an endpoint which is standards compliant and sends the correct SNI value. If you are dealing with malware, it can put whatever it wants (e.g., www.bankofamerica.com in the SNI) but then connect to its own CNC server. Selective decryption based on SNI only works with clients which aren't themselves malicious, like Web browsers. This is true whether or not the client is using ECH. Note that this form of evasion only works because of prearrangement between the malware and the CNC server, so it's not deployable as a general mechanism for Web browsers.

Traffic Analysis #

In principle it's possible to learn about the content of on encrypted traffic by looking at packet size, timing, etc. For instance, the traffic pattern associated with watching video (a lot of big packets sent continuously to the client) looks very different from that associated with using Webmail (small, relatively intermittent, chunks back and forth). This approach is often called "traffic analysis". Goldberg, Wang, and Wood provide a good overview of the situation for website identification, and Cisco actually sells technology for doing this (academic paper by Anderson and McGrew here) that tries to identify malware.

My understanding of the current state of traffic analysis is somewhat powerful as an attack on privacy: you certainly can learn more about people's browsing behavior than people might want you to learn, and is useful as part of an enterprise threat response system that attempts to detect malicious behavior, but is less useful at distinguishing precise behavior (e.g., which exact images did someone view on a specific site). It's also comparatively expensive to operate technically, doesn't scale that well, and requires seeing more behavior over a longer period than other techniques (e.g., SNI), which can make a decision very early in the connection. Thus, my sense is that it's less useful for making large scale content-based decisions for things like CSAM detection or DLP.

Client-Side Agents #

It's also possible to install a piece of software (an "agent") on the endpoint itself that monitors that behavior of the device. These agents sit into a variety of different and somewhat overlapping categories (anti-virus, DLP, endpoint detection and response (EDR), etc.) but basically they all do the same kind of thing, which is to say spy on other programs and report back or otherwise act on behavior it thinks is suspicious. These agents typically have elevated privileges and so can in some cases observe the internal details of other programs, for instance, by actually injecting their own code (this is a persistent problem for browser vendors because it can negatively impact the stability of the product). For instance, this would allow the agent to see the plaintext associated with encrypted traffic, including the URI, the content, etc.

In some cases, this software is something that users install themselves (e.g., antivirus), but in others it's something that is required by their employers, schools, etc. In the latter case, it may be deployed in parallel with network monitoring techniques to provide multiple views of the same activity. For instance, you might have a client-side agent but also do MITM interception This approach provides defense in depth: if you have such an agent on your work computer, the natural way to avoid monitoring is to use an unmonitored personal device. Network-level monitoring can help detect this, even if it can't see precisely what's happening, though it's obviously far less powerful in an age of ubiquitous fast mobile Internet: people can just turn off the WiFi and bypass your monitoring.

In general, if you have a third party monitoring agent installed on your computer, it's safest to assume it can do anything at all on that device (Microsoft's "Immutable Law of Security #1"). In particular, if you have an agent on your computer that is operated by someone else, the safest assumption is that they have complete control of your computer. In some cases, these organizations will have policies about (for instance), what data they look at, but that doesn't mean that there is any technical enforcement mechanism that prevents them from violating those policies. The few times I've actually looked at this I came to the conclusion that there weren't any meaningful technical controls; it's possible someone has built something safer in this space, but given the current state of computer security it's a very difficult problem.^[5]

Client-side agents are a popular technique in enterprise settings, but actually requiring their installation on everyone's non-work devices seems like it would be a major policy change, and I don't think it's likely that the EU would require it (at least I hope not!).

VPNs, Proxies, etc. #

As should be clear from the above, in the absence of cooperation from the endpoint, the network only has fairly limited abilities to selectively block traffic. More or less all it can do is to block specific sites, but not control what content people access on those sites. As technologies like encrypted DNS and ECH become more common, even that level of blocking will start to become more difficult. It will still be possible to block large sites which have their own IP space (e.g., Facebook or Google), but it will be harder to block just one site hosted by a given service, such as one Github pages account or a single site hosted by a CDN.

Encrypted DNS and ECH are designed to be "always on" technologies which people can just use for their regular browsing; this means that the protection they can offer is limited. However, it is also possible to provide a higher level of protection at greater cost by proxying traffic to another network which is not subject to blocking/filtering. This is what technologies like VPNs, Tor, and iCloud Private Relay do (see here for an overview of these techniques). The only really feasible way to prevent people from bypassing blocking using these mechanisms is to block access to the proxy/relay/VPN service entirely, which you would typically do by the same kind of mechanisms I've been discussing above. I've also seen some research designs for making that kind of blocking more difficult (e.g., Telex), but that's out of scope for this post.

What is technically feasible #

With this technical background, we can now look at the EU proposal. Assuming I am reading it correctly (and EDRI reads it the same way), it seems to have two requirements that are technically problematic.

First, as noted above, it's not really possible to block based on a list of specific Uniform Resource Locators, but only on sites. It's not clear to me how useful this really is: if there are specific sites which are just acting as hosts for CSAM, then there are a number of potential avenues for having them shut down directly, rather than filtering at the customer level (this happens fairly often with sites which engage in various kinds of copyright and trademark abuse). The primary reason why URL blocking is useful is that it allows you to selectively block part of a site—though here too it's not quite clear to me why the authorities can't have that content taken down once they are aware of it—but as noted above, that kind of selective blocking is simply not practical to do at the network level once traffic is encrypted.

For similar reasons, it's also not really possible to provide notice to users as required in Article 18 because there's no channel for the provider to do so. In most cases the client will be trying to establish an encrypted channel to the server. The network can instead reroute that connection to its own servers, but those servers cannot properly authenticate as the server, so all they can manage to do is cause the browser to show the user an error, but can't control the error. Depending on exactly what the provider does, it might look like this:

or like this:

But what it definitely will not have is some message from the provider about why the site is being blocked; there's simply no mechanism to communicate that. It's presumably possible to invent something here, but it's not something that the providers can do unilaterally.

Final Thoughts #

This brings us to the broader point, which is that the network providers are simply the wrong place to situate this kind of blocking. A basic assumption of communications security is that the network is under control of the attacker and 30+ years of work has gone into protecting Internet traffic from potentially hostile networks. This work isn't done, but there's been a huge amount of progress and at this point it's really not practical to do effective fine-grained blocking of traffic without the cooperation or coercion of one of the endpoints.

This is also why I am using the term "blocking" instead of the common term "censorship", which while technically accurate in my opinion, tends to just get us into debates about the definition of "censorship" from those who think that certain forms of blocking are good and that the term "censorship" has negative connotations. ↩︎
However, data from Huston and Damas indicates that most of the use of the big public resolvers is due to ISPs pointing their users to them, rather than users configuring it themselves. ↩︎
The public debate about the use of DoH and DoT has sort of conflated use by browsers with use by malware. The problem with malware use of encrypted DNS exists because there are public DNS servers which offer encrypted service, independently of whether browsers use it. To the extent to which browsers make the problem worse it's because their use of those servers makes it less attractive to just block them entirely. ↩︎
I once explored a design where the DNS server would send the client a list of blocklisted URIs on the requested domain, but this of course requires the client to cooperate, so it's more like Safe Browsing than like a unilateral blocking mechanism. ↩︎
The basic problem here is that if you don't trust the system you are monitoring to behave correctly, then you need access to its internals to be sure that it's not lying to you about its behavior. But that access is inherently abusable. ↩︎

Internet Transport Protocols, Part I: Reliable Transports

2023-01-18T00:00:00Z

Most people who use the Internet just have some vague idea that it carries data from point A to point B (famously, through a series of tubes). Even people who regularly work on Internet systems tend to work with it through many layers of abstraction, without a clear understanding of the infrastructure components that make it work. This post is the first of a series about one such piece of infrastructure: the transport protocols such as TCP that are used to transmit between nodes on the Internet.

Background: Network Programming #

If you've done any programming of networked systems, you've probably written code that looks something like this:

socket = connect("example.com", 8080);
write(socket, "Hello");       
response = read(socket);
print(response);

Even if you don't have much experience with networking, this code should be fairly self explanatory:

The first line forms a "connection" to the server named "example.com" (see my series on DNS) for how these names work. 8080 is what's called "port number" and we can ignore it for now. This function returns an object called a "socket" which represents that connection.^[1] Conceptually, this is like dialing the phone and calling "example.com".
The next line writes the string "Hello" to the server. Note that because we already are connected to the server, we can just pass in the socket, rather than the address of the server.
The next two lines reads the response from the socket and then print it out. As before, we don't need to specify the server's address because that's encapsulated in the socket.

As another example, here's a simple server that works with this client. This server just takes whatever the client writes to it and sends it back in upper case. The main difference here is that instead of using connect(), the server uses accept() which tells the computer to wait for a client to connect to it on port 8080.

socket = accept(8080);
loop {
  result = read(socket);
  print(result);
  write(socket, result.toUpperCase);
}

If we run this client/server pair, we would expect the server to print:

Hello

And the client to print:

HELLO

Of course, the client could write multiple messages, like so:

socket = connect("10.0.0.1", 8080);
write(socket, "At midnight all the agents"); 
write(socket, "And the superhuman crew");
write(socket, "Come out and round up everyone");
write(socket, "Who knows more than they do");
...

In this case, we would expect all of the messages to be delivered and that they will be delivered in order, so that the server prints:

At midnight all the agents
And the superhuman crew
Come out and round up everyone
That knows more than they do

Rather than

And the superhuman crew
That knows more than they do

And the superhuman crew
Come out and round up everyone
At midnight all the agents
That knows more than they do

Again, just like a phone call.

What we're seeing here is just the programming interface, though, which is to say it's a set of abstractions that the operating system and the programming language provide to you to write your programs. They don't tell us anything about what's actually happening on the network. That's the subject of this post.

Background: A Packet Switching Network #

The Internet is what is known as a packet switching network. What this means is that the basic unit of the Internet is a self-contained object called an Internet Protocol (IP) packet or datagram. An IP packet is like a letter in that it has a source address and a destination address. This means that when you send an IP packet on the network, the Internet can automatically route the packet to the destination address by looking at the packet with no other state about either computer. A simplified IP packet looks like this:

The main thing in the packet is the actual data to be delivered from the source to the destination, also called the payload. The payload is variable length with a maximum typically around 1500 bytes. Using IP is very simple: your computer transmits an IP packet and the Internet uses the destination address to figure out where to route it. When someone wants to transmit to you, they do the same thing. Importantly, for reasons we'll see shortly, packet switching is unreliable: when you send a packet to the other end it might or might not get there ("packet loss"). Moreover, packets don't always arrive in the order they were sent ("reordering").

Circuit Switching #

The alternative to packet switching is what's called "circuit switching". In a circuit switched network, the basic unit of operation is a connection between two endpoints called "circuit". In a circuit switched system, you set up the circuit and then just start sending and everything goes to the entity on the other end of the circuit, like in a telephone call (more on phones later).

In the original telephone network, this was actually a literal electrical circuit:^[2] phone service came into your house on a pair of copper wires and when Alice wanted to call Bob, the central office would connect Alice's wires to Bob's wires (there's some more electronics here, but you can ignore this). Originally this was done by having an actual person at a switchboard, which is just a board with a bunch of jacks corresponding to each outgoing circuit from the central office. When Alice wanted to call Bob, she would ring up the operator and tell them who she wanted to call. The operator would plug a patch cable from Alice's jack into Bob's jack, like so:

When the first automatic switches were invented (an amazing story), they worked much the same way: you'd pick up your phone and dial and the equipment at the exchange would connect your wires to the wires of the person you were trying to call. From then on, signals just went from your microphone to their speaker and then their ears and vice versa. Circuit switching is conceptually convenient but has a number of inconvenient properties. In the simplest version, it doesn't allow you to talk to more than one person at once (the second caller gets a busy signal!) and even if you arrange to connect more than one person as in a conference call, you have no way of distinguishing who is who (ever had to ask who was talking?). But of course in a modern computer network your computer is constantly talking to multiple computers at once ("multiplexing"). This works badly with circuit switching but just fine with packet switching because each packet is self-identifying.

The problem with packets #

Packet switching has a number of nice properties, but small self-contained packets are very limiting for the obvious reason that most things that people want to send are more than 1500 bytes, whether they be videos, phone calls, or large files; even Web pages are almost always more than 1500 bytes. Moreover, because packet switching is unreliable and packets might get lost or delivered in the opposite order from the order they were transmitted in, if you just break up your file into a set of packets and send them over the network, the other side may not receive exactly what you sent.

In other words, what we really want is circuit switching, but what we have is packet switching. If you know any computer people, you've probably guessed what I'm going to say next because it's the standard thing to do: we're going to emulate circuits on top of packet switching to build what's often called a reliable transport protocol. What a reliable transport protocol does is provide a service that looks like a circuit (usually called a "connection") but built on top of the unreliable substrate of packet switching. Designing these protocols so they work well turns out to be very substantial undertaking and we've been basically evolving them for the past 40+ years, starting with TCP, which has been used from the early days of the Internet, is one such protocol and more recently with a newer protocol called QUIC, which is built on similar but more modern lines.

The world's simplest reliable transport #

The obvious thing to do here would just be to break up whatever data you want to send into a series of packets and send them to the other side. However, as should be clear from the above, this won't work reliably, because the packets might be lost or reordered, preventing the receiver from reconstructing the data. Thus the minimal set of problems we need to solve is:

Allowing the receiver to reconstruct the order that the data was sent in, even if the network reorders it.
Ensuring that data is eventually delivered from the sender to the receiver.

We'll take these one at a time, reordering first.

Reordering #

The reordering problem is fairly easy to solve: we just add a field to each packet which contains its number. The receiver just sorts the packets as they are received, and delivers them to the application once it has all previous packets. So, for instance, if the receiver receives packets in order 1 3 2 4 then it will behave like so:

Packet	Action
1	Deliver 1
3	Store 3
2	Deliver 2, Deliver 3
4	Deliver 4

This is actually not how TCP works, however. Instead, it numbers not packets but bytes. Specifically, each TCP segment (i.e., packet) comes with a sequence number which indicates the first byte in the packet, and a length, which indicates the last byte of the packet. This allows the sender to re-frame data when it retransmits it. For instance, suppose that a TCP connection is carrying typed characters: you want it to send each character as soon as it is typed, so each will be in its own packet, but if you need to retransmit a set of consecutive characters, it's more efficient to put them in their own packet. This only works if the packets contain an indication of which byte is which. For the purposes of this post, however, we'll think of packets as being fixed size and assume there's no reframing.

Packet Loss #

There are a number of reasons that packets can be lost in transmission. For instance, some network element could malfunction and drop them or damage them, or, as we'll see later, an element could explicitly drop them because they exceed available capacity. In either case, if a packet is dropped, the only thing for the sender to do is retransmit it, but how does it know whether to do so? In other words, how do we detect packet loss? One potential approach would be for the malfunctioning element to send some kind of signal indicating that it dropped or damaged the packet. But of course that signal itself might be dropped or damaged by the network. Additionally, the problem might be in a passive element such as a piece of wire which isn't able to send its own messages. Finally, if the problem is a malfunctioning element, then it might malfunction in such a way that it doesn't correctly send a message. In any case, no mechanism where the sender receives a message informing it of a lost packet will work reliably.

The end-to-end principle #

This is a case of what's called the end-to-end principle. The basic observation is that there are a lot of places for things to wrong between point A and point B, and so if you want to ensure that a piece of data arrives at point B, then trusting intermediate elements isn't enough; you need A and B to work together. This doesn't mean that you can't have reliability mechanisms between intermediate elements, but merely that they're not sufficient to guarantee delivery all the way to the other end. Rather, they act as an optimization that allows you to detect failures more quickly than they would have been detected by an end-to-end mechanism.

Instead of having a signal that a packet was dropped, we're going to instead have a signal that the packet was received, called an acknowledgments (often abbreviated ACK). When the receiver receives a packet, it sends an acknowledgment of receipt. This tells the sender that the packet got all the way to the receiver. Of course, acknowledgments have a number of obvious drawbacks:

They only tell you when a packet was received, not that it was lost, so the only way you know a packet was lost is by waiting until you expected to see an acknowledgment and then not getting one.
The acknowledgment can get lost in transit, so the packet might have been delivered, but this still looks like packet loss.

The reason to use acknowledgments is that they are robust: no matter what is going on in the middle of the network, if the acknowledgment is received, you know the packet got through. If you just keep sending until you get an acknowledgment, eventually the packet should get through (unless of course, the network is totally broken).

The way this works is that after the sender sends a packet it waits for a period of time (see below for how long) for the corresponding acknowledgment. If the timer expires before the sender receives the acknowledgment, then it retransmits the packet, like so:

In this diagram, the sender sends the first packet, which arrives successfully, and is acknowledged. However, the second packet gets lost in transmission. Eventually, the sender's timer expires and so it retransmits packet 2. This time it gets through and so does the acknowledgment, so everything is good.

In the simplest version of this protocol, the sender sends one packet at a time. Once that packet is acknowledged (potentially after one or more retransmissions), then the sender sends the next packet. This is what is called a stop-and-wait protocol, because the sender doesn't do anything until it hears from the receiver. The basic problem with this design is that it's slow. The reason for this is round-trip latency: the diagram above shows packets as being sent and received at the same time, but in practice they take some time to get from point A to point B: even on a very fast Internet connection, it can take a few milliseconds for a packet to get delivered, and if the server is around the world, latency can be on the order of a 100 milliseconds. If the sender is waiting for the receiver's acknowledgment, then it's just idle during this period, as you can see in the diagram below, where the sender has to wait for a full round trip before it can send the next packet.

The obvious thing for the client to do is just to send data as soon as it's available but this has two big problems:

The sender may be able to transmit the data faster than the receiver wants to consume it. Think about the case of streaming video: the sender could send the whole video to the receiver but this would be really inefficient because the receiver would have to store it all until it was ready to play, and the viewer might decide to only watch part of it.^[3] Even in cases where the user wants to receive the whole file, their device might not be able to process the incoming data as fast as the sender can transmit it.
The network might not be able to handle the data at the rate the sender can send it. This happens frequently in cases where the sending device is attached to a very fast local network but the end-to-end connection to the receiver is slower. As we saw before, this eventually will overwhelm the slowest network link in between the two endpoints.

We'll deal with the first problem in this post and the second problem in the next post.

Flow Control #

In order to prevent the sender from over-running the receiver, we need a flow control mechanism. The standard approach is for the receiver to advertise the total amount of data it is willing to receive at once (see buffering). The technical term here is the "receive window". The sender can send as many packets as it wants as long as they fit within the window, as shown in the diagram below.

In this diagram, the sender starts out by assuming the receiver's window is 1, so it sends a single packet. The receiver acknowledges this packet with the message ACK (1, window=4), which means "I have received all packets up to 1 and you can send up to packet 3" (this is called a "cumulative ACK"). The sender responds by sending packets 2 through 4, and then waits for the receiver's ACK. However, in the time that packet 3 is in flight, the receiver has received packet 2 and so it sends an ACK acknowledging it and advancing the window to packet 5. This isn't received until after the sender has send packet 4, but it is receives shortly thereafter, allowing the sender to send packet 5.^[4]

This mechanism is usually called "sliding windows", with the idea being that the window of data the sender can send is continuously sliding forwards as ACKs are received. In this example, the sender still has to wait briefly before it can send packet 5, but if the window had been slightly larger, then it might have been able to send continuously, with the ACK advancing the window being received before the sender was ready to send its next packet. This is especially true if the sender isn't sending as fast as its network will support, for instance if it's sending data that depends on user input.

Buffering #

At this point, you may have noticed that there's a lot of waiting here. For instance:

The sender can't transmit until it has room in the window.
Once the sender transmits, it has to wait until it receives an acknowledgment, because it might have been lost or damaged.
If the receiver receives packets out of order it has to wait to deliver the packets to the application until it has received the ones before them.
If the sender transmits packets faster than the receiving application, the receiving operating system needs to store the packets until the application is ready.

During these waiting periods, it's necessary to store (technical term: buffer) a copy of the packet. For instance, when the program asks the operating system to write something, but there's no available window, the operating system just buffers the packet until window is available. Moreover, during this period the system may be trying to send more packets, which it may or not be able to send immediately. For instance, if an application tries to upload a file, it may send 10 or more packets at once, which the sending system needs to slowly meter out as window becomes available. The sender needs a significantly-sized buffer to store these packets. Similarly, when a packet has been received out of order, it needs to be buffered until the earlier packets are available.

This isn't the only place that buffering happen: not all links on the Internet are the same speed, so it's common to have a situation in which network A wants to send faster than network B can send. In this case, the computer connecting those networks (a router) has to buffer the packets until space becomes available (often this is called a queue). In addition, the user's devices need input buffers where they store packets that have come in but the operating system or application has not yet had time to handle.

In general, all devices on the Internet have some level of buffering to deal with mismatches between the rate at which it receives packets and the rate at which it can handle them, whether that means processing them locally or forwarding them to some other device. Buffering allows these devices to deal with situations where the incoming rate temporarily exceeds the processing rate (which happens all the time) but the longer it goes on, the more packets have to be stored. Most devices maintain a maximum buffer size—if nothing else, limited by the total amount of memory on the device, but typically far less than that—and when that size is reached, then they have to drop packets; either by discarding some of the packets already buffered or by discarding the new packets (or both).

Retransmit Timers #

I've been handwaving a bunch about how the sender sets a timer and waits for the acknowledgment, but that doesn't tell us how long the timer should be. In general, we want the timer to be based on the round-trip time (RTT) between the sender and receiver, which is to say the time it takes a packet to go from sender to receiver, the receiver to respond, and the respond to make it back. If we set the timer shorter than the RTT, then the ACK won't make it in time and the sender will retransmit even if packets aren't lost; if we set it much longer, then we're waiting too long to declare packets lost, which slows down the connection. In practice, you want the retransmit timer to be somewhat longer than the RTT because there's some variation in network speeds, etc., but not too much longer. There's a long literature on how to set the retransmit timer, which I won't go into here.

There's just one problem: we don't know the round trip time, because it's not a property that the sender can see directly. Instead it's a function of the speed of all the network links in between the sender and receiver. Even if I have a fast network, I might be connecting to someone with a slow network. It also depends on how heavily loaded they are at any given moment, because I'm competing for network capacity with other users, which means that it can change over time. Worse yet, RTTs can vary dramatically: the RTT from my house in Palo Alto to the nearest Cloudflare server is about 10ms. The best-case RTT from Australia to the US is around 150ms (300,000 km/s is not just a good idea, it's the law). If you pick a single value for your retransmit timer, you're going to have seriously suboptimal performance on many networks.

The way that transport protocols handle this is to measure the round trip time during the connection by looking at how long it takes the other side to send an ACK. For instance, if you sent packet 10 at T=2000ms and you get an ACK for it at T=2050ms, then the estimated RTT is 50ms. Each time you get an ACK, you update the RTT estimate. The typical approach is to maintain a smoothed estimate (effectively a weighted moving average) of the recent measurements to average out the noise in each individual measurement while also favoring more recent measurements. Of course, you don't have any measurements at the time you start transmitting, so the typical approach is to use a somewhat conservative starting point (QUIC uses 333/ms), but obviously if the path between you and the other side has a low RTT, you want to update that as soon as possible.

Set-Up And Tear-down #

So far I've just covered the steady-state case where the sender is already magically communicating with the receiver, but in practice, but how do we get into this state, and how do we stop?

Set-up #

In most transport protocols, there's some kind of initial setup handshake before data is transmitted. For instance, here's what TCP's handshake looks like:

As I said above, TCP doesn't number packets, but instead labels each byte with a sequence number. So, what's going on here is that the client sends an empty SYN (for synchronize) packet with sequence number 1234. The server acknowledges it with its own SYN packet with sequence number 8765), and if it wants can send data to the client at this point (though this isn't the usual thing). Upon receiving the server's SYN, the client can also send traffic, starting with sequence number 1235. In the same packet, it acknowledges the server's SYN. Why is this necessary, though? Why not just start sending? And why not just start the sequence number at 1 (or, as C programmers would expect, at 0)?

The problem here is that it's possible for there to be two separate connections between client and server. Suppose, for instance, that a client initiates a connection and sends some data over it, and then ends it and starts a new connection, as in the diagram below.

If a packet from connection 1 is delayed on the network for a long period of time, it may be received by the server after connection 2 starts and accepted as part of that connection. Disaster! The way TCP handles this is by having the new connection start with a sequence number which is intended not to overlap with valid sequence numbers from the previous connection. Sequence number selection is actually a somewhat complicated topic that I won't get into here, The 3-way handshake is needed to ensure that the client and the server agree on the initial sequence numbers for the connection. Otherwise, you could have a situation where the server was acting based on a delayed SYN from a previous connection, leading to problems (I'll spare you the details of the pathological cases).

The problem with the 3-way handshake in TCP^[5] is that the client has to absorb a full round trip before it can send anything, which is a real performance cost. This wasn't really seen as a big deal when TCP was first designed, but as Internet speeds have increased generally and latency has become a big deal, it's become much more important. It's possible to send data on the first packet as long as you can guarantee that the server can distinguish this connection from others. For instance, QUIC does this by having the client choose a long (minimum 64 bits) random connection ID value, which distinguishes this connection from all other connections (I'm simplifying here, as the QUIC connection ID logic is also quite complicated), thus allowing the server to know that this is a new connection and not a replay. There's still a setup handshake, but the client and server are able to send during it, which saves round trips. I plan to cover the complexities of getting this right later, but wanted to mention it here for context.

Tear-Down #

What happens when the endpoints are finished communicating? In principle, they can just stop sending, but then what? The problem here is that both sides have to keep state: in order to be able to process Alice's packets, Bob needs to remember the last packet she processed so that she knows whether a received packet is a replay (to be discarded) or new data (to be processed). This takes up memory and eventually Bob is going to want to clean up. But how does Bob know when Alice is really done and so it's safe to clean up versus Alice just went quiet for a while?

The obvious thing to do here is to have an in-band signal that says that the connection is closing. This signal would itself be acknowledged, so it would be delivered reliably. This is what TCP does, but experience with newer protocols such as QUIC has shown that this is not always the best approach. This is another topic I plan to cover in a future post.

Common Themes #

Aside from the technical details, you should be noticing a few high level themes.

First, the design of these protocols doesn't really depend on any information about the internals of the network. It could be built out of copper wire, optical fiber, microwave links, two tin cans and a string, or all of the above. Similarly, you don't need to know how fast any individual link is, how big the buffers are in the routers along the path, etc. From the perspective of the transport protocol, the Internet is just this opaque system where you put packets in one side and they come out the other end. So, when we measure the RTT, for instance, we're just measuring the aggregate RTT of the system as a whole.

Second, none of this needs any cooperation from the elements in the middle. This means that (1) it's robust against any technical changes in the network and (2) you can make changes to the transport protocol without first having to change those elements. These are key properties for deployability: the Internet takes a really long time to evolve, and if we needed to change every element between point A and point B before we could use a new transport protocol on that path, we'd be waiting a very long time.

Finally, we constantly have to think about what happens if the network misbehaves in some way, for instance by dropping our packets or delivering them way out of order. A properly designed transport protocol has to be robust to all reasonable kinds of network misbehavior—the bar for what this means has gone up over the years to include active attack—and operate properly, or at least fail safely. This is just the price of trying to build a reliable system out of unreliable components.

Next Up: Congestion Management #

What we have so far is basically a simplified version of what TCP was like in 1986, when the Internet link between Lawrence Berkeley Labs (LBL) and UC Berkeley (about 400 yards apart) abruptly suffered what's come to be known as "congestion collapse", in which flaws in the TCP retransmission algorithms caused the effective throughput of the link to drop by a factor of about 1000. In the next post, I'll be talking about congestion collapse and how to avoid it.

The term sockets goes back to the original BSD sockets programming interface which was commonly used on early Internet systems and is now nearly universal. ↩︎
Ironically, in the modern phone network, it's fairly likely that we're carrying the data over some packet-based transport, very often IP. ↩︎
Yes, I know that in practice it's common to actually download smaller chunks of the video. ↩︎
Note that it's usual not to acknowledge ACKs, otherwise you get into a situation where the sides are just ping-ponging ACKs at each other. ↩︎
TCP does have a new mode called TCP Fast Open which allows sending immediately, but this is comparatively modern and there are a number of deployment challenges. ↩︎

Surprise, blockchains won't fix Internet voting

2023-01-09T00:00:00Z

You'll notice that in my post on end-to-end voting I never mentioned the word "blockchain". However, there's been quite a bit of interest in the "crypto"^[1] community around somehow using the blockchain to "fix" voting. For instance, here's Binance CEO Changpeng Zhao arguing back in 2020 that it will lead to more secure elections with faster results:

If there is a blockchain based mobile voting App (with proper KYC of course), we won't have to wait for results, or have any questions on its validity. Privacy can be protected using a number of encryption mechanisms.
— CZ 🔶 Binance (@cz_binance) November 5, 2020

And here's Ethereum founder Vitalik Buterin endorsing the idea:

The technical challenges with making a secure cryptographic voting system are significant (and often underestimated), but IMO this is directionally 100% correct. https://t.co/J0qHiN2bbk
— vitalik.eth (@VitalikButerin) November 5, 2020

See also Buterin's more extensive defense of this position here, which argues for the blockchain-as-bulletin board design. I address some but not all of his points below.

Spoiler alert: I think this is wrong, in two separate ways.

First, blockchains are not really a useful element in Internet voting: they don't solve the basic security problems in the system, and are worse than the existing technologies they would replace.

Second, the basic premise that we need Internet voting in order to fix our existing voting systems is largely misguided: it's true that we see a lot of problems with those systems in practice, but it's also quite possible to use paper-based systems to run an election that produces quick results which can be independently verified. To a great extent, the operational problems that have gotten so much press are the result of conscious decisions made by policymakers. Moreover, at our current level of technology Internet voting has serious vulnerabilities that we just have no real idea how to overcome.

Blockchains are not the solution to Internet voting #

Let's dispose of the obvious point first: the big problems in the security of Internet voting stem from the need to secure software (and keying material) on voters' devices. A blockchain doesn't really do anything to address this. Moreover, the fact that we fairly routinely see successful attacks on crypto infrastructure as well as theft of crypto currency, including from crypto investors (and maybe even core Bitcoin developers???)—who you would expect to be sophisticated—does not exactly suggest that the cryptocurrency community has discovered the secrets to key management and to building secure cryptographic software. And of course, even if they had, that software has to run on commodity platforms which of course have their own security problems; if end-user devices are compromised, then you can't trust the cryptographic voting software on top of them even if that software is perfect.

The difficulty of getting ordinary people to use cryptography correctly isn't some surprising piece of news. There's decades of papers on how hard cryptographic software is to use (see here and then here). In fact, here's Zhao just last month saying that that 99% of people can't adequately handle manage their own keying material for their crypto:

For most people, for 99% of people today, asking them to hold crypto on their own, they will end up losing it.”

and:

“Most people are not able to back up their security keys; they will lose the device [...] They will not have the proper encryption for their backup; they will write it on a piece of paper, someone else will see it, and they will steal those funds,” he explained.

But this is precisely what we are asking people to do in order to do any kind of Internet voting (with or without a blockchain). The security of these systems depends critically on the security of the keying material used to authenticate each user. If people can't safely do that for the keys to manage their money, then why should we expect them to do so for a key they only have to use twice a year?

They aren't even a useful element #

OK, so blockchains don't solve the basic security problem with Internet voting, but maybe they are a useful component? Again, I think the answer is "no". The obvious place you might want to use a blockchain is as the "bulletin board" for an E2E system. The bulletin board needs to be (1) publicly accessible and (2) have public consensus on the contents. Given that the point of a blockchain is to provide consensus about which coins have been spent, this seems like a natural fit. The idea here would be that you would submit your ballot as a record on the blockchain (just as you would a record of a spending transaction). Any records which had been included as of the date of the election (or some other deadline, presumably) would then be treated as "on the bulletin board" for the purposes of the rest of the protocol. You'd of course need all the rest of the apparatus of end-to-end verifiable voting like the provable mix, etc., but maybe the blockchain would be useful as the bulletin board.

While possible in theory, this doesn't really get you much in practice. First, the verifiability properties of a blockchain do not map well onto what you need for an election. Second, this use of a blockchain in this context has a number of practical problems, as discussed in a quite thorough report by MIT researchers Park, Specter, Narula, and pioneering cryptographer (and co-inventor of the RSA public key algorithm) Ron Rivest.

Verification #

The distinguishing feature of blockchain type systems is that they are designed to be "zero-trust", in the sense that you don't need to trust a central authority to maintain the integrity of the log. The specific property that the blockchain is guaranteeing that everyone has consensus on:

Which transactions are in the log
What order they occurred in

The details of how it accomplishes this are out of scope for this post (I've been working on a post about this, but I'm not happy with it yet), but the key insight to have is that the reason you need this kind of system is that the transactions in the log do not themselves provide all the information you need to verify them. Specifically, while they are typically digitally signed and so you can verify they are authentic, but you need the blockchain to tell you what order they occurred and to ensure that people don't conceal transactions.^[2]

E2E voting is similar in that you don't trust the voting authority but different in that all of the information it publishes is self-authenticating, so you don't need some separate mechanism to ensure it was correctly recorded. Specifically:

You can verify that all the input votes are valid by checking their signatures (this is true of cryptocurrency systems too).
You can verify that the mixing was conducted correctly by checking the proofs of shuffling.
You can verify that the votes were decrypted correctly by checking their proofs.

The only thing you can't directly verify from this information is that votes weren't incorrectly excluded from the original input set, but a blockchain doesn't really assist you here, because it's just a record of what people claimed happened. Instead, what you need is for the authority to publish the input set in some way that everyone can see and that allows people to challenge the input set.^[3] Specifically, the authority publishes the set of signed encrypted ballots to the bulletin board and then:

Voters who believe that their votes were improperly excluded can challenge that exclusion.
Observers who believe that a vote was improperly included (e.g., the signature is invalid, or the voter is ineligible) can challenge that vote.

This does require that everyone agree on the contents of each bulletin board, but you don't need the blockchain to provide it because the election officials can just post it on their Web site. Well, mostly.

Partitioning Attacks #

The reason for the "mostly" is that you can't check whether all the votes that are supposed to be present actually are, because you don't know who voted. Rather, you are counting on other people having checked that their votes appear on the bulletin board (or people checking for them). If that bulletin board is just a Web site then it's theoretically possible to mount what's called a partition attack.

Suppose the election officials want to suppress Alice's vote. If they just exclude it from the bulletin board, then Alice might catch them. Instead, they selectively exclude it, by creating two copies of the bulletin board:

The main one they use for the actual count that excludes Alice.
A bogus bulletin board that includes Alice.

When Alice goes to check her vote, the election officials send Alice the bogus version, and so her checks succeed. However, when anyone else checks the bulletin board, they send the real copy.

This is actually a very hard attack to mount in practice because any number of things can go wrong. First, if Alice checks the final totals, she'll see that they don't match. Even if she's lazy, this depends on being able to perfectly detect when Alice is checking as opposed to someone else; as there is no reason to authenticate this transaction, that's difficult. You could use the IP address, but what if Alice votes from her phone and checks from her laptop?

Moreover, this attack is easy to defeat as long as you have any consensus mechanism at all. You certainly don't need anything as fancy as a blockchain, though because we already have numerous mechanisms for election officials to communicate authoritatively with the public in ways that ensure that everyone gets the same information (e.g., by having that information broadcast on television or published in the newspaper). All they need to do is publish the hash of the bulletin board via one of these mechanisms and then everyone can verify that they have the same bulletin board contents.^[4]

The point is that this is not a situation which needs distributed consensus; it just needs regular consensus. The whole system has to be centrally operated anyway, and that central authority is a natural mechanism for establishing consensus.

Practical Problems #

The details of how blockchains work are outside of the scope of this post, but briefly, a blockchain is a public list of transactions, with every transaction appearing—or at least attested to—by the blockchain. It is maintained by a set of servers who are responsible for checking the validity of transactions and appending them to the public log. In what's called a "permissionless" blockchain, these servers are just operated by ordinary people (or at least in theory, in practice of course it takes a lot of resources to be relevant) and there aren't any special trust relationships with those servers. At a very high level the process looks something like this:

The user (voter) generates a candidate record that it wants incorporated into the blockchain.
The user's software then sends the record to some set of other network nodes.
Those nodes propagate that record to other nodes until all—or at least most—of the other nodes in the network have a copy.
One or more network elements select a set of outstanding records and incorporate them into the blockchain. Note that I've totally omitted how this happens. For our purposes, it's magic.
The extended blockchain is propagated to the rest of the network.

The result is that everyone knows by looking at the blockchain which records are in the consensus and which are not (this part is magic too).

As Park et al. observe, there are a number of things which can go wrong here. For instance:

The nodes that the user submits their record to could decide not to propagate it to other nodes, thus preventing a given user from voting.
The nodes responsible for selecting the set of outstanding records could omit a specific record, either unintentionally (because it gets lost) or maliciously (to suppress a given user's vote).
An attacker could attempt to mount a denial-of-service attack on the network to prevent it from coming to consensus. Park et al. suggest a specific attack scenario which exploits the fact that in some networks the user has to pay to have their transactions included in the blockchain, and the nodes have discretion about which transactions to include (and can favor the higher bidding ones) at times when the incoming transaction rate exceeds the throughput of the network.^[5] If the network is shared with other applications like financial transactions, an attacker could potentially flood the system with transactions in an attempt to starve out legitimate votes.
An attacker might be able to exploit defects in system elements or the associated protocols to globally or selectively mount denial-of-service attacks on an election.

The bigger picture here is that blockchains don't provide a guaranteed level of service and that the actual delivered level of service depends on network elements which are untrustworthy and potentially malicious. This opens up a lot of opportunities for attackers to interfere with election outcomes even if they aren't able to actually forge votes. They don't need to be completely successful, either, they just need to have a big enough impact to swing a close election. Of course, some of these attacks are possible with centrally operated systems, but at least in those systems you know who to blame for outages (and remember, I'm not saying that Internet voting is good, even with centralized systems!).

I could go on here, but if you're really interested, you should read the MIT report. The authors do a valiant job of trying to design a blockchain-based voting system using coins as votes, but honestly it's just a mess, with all the problems I've described here and more (this isn't a critique of the authors; their point is that it's a bad idea, so it's proof by contradiction.) The bottom line is that blockchain technology just isn't a good fit for this application.

Solving the wrong problem #

Finally, the whole argument here kind of rests on a misdiagnosis of the situation, namely that the problem with conventional voting systems is that they are inherently (1) slow to get results and (2) open to questions of validity, and hence that we need Internet voting to solve these problems.

Speed #

It's entirely possible for conventional voting systems to produce rapid results (though in all fairness, not as fast as an Internet-only system). It's true that there have been a number of recent elections where it took a number of days to determine the winner, as more votes trickled in. In some cases, candidate A looked like a winner early but was the eventual loser when all the votes were in, which has caused a lot of suspicion among people who didn't understand what was happening. However, many jurisdictions actually are able to resolve elections quickly. For instance, Florida mostly got same-day results in 2022.

To understand what causes delay, it helps to understand the logistics of voting. The consensus best choice in the voting security community is optically scanned (opscan) paper ballots. These can be counted in one of two ways:

Precinct count: The ballots are fed into a machine in the precinct which counts them immediately and then can report the results.
Central count: The ballots are sent back to election central where they are scanned.

Precinct count systems can deliver results immediately upon poll closure, with some potential risk to voter privacy (you have to trust the machine not to record the order of ballots and their contents). With systems like this, you can get a count on election night (pending verification, as below). Central count machines obviously take longer to report values, but modern central count scanners can count hundreds of ballots per minute, so it's not implausible that you could get an election night count with an acceptable cost, as Florida already does.^[6]

There are a number of reasons why elections can be slow to resolve, but one of the main ones is absentee/mail-in ballots. For instance, in California, ballots can be postmarked on election day, so you need to wait days for all of the ballots that were mailed to be delivered. In some jurisdictions, you can't even start counting absentee ballots until election day, which means you need to count a lot of ballots right away. A number of jurisdictions have both of these problems: in Mississippi ballots can be processed up to 5 days after election day if they are postmarked on election day and you're not even allowed to start checking the signatures on them until election day! As noted above, if you have the right policies you can get answers reasonably quickly.

It's certainly true that ballots received over the Internet could be tallied instantly, so in that respect we would expect Internet voting to be faster, but this only works if we require everyone to vote over the Internet, which has the potential to really disenfranchise a lot of people (people who can't afford modern devices, those who aren't comfortable with new technologies, etc.). If a significant number of people still vote mail-in with paper ballots, then you still have the problem. The bottom line here is that if we want to prioritize rapid election results at the cost of making it harder to vote remotely (and while for many people an app would be easier, for some it would be harder), then we know how to do it; it's a choice to have slow election results.

It's also important to note that this is all about preliminary results. Full verification takes time, both with paper-based systems and for end-to-end verifiable systems. For paper-based systems, this is because the risk-limiting audit or hand count is manual. In end-to-end verifiable systems, the cryptographic pieces can be checked immediately, but you need to give time for people to challenge the initial vote input set (and specifically to object that their vote was not included). Until that's happened, you have no way of knowing that the voting system didn't just exclude a lot of voters.^[7]

Disputes about validity #

From a technical perspective, election validity comes down to the ability to demonstrate to a third party—ideally to any third party, but in practice to some set of third parties that are collectively trusted^[8] by the electorate—that each phase of the election was correctly conducted, or at least that the inevitable errors were insufficiently large to affect the final result.

For ordinary elections, verifiability is provided by a combination of observability—at least in principle—for the manual processes and double-checking for the inherently unverifiable electronic processes (if any).^[9] This second feature is typically described using the concept of software independence (SI), defined by Rivest and Wack as follows:

A voting system is software-independent if an undetected change or error in its software cannot cause an undetectable change or error in an election outcome.

The intuitive reason for SI is that we know computers to be very insecure—and multiple reviews of electronic voting systems have found serious vulnerabilities—and that their operations are opaque, so any voting system shouldn't depend on trusting them.

With a hand-marked paper ballot system, you have some set of processes to ensure that only registered voters vote, but you still need to verify that the tabulation is performed correctly. If you count the ballots by hand, we're back to observability, but if you count them by machine, then you need a double check. This can be provided by using using a risk-limiting audit, in which a sample of the ballots is publicly counted. Of course, if there is real doubt or the margin is very close then you can do a full hand count, but in either case the entire counting process can be made verifiable (though in practice, RLAs are nothing like universal). They key point here is that if you follow the right practices, then even a complete compromise of the scanner will not lead to the wrong result. If you use ballot marking devices instead of hand-marking the ballots, then this does not completely provide SI: if the BMD is compromised then the attacker can have it record the wrong result; some voters will check and catch the error, but others won't and for those voters the attack will succeed. The counting process is still verifiable, of course.

Similarly, end-to-end verifiable systems provide SI for tabulation by making it possible—at least in theory—for someone to write their own system from scratch that will verify the election. However, if users are voting on their own devices, then any compromise of those devices can completely compromise the device, and there's no plausible way to detect or recover from this form of attack, which is even worse than with BMDs. Imagine what happens in an election where it's discovered that even a small number of user devices had been compromised; how would you have confidence in the result? As noted above, using a blockchain doesn't help with this at all.

Even if we confine our attention to the parts of the system that are independently verifiable, actually convincing yourself that the election was correctly conducted can be a pretty challenging proposition. A full hand count is directly verifiable if you watch the whole thing, and while the idea behind a risk limiting audit is simple, knowing how many ballots to count involves some reasonably complicated math. The situation with any end-to-end verifiable system is dramatically worse in that not only is the math very complicated, even the logic takes thousands of words to explain. It's pretty hard to see how explaining that votes are correct because they are digitally signed and then mixed in a way you can check by verifying a zero-knowledge proof is going to put to rest any questions of validity.

You'll note that above I said that from a technical perspective validity disputes comes down to third party verifiability. The bigger problem here is that many election disputes don't come down to technical questions at all, because most people people aren't going to research the details of how elections are run—how many people still think that there was tabulation fraud in Georgia, even after a full hand count?—and end up making decisions on other grounds, using motivated reasoning or based on who they trust more. It's hard to see how any set of technical mechanisms will really convince everyone, though I'm especially skeptical that arguments based on fancy cryptography will do the job.

The Bigger Picture #

As I said in my original post on end-to-end verifiable voting, voting isn't just a technical problem: it's embedded in a system of social practices and it's those social practices which make the problem complicated (again, I encourage anyone interested in voting to actually go serve as an election worker). It's of course possible to improve voting technology, but most proposals for how we could radically improve everything using new technology X fall down when you realize that X don't take into account those existing operational realities. This is largely the case with Internet voting. The problem with using blockchains for Internet voting is simpler, though: it doesn't solve any problem that can't be solved with other, simpler technology. Of course, that could also be said of a number of other proposed applications of blockchains, which, to quote Mark Nottingham are not magical.

The scare quotes are here because there is of course a pre-existing use of the term "crypto" to mean "cryptography". ↩︎
The reason this is important is that you need to prevent "double-spending" attacks where people use the same cryptographic token to pay two people. ↩︎
The analogous check in a blockchain-based cryptocurrency system is that the payee verifies that a transaction is recorded on the blockchain before they believe they have been paid. ↩︎
This is actually how pre-Bitcoin timestamping systems were designed. ↩︎
The Bitcoin maximum transaction rate is famously low, though other networks do better. ↩︎
Handwaving alert: The Interscan Hipro can scan 300 pages per minute and costs under $200,000. Los Angeles is probably the biggest county in the US with almost 6 million registered voters: if you had about 40 scanners you could do all these counts in less than 10 hours at a capital cost of less than $10 million (of course, there are lots of other costs to consider). ↩︎
Remember that many registered voters don't actually vote, so you need some way of distinguishing the case where people didn't vote from the case where their votes were discarded. ↩︎
By which I mean that for the vast majority of voters, there is at least one verifier they trust, even if not all voters trust the same verifier. ↩︎
Outside the US, hand counting is common, but in the US, it's pretty much necessary to use machine counting for logistical reasons. ↩︎

How to securely vote for (or against) Elon Musk

2022-12-24T00:00:00Z

Note: this post contains a bunch of LaTeX math notation rendered in MathJax, but it doesn't show up right in the newsletter version. You may want to instead read the version on the site.

Earlier this week Elon Musk ran a poll for whether he should step down as head of Twitter. As of this writing, the poll stood overwhelming (57.5 to 42.5) against Musk.

Should I step down as head of Twitter? I will abide by the results of this poll.
— Elon Musk (@elonmusk) December 18, 2022

Unsurprisingly, there have been claims of voter fraud (via "bots") as well as concerns that Musk would retaliate against people who voted that he should step down. Twitter polls are just some code on a Web site, and so are trivially insecure in any number of ways, including:

There's no way to validate who voted.
There's no way to externally verify that the votes were accurately counted.
It's trivial for anyone in control of Twitter servers to see who voted which way.

These weaknesses follow directly from the way that Web sites are built: your browser is just running a program that is provided by the server, and you vote by sending your vote to the server, so of course the server can see your vote and lie about it. The typical way to address this is with physical countermeasures like having people vote with paper ballots or having some kind of paper trail of how people voted. However, over the past 25 years or so it's become possible to build a voting system that is entirely remote (i.e., that doesn't involve you voting in person or sending any physical object anywhere) and yet provides strong privacy and security guarantees [terms and conditions apply].

These technologies are typically called cryptographic or more recently end-to-end (E2E) voting systems. There has been an enormous amount of work in this area; in this post, I'll be describing a simplified version of a pair of papers by two of the pioneers of the field, Josh Benaloh and Ben Adida (Helios).

Background #

Before we get into end-to-end systems, it's useful to review how a typical paper ballot system works. You can find a more detailed description in previous posts and a description of the requirements here. Typically you have preprinted paper ballots which lists the choices for each contest. For instance:

The voter marks the ballot with their selection and then submits it for tabulation. In many (though not all systems) the ballot is then mixed with other ballots and shuffled (or maybe at least shaken around a bit) so that the order in which people voted is not preserved. For instance, they might be put in a cardboard box, shuffled, and then carried to some central place for tabulation. The ballots are then tabulated and the totals reported.

This system has a fairly straightforward verifiability story if you can observe the process: you can observe who voted and that each voter only got a single ballot. As long as the chain of custody for ballots is secure (i.e., the ones that go into the box are the ones that are counted) and then can observe the counting process, then you can verify that the totals are right, and can have confidence in the whole election. The privacy story is similarly straightforward: the ballots are shuffled and as long as people don't mark them in a distinguishing fashion—a big assumption!—then it's not possible to associate a ballot with a given voter (what's called "k-anonymity").

How Not to Build a Cryptographic Voting System #

Building an end-to-end voting system is more or less a matter of replicating these properties without the paper. This is harder than it sounds. The basic problem is that there is a tension between two properties:

Ensuring the integrity of the ballot through the entire process.
Protecting the anonymity of individual votes.

If you're willing to give up either of these properties, then the problem becomes fairly straightforward.^[1]

Secure but Non-Anonymous Ballots #

If you're willing to sacrifice anonymity, then you can just have signed ballots. The way that this works is that each user has a cryptographic key pair (this of course imports all the usual problems with cryptographic identities, but let's assume that those are solved). In order to vote you sign your ballot and submit it to the election administrators.

Knowing Who Voted #

It may come as a surprise to people that we would publish who voted, but this is actually a fairly common feature of real-world systems. For instance, when I worked the polls in Santa Clara County, you would cross people off the voter sheet when they voted and then periodically post a copy of the sheet; this is a useful transparency measure but also allows campaign workers to know where they should focus their get out the vote measures.

The administrators post all the signed ballots on some public bulletin board. This allows anyone to verify who voted and file challenges^[2] in case of irregularities, such as:

Their vote wasn't included
Someone voted who shouldn't have
Someone voted multiple times

Once the challenges are complete, everyone can then verify the tabulation for themselves. Of course, this also lets anyone know exactly how everyone else voted, which is bad.

Anonymous but Insecure Ballots #

On the other hand, if you don't care about the integrity of the election, you can use standard techniques to mix the ballots. For instance, you can have a series of proxies arranged in what's called a mix network (mixnet), as shown below:

The idea here is that you have a series of independently operated proxies. Each voter recursively encrypts their ballot, first to the tabulator, then to proxy 1, and then to proxy 2. They then send their ballots to proxy 1, which decrypts them, shuffles them, and forwards them to proxy 2. Proxy 2 does the same and forwards them to the tabulator, which finally decrypts them. The end result is that the tabulator gets a list of ballots but is unable to determine which ballots correspond to which voter or what order they were cast in: it receives them in random order and because encryption was removed at each layer, there is no way to match the contents of a given ballot to the encrypted version that was cast. This property holds as long as at least one of the proxies is honest, and you can of course have an arbitrary number of proxies.

Unfortunately, any one of the proxies or the tabulator can tamper with the election results. It's obvious that the tabulator can do this because they have the final ballots, but the proxies can do the same by replacing the genuine ballots with fake ones. You could of course have the voters sign the ballots, but then this obviates the point of shuffling them because the voter's identity will be available to the tabulator. Even if you sign them before they are sent to the first proxy, that proxy has to strip the signatures.

Building a Real Design #

The underlying problem with the mixnet scheme is that it doesn't do anything to ensure that the ballots that come into the mixnet are the ballots that come out of it. In an ordinary paper-based system, this is provided by physical properties: you verify that the box is empty at the start of the election and you can have confidence that paper ballots won't change in transit or create new ballots via spontaneous generation. However, the proxies are much more complicated than cardboard boxes and they can readily create, modify, or delete ballots.

What we need is some way to verify the integrity of the mixing system, or more precisely, a way for a mixer to prove that it has executed the mixing correctly, which is to say that there is a one-to-one relationship between the ballots that were put into the system and those that came out. I describe how to build such a mixer below.

Re-Encryption #

In order to do this we first need a new primitive, which is a way to reencrypt a value encrypted to Alice so that the ciphertext (the encrypted value) is different but the plaintext (what you get when you decrypt) is the same. Importantly, you need to be able to do this without knowing the encryption key or the plaintext (it's trivial to do otherwise by just decrypting and reencrypting). In the simple proxy design above we just solved this problem by using nested encryption, but for reasons that will shortly become apparent, that doesn't work here, so we need a new primitive.

You can find details of how to implement reencryption here but we can just assume that we have some function $R$ that performs this operation. Specifically, given a ciphertext $C$ and a randomizer $r$, we can compute:

$$ R(r, C) \rightarrow C' $$

Such that:

$$ Decrypt(C) = Decrypt(C') $$

We can create a mixer by using re-encryption instead of removing one layer of encryption, as shown below:

Without knowing the $r_i$ randomization values, it's not possible to associate the output ciphertexts with their corresponding inputs.

Unlike nested encryption, re-encryption has the nice property that you can re-encrypt the same ciphertext multiple times without any help from the sender. So, for instance, you can just add another mixer stage without having to add another layer of nesting. More importantly, you can can create an arbitrary number of equivalent ciphertexts from the same initial ciphertext. We use this fact below.

Provable Mixing #

Re-encryption-based mixing is a more flexible design than nested encryption, but this still leaves us trusting the mixer. However, once we base our mix on re-encryption we can prove that the mix was performed correctly.

It's of course trivial to prove that the mix was performed correctly if you're willing to reveal the mapping itself: you just publish which inputs correspond to to which outputs as well as the reencryption factors $r_i$ and anyone can verify for themselves that the ostensible inputs result in the right outputs. What we want to do however is prove that the mix was performed correctly without revealing the mapping between inputs and outputs, which is obviously harder. Fortunately, there is a clever trick we can use here, due to Sako and Kilian.

The basic idea is that instead of mixing the ballots once, the mixer instead does so twice, creating two alternative mixes. It publishes both of them, identifying (arbitrarily) one as the output and the other as what's called the "shadow" mix. The diagram below shows the situation, with dashed arrows to indicate that observers are unable to see the mapping:

Now consider the case where the mixer cheated and replaced value $V_1$ in the output with a new value $V_a$. Assuming everything else was correct, the shadow mix can be in one of two states. First, the shadow mix can be correct, which is to say that it contains $V_1$ rather than $V_a$. In this case, there is a 1-1 mapping between the input values and the shadow mix, but no 1-1 mapping between the shadow mix and the outputs.

Alternatively, the shadow mix can be incorrect and contain $V_a$ rather than $V_1$. In this case, there is a 1-1 mapping between the shadow mix and the outputs but not between the shadow mix and the inputs.

Either way, if the mixer cheated, there will either not be a mapping from the input to the shadow or from the shadow to the output (of course, it's possible for both to be wrong). If the verifier then randomly challenges the mixer to reveal either of the mappings, there is a $1/2$ chance that the mixer will be unable to do so (obviously, if the mixer discloses both, then this is the same as disclosing the full mapping to the output, but because the shadow mix is shuffled with respect to the input-output mappings, neither of the mappings to the shadow mix tells you anything about the input-output mappings). On the other hand, if the mixer has behaved honestly, it can reveal either mapping when challenged.

Given this design, if the mixer cheats they have a $1/2$ chance of getting caught, or, to look at it another way, a $1/2$ chance of getting away with it. It's straightforward, however, to make that chance arbitrarily small, just by having the mixer create more than one shadow mix. The verifier then asks them to reveal one half of the mapping for each of the shadows—but never both halves for a given shadow. Each of these challenges has a $1/2$ chance of detection, so if you have $n$ challenges, the chance of successful cheating is $2^{-n}$, which quickly gets very small; somewhere between 80 and 100 shadows is easily sufficient.

Note that this does not prove that the ballots were actually randomly^[3] shuffled, merely that they map 1:1 between input and output. The standard way to ensure shuffling is to have multiple mixers: as long as any one is honest and actually shuffles, the result will be random.

A non-interactive proof #

The obvious problem here is that this proof of correctness is interactive which is to say that it requires someone to actually generate the challenges. If you're not that person you just have to trust them. This is still better than nothing because the verifier could be separate from the mixer, but it's possible to do better still, creating a non-interactive proof that the mix was done correctly.

The intuition to have here is that the interactive proof works by forcing the mixer to commit to the outputs before they get to learn the challenge. This prevents the mixer from creating a specific dishonest mapping that will pass a specific known challenge, which is quite easy (just make the challenged side correct). However, we can achieve the same effect by making it impossible for the dishonest mixer to control the challenge for a given set of mappings. We do this by computing the challenge using a hash of the outputs. I.e., the mixer:

Computes the output and $n$ shadow mixes $S_1, S_2, ... S_n$.
Hashes those to produce a string of at least $n$ bits ($H_i$)
Publish the output and shadow mixes and also for each bit of the hash $H_i$, publish either the mapping from the input to the shadow (if the bit is 0) or from the shadow to the output (if the bit is 0).

The verifier then recomputes the hash over the outputs and checks that the mixer has provided valid mappings for the indicated side.

It's natural to wonder whether the mixer could compute a mapping such that the hash has the right set of challenges. In principle yes, but because the hash is an unpredictable function of the mappings, they have to first compute the mapping and then check whether it works. You have a random $2^{-n}$ chance of getting a matching mapping, and so you just have to keep trying; it costs about $2^{n/2}$ operations to find an appropriate input, which is prohibitive if $n$ is large enough.

The problem of turning an interactive proof into a non-interactive one occurs all over cryptography, and this hashing technique, called the Fiat-Shamir Heuristic, is the standard solution.

Tabulation #

Once we have a shuffled set of encrypted ballots, we need to count them. At a high level, this is simple: the election officials decrypt them to reveal the original ballots. They publish those ballots and anyone can then tabulate them themselves. However, there are two subtleties we need to consider here.

Verifiable Decryption #

The first problem we have is that the election officials could simply lie about the contents of the ballots. I.e., they could say that a vote for Alice was actually a vote for Bob. This actually turns out to have an easy answer: it's possible for them to create a proof that they correctly decrypted the ballot. The details are a bit complicated but don't really matter: the bottom line is that it's possible to publish the following triplet:

The encrypted ballot $E(V_i)$
The decrypted ballot $V_i$
A proof that $E(V_i)$ decrypts to $V_i$.

Once verifiers have checked that the proofs are correct, they can then tabulate the decrypted ballots.

Multiple Decryption Keys #

The second problem is that election officials might decrypt the encrypted ballots when they are initially posted on the bulletin board, this learning how everyone voted. As noted above, these ballots are signed and so are easy to attribute.

The standard approach to mitigating this threat is to encrypt each vote with multiple keys, so that you need multiple election officials—or even some trusted third party—to do the decryption. This means that they all need to collude in order to violate user privacy by decrypting ballots before they are shuffled. This is cryptographically straightforward (see here for one way to do it with ElGamal Encryption). Note that even if election officials do all collude, this still doesn't threaten the integrity of the election.

Putting it all Together #

We now have the makings of a complete system, shown in the figure below:

The election process looks like this:

To cast their ballot, each voter encrypts it with the public key(s) of the election officials and then signs it with their own private key. They post it to the bulletin board.
Once the ballots are all cast, the mixer strips the digital signatures (thus anonymizing them), shuffles the ballots, and posts them along with the proof of correct shuffling to the bulletin board. This can be the same bulletin board or a separate one.
The election officials take the shuffled ballots, decrypt them, and posts the decrypted ballots along with their proofs of correct decryption.

In order to verify the election, you take the following steps:

Check the signatures on the ballots. This ensures that the right set of voters cast their votes and that they attest to the contents.
Check the proof of shuffling. This ensures that the the shuffled ballots correspond to the ballots you verified the signatures on (though you can't tell which ones are which).
Check the proof of decryption. This ensures that the plaintext ballots correctly match the encrypted ballots.

Any observer can take these steps without any help from the voting officials.

Different Tabulation Methods #

In principle you can use any tabulation method you want, but things get a little complicated if you want to do anything fancy, because you want to prevent voters from being able to prove how they voted (a property called "receipt freeness"). The reason is that they might then be able to sell their vote (or be coerced into voting a certain way). If the ballot is complicated, the voter can encode their identity by voting a certain way in "down-ticket" (less important) parts of the ballot (an attack called "pattern voting"). It's easy to address this for less important contests (e.g., you are paid to vote in the Presidential election but encode your identity in your votes on local judges), by just having each contest voted separately, but for voting systems where you have multiple votes in each contest that need to be considered together such as single transferable vote (STV) the situation becomes more complicated^[4]. There are E2E designs, which work for STV, but they are more complicated.

If all the steps complete successfully, you have then verified that the output decrypted ballots have a 1:1 relationship with the signed ballots that you verified and hence with the ballots you expected to be cast, and therefore that the election was conducted correctly. You can then tabulate the ballots in the usual way and verify that the totals match what you expected, thus verifying the entire election.

Against Internet voting #

E2E voting is an amazing technical achievement, but despite that, the broad consensus of people working in voting is that Internet voting is a bad idea, even using E2E systems. Why the incongruity? The reason is that voting isn't just a technology, but rather is embedded in a whole election system, and it's in that context that E2E voting falls short.

Voting Device Security #

The first problem is that unlike (say) hand-marked paper ballots, cryptographic voting systems require users to vote on some sort of computer (you weren't planning to do elliptic curve math in your head, right?). There are two main ways for this to work:

You can use the same types of electronic polling place devices that people use for voting now.
You can vote on your own device (e.g., your phone).

But this means that you're trusting that computer to actually correctly cast your votes and computers are incredibly hard to secure, as we've seen this repeatedly in the elections context, where third party audits have repeatedly shown that even temporary access to polling place voting devices is sufficient to subvert them (see, for instance the reports from the California Top-to-Bottom Review back in 2007). The situation isn't much better with personal devices, which need regular updating to address a constant stream of discovered vulnerabilities (just as an example, here's the list of security issues in the latest iOS release; any major system has a similar list).

There has been some good work on allowing users to verify that their votes were correctly (see for instance Section 4 of Benaloh06). This is a more complicated problem than it seems because it's important to avoid providing the voter with a receipt that could be used to prove how they voted (as opposed to that they voted). Otherwise, this receipt can potentially be used to enable vote buying. Of course, these approaches ultimately require the voter to use some other computer to verify whatever proof the voting device spits out.

The Uses of Statistical Evidence #

If you have a voting system that introduces biased errors, it might in principle be detectable. Suppose that the system changes 1% of votes from Smith to Jones but leaves the Jones voters alone. If some fraction of voters check their votes, then we'll see more corrections of Jones votes than Smith votes, though we'll still see some Smith corrections, because some voters will accidentally vote Smith when they meant to vote Smith. You could imagine running some kind of hypothesis test to determine whether you saw an unexpectedly high rate of Smith → Jones errors, but even if that came up significant, it's not clear what you'd do with this information, because voter errors aren't unbiased either. To take a famous example, there's fairly strong evidence that the design of the 2000 Palm Beach Florida presidential ballot lead to systematic erroneous votes for Buchanan when the voters meant to vote for Gore. So, even if you had evidence that there was an unexpected rate of errors, it's not clear what you would do about it (in the case of Florida, nothing).

Even with these systems, you are left with roughly the same situation as with a Ballot Marking Devices (BMDs): users can in principle verify their votes but often do not. Specifically, suppose a machine is programmed to change 1/100 votes from Smith to a vote for Jones by acting as if the user had pressed the wrong button (ever make a typo on your phone?). If a user does verify their vote, the attack succeeds, and if the user does check, the machine allows them to correct it. Because users can and do accidentally vote for the wrong person, this type of attack is very hard to distinguish from voter error. Studies of Ballot Marking Devices (BMDs) by Bernhard et al. found that if left to themselves around 6.5% of voters (in a simulated but realistic setting) will detect ballots being changed. There is some good news here, which is that with appropriate warnings by the "poll workers" the researchers were able to raise the detection rate to 85.7%, though it's not clear how feasible it is to get poll workers to give those warnings. Given that checking a paper ballot is much easier than checking a cryptographic ballot, we should expect a fairly low rate of checking.

I do want to note that we are starting to see some interest in adding E2E to paper-based election systems, as in STAR-Vote or with Microsoft's ElectionGuard. This seems like a potentially good idea in that it augments the security of the paper-based system. However, in systems with no paper trail, such as voting from user's phones, then we're left just depending on the security of the device itself. The threat to be most concerned about here is an attack that compromises a large number of voter's devices, and through them the integrity of the election. Even if you subsequently managed to gather evidence that this had happened on a large scale, figuring out what to do after would be a political nightmare.

Operational Challenges #

Even if we assume that the voting devices are uncompromised, the actual logistics of building an operational E2E system are extremely challenging. Elections themselves are complicated to run—if you want to get a real sense of this, I recommend serving as a poll worker—and there are a lot of things that can go wrong; adding a bunch of complicated critical-path technology creates a lot of new opportunities for failure.

Server Infrastructure #

For example, if you want to have an Internet voting system you need some servers which accept the votes. What happens if those servers go down on election night or—worse yet—are attacked? These protocols are designed to be resistant to misbehavior by the voting servers in the sense that they can't tamper with the results, but this doesn't address attacks designed to prevent users from voting. Typical paper-based elections have mechanisms for addressing this kind of failure: if the voting machines fail, you can fall back to paper; if the electronic poll books fail, you may have paper records; if those paper records are unavailable, people can file provisional ballots and you can sort it out later. However, these mechanisms all depend on people already being in the polling place; if they're at home and things fail, the election can completely fail.

It's also possible to selectively mount attacks, for instance by having a compromised server reject only certain people's votes or by mounting a denial-of-service attack on certain precincts; this is a particularly powerful form of attack in the United States, where voting is managed locally, and so you could attack the infrastructure of a county that leans to one political party but ignore the infrastructure of a county that leans the other way.

Client Infrastructure #

As discussed above, in order to successfully vote on the Internet, the voting software needs to run on a device controlled by the voter. Even if we ignore attack, this is a prime opportunity for things to go wrong: here we have a piece of software which needs to be developed at low cost, run on more or less every device that anyone might have, needs to operate essentially perfectly, and only gets used once of twice a year. This is a tall order for any software shop.

Real-World Voter Authentication #

In the real world, voter authentication is actually quite lax. In many jurisdictions you can vote just by giving your name. While some jurisdictions require showing photographic ID, detecting fake IDs is not really that straightforward, especially for people who (again) have to do it on one day a year. In vote-by-mail systems, authentication is performed by mailing you a ballot (thus trusting the USPS) and then (hopefully) checking your signature on the ballot. Despite all this, the rate of voter fraud is very low. Probably a lot of the reason here is that it's hard to conduct this kind of in-person fraud at scale. But of course, this is not the case for Internet-based attacks.

To make matters worse, we have the problem of voter authentication. For obvious reasons, we need each voter to prove that they are authorized to vote, which means giving them some kind of credential. There are a lot of options here (give them a digital certificate, mail them a code, etc.) but whatever you do, they are all subject to voters losing their credentials. In ordinary Website authentication, we usually allow users to reset their passwords via e-mail or SMS, but for obvious reasons that's not OK here (allowing Gmail and T-Mobile to have the ability to impersonate a huge fraction of voters really undercuts the value of E2E voting). Here too, we're stuck with a situation where the failure happens at the worst possible time, and recovery entails actually going somewhere.

Implementation Complexity #

Next, we have to contend with the problem of implementation complexity. Even the best E2E voting systems are fairly complex, and the systems they need to be embedded in are even more complex. This means that even if we have a system design which is secure, we still have to worry about implementation errors, both of the protocol itself and of the rest of the infrastructure. So far, there hasn't been that much Internet voting, but serious errors have been found in several early systems. See for instance, the analysis of the Scytl system by Haines, Lewis, Pereira, and Teague^[5] and of the Voatz mobile voting system by Trail of Bits, so the situation is not encouraging.

Voter Comprehension #

Finally, we have the problem of voter understanding. It's not enough for the election just to produce the right result, it must also do so in a verifiable fashion. As voting researcher Dan Wallach is fond of saying, the purpose of elections is to convince the loser that they actually lost. With paper-based ballots, the chain of reasoning for how the election was decided is relatively straightforward: ballots go into the box and you count them. Despite this, we've still seen extensive attempts to question the resulting count, as in the 2020 US Presidential Election.

By contrast, the security of E2E voting depends on some fairly complicated cryptography that practically nobody understands. I've just spent 4000-odd words on this topic and it's only that short because I didn't explain how any of the actual cryptographic pieces work and just focused on the system logic; if you want to convince yourself that ballots were cast correctly you have to not just have a surface understanding of the cryptography but also have confidence that the mathematical problems it's based on are really hard. We don't even know for sure that that's true in the classical setting and we know that they're not if someone ever builds a big enough quantum computer. Try explaining that to your average voter.

Final Thoughts #

My point here is not to criticize E2E voting, which is an amazingly cool technology. The problem is that it's necessary but not sufficient for Internet voting, which requires correct operation of systems which are not covered by the cryptography, all under very challenging conditions. However, E2E does have two important use cases: first, it's potentially useful as an additional measure of security for in-person paper-based systems, such as Ballot Marking Devices. Second, there are lots of low to medium-stakes situations where people are already voting over the Internet using systems which are tragically insecure. These elections would be much safer and more private if they used E2E systems, even if those systems were still imperfect. So when do we get our E2E secure Twitter polls?

I owe this observation to Hovav Shacham. ↩︎
Note that you can have the contents of the ballots encrypted to prevent selective challenges against people who voted a certain way. ↩︎
Benaloh observes that you actually don't need to randomly shuffle, them: you can just sort the output values, which will destroy any order. ↩︎
By contrast, Approval Voting can be implemented by having each candidate be treated as a separate ballot. ↩︎
This analysis also includes an interesting example of an attack resulting from misuse of the Fiat-Shamir heuristic. ↩︎

Day	Morning Range	Miles Driven	Evening Range
1	200	80	120
2	180	80	100
3	160	80	80
4	140	40	100
5	160	40	120
6	180	40	140
7	200	40	160

Day	Morning Range	Miles Driven	Evening Range
1	200	80	120
2	180	80	100
3	160	80	80
4	140	40	100
5	160	40	120
6	180	40	140
7	200	40	160

Day	Morning Range	Miles Driven	Evening Range
1	200	80	120
2	180	80	100
3	160	80	80
4	140	40	100
5	160	40	120
6	180	40	140
7	200	40	160