Ryan Cao

Kimi Antonelli and Titanium Dioxide: A Quantitative Analysis

Ryan Cao — Wed, 27 May 2026 00:00:00 +0000

This paper is available for download as a PDF. It might look more convincing.

Abstract

Over the 2025 Formula One season, Andrea Kimi Antonelli, a driver for Mercedes-AMG Petronas Formula One Team, was observed to perform better in jurisdictions where titanium dioxide is a legal food additive. Using finishing position data for Grands Prix (including sprints) during the 2025 season, we found that Kimi Antonelli does finish significantly higher in races held in jurisdictions where titanium dioxide is a legal food additive; this effect is statistically significant both before and after normalization against the average constructor performance for Mercedes across Grands Prix. However, we did not find any statistical correlation between Antonelli’s fastest lap time during qualifying and titanium dioxide’s legal status, regardless of normalization against the team average. In addition, Antonelli’s generally lackluster performance at races situated in Europe, combined with the European Union’s ban on the use of titanium dioxide as a food additive, suggests that there may be other confounding variables involved in this correlational relationship.

Introduction

Andrea Kimi Antonelli is an Italian racing driver who has been competing in Formula One for Mercedes-AMG Petronas Formula One Team since the 2025 season and is currently the championship leader for the 2026 season. As the first race this year in a jurisdiction that does not allow the use of titanium dioxide as a food additive, the Monaco Grand Prix, draws ever closer, it was of great interest to us to review one of the myths that had been circulating during last year’s season: whether Kimi Antonelli performs better at races in jurisdictions where it is legally allowed for titanium dioxide to be used as a food additive.

Methodology

Using data from various sources, we compiled a comprehensive dataset of the 24 Grands Prix held over the 2025 Formula One season (6 of which included sprints, for a total of 30 races). The dataset includes the legal status of titanium dioxide as a food additive in each of the jurisdictions the Grands Prix were held in, the finishing positions of Kimi Antonelli and George Russell in each race, and whether the race was held in the European Union (in which titanium dioxide is not allowed to be used as a food additive). Titanium dioxide’s legal status in Azerbaijan was unclear at the time of writing, so it is labelled as 0.5; DNFs are attributed a finishing position of 21 for ease of comparison.

Table 1

race	tio2	antonelli	russell
AUS	1	4	3
CHN	1	6	3
CHN-S	1	7	4
JPN	1	6	5
BHR	0	11	2
SAU	0	6	5
MIA	1	6	3
MIA-S	1	7	4
EMI	0	21	7
MON	0	18	11
ESP	0	21	4
CAN	1	3	1
AUT	0	21	5
GBR	1	21	10
BEL	0	16	5
BEL-S	0	17	12
HUN	0	10	3
NED	0	16	4
ITA	0	9	5
AZE	0.5	4	2
SIN	1	5	1
USA	1	13	6
USA-S	1	8	2
MXC	1	6	7
SAP	1	2	4
SAP-S	1	2	3
LVG	1	3	2
QAT	0	5	6
QAT-S	0	6	2
ABU	0	15	5

We also collected data on the fastest laps put in by Antonelli and Russell, as well as the pole lap, for each race during the 2025 Formula One season. The data are in units of milliseconds.

Table 2

race	antonelli_quali	russell_quali	pole_quali
AUS	76525	75546	75096
CHN	91103	90723	90641
CHN-S	91738	91169	90849
JPN	87555	87318	86983
BHR	90213	90009	89841
SAU	87866	87407	87294
MIA	86271	86385	86204
MIA-S	86482	86791	86482
EMI	75772	74807	74670
MON	71880	71507	69954
ESP	72111	71848	71546
CAN	71391	70899	70899
AUT	65276	64763	63971
GBR	85374	85029	84892
BEL	102139	101260	100562
BEL-S	105394	102330	100510
HUN	76386	75425	75372
NED	69493	69255	68662
ITA	79200	79157	78792
AZE	101717	102070	101117
SIN	89537	89158	89158
USA	93114	92826	92510
USA-S	94018	92888	92143
MXC	76118	76034	75586
SAP	69685	69942	69511
SAP-S	69340	69495	69243
LVG	116314	108803	107934
QAT	79846	79662	79387
QAT-S	80532	80087	80055
ABU	83080	82645	82207

In order to measure the effects of additional confounding variables, we also included in the dataset whether races took place inside the European Union, where titanium dioxide as a food additive is banned.

Table 3

race	is_european_union
AUS	0
CHN	0
CHN-S	0
JPN	0
BHR	0
SAU	0
MIA	0
MIA-S	0
EMI	1
MON	0
ESP	1
CAN	0
AUT	1
GBR	0
BEL	1
BEL-S	1
HUN	1
NED	1
ITA	1
AZE	0
SIN	0
USA	0
USA-S	0
MXC	0
SAP	0
SAP-S	0
LVG	0
QAT	0
QAT-S	0
ABU	0

Results

Given this data, we fit a linear model against the relationship between Kimi Antonelli’s finishing position and the legal status of titanium dioxide as a food additive.

	Dependent variable: antonelli
tio2	-7.100*** (1.993)
Constant	13.502*** (1.421)
Observations	30
R2	0.312
Adjusted R2	0.287
Residual Std. Error	5.362 (df = 28)
F Statistic	12.696*** (df = 1; 28)
Note:	p<0.1; p<0.05; **p<0.01

We found that Kimi Antonelli’s finishing position in races during the 2025 Formula One season is strongly and negatively correlated against the legal status of titanium dioxide as a food additive, with a significance level of p<0.01.

In order to account for general differences in constructor performance across different circuits, we also normalized Antonelli’s finishing position against the overall team performance for Mercedes across circuits by calculating the delta between Antonelli’s finishing position and the average of Antonelli’s and Russell’s finishing positions (i.e. antonelli - ((antonelli + russell) / 2)).

	Dependent variable: antonelli_norm
tio2	-2.772*** (0.826)
Constant	4.082*** (0.589)
Observations	30
R2	0.287
Adjusted R2	0.261
Residual Std. Error	2.223 (df = 28)
F Statistic	11.257*** (df = 1; 28)
Note:	p<0.1; p<0.05; **p<0.01

Again, we found that Kimi Antonelli’s finishing position in races, even when normalized against Mercedes’ team performance as a whole, is strongly and negatively correlated against titanium dioxide’s legal status as a food additive, with a significance level of p<0.01.

Rather than using the qualifying position as an indicator of raw pace, as some prior literature on this topic has done, we chose to use fastest lap time during qualifying as a proportion of pole lap time as a better indicator of relative pace. Qualifying position itself is a data point that, in our view, is already reflected in race finishing position. However, it is to be noted that due to differing tyre allocations during different parts of qualifying and track evolution, it may not be on the whole completely appropriate to compare the fastest lap for a particular driver with the fastest lap overall in the context of a qualifying session.

	Dependent variable: antonelli_quali/pole_quali
tio2	-0.003 (0.006)
Constant	1.014*** (0.004)
Observations	30
R2	0.007
Adjusted R2	-0.029
Residual Std. Error	0.016 (df = 28)
F Statistic	0.195 (df = 1; 28)
Note:	p<0.1; p<0.05; **p<0.01

Counter to our expectations, Antonelli’s qualifying pace did not have any statistically significant correlation with the legal status of titanium dioxide as a food additive. We then normalized this qualifying pace data against the average for Mercedes (i.e. (antonelli_quali / pole_quali) - (((antonelli_quali / pole_quali) + (russell_quali / pole_quali)) / 2)).

	Dependent variable: antonelli_quali_norm
tio2	0.0001 (0.003)
Constant	0.004* (0.002)
Observations	30
R2	0.00005
Adjusted R2	-0.036
Residual Std. Error	0.007 (df = 28)
F Statistic	0.001 (df = 1; 28)
Note:	p<0.1; p<0.05; **p<0.01

After normalization, we still did not find any statistically significant relationship between Antonelli’s qualifying pace and the legal status of titanium dioxide as a food additive. These conclusions suggested to us that, if there was any causal relationship between Kimi Antonelli’s performance during Formula One sessions and whether titanium dioxide was legally allowed as a food additive, it was restricted to race pace only and not qualifying pace.

Recognizing the fact that Kimi Antonelli generally did not perform particularly well at the European races during the 2025 season compared to his overall performance throughout the year, and the fact that the European Union, which includes many of the jurisdictions the European races were held in, has a blanket ban on the use of titanium dioxide as a food additive, we considered being in the European Union a confounding variable in the relationship between Antonelli’s F1 performance and titanium dioxide’s legal status.

	Dependent variable: antonelli	Dependent variable: tio2
is_european_union	8.920*** (2.069)	-0.705*** (0.162)
Constant	7.455*** (1.069)	0.705*** (0.084)
Observations	30	30
R2	0.399	0.402
Adjusted R2	0.377	0.381
Residual Std. Error	5.012 (df = 28)	0.393 (df = 28)
F Statistic	18.585*** (df = 1; 28)	18.833*** (df = 1; 28)
Note:		p<0.1; p<0.05; **p<0.01

Conducting linear model fitting for both of these variables against membership of the EU, we found that both Antonelli’s performance and the legal status of titanium dioxide had a statistically significant relationship with EU membership. It is possible, therefore, that there are other causes that could explain Antonelli’s relative poor performance in Europe during the middle part of the 2025 season that are not related to titanium dioxide not being allowed as a food additive, including specific circuit characteristics and Antonelli’s own ongoing development as a Formula One driver.

Conclusion

Using data on finishing positions and qualifying lap times during the 2025 Formula One World Championship as provided by the FIA and conducting linear model regressions against the legal status of titanium dioxide as a food additive, we found that Antonelli finished in statistically higher positions at races taking place in jurisdictions where the use of titanium dioxide as a food additive was legally allowed, both before and after normalization for average constructor performance across circuits. We did not, however, find any statistically significant relationship between Antonelli’s qualifying pace and the legal status of titanium dioxide regardless of normalization. If culinary use of titanium dioxide was causally linked to Antonelli’s racing performance, it is only race pace and not qualifying pace that is affected. In addition, it is possible that other factors may be able to explain Antonelli’s poor performance in Europe during the 2025 season that are unrelated to titanium dioxide’s legal status, due to the confounding effect of the EU’s general ban on the use of titanium dioxide as an additive.

Recommendations

Despite the uncertainty surrounding the causality between the use of titanium dioxide as a food additive and Antonelli’s racing performance in F1, due to the non-zero possibility of Oscar Piastri, a highly talented driver racing for McLaren Mastercard F1 Team, making a miraculous comeback in the remainder of the 2026 season and winning his first WDC against all odds, it is our recommendation that Mercedes-AMG Petronas Formula One Team supply Kimi Antonelli with a titanium dioxide-heavy diet if they wish to secure the 2026 World Drivers’ Championship for Antonelli.

Further research on this topic should consider expanding the dataset to include drivers from other teams as well and possibly conducting a controlled dietary experiment, which would result in more credible results and recommendations to drivers and constructors on how to best adjust for titanium dioxide availability across different races. It may also be beneficial for the FIA to look into banning titanium dioxide intake for drivers as part of the new set of regulations introduced in 2026 in order to ensure fairness and improve racing, if there are further studies that justify doing so.

Five Years of Design

Ryan Cao — Thu, 25 Sep 2025 00:00:00 +0000

In September, I had the privilege of being able to attend NixCon 2025 in Rapperswil-Jona, Switzerland. Aside from listening to a lot of fun and/or interesting talks about Nix (“You can’t spell ‘devshell’ without ‘hell’” was one of my favorites) and meeting some of my friends in real life for the first time, I also had the wonderful opportunity to observe Swiss graphic, and especially typographic, design in action. This experience started with Zürich Tourism’s website; it left a lasting impression on my mind, since it was one of first usages of Helvetica-adjacent neo-grotesque sans-serif fonts that looked good in my opinion. The use of various colors and font weights made the font (a custom one; “Zurich Haas”) an essential part of the website’s character.

In Switzerland, the same style of font appeared everywhere: wordmarks on trains, signage in train and tram stations, posters, and even receipts. What struck me most was the prominent, almost blatant placement of text, often in exceptionally large sizes, as the central element in a design. This stylistic choice conveys information very clearly to viewers without distracting elements, and fully demonstrates the inherent elegant design of the font as well — a utilitarian design, but beautiful in its utilitarianism.

Inspired by all the instances of Swiss style design that I had seen, I set about redesigning my website in this style. The first step was finding a suitable neo-grotesque sans-serif font face. Helvetica was, no doubt, the best option. Monotype designed an update of Helvetica in 2019 called Helvetica Now, and it looked to be a pretty great choice; it was also $548.99, so I looked to other potential alternatives. In my search, I discovered several other amazing fonts: Suisse, Neue Montreal, and Söhne. They all looked like what I was looking for, but unfortunately I wasn’t prepared to allocate a particularly significant amount of capital to a font family for my personal website. So what you’re looking at now is what is possibly the most overused free and open source font family in the history of web design: Inter. The majority of glyphs in Inter actually look somewhat similar to Helvetica, and while experimenting with font features, I discovered the ss07 (square punctuation) and ss08 (square quotes) stylistic sets which, when enabled, made Inter look a lot more like Helvetica and less like Inter.

Comparison between Helvetica Neue, Inter Variable, and Inter Variable with ss07 and ss08 enabled.

After deciding upon the font, the next typographic features to make modifications to were the font sizes and weights. I decided to try out increasing font sizes to dramatically large sizes, especially to emphasize one important feature on a page; I also increased the general font size scale across the website. The largest font size in use went up to 8rem (a maximum of 128px depending on your viewport size), making the visual center of a page more apparent and conveying important information in a more upfront manner upon initial viewing. The increase in differences between adjacent levels of font sizes in the visual hierarchy also meant that the overall layout and flow of pages became much clearer than before.

In addition to typography, I also experimented with introducing more bits and pieces of color onto the website. One of the ways in which I did this was making the punctuation mark (e.g. periods, exclamation marks) at the end of prominently displayed titles or sentences on pages use the website’s global accent color. This adds some liveliness to the overall design by introducing some variation, as well as drawing more attention to the parts of a page that require a viewer’s initial attention. Borrowing a neat trick from Miniflux, I also made part of my name (i.e. the website’s title) have color and switch to the other part having color on hover.

A stylized screenshot of part of my website at the time of writing.

How long will this iteration of my website stay in use? I’m not sure myself. It might be here for a month, a quarter, or even a year. Nonetheless, I love this design, and not just because it is a realization of an aesthetic ideal that I’ve admired for a long time; it’s also because it is the cumulative result of the long way I’ve come in software, and especially web, development.

I still remember my very first attempt at a personal website a few years ago, when I first started: a crude clone of Evan You’s website at the time, uploaded as a ZIP archive and hosted on a random free website host.

As the content of this website diversified, with blog posts and other content pages, its design changed rapidly as well. The next major iteration that I can distinctly recall is one built with Next.js, with a design referencing that of Brian Lovin’s old website.

These early days of this website were often imitations of other peoples’ websites whose design I really enjoyed when I happened to come across them on the Internet. I didn’t know much about how to design interfaces by myself yet, and even if I had a rough idea of what something should look like, I didn’t have the ability to transform that idea into a reality that matched my vision.

The modern story of this website, and the codebase currently in use today, starts in 2021. Having come across Tom MacWright’s website, I was fascinated with the minimal and clean design language that it used: a primarily black and white color palette, a mostly uniform font size throughout the website, and singular Unicode arrow symbols indicating navigation state.

The choice of a two-column layout is, I believe, relatively uncommon for personal websites, but I liked the look, so I went about cloning this design on my website with Tailwind CSS.

Many things have changed in the years since then. I went through many, some might even argue too many, font choices and pairings (Switzer, Satoshi, Inter, IBM Plex Sans, and DINish, to name a few); I added more than a dozen themes and removed all of them except for light and dark after a while; I shifted parts of the website around to experiment with where everything fits together; and I adapted the design to the increasing amount of information on the website while adding more features (tags, read counts, additional pages, etc.)

Throughout these changes, the two-column layout mostly remained, and as my experience with design and web development in general increased, I became more comfortable with making changes that reflected what I personally thought was most aesthetically pleasing. Hours were spent on tweaking font weights, gaps, transition properties, and letter spacings, and with every change, a different style emerged.

DINish was used for a while as the primary font; as a grotesque sans-serif typeface designed to be similar to FF DIN, it made the website feel modern, condensed, industrial, and fast-paced. Before that, I used IBM Plex Sans, another grotesque sans-serif font that is also quite well designed and introduces more character to the website’s design (compared to, say, system font stacks). Despite the various font family changes, the typographic design of this website had not changed much since 2021.

Which is why this recent redesign is such a milestone for this website and myself. Although I’m not a graphic designer myself by any measure, I’ve always been enamored with simple and elegant graphic design, whether it’s industrial design, typographic design, or human interface design, and I am happy to have been able to design something that, at least to my subjective point of view, embodies the functional and utilitarian aesthetic that I have hoped to attain, after many years of experience and practice.

A Corepack by Any Other Name

Ryan Cao — Sat, 26 Apr 2025 00:00:00 +0000

How many HTTP requests do you think Corepack makes when you run corepack use pnpm to use the latest version of pnpm in your project?

Wrong — it’s both one and two. Two, in the sense that it makes two requests; one, because these two requests are completely identical. I came across this little idiosyncrasy while working on Moldau, a version manager for Node.js package managers that is part of my increasingly expansive repertoire of cryptically named developer-oriented tools. For those of you familiar with Node.js, you probably use, or at least know of, the tool that is traditionally employed for this use case: Corepack. In a nutshell, Corepack allows you to use specific versions of package managers for different projects, with the version being specified in the packageManager or devEngines.packageManager field in the package.json of each project; kind of like Nix development environments, or mise, but exclusively for Node.js package managers.

Since Corepack will, sadly, not be distributed in Node.js from Node.js v25 onwards, I thought it might be a fun idea to write a Corepack alternative myself in Rust. I embarked on this journey with bravado, aiming for best-effort compatibility with most of Corepack. But soon enough, I began to realize the great folly with which I had set myself on this task. As I ran into numerous weird compatibility issues and differences in Moldau’s behavior from Corepack, I realized that Corepack’s technical design was much more complicated than I thought.

One of the most interesting choices that Corepack makes is that it uses a hardcoded config file for storing a lot of package metadata. In Node.js, the "bin" field in package.json specifies which files in the package are to be installed as executables for the user to run, and if you download the tarball that the npm registry provides, you can retrieve this data from the package.json in the tarball. With Corepack, though, this data is hardcoded in the config itself. This would an odd choice if Corepack downloads package managers as package tarballs, but as it happens, it does not!

For Yarn, and Yarn only, Corepack downloads a singular JavaScript bundle from repo.yarnpkg.com instead of downloading a tarball from registry.npmjs.org if the major version is greater than or equal to 2. This fascinating behavior is necessitated by the fact that Yarn has a prodigiously confusing versioning scheme. Yarn “classic”, with a major version of less than or equal to 1, is distributed on the npm registry as registry.npmjs.org/yarn; Yarn “modern”, or “berry”, with a major version of greater than or equal to 2, is distributed on repo.yarnpkg.com. In the Yarn 2 release post, Maël Nison, the lead maintainer for Yarn, explains thus:

The yarn package on npm will not change; we will distribute further version [sic] using the new yarn set version command.

Yarn’s original release model relied on keeping the classic version of Yarn (i.e. registry.npmjs.org/yarn) around for all users to install (in the interest of backwards compatibility) while having classic Yarn fetch bundles of modern Yarn to execute from repo.yarnpkg.com if a user requested them. If you wanted to specify a version of Yarn to use in your project, you would set the yarnPath config to the path to the downloaded bundle (which could be checked into your project’s VCS as well).

On March 12, 2020, Corepack was born, written by none other than Maël Nison. Corepack was an elegant solution to the problem of package manager version management; by including the versions in package.jsons and distributing the tool to read these versions alongside Node.js, everyone could easily get on the same page. Since the release of Yarn v3, Yarn’s official documentation has recommended using Corepack rather than installing Yarn globally or using yarn set version; in fact, in Yarn v4, yarn set version defaults to configuring Corepack instead of modifying the yarnPath config property. But an issue remained: Yarn v2 was not distributed anywhere other than repo.yarnpkg.com (as far as I’m aware); consequently, in order to support Yarn v2, Corepack still had to download the bundles from repo.yarnpkg.com, as yarn set version did, if users tried to use modern Yarn. This also made it necessary for Corepack to hardcode the names of executables in its config, since the information was not readily available for the downloaded bundles of Yarn (pun most definitely intended).

Thus, in order to support both classic and modern Yarn, Corepack has two configs for Yarn, differentiated by the SemVer range <2.0.0 and >=2.0.0. This config duplication also extended to pnpm, when in v6.0.0 they renamed their executable files from bin/{pnpm,pnpx}.js to bin/{pnpm,pnpx}.cjs. Since the executable names were hardcoded, Corepack had to create a new config for >=6.0.0 with an updated, hardcoded "bin". And this is where it gets exceedingly interesting; take a look at the following code snippet.

// https://github.com/nodejs/corepack/blob/aefde28a631356bfdec91795d2c60be07dbf5be3/sources/Engine.ts#L409-L415

const versions = await Promise.all(
  Object.keys(definition.ranges).map(async (range) => {
    const packageManagerSpec = definition.ranges[range];
    const registry = corepackUtils.getRegistryFromPackageManagerSpec(packageManagerSpec);

    const versions = await corepackUtils.fetchAvailableVersions(registry);
    return versions.filter((version) =>
      semverUtils.satisfiesWithPrereleases(version, finalDescriptor.range),
    );
  }),
);

Corepack doesn’t choose one of the duplicated configs to fetch from; it fetches all of them and joins the matching versions together! The technical choices that Corepack made it so that it had to obtain information from all the ranges before it could resolve the final version if the user provides a non-exact version, and because the two configs for pnpm differ in nothing other than the "bin" field, Corepack makes two completely identical requests for the same package data if you ask it for a version of pnpm.

For Moldau, I did not want to implement a whole set of code just for downloading Yarn while I could handle npm and pnpm easily through a generic interface to the npm registry. Fortunately, I discovered that versions of Yarn from v3 upwards were also published to an npm package with the name of @yarnpkg/cli-dist; Heroku’s buildpacks and Volta use it for installing Yarn, and Corepack even uses it as a fallback for when the user specifies a custom npm registry URL. All in all, this meant that Yarn was distributed in three locations as far as I knew:

registry.npmjs.org/yarn: v1.*, v2.0.0-rc.24, v2.0.0-rc.27, and v2.4.3
registry.npmjs.org/@yarnpkg/cli-dist: v3.*, v4.*, v2.4.1, and v2.4.2
repo.yarnpkg.com: v0.*, v1.*, v2.*, v3.*, and v4.*

In the interest of the DRY principles and the soundness of my mental faculties, I decided to use the @yarnpkg/cli-dist and yarn packages on the npm registry to install Yarn versions in Moldau; this way, all three supported package managers could share the same code that interacts with registry.npmjs.org. Of course, this came at the cost of not being able to support most Yarn v2 versions; however, usage of Yarn v2 with Corepack is low (as far as I could tell from a cursory GitHub code search), since Corepack only became the preferred installation method with Yarn v3, and it is unlikely that users will choose to use Yarn v2 today.

After implementing the functionality to download a package tarball and unpack it, I ran into yet another issue that was caused by Corepack’s eccentric handling of Yarn. The packageManager key in package.json optionally supports specifying a hash for verifying the integrity of the downloaded package manager; however, with Yarn, the hash that Corepack uses is the hash of the bundle, not the package tarball, since it doesn’t download the tarball in the first place. To resolve this issue, I had to write some Yarn-specific code: when verifying integrity hashes for Yarn, Moldau finds the Yarn executable bundle in the unpacked package and calculates the hash of that bundle, instead of calculating the hash of the tarball as it does with npm and pnpm. The things we do for compatibility.

In general, I am quite satisfied with what I achieved with Moldau. Despite the various hiccups and pitfalls in making Moldau compatible with Corepack’s core functionality, I made several of what are, in my opinion, improvements over Corepack’s design. In order to figure out whether to use @yarnpkg/cli-dist or yarn when resolving Yarn versions, I implemented a heuristic that determines whether modern Yarn or classic Yarn is being requested based on the SemVer version or range provided by the user, so that Moldau only makes requests that are necessary:

let is_classic = self.version.exact().is_some_and(|v| v.major <= 1)
	|| self.version.semver_req().is_some_and(|r| {
		r.comparators.iter().any(|c| match c.op {
			semver::Op::Exact
			| semver::Op::LessEq
			| semver::Op::Tilde
			| semver::Op::Caret => c.major <= 1,
			semver::Op::Less => {
				c.major <= 1
					|| c.major == 2
						&& c.minor.is_none_or(|n| n == 0)
						&& c.patch.is_none_or(|n| n == 0)
			}
			_ => false,
		})
	});

I did not have to hardcode information on where package managers’ executables are in Moldau, since this information could be dynamically read from the "bin" key from the unpacked packages’ package.jsons. I added a nice progress bar when downloading package tarballs, powered by the indicatif crate, and I left out several pieces of functionality that I personally didn’t deem to be useful, such as the Known Good Releases mechanism and auto pin. And, as goes without saying, Moldau is marginally faster than Corepack due to being written in Rust and compiled to native code.

Corepack is a very impressive project, and it’s certainly been an experience going through source code, docs, and blog posts to understand how it works and why it is implemented the way it is. Moldau was born out of these endeavors as something of a Corepack by another name, but I believe it to be much more than that; if you happen to try it out (cargo binstall moldau), I hope you will find that it smells as sweet.

Ephemeral Permissions Considered Beneficial

Ryan Cao — Sat, 29 Mar 2025 00:00:00 +0000

In last year’s macOS Sequoia release, one change attracted a lot of attention: the new periodic confirmation for apps that use screen recording permissions. Every month, macOS would display a prompt to confirm a user’s intent to continue allowing an app access to their screen when the app is used. This change drew criticism from a lot of macOS users, who accused the feature of being intrusive, unnecessary, or anticompetitive; projects such as Amnesia were even created to solve the singular problem of these permission prompts.

Ephemeral permissions models like these appear to be annoying at first sight. They put more obstacles in users’ ways when they are trying to get their computers to do something, adding yet another frustrating dialog to click through in order to reach their ultimate objective. However, the privacy benefits that ephemeral permissions bring far outweigh the increase in required user interactions that they are associated with. The operating system’s (or browser’s) permissions model is the vital boundary that guards the increasingly powerful capabilities of users’ devices against potential intrusion or misuse, and ephemeral permissions play an important role in protecting users from potentially malicious applications and themselves.

In current systems, most permissions are typically designed to be granted permanently. Once a user presses “Allow”, that permission is granted for the application until the user, for whatever reason, decides to go into settings and revoke that permission. This assumption, that an application should always have access to a specific capability when the user has only granted it once, is a convenient yet dangerous one, especially for more sensitive capabilities such as geolocation, microphone, camera, and screen recording. Permissions systems exist because applications installed by the user are not considered fully trusted; they should only have access to whatever the user currently needs them to access in order to function. For the same reason that applications do not have access to all of a device’s capabilities by default, they should not have access to a capability forever based on a one-time expression of intent. For example, if a user grants Discord access to their microphone for a voice chat on a certain occasion, their ultimate intent is not to allow the app to access their microphone anytime, anywhere, but to allow the app to access their microphone for the duration of the voice chat. Would it not make more sense, then, to have the microphone permission only be granted to the app for a limited timeframe and then revoked, for instance, when the user closes the app, or when the device is locked, or after a week?

Permissions systems sometimes address this problem by providing indicators of access to permissions, especially sensitive ones. For instance, macOS displays privacy indicators in Control Center and in the menu bar when sensitive permissions such as the microphone, camera, location, and system audio are being used by applications (incidentally, a subset of users also consider this to be unnecessary). The App Privacy Report on iOS and iPadOS allows users to see a record of when and how apps access permissions (data & sensors) granted them. These features give users insights into when the permissions that they had granted in the past are being used, and help to surface unauthorized access patterns. However, it is oftentimes far too easy to ignore the signals provided by these privacy features; after all, they do not require user interaction! A small yellow dot showing up in the top right corner of a display is quite easy to ignore, especially if the user is engrossed in a task that demands their full attention elsewhere on the screen.

In addition, the number of apps and websites that an individual uses and the number of permissions and capabilities that devices have are both steadily rising; it is impossible to assume that the average user will be able to keep track of everything they have authorized the applications that they use to access. An iOS user could very well forget that they had given an app access to their calendar, until some day by a fluke they happen to check their App Privacy Report and realize that it has been periodically accessing their calendar data for no apparent reason. Opaque business practices and legalese-filled privacy policies further make it difficult to hold applications accountable for where data goes after it is collected from devices’ capabilities. Thus, it is the increasingly indispensable duty of the operating system/browser, acting as the security boundary, to actively remind the user of these permissions (by making them temporally limited) and give them an opportunity to periodically review them.

Ephemeral permissions ensure that users will have to review their privacy settings on a regular basis through active interactions with the permissions system. Whether implemented through centralized settings or operating system/browser prompts, the fact that an application has authorization to access a specific capability on a device is prominently brought to the user’s attention. The user might want the application to continue having the permission; in that case, a few interactions will confirm such an intent. If the user does not want the application to continue having the permission, however, this will bring the issue to their attention and they will decline to grant the permission or deny it for the application. In any case, the ephemeral nature of these permissions will require active user intent to periodically confirm or deny them, thereby ensuring that the user’s preferences (which might often change) are always reflected in their privacy settings.

Ephemeral permissions systems also automatically revoke permissions or remind users to revoke them when they are no longer needed. In the previously mentioned Discord example, a good ephemeral permissions model will either (a) remove the microphone permission from the app at some point in time after the voice chat or (b) remind the user that the app has access to their microphone, at which point they can choose to grant or deny the permission. This behavior enforces the principle of least privilege for applications; they only have access to the permissions that are required for the function that the user uses them for. If a user gives camera access to a maps app for AR navigation one time but then does not use AR navigation ever again, ephemeral permissions systems will, at some point, revoke camera permissions for the maps app, ensuring that the maps app no longer has access to a permission which it does not need to function. Chromium’s “Automatically remove permissions from unused sites” setting is founded on such a premise; something that a user has not used for a while and perhaps does not even recall using should not have access to sensitive user data. Ephemeral permissions systems give users opportunities to reconsider whether an application currently needs the permission that it is requesting, reminding them of a choice that they can take but may have forgotten about or preemptively protecting them from unauthorized access.

An interactive ephemeral permissions system design, in which permissions are granted and revoked as a user interacts with the application that is requesting the permission, helps to reduce the maintenance burden of privacy settings as well. Instead of having to go into a centralized privacy settings page and toggling permissions for prodigious lists of apps, users will be able to manage these permissions in the course of utilizing the functionalities that require them; the conscious effort that is required for a user to review their privacy settings is significantly reduced. Even for users that, for one reason or another, are regrettably predisposed to impetuously granting permissions to applications without considering their specific use cases or implications, ephemeral permissions systems might provide a significant improvement in privacy protection. Since permissions requests are repeatedly presented to the user over time, there is a greater chance of them actually reviewing the permissions request and making an active decision on it at some point; such an opportunity is not offered to the user in a permanent permissions system.

Ephemeral permissions models provide a level of privacy guarantees and protection that significantly surpass “traditional” permanent permissions models. Any implementations of such systems have to strike a delicate balance between usability and privacy; they must keep the user actively aware of their permissions choices through requiring interaction, while avoiding obstructing the user’s daily usage to the point where they devise strategies to circumvent the very system designed to protect them. In general, ephemeral permissions are definitely a net positive for privacy. macOS Sequoia’s implementation of screen recording permissions was a commendable move in favor of this model, and it would be wonderful to see more ephemeral permissions systems in production across operating systems and browsers.

Where Did My Colorful Home Manager Logs Go? Debugging Ghostty and Sudo

Ryan Cao — Tue, 10 Sep 2024 00:00:00 +0000

Ever since switching to Ghostty, my Home Manager activation has stopped printing its headers as cyan and bold. I never bothered enough to fix it, since I work on my flake most of the time in VS Code, but since I happened to be working on morlana, an alternative implementation for darwin-{rebuild,installer,uninstaller}, and was getting acquainted with some of the internals of how a nix-darwin system is activated, I decided to take a look at what exactly was causing the missing colors.

My initial hypothesis, the one that I had from my first encounter with this problem, was that Home Manager had some sort of registry of TERM variables to check color support, and this registry included xterm-256color but not xterm-ghostty. I dived into the Home Manager codebase in search of evidence for this hypothesis, but searches for TERM and xterm came up with results unrelated to the activation logging. Huh, I thought. So where exactly was whether to print colored output determined?

# https://github.com/nix-community/home-manager/blob/8a175a89137fe798b33c476d4dae17dba5fb3fd3/lib/bash/home-manager.sh#L22-L34

# Enable colors for terminals, and allow opting out.
if [[ ! -v NO_COLOR && -t 1 ]]; then
	# See if it supports colors.
	local ncolors
	ncolors=$(tput colors 2> /dev/null || echo 0)

	if [[ -n "$ncolors" && "$ncolors" -ge 8 ]]; then
		normalColor="$(tput sgr0)"
		errorColor="$(tput bold)$(tput setaf 1)"
		warnColor="$(tput setaf 3)"
		noteColor="$(tput bold)$(tput setaf 6)"
	fi
fi

This was pretty straightforward. The tput utility reads from terminfo databases to print information about terminal capabilities and features, such as ANSI colors. Here, as terminfo(5) helpfully tells us,

The numeric capabilities colors and pairs specify the maximum numbers of colors and color-pairs that can be displayed simultaneously.

I ran tput colors in Ghostty to test if it returned a valid value.

$ tput colors
256

It did! I also tried testing the if condition in bash, and the result was the same. It was a TTY, NO_COLOR wasn’t set, and it supported a 256-color lookup table. So what on Earth was causing disabled colors in logging?

All of a sudden, it occurred to me. From my time spent writing morlana, I knew that the activate step in darwin-rebuild switch or morlana switch used sudo to execute the activate script with elevated privileges.

# https://github.com/LnL7/nix-darwin/blob/76559183801030451e200c90a1627c1d82bb4910/pkgs/nix-tools/darwin-rebuild.sh#L247-L251

if [ "$USER" != root ]; then
	sudo "$systemConfig/activate"
else
	"$systemConfig/activate"
fi

// https://github.com/ryanccn/morlana/blob/a3cabed7e0824b0fda55652628c102ab7a108c2f/src/stages/activate.rs#L23-L34

pub fn activate(out: &Path) -> Result<()> {
    if !util::sudo_cmd(out.join("activate"))
        .stdout(Stdio::inherit())
        .stderr(Stdio::inherit())
        .status()?
        .success()
    {
        bail!("failed to activate");
    }


    Ok(())
}

Was it possible that sudo was somehow interfering with the colors to make them not work? To validate this hypothesis, I tried running sudo tput colors.

$ sudo tput colors
tput: unknown terminal "xterm-ghostty"

Sudo was causing the issues, and now I also know why: commands that are running inside sudo do not recognize xterm-ghostty, because they don’t have access to the Ghostty terminfo!

In a misguided effort to rectify this problem, I enabled the sudo wrapping feature in Ghostty’s shell integration, which preserves Ghostty terminfo. Now sudo tput colors printed 256 as well! But Home Manager still did not print colored logs. As it turns out, what should’ve been obvious to me in the first place was that shell integration was modifying the shell and creating a wrapper function in the shell, while the sudo that activate was running under was the executable, not the function.

So, I looked into Ghostty’s source to find out what the shell integration was doing in order to figure out how to make this work for sudo anywhere.

# https://github.com/ghostty-org/ghostty/blob/12bf107bcbac28202c5fab828416e8aa43b1b798/src/shell-integration/fish/vendor_conf.d/ghostty-shell-integration.fish#L74-L93

# Wrap `sudo` command to ensure Ghostty terminfo is preserved
function sudo -d "Wrap sudo to preserve terminfo"
	set --local sudo_has_sudoedit_flags "no"
	for arg in $argv
		# Check if argument is '-e' or '--edit' (sudoedit flags)
		if string match -q -- "-e" "$arg"; or string match -q -- "--edit" "$arg"
			set --local sudo_has_sudoedit_flags "yes"
			break
		end
		# Check if argument is neither an option nor a key-value pair
		if not string match -r -q -- "^-" "$arg"; and not string match -r -q -- "=" "$arg"
			break
		end
	end
	if test "$sudo_has_sudoedit_flags" = "yes"
		command sudo $argv
	else
		command sudo TERMINFO="$TERMINFO" $argv
	end
end

As it turns out, it’s very simple! It just keeps the TERMINFO environment variable in the sudo invocation. Referring again to terminfo(5),

If the environment variable TERMINFO is set, it is interpreted as the pathname of a directory containing the compiled description you are working on. Only that directory is searched.

So, keeping the TERMINFO variable (which Ghostty sets) in sudo should suffice to make colors work again in Home Manager. Since sudo on macOS defaults to resetting the environment with env_reset, we need to add a default to /etc/sudoers that keeps the TERMINFO environment variable. And accomplishing this is as simple as

Defaults    env_keep += "TERMINFO"

I added this magic line of configuration to /etc/sudoers.d/env-keep-terminfo (since files from /etc/sudoers.d are included by default in the config), and tried switching to the configuration again. Home Manager’s logs had become cyan and bold, as they are meant to be.

After writing to this file, I naturally became wracked with guilt over writing it into a file imperatively rather than including this fix as part of my declarative nix-darwin configuration. After a quick search in the nix-darwin reference, I was relieved to see that nix-darwin provided an option for providing extra configuration to sudo: security.sudo.extraConfig. (It writes to /etc/sudoers.d/10-nix-darwin-extra-config.)

{
  security.sudo.extraConfig = ''
    Defaults    env_keep += "TERMINFO"
  '';
}

And with that, all of my problems were solved. This was a problem that had been bugging me for a very long time, and I was glad that with a little under an hour’s work, I had managed to come up with a clean fix for it. Hopefully, you who are reading this have found this article modestly helpful as well; cheers!