Posts on Seirdy’s Home

Post-OCSP certificate revocation in the Web PKI

seirdy@seirdy.one (Seirdy) — Wed, 25 Sep 2024 15:29:38 +0000

Introduction

Today, TLS certificates in the Web public key infrastructure (PKI) have long validity: almost all remain valid for at least three months! An attacker compromising a certificate early enough in its lifetime¹ keeps it compromised for months. Certificate revocation addresses this problem: a client must know to distrust a certain key for a domain, even if the valid key hasn’t expired yet.

The issue? Billions of clients use the Web PKI: browsers, crawlers, link-preview generators, chatbots, email servers, email clients, etc. The easy part for a CA is knowing when to revoke a certificate.² The hard part is telling every client to ignore a certain compromised certificate. All approaches to revocation trace their roots to at least one of the following:

Certificate Revocation Lists (CRLs)
Online Certificate Status Protocol (OCSP)
Short-lived certificates

Initial approaches to each option showed major shortcomings. All three evolved:

CRLs became sharded CRLs and combined client-side “summarized CRLs”.
OCSP became OCSP stapling and OCSP Must-Staple. It almost evolved into OCSP Expect-Staple. The shutdown of OCSP resolvers impacts all three; we need alternatives.
Short-lived certificates became ACME-STAR and delegated credentials.

I’ll break down each of these, along with some of my proposals. We should double down on client-side summarized CRLs³ and work towards reducing certificate lifetimes.

Most solutions still have caveats or won’t gain mainstream adoption for several years. Until then, I propose offering six-week certificates.

Motivation

Why discuss revocation now?

In August 2023, the CA/Browser Forum voted in favor of Ballot SC-064 v4. This ballot made the Online Certificate Status Protocol (OCSP) optional and outlined where CAs should focus instead. Let’s Encrypt published Intent to End OCSP Service on 2024-07-23, and will likely shut down its OCSP service sometime in late 2025 or 2026. Let’s Encrypt issues TLS certificates for almost 60% of websites.⁴ This means most websites will soon have no more OCSP: while it might live on in other networks, OCSP will leave the Web PKI.

The announcement from Let’s Encrypt merely declares intent. Some staff members show openness to a migration period for stapling, with at least a year before any changes.⁵ After the migration period, I expect webmasters to lose the option for OCSP Stapling or working OCSP Must-Staple. Without OCSP, most clients either trust all certificates from their issuance until expiry or have to constantly update compressed revocation filters (“summarized CRLs”) to check the revocation status of a certificate. We can also look to other solutions on the horizon.

Note: I made this article ACME-centric.⁶ Most websites use ACME to automate the generation and renewal of certificates validated by a certificate authority (CA). Where non-ACME setups are relevant, I disregard them. Use ACME!

Target audience

I wrote this for people with some basic familiarity with TLS, certificate authorities, and maybe OCSP; this represents what I knew before I started writing this article. I did my best to link other resources and define terms where appropriate.⁷ The Let’s Encrypt glossary might assist you.

For readers less familiar, I recommend Intro to TLS certificates by Carrie Bartle for a primer on how TLS certificates and Web PKI work.

xkcd comic: Average Familiarity

I’m not an “expert” but this comic captures how the first draft of this article read. From xkcd

Toggle comic transcript

Comic transcript

Ponytail and Cueball are talking. Ponytail has her hand raised, palm up, towards Cueball.

Ponytail: Silicate chemistry is second nature to us geochemists, so it’s easy to forget that the average person only knows the formulas for olivine and one or two feldspars.
Cueball: And quartz, of course.
Ponytail: Of course.

A caption below the panel reads, Even when they’re trying to compensate for it, experts in anything wildly overestimate the average person’s familiarity with their field.

Transcript from the explain xkcd wiki entry for xkcd #2501.

Toggle table of contents

Certificate Revocation Lists

CAs regularly publish live lists of revoked certificates called Certificate Revocation Lists (CRLs). When revoking a certificate, CAs update OCSP responses and push an entry to a CRL. They have up to a seven-day deadline to do so (less in certain cases⁸). CAs annotate entries with one of ten possible reasons for revocation. See RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile for details on the contents of CRLs.

CRLs’ large size and short validity make them a poor fit for client-side revocation checking: most clients can’t regularly re-download such large lists for revocation lookups. CAs started offering OCSP as a lightweight alternative. CRLs are far from obsolete, though: they support transparency, research, and other revocation technologies.

CRLs, the oldest revocation method in this article, only recently joined the CA/Browser Baseline Requirements in Ballot SC-064 (the ballot I mentioned in the “motivation” section).⁹

Online Certificate Status Protocol (OCSP)

Before trusting a certificate, browsers can ask its issuing CA if the CA has revoked the certificate by using the Online Certificate Status Protocol (OCSP). OCSP has a host of problems:

Performance: Asking a CA about a new certificate before trusting it and loading a page can take hundreds of milliseconds or even seconds. That slows down page loads.
Privacy: This leaks domain names to the CAs in question. Users can always switch their DNS providers to options they trust, but they can’t select a different place to check for OCSP status.
CA reliability: A CA needs good uptime and needs to respond to a massive number of requests from HTTPS clients worldwide. OCSP-supporting clients query every certificate from the CA they encounter and expect a low-latency response.
Robustness: A bad firewall or a poor connection could prevent successful and timely connections to the CA for an OCSP check. For this reason, failed live OCSP checks typically soft-fail. If the OCSP check doesn’t succeed or takes too long, the client trusts the certificate. An attacker can also block connections to the CA to get a victim to trust a compromised certificate.

OCSP Stapling and Must-Staple

OCSP Stapling addresses performance, privacy, and CA reliability with a certificate extension. A web server can run an OCSP check on its own certificates and attach the successful responses to them, refreshing them periodically. Clients receiving a fresh signed OCSP response with a certificate need not fetch a copy themselves. It does slightly increase the size of a certificate, but the size increases pale in comparison to the footprint of live OCSP lookups.¹⁰

OCSP Must-Staple addresses OCSP’s robustness concerns. A certificate can include metadata instructing clients to reject the certificate if it doesn’t include a successful stapled OCSP response. With OCSP Must-Staple, certificates behave almost as if they have a short one-week lifetime.

Must-Staple has limited adoption: fewer than 1% of all unexpired TLS certificates use this feature.¹¹ Any failure in the OCSP pipeline means downtime. This risk prevents most ACME clients from making it the default setting. Most webmasters won’t find the benefits worth the cost of adoption and the risks involved. See Improving Revocation: OCSP Must-Staple and Short-lived Certificates by Mark Goodwin, published on 2015-11-23 for Mozilla’s rationale.

OCSP Expect-Staple

The OCSP Expect-Staple proposal gained some adoption from a limited number of websites and received some browser-side experimentation but never took off. OCSP Expect-Staple by Scott Helme introduces the concept.

The design of OCSP Expect-Staple resembles HTTP Strict Transport Security (HSTS), so let’s examine HSTS first. HTTPS-only websites almost always keep an HTTP site live on port 80 for redirection to the HTTPS site. An attacker can still intercept unencrypted HTTP traffic on the HTTP request before the HTTPS redirection. HSTS mitigates this: the website instructs the browser to prefer HTTPS for all future navigation. Websites can opt-in to a client-side list of domains forbidding plaintext HTTP, called the HSTS Preload list. Membership in the preload list ensures that TLS protects the initial request to a website, too.¹²

OCSP Expect-Staple applies the concepts behind HSTS to OCSP Must-Staple instead of HTTPS. In a response header, the website can tell browsers to expect stapling on all future renewals of a given certificate. Browsers will know to reject any certificates without a stapled OCSP response, should a malicious server send a revoked certificate and omit the staple.

Chromium experimented with Expect-Staple in 2016 and even had an initial preloaded list, but Chromium later retired all support. Then, it retired all support for OCSP (including stapling and Must-Staple).

Poor implementations

The most popular Web servers (uncustomized Apache and Nginx) have poor support for stapling. I’m unfamiliar with Apache, but Nginx will happily serve a stale OCSP response. Nginx has a broken DNS resolver that can cache the wrong IP of an OCSP stapling server. I worked around the issue with a custom version of certbot-ocsp-fetcher, but I don’t expect most system administrators to use a shell script to work around broken servers or to migrate to something that gets it right (such as Caddy). When the most popular web servers ship broken stapling implementations for years, we need to try something else.

Querying CRL shards

Recall that most clients can’t query and update giant CRLs directly. This inefficiency motivated the creation of OCSP. Ballot SC-063 also permits CAs to partition their CRLs into smaller “shards”. Each shard has a publicly available URL.

OCSP-enabled certificates contain an OCSP URL in their metadata for clients to submit OCSP queries. Let’s Encrypt plans to replace these OCSP URLs with the URL to a CRL shard containing revocation information for that certificate. Instead of querying a CA’s OCSP endpoint, clients download the relevant CRL shard containing the revocation status of several certificates at a time.¹³

Downloading the revocation status for many certificates represents a partial privacy improvement. Querying entire shards instead of individual domains adds entropy: a CA doesn’t know which entry on a CRL shard a client needs to check.

Clients will also see bigger downloads, as shards have footprints several times the size of single OCSP lookups. Remember that “modern” websites often contain sub-resources from many domains. As CRL shard downloads accumulate, the small size savings over summarized CRLs (see next section) might not justify the privacy risk.

CAs find this solution easier than OCSP, but I don’t think this resolves most of the OCSP issues clients experience. Directly querying CRL shards only partially mitigates each of the four OCSP issues I enumerated.

Client-side summarized CRLs

Browsers subset or compress the giant set of all CRLs into compressed client-side lists with frequent push-based updates to keep browsing traffic private. Chromium CRLSets subset the complete set of CRLs with some inclusion criteria, while Mozilla’s CRLite uses Bloom filters to compress a list of all current and revoked certificates. Let’s Encrypt refers to both technologies as summarized CRLs.

Google’s approach: CRLSets

Chromium has a data set called “CRLSets”. CRLSets initially contained a small fraction of all unexpired and currently-revoked certificates, preferring high-impact and Extended-Validation sites over smaller, unimportant domains such as seirdy.one. It later expanded to cover certain reasons for revocation.

My search through scattered documentation ended with three excellent articles:

Revocation checking and Chrome’s CRL by Adam Langley, published on 2012-02-05, introduces the concept and motivation behind CRLSets.
Revocation still doesn’t work by Adam Langley, published on 2014-04-19, explains why the Chromium team didn’t design CRLSets to scale to all revoked certs. He suggests probabilistic data structures but cites their inherent error rate.
An End-to-End Measurement of Certificate Revocation in the Web’s PKI, published on 2015-10-28, evaluates several certificate revocation mechanisms and finds that CRLSets covered 0.35% of all revoked certificates.

In 2024 (this year, at the time of publishing), Chromium expanded CRLSets to cover compromised keys to improve the situation. CRLSets still don’t cover mass revocation events due to scalability issues.

We’ve added support for certificate revocations due to key compromise to CRLSet, and enabled enforcement. Any certificate revoked with the key compromise reason code should now be blocked by Chrome clients within 24-48 hours. This approach should work for day-to-day revocation, but will not work for mass revocation events, due to a limit on the max size of a CRLSet.

— Chrome Security 2024 Q2 Update

Given the subset of revoked certificates covered by CRLSets, I don’t consider them a robust solution to certificate revocation. This remains Chromium’s single current method for certificate revocation. Firefox used a similar mechanism called OneCRL, but it later migrated to a new approach called CRLite with full coverage.

Mozilla’s approach: CRLite

The second article by Adam Langley mentioned compressing certificate revocation lists into probabilistic error-prone data structures for better coverage with a small size. Firefox’s CRLite takes this approach with Bloom filters but without the errors.

Certain browsers (Safari, Chromium/Edge) require CAs to participate in Certificate Transparency (CT). Certificate Transparency logs are append-only distributed ledgers that publicize all CA-issued certificates for public scrutiny.¹⁴ All certificates in CT receive a signed certificate timestamp (SCT) cryptographically proving their presence in a CT log, which browsers can check. Safari, Chromium, and derivatives perform these checks; Firefox currently lacks support for CT.¹⁵

The CRLite Bloom filter generation process can compare the filter against actual CT logs to remove all errors. The result has complete coverage of certificate revocations with a tiny footprint and an error rate of zero!

CRLite has a much smaller storage footprint than the hundreds of megabytes CRLSets would need for complete coverage. I still find this footprint too large for sufficiently constrained clients. When it first rolled out, it weighed 10 megabytes with a 580 kilobyte daily download for updates. CRLite’s footprint has at least doubled since then and continues to grow.¹⁶

Apple’s approach: valid.apple.com

Apple adopted an approach similar to CRLite using Bloom filters; it’s known as “valid.apple.com”, or simply “valid”. I found a now-unlisted WWDC 2017 presentation called Your Apps and Evolving Network Security (video/quicktime); the relevant part begins around 00:17:45. According to the 2017 presentation, when a lookup against Apple’s summarized CRL has a positive signal, clients perform an OCSP lookup when no stapled response exists.

This approach reduces the number of live OCSP queries to leak less traffic and slow down fewer connections. At the time of writing, the device I tested still makes regular live OCSP checks.

I won’t discuss valid.apple.com in detail because I’m unfamiliar with Apple’s approach, but this article would be incomplete without mentioning it. Braver souls can browse Apple’s maze of public source code or Apple’s API documentation for Web PKI policies. valid.apple.com lacks any meaningful documentation.

The documentation I cited comes from seven years ago. I suspect the approach has changed: the devices I tested seemed to make OCSP requests for every domain, and a thread on Apple Developer Forums seems to indicate that Apple stopped using client-side summarized CRLs. I expect major changes coming soon: Apple voted to make OCSP optional in SC-064.

Shortcomings of summarized CRLs

As shown in the earlier section, revocation data sets such as CRLSets can’t scale to cover all revoked certificates. Probabilistic filters can, but both have additional issues.

Summarized CRLs make sense for browsers, but not for smaller clients. cURL, small chat apps, mail clients, feed readers, weather notifications, etc. all use HTTPS and all need a summarized CRL updated every few hours. This creates the need for an operating-system-managed summarized CRL, which I doubt would work well if OS-managed certificate bundles serve any indication.

Tiny embedded clients, Internet of Things devices, machines running ancient releases of stable-release distros,¹⁷ retro computers, etc. won’t constantly update an evergreen multi-megabyte revocation filter. Getting a live-updating compressed summarized CRL on short-lived spin-up-spin-down servers might require effort from cloud vendors. Short-lived certificates make for a more realistic option to cater to such clients.

Let’s Revoke

Unlike the other options in this section, Let’s Revoke is just a proposal. Like CRLite, Let’s Revoke involves pushing all active and revoked certificates to a client in a highly-compressed form. However, it scales far better than existing options.

Let’s Revoke requires changes from CAs: they need to generate Certificate Revocation Vectors (CRVs), small bit-vectors, and include them in every issued certificate. Under Let’s Revoke, a CA pushes an incrementally-updated, highly-compressed archive of all CRVs for active revoked certificates to clients. Clients then use the archive to look up every certificate from that CA. Let’s Revoke uses a fraction of CRLite’s storage footprint.

For extra-constrained clients, the CA can offer pull-based Let’s Revoke checks similar to OCSP and querying CRL shards. I’ll disregard live Let’s Revoke lookups in this article, as CAs have already settled on using CRL shards for live lookups as the successor to OCSP.

Getting all CAs on board will prove difficult: getting them on board with certificate transparency, signed certificate timestamps, and CRLs took a long time. Let’s Revoke only offers binary information about revocation status (no reasons, no revocation timestamp, etc.), so clients capable of handling CRLite’s footprint might find Let’s Revoke less useful. However, its ability to scale with a tiny footprint makes it promising for lightweight clients such as Internet of Things devices.

ACME Renewal Information (ARI)

ACME Renewal Information (ARI) is a protocol that notifies a server’s ACME client when a certificate needs renewal. It can tell an ACME client when a certificate grows stale (e.g., after 60 days for a 90-day certificate) or upon certificate revocation to facilitate quick renewal.

Other revocation checks on this page ensure clients don’t trust revoked certificates. ARI ensures servers don’t offer them. Even though ARI isn’t a revocation check, an article describing the complete landscape of revocation checking should at least mention it.

ARI complements other forms of revocation. Both ARI and OCSP Stapling get servers with long-lived certificates to check in with CAs more often to ensure that their certificates remain unrevoked.

The lego ACME client supports ARI thanks to contributions from Let’s Encrypt. See An Engineer’s Guide to Integrating ARI into Existing ACME Clients by Samantha Frank for more on the implementation.

Short-lived certificates

Recall that CAs have a deadline to revoke a certificate; seven days represents the longest possible deadline. A certificate with a lifetime shorter than this can abstain from both OCSP and CRLs.¹⁸

If we reduce a certificate’s lifetime to less than one week, revocation becomes much less of a problem. Instead of “revoking” a certificate, a CA stops re-issuing certificates for a domain and waits for the most recent certificate to expire. The European Telecommunications Standards Institute (ETSI) calls certificates with a lifetime of no longer than seven days short-lived certificates.¹⁹

Live OCSP checks, sharded CRL lookups, and summarized CRLs add centralized points of failure for client-side revocation look-ups. Attackers can block component updates, online OCSP checks, or CRL shard fetches.²⁰ Short-lived certificates add no more points of failure.

Short-lived certificates come with their own set of challenges:

Webmasters have narrow time windows to fix certificate issues. They’ll need to set up monitoring, alerts, and backup CAs should they not want a CA’s reliability to bottleneck their own.
CAs need to issue certificates far more often, increasing their load. Phasing out OCSP frees up some resources for them to do this, although CAs need much fewer resources for serving an OCSP response than for renewing a certificate.
CAs need to improve their availability. Large ones can take down millions of services by going offline long enough.

Overcoming these obstacles will take much work. ACME-STAR and delegated credentials for TLS look like promising attempts to shorten the longevity of certificate trust in the Web PKI.

ACME-STAR

RFC 8739: Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) outlines how ACME-STAR improves efficiency when issuing short-lived certificates at scale.

Requesting a certificate from a CA requires the CA to issue a certificate immediately, even during heavy load. Shrinking the issuance window from two months to mere days would dramatically increase this load. We require an alternative to issuing certificates on-demand. CAs already generate OCSP responses ahead of time and offer them for ACME clients to download and staple, so why should they handle short-lived certificates differently?

With ACME-STAR, CAs can schedule certificate re-issuance, generating them ahead of time for ACME clients to download later. ACME clients no longer need to request certificate generation; instead, they regularly re-fetch the most recently generated certificate.

Delegated credentials

An Identifier Owner (IdO) is a party that operates and controls an identifier (usually a domain name²¹). Traditionally, CAs issue a TLS certificate to an ACME client operated by the IdO. Often, the IdO delegates another party with more infrastructure to serve responses on its behalf. How do we handle certificate issuance when the IdO delegates a separate ACME client operator?

Servers fronted by Content Delivery Networks (CDNs) generally trust the CDN to handle TLS. The CDN has a TLS certificate that verifies a trusted link between ownership of the certificate and use of the domain name. The TLS certificate doesn’t, however, prove any involvement from the IdO, the one who holds and controls the domain name. The IdO ostensibly communicates with the CDN over one TLS connection, and the CDN communicates with clients using a separate TLS connection. We extend the trusted CDN-to-domain link to include the IdO-to-CDN link with a delegated credential.

A delegated credential is a short-lived certificate that the delegate (such as a CDN) frequently re-generates on behalf of its IdO. A CA’s private keys sign a normal TLS certificate to show approval from the CA. A delegated credential receives one more signature: the IdO’s longer-lived TLS key also signs the delegated credential.

Delegated credentials solve three problems:

Clients can now verify that the TLS key sent by a CDN has approval from both the CDN and the IdO behind the CDN.
Clients receive the benefits of short-lived certificates: they don’t have to worry about revocation.
We have a standard, vendor-neutral way for CDNs to generate certificates on behalf of an IdO without access to the IdO’s private keys, in a more efficient manner than current approaches such as Cloudflare’s “Keyless SSL”.²²

Delegated credentials solve revocation of the certificate issued to the CDN, but not to the IdO. Should a CA revoke an IdO’s long-lived certificate, we need another revocation solution. Delegated credentials address the need to distrust CDNs, so we can’t rely on CDNs to respond to the revocation of the IdO certificate.

I still find delegated credentials worthwhile in the context of revocation. They could lay a foundation for future advancements to enable revocation checking of both certificates: the delegate’s and the IdO’s.

RFC 9345: Delegated Credentials for TLS and DTLS outlines the mechanism that Cloudflare, Facebook, and Firefox use for delegated credentials with other rationales.

ACME-STAR Delegation

ACME-STAR lays its own foundation for delegated credentials in RFC 9115: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates.

Don’t feel too optimistic about this proposal: the version of delegated credentials used by Cloudflare, Facebook, and Firefox doesn’t use ACME-STAR, let alone ACME-STAR Delegation. Its publication came almost two years after the final revision of ACME-STAR Delegation, and it doesn’t mention ACME-STAR Delegation anywhere in its “Related Work” section.

For an introduction to the proposal, see Certificate Delegation with ACME and STAR Certificates by Yaron Scheffer, one of its co-authors.

My proposals

Eliminating single points of failure

Browser-summarized CRLs and live checks have a single point of failure: if a malicious party blocks component updates or live checks, they can block revocation information for a compromised certificate. We can mitigate this issue by decentralizing the points of failure. I like the idea of using Signed HTTP Exchanges (SXGs) to enable other parties to serve revocation filters while verifying their authenticity. I recall hearing proposals for serving them over a WebRTC or WebTransport-based peer-to-peer swarm resembling WebTorrent.

We can also use SXGs to distribute CRLs or CRL shards.

Enforcing short-term certificates

I have two proposals that can work alongside existing proposals for short-lived certificates.

Today, Certificate Authority Authorization (CAA) DNS records restrict the issuance of certificates in several ways:

Restrict CAs permitted to issue certificates to a given domain.
Restrict domain validation methods accepted (RFC 8657).
Restrict ACME account URIs for a given CA (also RFC 8657).

CAA records should receive two more extensions:

Restrict issuance to short-lived certificates.
Restrict approved delegates for delegated credentials.

With the first extension, an attacker who triggers a misissuance would compromise it for a few days or hours rather than months. The second extension limits the potential for rogue delegates to serve traffic on behalf of an IdO.

I want to see the protections offered by Expect-Staple preloading for short-lived certificates. HTTPS Resource Records (RRs) or client-side preload lists can proactively tell clients to distrust any long-lived certificate for a domain.¹²

These two proposals might initially seem identical and redundant, but they serve different purposes. A CAA extension tells CAs not to issue long-lived certificates; HTTPS clients ignore these. An HTTPS RR or client-side preload list tells clients not to trust a long-lived certificate if one already exists. Both proposals work together to protect against long-lived compromises on two fronts.

Incremental change: shorter long-lived certificates

Every week we shave from the average certificate’s lifetime means:

One less week an attacker has to exfiltrate a key.
One less week a compromised cert has to stay in a revocation list.

Every reduction we make to certificate lifetimes translates to smaller, more manageable revocation lists. Client-side Bloom filters can shrink, CAs can more gradually scale up and address difficulties with shorter lifetimes, and everybody has a lower likelihood of trusting a compromised certificate.

We don’t have to go down to ten-day lifetimes right away. I propose starting by shrinking lifetimes from three months to six weeks, with biweekly renewal. This would encourage webmasters to set up alerting systems for renewal failures, as they’ll have just two weeks to notice failures. It’ll also potentially reduce the growth rate of revocation filters until we adopt better options.

Requesting a shorter lifetime

ACME clients can set a notBefore and notAfter parameter in their certificate request to customize the exact certificate lifetimes. CAs that support this feature include:

Sectigo (through ZeroSSL)
Google Trust Services

ACME clients that support these parameters include:

lego (recommended)
acme.sh²³
Posh-ACME

Conclusion

With OCSP on its way out, the end draws near even for robust OCSP-based options such as OCSP Must-Staple. The future lies in:

Live lookups using sharded CRLs
Summarized CRLs such as CRLite and Let’s Revoke
Short-lived certificates using ACME-STAR. Delegated credentials only partially address revocation.

Live sharded-CRL lookups resemble live OCSP lookups. They differ in their lower operational complexity for CAs, added noise for a slight privacy improvement, and larger downloads. Summarized CRLs seem like the opposite approach to OCSP, downloading all current revocations in advance and checking them locally.

I find short-lived certificates a spiritual successor to both by applying OCSP’s approach to certificate issuance. All three options represent improvements, but I find short-lived certificates more robust. Unfortunately, without better tools, short-lived certificates place a greater burden on webmasters. The fact that seirdy.one has a three-month certificate at the time of writing (admittedly, with OCSP Must-Staple) illustrates the height of this barrier as of late 2024.

That said, not all sites need to adopt short-lived certificates. Client-side revocation filters increase in total size and daily download footprint every year, but a large enough share of sites adopting short-lived certificates would mitigate that trend.

We have so much more work to do. Most non-browser clients support none of the revocation solutions outlined on this page. All BoringSSL-based clients, including Chromium, have no support for OCSP (including OCSP stapling). This means most Web traffic lacks robust revocation checking. We need libraries that support delegated credentials. We need CA support and server tools for ACME extensions, such as ACME-STAR.

Aside: browser wars

Firefox continues (rapidly) playing catch-up to Chromium on important aspects of browser security, but its security edges ahead in some areas. It’s the best at revocation checking, but the worst at alerting webmasters that they need to revoke.

Firefox has the best support for OCSP (including OCSP Must-Staple and an option to require OCSP and make it hard-fail), years after Chromium removed all OCSP support.
Firefox uses complete and error-free Bloom filters in CRLite. Chromium covers a fraction of all revoked certs in CRLSets. I’m too unfamiliar with Safari’s approach to comment.
At the time of writing, Firefox stands alone as the single browser with support for delegated credentials.

For years, Firefox has also been the only one of the three major browsers to lack any support for Certificate Transparency enforcement. Without enforcing CT, domain owners won’t know when misissued certificates exist. All the revocation checking in the world won’t tell a domain owner when they need to revoke.

Acknowledgements

Thanks to Andrew Ayer for giving me detailed feedback on an early draft. He offered feedback that significantly improved this article by:

Pointing out several areas needing elaboration.
Linking me to Chromium’s Q2 2024 update to fix my outdated information.
Highlighting at least six factual errors.
introducing me to valid.apple.com.
Telling me about the relevance of Firefox lacking CT support.

Erin Alexis Owen Shepherd also reviewed a draft. Among other feedback, they encouraged me to mention pre-OCSP CRLs; this was the only part of the history of revocation I hadn’t covered.

See the section with my proposals for an example of how an attacker can compromise certificate issuance for a domain unprotected by CAA DNS records. An attacker might also steal your private keys, but at that point, you have worse things to worry about. ↩︎
Relatively speaking, this part is easier than revocation but that doesn’t make it easy. High-volume free CAs such as Let’s Encrypt can’t handle individual requests for revocation. They usually revoke certificates in bulk when they experience an issue. ↩︎
I noticed people referring to CRLSets and CRLite as types of CRLs but I find the term inaccurate. A Certificate Revocation List contains revoked certificates for a given CA complete with metadata about reasons for revocation; browsers’ revocation databases accumulate and subset or compress all CRLs into a single list or filter with limited metadata.

I still needed a term that referred to CRLSets, CRLite, and Let’s Revoke. Let’s Encrypt picked “summarized CRLs”, so I decided to compromise and use their term despite my reservations. ↩︎
Source: W3Techs. ↩︎
For more staff comments, see some forum replies:
- A multi-part answer to what will happen to Must-Staple by Aaron Gable
- We will make sure we have a solution for anyone with OCSP must-staple enabled by Matthew McPherrin.
- This is probably at least a year, if not more, away by Matthew McPherrin.
Both staff members find OCSP, even with Must-Staple, the wrong long-term solution. ↩︎
ACME stands for Automatic Certificate Management Environment, the standard protocol for automating certificate management between certificate authorities and servers. ↩︎
I even used the dfn HTML element like a good little HTML author. 🥺 ↩︎
See section 4.9.1.1 of the CA/B Baseline Requirements⁹ for 24-hour and five-day deadlines. The next section (section 4.9.1.2) describes seven-day deadlines. Past compromise of a subscriber key, authorization during certificate requests, or domain validation leaves a CA with 24 hours to revoke.

The Baseline Requirements exempt short-lived certificates from this deadline. I find the tradeoff acceptable, given how many compromised certificates still won’t experience revocation in time but will be renewed. ↩︎
For all the requirements CAs must obey, read the CA/Browser Baseline Requirements. I recommend reading through them for a fascinating overview of what CAs do. ↩︎ ↩︎
I oversimplified the nuance of the size increase. HTTPS clients that support OCSP cache live OCSP responses for a week, so later sessions will have a lower footprint than they would if the certificate had a stapled OCSP response. The footprint of a webpage might eclipse the footprint of a stapled OCSP response, but remember that HTTPS responses besides webpages exist. Instant messages, API responses, etc. tend to weigh less and often have significant latency constraints. ↩︎
Ballot SC-064’s Google Doc for background, rationale, and considerations cites a survey of all unexpired certificates at the time in CT logs, finding that 0.0622% of all certificates used Must-Staple. ↩︎
I always found protecting the initial request with a client-side domain list a horrible, but effective, hack. We should have a way to query available connection methods for a domain using the correct venue for querying domain metadata set by a domain owner: DNS.

We have a better solution today with HTTPS resource records! These specify how to access an HTTPS service before making an HTTPS connection. They list the availability of HTTP/2 and HTTP/3 (both require TLS), an IPv4/IPv6 address, and Encrypted Client Hello keys.

In an alternate timeline where OCSP Expect-Staple took off, perhaps HTTPS resource records could include Expect-Staple metadata. ↩︎ ↩︎
If you’re too impatient to wait for shard URLs embedded in certificates to roll out, look up the CRL for a given certificate in the Common CA Database (CCADB). All three major browser vendors require CA participation in the CCADB; it’s the place to look for CRLs today, and therefore critical to their generation of summarized CRLs. ↩︎
Note that CT logs don’t specify revocation status. Revocation happens after certificate issuance; the CT log already lists the certificate by then. ↩︎
Follow Firefox’s progress for implementing CT in Bug 1281469. ↩︎
Updating summarized CRLs requires browsers to make regular automatic connections by default. I find browser patchsets to turn off all automated connections misguided partly because they break revocation. ↩︎
Here’s your regular reminder that Debian Extended Long-Term Support exists. Debian 8 “Jessie”, released on 2015-04-25, will continue to keep security professionals up at night with officially-endorsed third-party limited commercial support from Freexian through 2025-06-30. Debian 12 support lasts till 2033. ↩︎
Yes, one week. Firefox skips revocation checking for certificates with a validity period shorter than 10 days. Until recently, CAs and browsers agreed that the definition of a short-lived certificate required a validity period shorter than 10 days. The CA/Browser Ballot SC-064 v4 specifies adopting the European Telecommunications Standards Institute (ETSI) specification for short-lived certificates,¹⁹ constraining their lifetime to the maximum time to process a revocation request. This will shorten the maximum lifetime of a short-lived certificate from 10 to 7 days by 2026-03-15. ↩︎
Fittingly, the canonical location of this ETSI specification lives on a server experiencing live OCSP failures. I saved an archived copy of the ETSI specification for certificate profiles. ↩︎ ↩︎
See my own proposals for a mitigation to summarized-CRLs’ single point of failure. ↩︎
Valid identifiers in the Web PKI also include IP addresses and .onion addresses, but most CAs don’t offer free certificates for those. ↩︎
Delegated Credentials for TLS on The Cloudflare Blog describes this motivation in more detail. Essentially, a delegation credential gets rapidly pushed to the edge server. It represents an efficiency improvement over edge servers periodically requesting new certificates. ↩︎
I don’t recommend acme.sh. Sandboxing complex shell scripts proves difficult. acme.sh has had severe arbitrary remote-code-execution vulnerabilities exploited by a CA: see CVE-2023-38198. While acme.sh developers fixed the vulnerabilities, they revealed the difficulty of securing a complex shell script that handles untrusted content. ↩︎

Takeaways from the Google Content Warehouse API documentation leak

seirdy@seirdy.one (Seirdy) — Thu, 30 May 2024 08:47:38 +0000

Introduction

In March, the official Elixir client for Google APIs received an accidental commit for internal non-public APIs. The commit added support for Google’s Content Warehouse API, which includes Google’s 14,000+ search ranking factors. Oops! Some people noticed this after its redaction earlier this month, and the news broke on May 28. You can read through the Content Warehouse API reference on HexDocs. I skimmed through these and read some blog posts by others who looked more deeply.

In particular, I referenced Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked by Mike King. Note that Mike King’s article doubles as an advertisement for his company’s services and for the legitimacy of search engine optimization (SEO) companies in general. I don’t endorse that message. I disagree with some of its claims, and elaborate on them in the coming sections. That said, I found the article well-researched. It cross-references information against other leaks, too.

Thoughts on individual ranking factors

Google has over 14,000 ranking factors. I have not and will not read them all. I went through what other bloggers found notable, the PerDocData page, and what looked interesting when I searched for keywords I thought would reveal important ranking factors.

Small personal sites and commercial sites

Google determines if your site is a small personal site¹ and calculates a commercialScore in PerDocData which indicates [the] document is commercial (i.e. sells something). The docs have no information about whether either signal is positive or negative. Given how Google results look today and the language it uses in its documentation for manual reviewers,² I conclude that personal sites don’t receive a significant boost. If anything, they may be demoted instead.

I feel disappointed. I always considered the bias against small sites unintentionally emergent from them having no SEO budget. If a solution already exists, why doesn’t Google use it to even this gap? A more optimistic interpretation is that this factor will have weight when it’s ready and resistant to manipulation, but I don’t see incentives lining up to make that happen.

Font size‽

Google tracks “weighted font size” to notice key terms. Separation of content/semantics and form/presentation is baked into the DNA of the Web. Google should stick to semantic HTML elements such as <dfn> and <dt>, or at least <strong> and <em>.

I worry that people will interpret this piece of API documentation as advice and run with it. Search engines have the power to incentivize good behavior, and this piece of information has the opposite effect. Visual emphasis should derive from semantic meaning, dammit!

This might have no weight in production. Perhaps Google uses the font size factor during A/B testing, comparing how results change when considering both styling and semantics. Google tracking something isn’t evidence that Google uses it in production. A closer read of the docs shows Google tracking ten font metrics, and I don’t believe that attributes such as medianLineSpan and fontId are ranking factors. It’s still plausible that font size impacts ranking since Google does track font size separately as an attribute of anchor text.³

Chrome user data

Google uses Chrome and click data, much like how Brave Search uses Brave data.⁴ I don’t like this, as it lends itself to clickbait and chasing engagement rather than actual quality. At least, unlike Brave, Google doesn’t measure clicks on competitor engines. This contradicts many official docs and spokespeople. I would put a disclaimer like the one in the earlier section, but Mike King cross-referenced this against other leaks that confirm as much. Plausible deniability seems low.

Manual review

golden (type: boolean(), default: nil) - Flag for indicating that the document is a gold-standard document. This can be used for putting additional weight on human-labeled documents in contrast to automatically labeled annotations.

— Google Content Warehouse API documentation: GoogleApi.ContentWarehouse.V1.Model.NlpSaftDocument

The existence of manual review to evaluate Google’s ranking has never been secret, but evidence that manually reviewed documents can have a ranking adjustment is new.

Manual ranking can combine with modifications to your ranking algorithm to bias your centrality algorithm around handpicked pages, which is how Marginalia achieves its anti-SEO bias.⁵ Personalized PageRank is one such algorithm, documented in the original PageRank paper. I like the use of manual review for “gold-standard documents” when applied to centrality algorithm biasing. However, I don’t know how I feel about manual reviewer scores directly appearing as a result ranking factor.

Like font size, we don’t know whether Google actually uses manual review in production ranking factors. Google might catalog it here to run tests of expected-versus-actual ranking. Directly or indirectly, it shows that Google does take manual reviews into account in some way.

Bias against new sites

It’s not just you. Google has a bias against new sites due to their spam potential.⁶ Contrary to what official statements say, Google has a “sandbox” for new sites. Google also uses domain registration information.⁷ Mike King’s post says this comes from Google Domains itself, but I haven’t found evidence to back this up. Current domain registration records are public. An organization such as Google can use them to build a catalog of historical registration information without tapping into its domain registry. Anybody with whois can do this!

Truncation

Google does truncate pages to a certain number of tokens,⁸ like most engines, instead of reading long pages indefinitely. I find this strange: based on keyword matches, I’m sure Google has read to the end of some of my longest blog posts. Some fill almost 100 pages printed out (yeah…I have a problem). Google uses a limited number of historic versions of pages,⁹ so this isn’t due to historical versions of my page. Perhaps the token limit is just that high.

Author name mismatches

Google extracts the same piece of metadata (e.g., published/updated timestamps or author names) from wherever it exists (the URL, byline, natural-language processing, structured data, the sitemap, etc.). For authors, it does seem to care about mismatches. Public documentation allows an author entity to have many names, and this factor doesn’t necessarily contradict that. I imagine that ensuring author name consistency could create bias against people who do specify different authors in different parts of the same page (plural systems come to mind), especially when we consider false positives. I’m uncertain; this is speculation on my part.

A cold shower: this isn’t as significant as some SEOs claim

We only have API documentation. We don’t know about any hidden knowledge, whether any of these factors have a ranking weight of “zero”, whether any of these conditionally apply, which are only used internally for testing, etc. As I said in prior disclaimers, some factors might exist for testing purposes. Serious conclusions drawn from this leak are, to some degree, speculation.

I wouldn’t panic over how SEO companies use this leak to game the algorithm and ruin search more. Given their track record of missing the forest for the trees and the ever-changing hidden weighting factors we can’t see, we have little reason for concern. I imagine certain people in the SEO industry jumping to conclusions based on word choice in these API docs, not realizing how words’ original legacy meanings and current meanings are different.

For example, per-page metadata includes integer attributes such as crawlerPageRank and pagerank2, but PageRank is no longer a useful way to build a ranking algorithm for the entire Web. The attribute might no longer carry weight, or the decades-old PageRank centrality algorithm might not populate this anymore. To put this in perspective, the docs mention a HtmlrenderWebkitHeadlessProto but Google’s known to use a Chromium-based browser to render pages. Chromium hasn’t used WebKit in a decade; it hard-forked WebKit to make Blink in 2013.

Per-page metadata also includes a toolbarPagerank integer attribute that hearkens back to the ancient Toolbar PageRank; this also probably doesn’t carry weight today. You can read more about Google’s use of PageRank and Toolbar in RIP Google PageRank score: A retrospective on how it ruined the web by Danny Sullivan.

Conclusion: my takeaways

I still despise how the SEO industry and Google have started an arms race to incentivize making websites worse for actual users, selecting against small independent websites. I do maintain that we can carve out a non-toxic sliver of SEO: “search engine compatibility”. Few features uniquely belong in search engine, browser, reading mode, feed reader, social media link-preview, etc. compatibility. If you specifically ignore search engine compatibility but target everything else, you’ll implement it regardless. I call this principle “agent optimization”. I prefer the idea of optimizing for generic agents to optimizing for search engines, let alone one (1) search engine, in isolation. Naturally, user-agents (including browsers) come first; nothing should have significant conflict with them.

If you came to this article as an SEO, I don’t think I can convince you to stop. Instead, remember that it’s easy to miss the forest for the trees. Don’t lose sleep over one in fourteen thousand ranking criteria without other data backing up its importance and current relevance.

Consider my rule of thumb, whose relevance will outlast this leak: assume Google looks at whatever information it can if it helps Google draw the conclusions its public guidelines say it tries to draw, even if those guidelines say it doesn’t use that information. The information Google uses differs from what it tells the public (yes, Google lied), and changes with time; however, Google’s intent makes for less of a moving target. This leak might contradict how Google determines what it should rank well, but not what it looks for. A good reference for what Google looks for is Google’s search rater guidelines for manual reviewers.

Google lied, but don’t uncritically fall for the coming SEO hype.

See the smallPersonalSite attribute of QualityNsrNsrData. ↩︎
See the conclusion, or snippets of the Google Search Central documentation such as this page describing the EEAT principle: experience, expertise, authoritativeness, and trustworthiness. ↩︎
AnchorsAnchor has a fontSize member with no extra documentation. ↩︎
I’d always assumed (in private, due to a lack of evidence) that the Chrome User Experience Report (CrUX) played a role in search rankings. I don’t know if or how this data overlaps with CrUX. ↩︎
The creator of Marginalia documents initial experiments in a 2021 blog post, and later confirmed this on “Hacker” “News”. In 2023, Marginalia switched away from PageRank to a different centrality algorithm. ↩︎
See the hostAge attribute of PerDocData. ↩︎
See RegistrationInfo. It defines createdDate and expiredDate attributes. ↩︎
See docs for numTokens in DocProperties: we drop some tokens in mustang and also truncate docs at a max cap. ↩︎
See the urlHistory attribute of CompositeDocIndexingInfo. ↩︎

MDN’s AI Help and lucid lies

seirdy@seirdy.one (Seirdy) — Thu, 04 Apr 2024 23:15:54 +0000

Introduction

Following the release of MDN’s AI chatbot “feature”, many developers turned to GitHub Issues to voice concerns. Most concerns revolved around the chatbot spouting misinformation on a technical reference expected to contain accurate information, and ethical concerns related to OpenAI and the use of a large language model (LLM).

I don’t find the mere existence of LLM dishonesty to be worth blogging about; it’s already well-established. Let’s instead explore one of the inescapable roots of this dishonesty: LLMs exacerbate biases already present in their training data and fail to distinguish between unrelated concepts, creating lucid lies.¹

A lucid lie is a lie that, unlike a hallucination, can be traced directly to content in training data uncritically absorbed by a large language model. MDN’s AI Help is the perfect example.

Conflating common and uncommon angles

“AI Help” answers usually apply to the common case at the expense of a less-common case, even when asked about the less-common case. One of many examples is horrible accessibility advice.

Example: assistive technology performance tips

Ask the chatbot about a performance technique’s applicability to assistive technology (AT), and it’ll give you advice on performance related to graphical rendering while passing it off as improving AT performance. For example: I often work with large DOM sizes, which can be a performance challenge for AT such as screen- and braille-readers which struggle to handle large accessibility trees.

At one point, I wanted to use content-visibility to improve large-DOM performance. Until later, I didn’t realize that its relevance to the accessibility tree was so different from its relevance to rendering performance. Here is one answer to the question I have many DOM nodes. How can I improve AT performance using content-visibility?

To improve accessibility tree (AT) performance using content-visibility, you can utilize the content-visibility: auto property. This property allows you to improve page performance without negatively impacting accessibility.

When you apply content-visibility: auto to off-screen content, it remains in the document object model (DOM) and the accessibility tree. This means that the content is still accessible to assistive technologies, but the styles for off-screen content are not rendered. However, it’s important to note that elements intentionally hidden with display: none or visibility: hidden will still appear in the accessibility tree.

If you want to prevent an element from appearing in the accessibility tree, you can use the aria-hidden="true" attribute.

Here’s an example of using content-visibility: auto to improve rendering cost for long pages:
section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}
In this example, the section elements have content-visibility: auto applied to them. This allows the user agent to skip rendering work (including layout and painting) for off-screen sections until they come close to the viewport. By skipping the rendering work, the initial page load becomes faster, improving performance.

Remember, content-visibility: auto helps optimize rendering and layout, but it’s important to ensure that your content remains accessible to all users.

There are multiple inaccuracies present,² but I’ll focus on a glaring one:

This response cites an MDN page that contradicts the given advice. While content-visibility: auto does improve graphical rendering by deferring off-screen rendering, this has no impact on the accessibility tree: off-screen content is still accessible to AT (assistive technology, not accessibility tree), find-in-page, etc. Only rendering is deferred.

The assistive technology implications are an afterthought that don’t get equal treatment alongside graphical rendering concerns. Regardless of your thoughts on said treatment: here we see that bias amplified, resulting in misinformation and disability erasure.

Conflating broad and specific questions

Broad questions already tend to have more documentation than specific questions. Trained on this understandably biased documentation, AI Help tends to fall flat when asked for any overly specific advice.

Example: asking about specific page speed metrics

It’s easier to find generic advice on improving load times than it is to find advice on improving specific aspects of load times. AI Help conflates the two, offering incorrect advice for improving a given metric.

Say you run a page speed benchmark using your favorite website speed test,³ and find out that your performance is excellent across the board except for the Time to First Byte (TTFB). A natural follow-up question would be: How do I reduce my TTFB?

Let’s see how AI Help answers:

To reduce your page’s Time to First Byte (TTFB), which is the time between the browser requesting a page and receiving the first byte of information from the server, you can implement several optimizations. Here are some strategies to improve TTFB:

Optimize Server Response Time: Ensure your server responds quickly to requests. This can be achieved by optimizing server-side code, database queries, and server configurations.

Use a Content Delivery Network (CDN): Utilize a CDN to cache and deliver content from servers closer to the user, reducing the physical distance and network latency.

Enable Compression: Compress resources like HTML, CSS, and JavaScript using techniques like GZIP or Brotli compression to reduce file sizes and improve transfer speeds.

Minimize HTTP Requests: Reduce the number of resources loaded on your page by combining files, using image sprites, and minimizing unnecessary requests.

Browser Caching: Implement proper caching headers to allow browsers to store resources locally, reducing the need to fetch them again on subsequent visits.

Optimize Images: Compress and optimize images to reduce their file sizes without compromising quality. Consider lazy loading images to defer loading offscreen images.

Reduce Server-Side Processing: Minimize server-side processing by caching dynamic content, optimizing database queries, and using efficient algorithms.

By implementing these strategies, you can help reduce your page’s TTFB and improve overall performance. For more detailed information and best practices, you can refer to the Performance best practices documentation on MDN.

In this situation, TTFB is the bottleneck. Any advice concerning different aspect of page speed optimization would encourage premature optimization. Despite the question specifically asking about TTFB, we’ve received plenty of performance advice that has nothing to do with it: A page’s TTFB only describes the time spent waiting for the initial byte of a response. The number of subsequent requests and the size of the requests have no impact on it. Points 3 and 6 are premature optimizations; point 5 is a partial workaround but not really an answer.

Blurring the lines classifying LLM lies

Sometimes the boundary between specific/general mislabeling, conflation of overlapping topics, and hallucination isn’t so clear. Let’s look at an example of an LLM blurring the lines between all three.

Combined example: specific information, conflation, and hallucination.

I did some research before enabling a TLS feature called Zero Round Trip Time (0-RTT) on my seirdy.one domain, to make sure it was safe to do so given 0-RTT’s susceptibility to replay attacks. I moved anything vulnerable to replay attacks to alternate domains.⁴ I wanted to know the answer to the question: What are the security implications of 0-RTT on a static site?

Here’s what AI Help had to say:

0-RTT (Zero Round Trip Time) is a feature of the Transport Layer Security (TLS) protocol that allows a client to send data to the server in the first message of the TLS handshake, reducing latency. However, there are security implications to consider when using 0-RTT, especially on a static site. When it comes to a static site, where content does not change frequently and interactions are limited, using 0-RTT can introduce potential security risks. Since 0-RTT data is sent before the server’s response, it can be replayed by an attacker. This means that if sensitive data is transmitted in the 0-RTT data, it could be intercepted and replayed by an attacker to impersonate the client. To mitigate these security risks on a static site using 0-RTT, it’s important to:

Avoid sending sensitive data in 0-RTT messages: Ensure that any data sent in the 0-RTT phase is non-sensitive and does not pose a security risk if intercepted and replayed.

Implement additional security measures: Consider implementing additional security measures such as encryption, authentication mechanisms, and data validation to protect against replay attacks and unauthorized access.

Regularly review and update security practices: Stay informed about the latest security best practices and updates related to 0-RTT and TLS to ensure that your static site remains secure. For more detailed information on 0-RTT and its security implications, you can refer to the TLS 1.3 specification on MDN.

This is the most clear-cut lie that MDN’s AI Help has told me so far. Static sites represent some of the safest uses of 0-RTT, without any extra backend protections: replaying a request for a static asset doesn’t help an attacker until we introduce other complexities to our backend.

On MDN and the Web in general, advice on 0-RTT tends to be general to all sites, or apply to common CMS platforms; little applies specifically to static sites. MDN gave us generic advice that only applies to a complex CMS when asked specifically about static sites.

This is also partly a hallucination: MDN has no documentation on what a replay attack is, or how to defend against it. AI Help made up vague defenses such as “encryption” and “authentication”, even though this is a weakness in authenticated encryption protocols. These are valid defenses on their own, but have nothing to do with the question asked.

An LLM may be able to answer simpler questions, such as:

What is a static site?
Are static sites vulnerable to replay attacks?

The ability to answer such questions isn’t unique. Asking a chatroom, a forum, or even a link-and-summary search engine should pull up useful information.

An LLM cannot be trusted to synthesize different concepts without conflating them, or to switch from broad to specific concepts. Pseudo-hallucinations fill the gap.

Conclusion

Conclusions about MDN’s AI Help

I’ve provided examples of uncommon angles and specific topics that cause MDN’s AI Help to lie.

The Mozilla Blog post Responsibly empowering developers with AI on MDN highlighted positive quantitative feedback for AI Help. Positive perceived helpfulness needs to be multiplied by actual helpfulness before it’s taken into account; in this case, I argue that actual helpfulness is negative. A user unfamiliar with content-visibility (such as a past version of myself) or TTFB only reinforces the harmfulness of such a tool by marking these answers as “helpful”. The high perceived helpfulness counts against this feature’s merit.

Not everything should optimize for engagement. Engagement multiplies harms.

A recurring complaint we heard from our readers was that MDN is excellent when you know what to look for. If you don’t, it’s not easy to discover the information you need…Developers with less experience find it harder to navigate through MDN

— Reflections on AI Explain: A postmortem, by the MDN Team

If all web development questions were easy to answer by browsing MDN, this tool wouldn’t be necessary. Uncommon and specific questions are the hardest questions to answer without expert assistance. A tool designed to answer hard questions that is so likely to fail under these conditions is worse than no tool all.

I do like the tool’s ability to suggest links to relevant MDN pages. Perhaps it could power improvements to MDN search’s result ranking, or suggest keywords for future searches.

Implications for LLMs as a whole

Some topics get written about more than others. Our society disproportionately incentivizes generic, far-reaching, easy-to-create, and profitable content. I don’t think it’s currently possible to source nontrivial training data without biases. More importantly: I’m skeptical that such an impossibly comprehensive data set would eliminate the conflations I described in this article. Tripping over bias to fall into a lucid lie is one of a range of symptoms of an inability to actually think.

The model, per se, doesn’t exist until after the training process is completed, and has no ability to make such decisions at all. It bases its statistical model of language on the entirety of the training data with no discrimination, except maybe a little outlier exclusion.

— Athena Martin in a Fediverse DM

Current LLMs can’t critically examine training data and its biases. For humans, such critical analysis is often difficult; for machines, it’s currently impossible. Until we make such a breakthrough, LLMs can never be remotely honest. Nobody should consider deploying an LLM to perform a role that demands significant accountability. Answering questions honestly and accurately demands accountability for dishonest and inaccurate answers, so this responsibility shouldn’t fall to LLM. To market an LLM as capable of answering questions reflects dishonesty or ignorance; neither inspires trust. Hallucinations are one thing, but miscategorizing facts due to an inability to critically analyze biases and topic relations in training data is something that no amount of reinforcement learning will fix. These are lucid lies.

This article on AI focused on the inherent untrustworthiness of LLMs. Stay tuned for a follow-up article about AI that focuses on data-scraping and the theory of labor. It’ll examine what makes many forms of generative AI ethically problematic, and the constraints employed by more ethical forms. I’ll edit this paragraph with a link to the follow-up post when it’s ready.

Acknowledgements

Thanks to Athena Martin for providing feedback on an initial draft. She helped me better communicate the idea that LLMs are statistical models, not thinking machines. With her permission, I borrowed a quote from her feedback to use in my conclusion.

Thanks to Emily for highlighting that biased data isn’t the root of the issue; the issue is an LLM’s inability to think. I agreed, and reworded (and re-titled) much of this article in response.

I use the term “lie” instead of hallucination because it’s broad. A hallucination is merely one type of lie. LLMs may lie in any way a human can. Lies by omission are the first non-hallucinatory lie that comes to mind. I exhausted other terms: calling them “misunderstandings” implies that LLMs have the capacity to understand things; calling them “bugs” implies that this is due to a programming error; calling them “accidents” implies that this isn’t expected behavior (this article shows why it should be). Telling a lie does not require understanding; repeating one does not require intent. ↩︎
Another inaccuracy: while it’s not standard behavior, many browsers do exclude content from the accessibility tree in response to certain display properties, including display: none. It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties by Adrian Roselli covers this in more detail. ↩︎
I recommend Chromium’s Lighthouse for simple measurements, and the Firefox Performance Monitor for detailed analysis. Plenty of tools exist between those extremes. ↩︎
This included my Webmention collector and my CSP-report collector (only used on my staging site and a dedicated CSP debugging page), which I moved to collector.seirdy.one. All that’s left here is a static site, Libravatar endpoint (implemented in Nginx configs), single-user WebFinger endpoint (implemented with Nginx configs), Webmention endpoint, and a not-so-secret DNS resolver ↩︎

Proposal: an HTML element for spoilers

seirdy@seirdy.one (Seirdy) — Sun, 12 Nov 2023 21:48:00 +0000

Introduction

I wish it were possible to look up any medical issue without being exposed to the most graphic photographs ever taken by man or beast.

— Velveteen, Post on akko.wtf

While browsing the WICG discussion forms, I stumbled upon a proposal for a standardized <spoiler> element in HTML5. I made two comments, and stopped myself before writing a third; this called for a blog post. I think HTML should have a spoiler element.

Toggle table of contents

Prior art

Spoilers are already implemented in several places around the Web, but without a standard set of semantics.

A useful reference is the markup used in the Matrix protocol. Matrix messages may include a standardized subset of HTML, with some additional features provided by HTML attributes.¹

Code snippet 3 (HTML): The following syntax creates a spoiler in Matrix:

<span data-mx-spoiler="optional placeholder text">hidden content</span>

A screenshot of how Element, a Matrix client, renders a spoiler element:

The visual result is typically the placeholder text followed by blurred or blacked-out hidden contents, revealed upon user interaction. Children aren’t limited to text; this is a common approach to hiding images.

An image marked sensitive on Firefish (a Fediverse server) shows a blurred placeholder. Original thread.

Code snippet 4: More special syntax for spoilers:

||optional placeholder text|Fluffychat and Discord hide this.||
>!Reddit hides this.!<
[spoiler=optional placeholder text]BBCode hides this[/spoiler]

BBCode is the oldest example of dedicated spoiler syntax I know of.

Comparison with `details`

On the WICG forum, one user asked about the differences between spoiler and details. The two elements have very much in common; I’d even go so far as to say that spoiler elements could also make use of summary children for placeholder text.² That being said, the semantics and behavior have important differences.

Semantics

While a disclosure widget exists to allow toggling information, a spoiler exists to make information inaccessible without consent: invisible, inaudible, unreadable. A disclosure widget helps divert user’s attention away from hidden text; a spoiler protects users from hidden text.

Following the examples in the “Prior Art” section, summary can be an optional first-child of a spoiler while remaining a mandatory first-child of details.

Behavior

Semantic differences should impact how activation works. Spoiler text should not be revealed until the placeholder text has been read. Unread spoiler text may include off-screen placeholders, placeholders that a screen/braille-reader hasn’t reached yet, and perhaps even spoiler text whose placeholders haven’t reached a magnifier’s viewport. Spoilers shouldn’t be revealed by accident.

For visual users, placeholder text should be in the viewport for a minimum duration. A user-agent should expose a setting to increase this duration. Ideally, it could allow users to supply keywords for sensitive or non-sensitive topics for auto-hiding or auto-revealing spoilers. Spoiler text matching sensitive topics should require some form of additional confirmation.

Functionality such as find-in-page may indicate a match obscured by a spoiler, but shouldn’t activate the spoiler. It may expand a disclosure widget.

Presentation

details is a block element; spoiler can be either an inline or block element. A few words within a paragraph can be hidden behind a spoiler. details tends to work more effectively on larger sections of content. A spoiler should obscure content, but not the size of said content; it obscures content without removing it.

For printouts, behavior should mirror details. Print hidden if it’s hidden in the browser, and print revealed if it’s been revealed in the browser.

Use-cases

Several overlapping use-cases exist:

“Spoilers” for plot-twists. These are common on wikis such as TV Tropes.
A warning for imagery that may be inappropriate in a public setting (you might want to hide erotic or gory content when you’re on the train).
Content-warnings for potentially triggering topics.
Hiding a joke’s punchline, or the answer to a riddle.
Hiding user-generated content that’s been flagged by other users, awaiting moderation.

I could go on. This is an immensely useful feature that HTML doesn’t adequately address right now.

Potential attributes

Some semantic configurability should be possible with HTML attributes:

preview: A boolean attribute for spoiler. Hidden content could have a preview available or have no preview at all. A “true” value could show a partial preview of a sensitive image (e.g. a version with a reduced resolution and saturation, passed through a heavy blur filter); a “false” value could simply hide the content behind censor bars or filler content.
preview-alt: An attribute for any element that supports the alt attribute. This can supply alt-text for hidden versions of media without overly descriptive language, analogous to blurred or pixelated previews. “Black-and-white photo of a large wound” could be an image’s “preview-alt” text, while the actual alt text could describe the image more…vividly.³
loading: img, iframe, and other elements already support loading="lazy" to enable native lazy loading. A thread on the WICG forums proposes allowing the attribute on container elements to apply to their children, singling out details in particular. As spoiler hides content, hidden children may have loading deferred until their parent spoiler element activates.

Considerations

Considerations for user-agents

Many browser developer tools allow viewing a page’s media; for example, the Network Inspector allows rendering the body of an individual request. A request for an image inside a spoiler should not unnecessarily bypass this. Browsers with such features shouldn’t ship spoiler support until a developer-tools toggle for “show spoiler contents” is ready. Should this also apply to spoiler text?
Users who frequently visit a website may wish for a site-specific setting to auto-show sensitive media. This is a common setting on social media sites.
A simple click-to-toggle would interfere with selection, as repeated clicking is a common way to select text. We should come up with an alternative.

Considerations for authors

In some situations, could alt-text be more sensitive than visual media? If so, perhaps preview-alt could apply even without a parent spoiler element.
Good preview-alt-text is descriptive enough to inform the decision to toggle media, but not so descriptive that it needs a spoiler of its own. Reaching that balance is extremely difficult.
This might be a situation in which SEO-style keyword-stuffing might actually have real merit, to accurately trigger users’ own keyword filters.
Authors may wish to provide a JavaScript polyfill for clients that lack support, and perhaps preface their content or links with a noscript warning for clients lacking support for both spoiler and scripting.
How should authors describe severity levels? An image containing blood could depict a minor scrape or severe medical gore. We’ll need guidelines on how to do this, just as we have guidelines on alt-text.

Privacy considerations

User keyword filters may present a fingerprinting vector. Anonymity-focused browsers like the Tor Browser probably shouldn’t expose this functionality. Perhaps spoilers combined with lazy-loading should be disqualified from auto-revealing.
A user who consistently declines to reveal spoilers with certain keywords in the placeholder text may be fingerprinted accordingly. The Tor Browser’s “safest” mode disables lazy loading and JavaScript, which should close this fingerprinting vector.

Further work

We may need to create additional corresponding ARIA roles for spoilers. I can’t decide on an ideal existing one.

We may also need to define a vocabulary for well-known spoilers, and encourage authors to use that vocabulary when relevant. This could improve how well auto-revealing spoilers works. Of course, I’m not proposing that any content matching that vocabulary should receive a spoiler; I’m only proposing to choose that vocabulary when writing spoiler-text, if it’s relevant. I don’t think we should be prescriptive about what to use spoilers on across the entire Web.

There should be a way to spoiler a whole page, or a whole website, if the primary focus of the page/website is a sensitive topic. This is common on sites devoted to erotic or age-gated content.

Other areas may benefit from standardized spoiler-like semantics. Someday, chapter indicators in media containers could come with Sponsorblock-inspired vocabulary; some chapters could be marked “sensitive” and auto-pause while displaying a reason. If other spoiler-like semantics exist, we should create mappings between proposed HTML semantics and existing semantics. Perhaps such an exercise would change how we develop HTML semantics for spoilers.

Snarky thoughts: conflicts of interests

Ad companies probably won’t want to hide ads containing sexual/erotic, anxiety-inducing, or shock content behind spoilers; they profit from what spoilers protect against. Sites with such ads probably won’t benefit from hiding such content behind spoilers if ads are exempt.

A good solution would be for ads to identify themselves as such along with the psychological weaknesses they prey on (porn addictions, anxiety, eating disorders, gambling addictions, etc.) so that user-agents could selectively or globally block them. For some reason, I don’t think adtech companies would like this very much. More research is required to find a form of basic compassion that allows dominant advertising business models to exist.

Acknowledgements

Thanks to Athena Martin for providing feedback on an initial draft. She raised concerns about user-agents without support, the possibility of specifying machine-readable severity levels, and printouts.

Thanks to ~keith for bringing up good points concerning prescriptivity of spoiler norms.

Thanks to Locria Cyber for reminding me about BBCode.

This format is called org.matrix.custom.html. The Matrix Specification Client-Server API, section 11.2.2.6: “Spoiler messages” specifies the spoiler syntax, semantics, and recommended client behavior. ↩︎
Note that summary was originally specified as a block-level button, not an inline element. This may require changes to the definition of summary. I don’t believe that the changes should significantly impact conformant pages, but non-conforming pages that incorrectly use summary elements without the required details parent may be impacted. Perhaps we really do need a new element for spoiler summaries. ↩︎
I came up with the idea of this attribute when I was browsing some Wikipedia articles on medical topics and ended up on the article for “maggot therapy”. I had uBlock Origin configured to make large media click-to-load, and the figure captions told me which ones would be safe to load when others were in the room. However, figure captions aren’t a replacement for alt-text. ↩︎

De-federating P92

seirdy@seirdy.one (Seirdy) — Tue, 20 Jun 2023 22:30:54 +0000

Facebook (“Meta”) is launching a Twitter alternative that will interoperate with the Fediverse, currently codenamed “Barcelona” and “P92” (and likely to be known as “Threads”). We don’t know the extent to which this will or won’t interoperate; admins who’ve met with Facebook/Meta employees to discuss P92 have signed non-disclosure agreements. Most discussion can be framed in two ways:

Whether P92 in particular is worth defederating from, should it involve an ActivityPub server.
Whether Facebook/Meta projects in principle would be worth proactively blocking, should they attempt to interoperate with a Fediverse instance.

I’m going to focus on the latter topic, as we know little about the former.

Privacy concerns

Of the reasons to resist a Facebook/Meta presence in the Fediverse, privacy is relatively low on the list. The best way to mass-scrape Fediverse content has always been via large, established, well-connected instances’ federated timelines. It’s also quite hard to detect. I imagine that most of this happens through instances such as mastodon.social, fosstodon.org, and mstdn.jp.

Authorized-fetch is an excellent way to increase friction for harassment, and it ought to be the default. Unfortunately, it does nothing to stop the scraping methods I outlined. Presenting it as a robust privacy measure gives users a false sense of privacy.

If Facebook/Meta prioritizes data from its users’ timelines and interactions, then enabling authorized-fetch and de-federating might admittedly offer limited protection. They’ve pulled similar moves before, with shadow profiles of non-Facebook users based on phone numbers of its users’ contacts.

Incompatible values and complicity

As I’ve said elsewhere, Facebook/Meta is doing this for a return on investment. This organization has one of the worst track records in Silicon Valley:

Facebook has aided and abetted in genocide…more than once. Myanmar and Ethiopia are the main examples I know of. After Myanmar, Facebook repeated the same process in the Phillipines, fueling Duterte’s bloody drug war that claimed thousands of lives.
Facebook allowed the rise of Hindu nationalism in India, with embarrassingly flimsy responses after receiving news coverage.
Facebook continued on its path despite knowing the harm caused by its recommendation algorithms.
Facebook played a key role in the Facebook–Cambridge Analytica data scandal.
Facebook’s “real-name policy” has its own Wikipedia page for its controversies, most of which relate to cultural supremacy, transphobia, and privacy. Issues persisted years after Facebook claimed to make reforms.

I could go on.¹ Any instance with staff doing any of the above would likely be widely de-federated; Facebook profits from it. If Breitbart, the Daily Stormer, or Alex Jones announced they were joining the Fediverse, we wouldn’t wait until after the obvious happens since we already know what they deem acceptable. Facebook should not get special treatment.

I feel an obligation to resist any further growth of this company. Knowing what this organization has done, and without good reason to believe it has “stopped”, I don’t feel comfortable supporting it. Facebook starts projects like this to secure a return on investment. I don’t want to help Facebook secure a return on this investment.

Administrative decisions should be affirmations of shared community values. Facebook has demonstrated that it values growth at the expense of lives, if necessary. At a certain point, the right way to show our values is to put our foot down and say “no”.

I support initiatives such as FediPact to resist interoperating with Facebook/Meta projects. That being said, as I described in my article outlining my blocklists, I avoid suspending purely based on federation decisions. Remember that the FediPact list is not an authorative or comprehensive list of instances that will be proactively defederating from Facebook-affiliated servers.

See this Fediverse thread for a longer list, and my coverage of how they fragmented the XMPP ecosystem. ↩︎

My Fediverse blocklists

seirdy@seirdy.one (Seirdy) — Tue, 02 May 2023 07:00:54 +0000

I moderate the “pleroma.envs.net” Akkoma instance on the Fediverse, as @Seirdy@pleroma.envs.net.

I maintain four main blocklists for the Fediverse. Do not import them until you’ve read everything until the “receipts” section. I encourage blocklist skeptics to read the “receipts” sections, and to treat them as lists of reported content rather than importable blocklists.

The pleroma.envs.net blocklist

A large list of instances that I find worth suspending. After the first couple hundred entries (imported and then reviewed), I started collecting receipts. Since early 2023, every entry has documented reasons and receipts. I share these with multiple people in a collaborative document, but I don’t share it publicly due to risk of harassment.

Unlike the other two lists on this page, it wasn’t made for general use. You’re welcome to use it as reference, or as one of many sources for a consensus-based list with a minimum required consensus level.

tier0.csv

A much smaller semi-curated subset of pleroma.envs.net suitable for the majority of instances wishing to uphold the Mastodon Covenant’s moderation standards, though somewhat heavy-handed. I hope to make it a good starting point for your instance’s blocklist, with wiggle room for your own adjustments. I encourage you to add and remove entries as you see fit. Regularly importing tier0.csv won’t account for retractions; a sibling blocklist for tier-0 retractions exists for FediBlockHole users.

Note that this list is larger than the bare-minimum I recommend. the bare-minimum is FediNuke. If you’re skeptical of imported blocklists, you should start there. If you run an instance for many others: please do not blindly import this list unless you intend to review its entries.

FediNuke.txt

A curated subset of tier0.csv, containing what I deem the “worse half” of it. This contains instances I really do recommend most people block, or at least avoid. I try to make it a suitable candidate for a “default blocklist”, and use it as reference when I evaluate the quality of other blocklists.

This list is not comprehensive; to keep this list small, I excluded many really bad instances. I take into account not just severity, but also notoriety and likelihood of reaching/harming people on other instances (e.g. spewing toxicity in others’ mentions, running block-notification bots, etc). Bad instances that mostly keep to themselves are less likely to cause problems for a new admin, and therefore less likely to get included in this minimal list. Finally, I take into account controversy; in order for this blocklist to fulfill its purpose of widely defederating the worst actors, no entry on it should be too controversial outside of the parts of Fedi already likely to reach tier-0. For this to be possible, entries must require minimal context. If a dossier is necessary to understand why it’s worth blocking an instance, no matter how bad it is, it’s unlikely to reach FediNuke.

Criteria are not set in stone. Instances well-known for causing significant problems for many other instances, particularly for instances run by and for marginalized groups, may be added.

All these lists, just like all my content on seirdy.one, are CC-BY-SA licensed. However, I’d rather you not use them in another blocklist-related project without contacting me first. I made a lot of decisions about how these blocklists work and learned some tough lessons; I’d rather not see someone repeat my mistakes.

This post is an attempt to document how they are made, their differences, their intended use, and especially their caveats. It also contains a work-in-progress list of receipts for instances in FediNuke and my Tier-0.

Toggle table of contents

How Tier-0 and FediNuke work

My tier-0 list is a subset of the pleroma.envs.net blocklist. It contains entries that appeared on at least 15 out of 27 other hand-picked instance blocklists (“bias sources”), with exceptions detailed below. Not all Tier-0 entries have the same level of severity; a smaller list containing what I personally deem the “worse half” of Tier 0 is FediNuke.txt. Consensus builds Tier-0; severity builds FediNuke.

When I add a bias source, I may also increase the minimum number of votes required if I find that its blocklist is too close to (or mainly just imports all of) tier-0 or the blocklist of a bias source’s blocklist. That’s the reason why the threshold is 15 instead of 13 or 14.

All entries use the root domains when applicable, or are as close to the root domain as possible without triggering false-positives.

Overrides

There were some block-overrides for instances with fewer than 15 votes. Here’s how I went about overriding:

If an instance has 10 votes, I may elect to add it after additional review instead of waiting for it to hit 15 votes.
If an instance is run by the same staff as another Tier-0 instance and has at least 5 votes, I may add it after asking other admins about it and getting multiple thumbs-up from admins who import tier-0.
If an instance contains blatant/unapologetic bigotry (something really undeniable, like Nazi imagery or excessive use of slurs in violent/hateful/definitely-not-reclaimed contexts) with staff approval or involvement, I may add it to both tier-0 and FediNuke.txt after I get multiple thumbs-up.
If an instance becomes risky even to many tier-0 instances (untagged gore, dox attempts, significant cybersecurity risk, CSAM, etc. with staff approval or involvement): I may add it to both right away, skipping any process. This is rare.

Under ten controversial entries were excluded despite having more than enough votes, after consulting with other admins. Typically, these were instances that didn’t pose a major safety risk, but did fail many admins’ “vibe check” or exhibit major governance issues.

I also excluded Twitter mirrors such as BirdSiteLive and bird.makeup, and bridges to other social media platforms; I maintain supplementary lists for those that don’t require consensus.

Bias sources

Criteria for a bias source:

Has a blocklist I can easily download, possibly with an API key.
Practices timely and proactive moderation: doesn’t just wait for another instance start interacting and cause trouble, and updates more often than once a month. Evaluating this takes time.
Blocks at least half of FediNuke.txt.

The final tier0.csv isn’t a pure representation of agreement between instances; it contains overrides and is merely a subset of the pleroma.envs.net blocklist. Other lists only serve to determine the bias used for filtering the pleroma.envs.net blocklist. The pleroma.envs.net blocklist is technically the only “real source”. Other bias sources shouldn’t be held responsible for the final tier0.csv contents. I’ll explain my motivation for doing this in the next section.

Since accountability for tier0.csv rests on me rather than on other instances, I don’t publish the current bias sources. Blame for any problems in tier0.csv should rest with me, not them.

Motivation for including personal bias

If tier0.csv were merely an unbiased list of the most widely blocked instances, then being on the list would become a self-fulfilling point of no return. If an instance gets blocked by enough other instances, then it shows up on my lists. If an instance shows up on my lists, it will get blocked by other instances which import my lists. If more instances block it…you get the picture. This leaves little room for retractions and mistakes. By making all my blocklists a subset of the pleroma.envs.net blocklist, I ensure only one party needs to be convinced to remove an entry.

Some instances migrate their domains. If the old instance was already deemed worthy of a suspension and the new instance maintains the same staff with no visible attempt to change its reputation, then I deem the new location to be as block-worthy as the old location and make an override. It’s the same bad actors under a different banner.

Refreshing

Refreshes are a manual process. Refreshes update my tier-0 list, but do not update FediNuke; that list is a manually-curated subset of my tier-0 list. Every time I refresh, I get prompted with changes (if they exist) so I can review them. Since my tier-0 is a subset of the pleroma.envs.net blocklist, all additions should have some level of approval from me already, but I’ve started giving new additions a second look anyway. Manual review, subsetting the pleroma.envs.net blocklist, having a large number of bias sources, and some level of vetting for my bias sources should mitigate the risk of one bias source “going rogue” and compromising its blocklist right before a refresh.

Retractions

A separate list exists for retractions from my tier0.csv list. I don’t add entries to my retractions list when I remove dead instances, or when an admin on a removed instance prefers not to be included in it (some wish to remain less prominent).

Intended use

The original goal was to make a blocklist appealing to instances with a more laid-back moderation approach, so that they would actually implement a decent blocklist and limit the reach of the worst actors. Unfortunately, the final tier0.csv blocklist is 350+ entries; this is still a bit much for the moderate instances.

I pared that down to FediNuke.txt, which contains instances that were both really bad and well-known. It’s kind of hard to overlook how shitty each instance on the FediNuke.txt subset is. Common themes tend to be repeated unwelcome sui-bait¹ from instance staff against individuals, creating or spreading dox materials against other users,² unapologetic bigotry, uncensored shock content, and a complete lack of moderation.

I think if you’re starting a well-moderated instance, Tier 0 is a decent place to start (that’s why it’s in the standard CSV format). You should add and remove entries as you see fit. If you’re making a client and want to give it a built-in blocklist, or are looking for a good “default” blocklist: FediNuke is a good option.

However: if your instance grows larger (or if you intend to grow): you should be intentional about your moderation decisions, present and past. Your members ostensibly trust you, but not me. See the “trust but verify” section for for more information.

Rationale for creating two subsets

I used to just make a Tier-0 list. Later, I added the FediNuke list. Some people have asked why I don’t just use one or the other; if Tier-0 was big enough to warrant FediNuke, why publish Tier-0 at all?

I have two reasons for maintaining two blocklists:

I didn’t feel comfortable placing some Tier-0 instances right next to, e.g., openly Nazi instances when they weren’t at the same level of severity. FediNuke’s existence establishes that some instances on the list are much worse than others. Maintaining multiple blocklists makes their subjectivity more obvious.
The lists can work together. As I previously mentioned, the division makes it easier for people to feel comfortable importing blocks. Some admins have found that importing FediNuke and gradually combing through the rest of Tier-0 is more approachable than an “all or nothing” approach.

Use FediBlockHole

The CSV format I use is the format used by FediBlockHole. I do this for two reasons:

FediBlockHole supports retractions: admins can configure a merge strategy to support downgrading an entry’s severity, with the lowest severity (noop) being equivalent to a removal with an optional reason.
Other blocklists use my blocklists as sources, and are powered by FediBlockHole.

If FediBlockHole supports your Fediverse server (it currently only supports the Mastodon admin APIs), I recommend using that if you want retractions to work.

Trust, but verify

I totally get resistance to blindly importing blocklists; I don’t actually feel comfortable going the “import and forget” route myself! The first couple hundred entries of the pleroma.envs.net blocklist started with a few imports, but all domains have since been manually reviewed. For admins who don’t feel comfortable “outsourcing” their moderation to blocklist authors: I generally see pre-made blocklists as a starting point.

Importing FediNuke.txt and then individually importing tier0.csv entries after manual review is a decent way to balance two conflicting needs:

The need to verify suspensions.
Not having the time/spoons to verify all the entries.

Another option is to use some text-processing tools to find entries that are common between Tier-0 and another trusted instance’s blocklist. You can import the overlap.

Finally, you could just do something else entirely. I never use “your blocklist is different from mine” as a block-reason; even “totally open federation” is never the sole reason for pleroma.envs.net suspending an instance. Suspending instances for not using my own blocklist feels wrong; it’d turn these lists into a source of authority and cross the line from moderation to cop behavior.

Before you decide to trust one of my lists, please read the “Mistakes made” section.

Mistakes made

Here, I publicly document all significant mistakes I’ve made in the process. I sort entries in descending order by date addressed.

One mistake hasn’t yet been listed; I’ll wait for approval from one of the people impacted.

Early April 2023: Oliphant’s max list containing bad entries

I made a mistake that didn’t have a negative impact on my lists, but did impact someone else’s. Even if my own lists came out okay, the fact that I allowed this to happen should be enough reason for you to seriously question my judgement.

I used to work with Oliphant when generating lists.³ Oliphant offered his own respository of blocklists (GitHub mirror). Using an approach inspired by my tier0.csv generation process, he made lists generated from consensus across other lists. Unlike tier0.csv, the generated lists don’t have significant manual curation. Oliphant’s tier-1, tier-2, and tier-3 blocklists required decreasing levels of consensus. Until recently, he also offered a “unified max” blocklist containing ~~any entry common across at least two other blocklists~~ every entry from any trusted source.

One of Oliphant’s sources was a single-user instance with many blocks made for personal reasons: the admin was uncomfortable with topics related to sex and romance. Blocking for personal reasons on a personal instance is totally fine, but those blocks shouldn’t make their way onto a list intended for others to use. The admin of this instance gave permission to use this blocklist. However, they did warn us of this fact. With my own encouragement, we decided to use their list anyway.

I had reason to be comfortable with the personal nature of this blocklist. This was was one out of 20 bias sources used for tier0.csv generation, and tier0.csv is merely a subset of the pleroma.envs.net blocklist. These two facts prevented someone else’s one-off “personal” blocks from making its way onto my list. I also found that adding this trusted source only introduced a dozen generally uncontroversial entries to tier0.csv.

Unfortunately, the situation was different for Oliphant’s unified-max blocklist. Several entries made that list for personal reasons. I focused too much on my tier0.csv and failed to notice that anything was off with Oliphant’s lists, even though I bore much responsibility for this blunder.

Tyr from pettingzoo.co raised important issues in a now-deleted thread after noticing his instance’s inclusion in the unified-max blocklist. He pointed out that offering a unified-max list containing these blocks is a form of homomisia: it risks hurting sex-positive queer spaces. Simply claiming that the unified-max list isn’t intended to be imported isn’t enough; there’s a real risk that future admins may import it without reading the documentation. I recommend giving the thread a read.

Oliphant got understandable push-back for this issue in his blocklists, but it’s not fair for all of the criticism to be directed at him and none at me. Many small mistakes from multiple people, including me, cascaded into one big failure.

Since then, Oliphant has removed that admin’s list (and his own) from his blocklists’ trusted sources. I removed the same ones. Oliphant also stopped generating the unified-max blocklist, as the potential for misuse was too great. I became less involved in Oliphant’s list; by the end of August 2023, I decided to withdraw from the project completely. I’m not prohibiting the use of my blocklists in raw-domain form, as I don’t think a “list of domains” constitutes a creative work worth restricting beyond the provisions of a CC-BY-SA license.

July 2023: bad receipt for bungle.online

A receipt for bungle.online, at the time a tier-0 instance, cited slurs from the admin account. One was a racial slur. However, I later found that the slur may have been used in a reclaimed context. I subsequently demoted the instance to tier-1 and removed that receipt. I later abandoned the tier-1 blocklist entirely.

Now I endeavor to be more careful about examining my preconceived notions when using slur-usage as a receipt. If a receipt revolves around slur usage, I should do a better job considering how the slur was used if there aren’t many other receipts indicating a pattern of discriminatory usage. I also should specifically seek approval from people of the relevant marginalized identity before publishing.

Other errata

More minor corrections:

August 2023: I mistakenly said that ryona.agency and plagu.ee have an MRF policy to convert DMs to public posts. This was false: the policy converts followers-only and unlisted posts to public, but not DMs.
August 2023: I assumed that an account called “Shishihime” was a bot. The admin later claimed that it was an actual user. I then retracted the “bot” description.
September 2023: I incorrectly stated that a local user on ap.maladaptive.art was a staff member. I retracted the statement.

Important modifications before importing

If you have read this far and plan to import my lists or a list that imports mine, please delete the following fake entries from the lists or modify the “canary” subdomains:

000delete.this.line.if.you.have.read.the.documentation.on.seirdy.one
canary.tier1.example.com
canary.tier0.example.com
canary.fedinuke.example.com

Doing so signals that you’ve read these docs. If you build a consensus-based blocklist that uses my lists as a source, I suggest adding your own canary domains. “tier1” is a legacy indicator for a blocklist I retired.

If you see an instance whose blocklist contains these entries, unmodified: if it’s a large or open-registration instance, assume the moderators aren’t doing their jobs and do not register for it. Single-user or tiny tight-knit instances are free to import whatever they want, though. Moderators of large or open-registration instances should be willing to set aside ten minutes to read something before importing a list.

If you run a non-private instance that subscribes to a blocklist (whether mine or someone else’s) with minimal manual review, I strongly recommend saying so in your instance’s “About” page or equivalent. Users should know who is responsible for moderation, and that the biases of their instance staff don’t paint the full picture of the biases of the instance’s moderation.

Supplementary blocklists

Some supplementary blocklists I maintain with very different criteria:

BirdSiteLive and bird.makeup: These are services that allow Fediverse users to follow any Twitter user. Now that far-right figures are back on Twitter, these instance pose a problem. Admins wishing to ban a single Twitter user will need to ban that user across over 100 different Twitter mirrors. Moreover, any interactions with bridged accounts are unseen by the account holder on Twitter. Twitter users may not have consented to such mirroring. Admins wishing to simply ban mass-Twitter-mirroring can import this list.
Bridges: Bridges to other social media platforms, excluding Twitter/X bridges, that aren’t opt-in. Bridges to Nostr are common. These are excluded from tier0.csv as they’re in a dedicated list. Nostr is especially worth blocking because most bridges don’t appear to do significant moderation or delegate to relays that do, effectively requiring moderators to moderate the whole network in its unmoderated form and potentially duplicate their work across multiple Nostr bridges.
Corporate social media with user-hostile dark patterns: A short list containing instances run by social media companies that have displayed user-hostile behavior, for anybody who doesn’t wish to support such practices. Privacy abuse, growth-mindsets, dark patterns, and a history of vendor lock-in are common (but not all universal) themes. Not updated very often. I’ve explained my views on Threads in another post: De-federating P92.
Spammy subdomains: These domains are often used for HTTP tunneling or short-lived spin-up-spin-down servers. Fediverse instances running on their subdomains almost certainly aren’t in it for the long haul, and very frequently shut down within hours or days without doing a clean self-destruct. Note that this is not to be confused with traditional dynamic-DNS subdomains, which are often used for longer-lived servers (although some admins do understandably block those anyway).; This list might prove useful in non-Fediverse contexts as well; I imagine it could be useful for moderating Matrix rooms.

Frequently-asked questions

Why don’t you use tags for easy filtering?

Tags remove nuance. There exist gray areas that make it hard to determine whether an instance clearly fits within a tag; choosing to include or exclude that instance is choosing to make a statement about what “counts”. I prefer to describe an instance’s reason in my own words, properly.

How do I get off a list?

If you believe a receipt is inaccurate or you don’t belong on a given list, contact me. My contact info should be easy to find on my “about” page. I can’t promise I’ll respond quickly; feel free to re-send your request if I don’t respond within a couple days. I might not be receptive to requests from FediNuke instances, though. I’d prefer if you made an effort to respond to the concerns raised by a receipt if possible.

Receipts

The following are receipts for instances on my blocklists. Read the text surrounding a link before navigating to it, and let that context serve as a content-warning. No links point directly to the blocked instance; all go to a third-party archiving service.

I use archive links instead of screenshots. Screenshots pose accessibility issues, can be doctored, and are easy to take out of context.

Receipt criteria

Receipts are biased towards patterns in staff behavior or pervasive patterns among users with staff approval, as that generally won’t be solved with a federated report. A one-off user action taken out of context, without any sign of staff endorsement, isn’t enough to end up on one of these lists because it’s not indicative of an instance’s moderation policies.

Receipts revolving around slur usage depend on context. Slurs used in reclaimed contexts aren’t grounds for defederation. Patterns of slur usage in discriminatory contexts would warrant adding a receipt. I’m a native English speaker, so I mainly consider English slurs. I give the benefit of doubt to users who aren’t native English speakers when using English slurs, depending on context. When I’m unsure, I ask for feedback from other mods from the relevant marginalized group.

Some receipts aren’t reasons to block, but exist to contextualize other receipts. For example: I may mention that an instance has open-registration only to highlight that the instance’s moderation policies will allow additional bad actors in the future.

One exception is receipts for legally risky media (e.g. sexual depictions of minors): I don’t publish archive links for those. It should be easy to verify them yourself if you need to; I’ll provide a user handle if necessary.

I grouped some related domains together and added receipts to them collectively. If you see multiple consecutive domains, that’s why.

Toggle receipts

FediNuke entries

Criteria for a good FediNuke receipt is stricter than the aforementioned criteria:

Reblogs are only significant if they are from a staff member and are boosting local users. They are mentioned alongside other receipts to indicate that the content in question is permitted by staff.
Each instance must have multiple receipts. I’m working towards getting at least three receipts for most instances.
For larger instances: receipts must show staff behavior, or show consistent behavior from several users.

This section is a work-in-progress, and it will grow with time.

13bells.com: Admin posts Sandy Hook school shooting conspiracy theories, transmisia, and queermisia. Admin spreads vaccine misinformation.
1611.social: antisemitism from admin, anti-vax from admin with other local members, antisemitic caricature from admin.
4aem.com: Freeze peach PeerTube instance on the “tube” subdomain, hosting blatant antisemitic content. “Clown World” dogwhistles, antisemitic “Why Kanye West is right”, more antisemitism.
5dollah.click: Blatantly racist use of slurs from staff account, more racism from same account.; The other staff account is racist too. Extreme racism from staff.; “About” page lists no rules.
adachi.party: The instance in question is on the “pleroma” subdomain. Its “about” page has the “Kill, behead, roundhouse kick” copypasta with racial slurs. Archived “about” page.; Later updated rules to include “must advocate for racism/fascism/nazism”.; Admin posts racist transmisia, mass-tags other users with blatant racism.
adtension.com: Admin posts blatant anti-Black racism, and doubles-down with more after being called out on it.
annihilation.social OR dembased.xyz: #FediBlock on 2023-02-24; Hosts a block-notification bot, with the handle “blockbot”, and a defederation-notification bot. Racism from admin. In light of this, I’m not inclined to give the benefit of doubt over the cross in his display name and doubling down on vaguely antisemitic posts. Another example of antisemitic caricatures from the admin.; Blatant antisemitism from local user.; dembased.xyz used to run the predecessor of annihilation.social. A few times since, a small experimental instance has been set up on a subdomain. Both are owned by the same person.
anon-kenkai.net: Blatant antisemitic caricature on the landing page of its “peertube” subdomain. Admin on the “mitra” subdomain posts anti-pride messages.
asbestos.cafe: Racism and ableism from admin.; Admin sharing a dox attempt; Antisemitism from local user followed by ableism from admin. Admin defends antisemitism.; Queermisic user.; Very explicit anti-blackness from local users.
bae.st OR skippers-bin.com: Admin profile page has an “n-word pass”. Runs a host of bots posting lewd artwork, some of which venture into lolicon and Black-fetishism territory (e.g. “NessaBot”). Runs “glow_in_the_dark_cia_agent”, one of the biggest followbots on Fedi. Instance rejects deletes.; Another admin has a Confederate battle-flag and unreclaimed transmisic slurs in their display name.; skippers-bin.com is run by the same person as bae.st.
banepo.st: Runs a block-notification bot. Admin posts antisemitism, homomisia, and transmisia in one post, another with more of the same, all of that with a side of ableism.
bassam.social: The admin equates people being against anti-queer discrimination with “oppression”. After a user made a FediBlock post against bassam.social, its instance admin doubled down on permitting bigotry.
beefyboys.win: Runs a block-notification bot. Staff member “Prude” has a profile with a racist rant pinned. Staff member “Tyler” posts “racism is cool and natural” followed immediately by racial slurs, and other slurs in a non-reclaimed context.
boymoder.biz: Admin accounts post anti-Indian racism, racist copypasta. Staff includes “meso” from the.asbestos.cafe. Incompatible moderation standards.
brainsoap.net: dismissive over white supremacy, Nazi humor
breastmilk.club: Admin “leyonhjelm” posts transmisic sui-bait, spamming the “mutualaid” guppe group with blatant queermisia.
brighteon.social: Brighteon’s “about” page marks the instance as a far-right cesspit. Instance is connected to the Brighteon network, a far-right network featuring shows such as “The Reality Camp” with Stacey Campfield.
cachapa.xyz OR cachapa.cc: Admin posts blatant racism, blatantly racist transmisic sui-biat.; Root domain’s “about” page contains transmisic, racist, queermisic, and other slurs in a list of things the owner “hates”.; Instance permits lolicon, and runs accounts for it such as “Shishihime” and “NahidaBot”; this may be a legal risk, depending on your jurisdiction.
caekis.love: Posts extreme anti-black racism, more anti-black racism cross-posted from their Twitter/X account, more.; Extreme antisemitism, and more antisemitism to the point of wishing for genocide.; Anti-blackness and antisemitism.; Participating in a queermisic harassment campaign.; Admin and primary user originally on the same “caekislove” handle on gleasonator.com; see their receipts on the entry for gleasonator.com.
cannibal.cafe: Shares some staff with lolison.top; see its FediNuke entry. Staff-endorsed instances in the “local bubble” include nnia.space, freak.university, rapemeat.express, and other instances on FediNuke for similar reasons.; Admin is explicitly pro-contact.[^3]
catgirl.life OR peervideo.club: Both are part of the Waifu Hunter Club’s suite of services, along with gameliberty.club; see its FediNuke entry. catgirl.life has the same admin as gameliberty.club, who has used the domain for block-evasion. Like gameliberty.club, both instances also permit lolicon.
cawfee.club: Racism from multiple users, including admin.; Anti-Romani and racist posts from admin.; Users engaging in more racism.; Anti-vax from admin.
childlove.space OR childlove.su: Pro-contact MAP instance.[^1] Admin profile, user profile, and several other users identify as pro-contact. Appears to contain many users close to Newgon, a bigoted pro-contact conspiratorial group.; This pro-contact instance explicitly allows minors in its ToS.
clew.lol: Racist meme from admin.; Another racist meme.; Racial slurs in bio of a user with a white-nationalist dog whistle in their handle who posts NJP propaganda; Local users participating in a transmisogynistic harassment campaign with sui-bait.
clubcyberia.co: Instance features anti-black emotes. Users such as “Inginsub” often post blatant racism. Hosts a KiwiFarms staff member.; Staff member publicizes reports against extremely transmisic harassment in a reply to said harassment (YWNBAW-like copypasta).
cottoncandy.cafe: pro-contact MAP admin, pro-contact user. Instance local bubble shows that the admin endorses other pro-contact instances.
crlf.ninja: Instance admin endorses sending toxic racist slurs and being “horrible” to people for blocking instances.; Admin participated in a transmisic dogpiling campaign.; Admin publicizes blocks.; Admin uses triple-paren antisemitic dogwhistle.
crucible.world: Admin participating in extremely transmisic harassment; More transmisia from admin; Even more transmisia.
cum.camp OR cum.salon: Instance has MRF policies to reject deletes and run a block-notification bot on cum.camp and on cum.salon. Staff members “pernia” and “nimt” are known for overly-creepy posts related to sexual assault, esp. CSA, another.; The cum.salon domain name was recently terminated by PorkBun after several people reported it for publishing dox materials. Other instances have locally overridden their DNS to continue federating until its TLS certificate expires; however, it came back after transferring to Epik.
cunnyborea.space: Appears to be a racist pro-contact pedophilia-themed instance. One admin has swastikas in their profile bio and several variations on “total ___ death”. The other admin’s bio has blatant racism and antisemitism.
decayable.ink: Instance is well-known for harassment campaigns.; Targeted transmisogynistic harassment, and aftermath of said harassment.; Racist admin.; The instance introductory post is chock-full of red flags.; Another instance of haraassment.
detroitriotcity.com: Well-known Nazi instance. Instance “about” page says: racial pejoratives, NSFW images & videos, insensitivity and contempt toward differences in sexual orientation and gender identification, and so-called “cyberbullying” are all commonplace on this instance and has a staff account display name featuring an iron cross. Policies permitting lolicon may make it a legal risk, depending on your jurisdiction.
djsumdog.com: Admin posts blatant transmisia, more blatant transmisia. Defends teaching children to be transmisic on moral grounds.; Jan 6th conspiracy theories while calling participants “discount Mandelas”.
drinkanddrive.africa: Extreme anti-Blackness; Anti-blackness; Violent anti-Blackness; Antisemitism
eientei.org: Instance “about” page explicitly describes it as a racist instance, anad uses racial slurs. MRF policies on the “about” page feature a block-notification bot and rejecting deletes. Admin posts antisemitic caricatures. User “lina” has a bio with blatant bigotry.
eveningzoo.club: Transmisia from admin; More admin transmisogny; Racist meme from admin; Antisemitism from admin; More antisemitism from admin; White nationalism from user.
feministwiki.org: Pedojacketing and misgendering from admin.; Admin explicitly promoting transphobia by name as a moral imperative.; More misgendering from admin.; Root domain is full of standard TERF/gender-critical talking points.
fluf.club: Transmisia from admin, more transmisia, transmisic sui-bait.; The instance “about” page recommends freespeechextremist.com and kiwifarms.cc as instances “with similar moderation policies”; both those instances are on FediNuke with receipts.
foxgirl.lol: Blatantly antisemitic use of slurs from admin.; transmisic slurs from admin.
freak.university OR pedo.school: Instance known for permitting paraphilia including pedophilia, and also explicitly allows minors (13+ although that limit may be lowered). Scroll through local users on /directory for more receipts.; pedo.school has identical rules on its “About” page. Instance contains untagged sexual depictions of minors and multiple self-described “pro-c” users; scroll through local users on /directory for more receipts.
freeatlantis.com: Far-right MAGA instance.; Admin has reblogged local users posting extreme transmisogny, xenomisia, anti-drag, MAGA, anti-vax, more anti-vax.; Admin posts QAnon.
freespeechextremist.com OR fsebugoutzone.org: End of this thread has blatant antisemitism.; Multiple other users engaging in transmisogyny, and participating in a transmisogynistic harassment campaign.; Transmisic blanket-pedojacketing.; MRF policies include a block-notification bot. The linked page also makes it clear that this is a freeze-peach instance, so reporting won’t help.; In April 2024, FSE migraterd to fsebugoutzone.org due to technical issues. Blog post, new matching admin profile, new “about” page. The MRF policies listed include rejecting deletes, block-notification, and a freeze-peach moderation policy.
froth.zone: Blatant racism, racist homomisia. Reporting is unlikely to help given the lack of rules against this, some ableism from the admin and some racism from the admin.
gameliberty.club: Freeze-peach rules permit lolisho, which may be a legal risk depending on your jurisdiction.; Admin pinned posts contain slurs in un-reclaimed contexts, and runs an rsdb bot for more.; Admin posts racist memes, more racist memes, anti-pride.
gearlandia.haus: Transmisic targeted harassment from multiple staff members, including sui-bait.; Racist use of slurs from another staff member.; Assorted queermisia from multiple users, including staff.; Staff members sometimes post lolisho, which may pose a legal risk in some jurisdictions.
geofront.rocks: Well-known Nazi instance.; Blatantly racist and transmisic use of slurs, ethno-nationalism, more racism. All from what seems to be the primary active user of the instance.; Another user has a blatantly Nazi profile featuring violent transmisic shock content.
genderheretics.xyz: “About” page explicitly labels the instance as transmisic.; Admin posts unmarked NSFL medical gore in a transmisogynistic context.; Anti-drag pedojacketing from admin.
gleasonator.com: Admin is an outspoken TERF, who was head of engineering for Truth Social.; User “caekislove” pedojackets and sui-baits trans users, does homomisic pedojacketing as well, and posts extreme classism (violent imagery).; Admin is aware of the user but will not take action (unrelated extreme bigotry and Nazi iconography in thread).
glee.li: Racist harassment of Mutual Aid posts.; More blatant racism and transmisia.; Admin posts glad shes gone in response to a gender and sexuality scholar dying, and participates in a transmisogynistic harassment campaign.; More blatant racism.; Instance is associated with the website https://getgle.org. Split off of asbestos.cafe in early 2023, formerly at a subdomain of getgle.org.
goyim.social: antisemitism, racism. All the following posts are from main user “Flatulenator”; Anti-Black racial caricatures; Antisemitic use of triple-parens; Anti-diversity white pride; Holocaust denial; More blatant antisemitism.
harpy.faith: blatant antisemitism from admin, admin doubling down with racist slurs after being called out.; Admin sends sui-bait transmisic replies to trans women.; suibait from user.
h5q.net: Contains untagged AI-generated photorealistic erotic content that may pose a legal risk in several jurisdictions.
haeder.net: Instance blocklist reasons are unapologetically queermisic, calling nonbinary individuals “delusional” and saying We don’t need more diversity and tollerance when this doesn’t fall back on us straight people.; Admin bio has blatant transmisia and hashtags such as SayNoToWoke.
hitchhiker.social OR battlepenguin.video: Sibling instances of djsumdog.com, run by the same admin; see its entry.
iddqd.social: Admin posts anti-Black caricatures, supports organized predatory retaliation against DEI efforts. Instance landing page markets itself as an instance for 4chan users.
kitsunemimi.club: Admin “bronze” participates in racist harassment.; Admin sends users transmisic shock content, makes transmisic TTD posts with hashtag spam.; Runs the HighRoller MRF policy for a block-notification bot.
kiwifarms.cc: The official occasionally-online KiwiFarms Fediverse instance. Look up “KiwiFarms” online if you want receipts. It briefly came back once after a long period of downtime, so I’m not removing it during the current downtime.
kyaruc.moe: Admin sui-baiting to get on this list. Later changed their mind, got mad about being on it, and publicized an attempted dox.; Racist use of slurs, targeted ableist harassment
leafposter.club: Blatant antisemitism and queermisia, SWERF, blatant racist use of slurs.
liberdon.com: Freeze-peach ancap instance.; Medical misinformation: COVIDspiracy, anti-vax, more anti-vax) across three different users.; Across four users: transmisia, flat-earth conspiracy theories, antisemitism, blatant nazism, and fashjacketing antifa.
ligma.pro: The admin threatened mass violence, threatened animal cruelty, posted unmarked gore (CW: NSFL gore), bragged about making death threats. After his infosec.exchange alt got banned he set up shop on fosstodon.org.
loli.church: Instance announcement post explicitly condones racist posts (reblogged by admin). Author of that post also posts blatant antisemitism and anti-Indigenous ethno-nationalism.; loli.church is the new home of fediverse.dotnet00.dev. Receipts from the old instance: Racist user “Wiz”, posts edgy bigotry.; Receipts from the old instance: Reporting probably won’t help, as the admin maintains a freeze-peach policy and regularly boosts racist content themself.; The users in receipts for dotnet00.dev are now on loli.church with the same handles. Their profiles contain uncensored loli hentai.
lolicon.rocks: “About” page states posting.lolicon.rocks is a common carrier telecommunications provider that does not moderate content and also features the owner with the handle “BlinkRape”.; Owner profile bio contains racist and ableist slurs.; Owner posts antisemitism, blatant racism in a climate-denial thread.
lolison.network OR lolison.top: Sibling instances focused on the MAP/pedophilia community. Claim to forbid CP, but also appears to have rules too lax for instances with such focus. Admin “Spag” also admins rapemeat.express; see its FediNuke entry.
magicka.org: antisemitism from admin.; unreclaimed use of homomisic slur.; climate change denial conspiracy theories.; anti-abortion.
marsey.moe OR taihou.website: boks.moe had the occasional holocaust denial meme. one of the main users “Ruusu” set their display name to a racial slur in a violent context. Staff member “MischievousuTomatosu” posts blatantly racist takes on border control.; boks.moe moved to marsey.moe, which features a hitler-themed racist “Witster_” account, making fun of mutual aid posts, racist misogyny, blatantly transmisic jokes.; Staff member later moved to taihou.website. The staff member then went on to post rape threats, anti-vax, indomisic racism, and some more xenomisia
merovingian.club: Instance “About” page bills it as “a club for redpilled exiles”.; Admin is active on MGTOW.TV, and posts racist caricatures. Admin and instance members are deeply misogynistic. Another example of admin misogyny.; Among users, there’s blatant transmisogyny, antisemitism, anti-vax.
midwaytrades.com: Runs a Libs of TikTok bot. Transmisic and misogynist admin.
mirr0r.city: Paraphilia- and pedophilia-focused instance that explicitly welcomes pro-contacts and neo-Nazis.
mouse.services: Admin posts blatantly racist use of slurs, more racism.
morale.ch: Transmisia, blatant antisemitism, and both at once. Ableist holocaust denial. All from the admin account.
mugicha.club: Admin participated in a transmisic targeted harassment campaign with local users.; Anti-asian racist slurs from admin.; Misogynistic racism from admin with several local users with Confederate battle-flags in their display names.; More blatantly racist use of slurs from admin.
natehiggers.online: Used to run an awful Pleroma instance, which shut down. A WriteFreely instance is still up on the “wf” subdomain. Domain name is an obvious spoonerism of racist use of slurs.; The WriteFreely blog features COVID conspiracy theories, violent racist transmisogyny, anti-vax, and other far-right content.
narrativerry.xyz: Admin posts blatant anti-Indian racism.; Admin combines antisemitic conspiracy theories, homomisia, and racism in a slur-filled thread.
nobodyhasthe.biz OR nationalist.social: “About” page lists multiple admins and mods with swastikas in their display names and/or profile photos.; Admin “ShariVegas” is an unapologetic white supremacist and antisemite.; Admin “thomaslewis” makes fun of a report against a blatantly racist user while adding a homomisic and antisemitic slur of his own.; Moderator “BobRoss” has a bio starting with Spreading the joy of antisemitism and encourages calling users slurs instead of reporting as an integral part of the culture around here.; nobodyhasthe.biz eventually migrated to nationalist.social. Instance announcement establishes the connection. Contains the same/similar staff handles.; Some local users on the new instance: a self-identified racist with nazi iconography, and a blatantly antisemitic white nationalist.; Admins of nationalist.social made it clear that reporting won’t help, if you’re still holding out hope for some reason.
peertube.se {peertube-se}: Instance self-affiliates with the Nordic Resistance Movement. This is the main active account on the instance.
shortstacksran.ch OR needs.vodka: Admin posts ethno-fascist harassment, antisemitism. Supports racist, misogynistic, violent grooming.; shortstacksran.ch is the continuation of squid.kids and shortstackran.ch (note the extra “s”), by the same admin. See prior FediBlock post. On the new instance, the admin posts extremely racist use of slurs, and racist antisemitism. Blatantly racist use of slurs and hashtag-spam in a block-bait post from a local user.
nicecrew.digital: Blatant anti-Black racism from staff, anti-Black racist caricature from staff. Antisemitic COVIDspiracy from staff.; Has a bot to spam threads with racist slurs.
nightshift.social: Anti-Black racism and antisemitism from staff.; Extreme anti-black racism and more antisemitism from another staff member.
nnia.cc OR nnia.space {#nnia}: Paraphile pro-zoo pro-MAP instance that also allows both minors and pro-contact users to register. Pro-C zoosexuality.; nnia.cc is a newer instance that claims to be a continuation of nnia.space. It also claims to have closed federation, but I included it alongside nnia.space should that ever change, since I can’t imagine that FediNuke users would wish to federate with it anyway.
noagendasocial.com: Far-right instance connected to the No Agenda show.; Blatant queermisia.; One of its more popular users is openly an ethno-nationalist with thinly-veiled genocidal views and runs the far-right amerika.org blog.; An even more popular user regularly posts far-right content.
noagendasocial.nl OR noagendatube.com: Sibling instances of noagendasocial.com, also connected to the No Agenda Show.
noauthority.social: Run by the admin of noagendasocial.com (see the No Agenda Social FediNuke entry). Features more blatant transmisia from the admin.; Instance “about” page describes it as a free-speech instance with a link to a directory of other instances with similar policies; all the live domains on that list are also on FediNuke with receipts.
norwoodzero.net: Admin pedojackets in a transmisic harassment campaign.; Admin invites others users for the purpose of harassing trans users. Another example, using the fact that the instance is “barely defederated” as a selling point.; Instance “about” page contains racial slurs and an animated banner that says “whites only”.
nyanide.com: Staff member sends transmisogynistic pedojacketing harassment.; Same staff member posts blatant extreme racism (CW: SA).; Same staff member sends anti-vax harassment to other users.; Two staff members in a racist and antisemitic thread.
onionfarms.org: “About” page says This is a Mastodon server for the Onionfarms and Kiwifarms communites [sic] and admin bio confirms it.
pawlicker.com: Root domain hosts a pro-KiwiFarms and transmisic essay. Admin posts transmisogyny, more transmisia (the person he references knowing more is a KF staff member), even more transmisia.
pawoo.net: Lolisho instance that does not moderate sufficiently. Has had several incidents of actual CSAM and child predators going unmoderated for long durations, despite reports.
parcero.bond OR parcero.casa: Blatantly racist slur use from admin.; Antisemitism from admin.; Sui-bait from admin.; New domains included mi.parcero.casa and ti.parcero.casa. Admin endorsed transmisia.
piazza.today: climate denial from admin, COVID misinformation from admin, transmisia from admin.; xenomisic MAGA crap and Great Replacement conspiracy theories (archive visually cut off, but the post is visible in the screenshot tab or in page source code) from local user.
pibvt.net: Lolisho and actual photos of toddlers posted by MAPs. FediBlock post with some more details.
pieville.net: Admin is a white nationalist who supports building an ethno-state, and genocide. Admin profile features more blatant slur-filled racism, antisemitism, etc.
poa.st: Well-known Nazi instance. See receipts for needs.vodka, kitsunemimi.club, and shitpost.cloud for poast users. Also see this Poast thread containing unapologetic racism, transmisia, and other bigotry from the Poast admin and users volunteering receipts for this resource.
poast.org OR poast.tv: Instances affiliated with poa.st.
pisskey.io OR sad.cab: Graf, admin of poa.st, also runs (and block-evades from) pisskey.io, and sends racist transmisic antisemitic harassment from it too.; Also runs sad.cab.
poster.place: Staff member “spitfire” spams the “mutualaid” guppe group and hashtag with extreme queermisia, and makes racist homomisic slur-filled anti-antifa posts. Instance header contains an animated GIF full of slurs.
rapemeat.solutions OR rapemeat.express: rapemeat.solutions is the successor to hentai.baby, run by its admin. hentai.baby was known for posting real CSA material. Openly pro-CSA. Has drawn nudity in the instance background.; rapemeat.express is the more public counterpart to rapemeat.solutions according to its “About” page.
rayci.st: Admin posts racial slurs, anti-Indian racism, anti-Black racist use of slurs, and some antisemitism.; Admin spams the MutualAid guppe group with shock content.
rebelbase.site: Admin posts blatant transmisia, posts more thinly-veiled transmisia, insists on misgendering.; Admin is anti-abortion, identifies as an MRA.[^4]; Elsewhere on the site is a user who posts COVID denial, anti-vax with a side of queermisia and Islamomisia.
ryona.agency OR plagu.ee: Admin bio features blatant racism, antisemitism, misogyny, and other bigotry.; Admin participates in transmisogynistic harassment.; Blatant racism from a local user.; The instance “about page” features MRF policies to power a block-notification bot, to convert all posts (including followers-only posts) to public visibility, and to reject deletes.; Also runs a version of Pleroma patched to allow bypassing authorized-fetch.; plagu.ee is run by the same admin as ryona.agency, with similar patches and MRF policies applied as per the plagu.ee “about” page.
schwartzwelt.xyz: Admin participates in a transmisic harassment campaign by posting transmisic pedojacketing[^5] sui-bait containing Nazi iconography. More blatant transmisia from admin.; Admin participates in anti-indigenous racist harassment.; Local user “Agartha_Noble” posts blatant racism in a thread about race-mixing.
seal.cafe: Users including admin participate in transmisic targeted harassment.; Racist slurs from admin.; Antisemitic transmisia from a user.; Admin posting sui-bait in response to a trans woman coming out.
shaw.app: Admin pedojackets trans people, posts blatant denial of trans validity (alongside other far-right talking points), and leaves transmisic replies to trans women.; Anti-mask post from admin.
shitpost.cloud: Admin “Hoss” uses racial slurs in an unreclaimed context.; Admin publicized reports against local users participating in a targeted transmisic harassment campaign.; A user with a violent racist display name, with staff participating later in the thread.
skinheads.social OR skinheads.eu: The Antisocial Network is for white-nationalist skinhead subculture. “Aryans” bot white pride, Nordic resistance movement.
skinheads.uk OR skinheads.io: Alternate domains for The Antisocial Network.
spinster.xyz OR neenster.org: Spinster is a TERF instance created by Alex Gleason, admin of gleasonator.com; see its entry. Instance mostly engages in transmisogyny.; Staff member posts blatant transmisogyny.; Another staff member openly admits to being a TERF in their profile.; A third staff member posts a rant against the validity of trans women, with several local members piling on in the replies.; Neenster shares staff members (Alex Gleason, Nina Paley). The latter posts self-described TERF content and links to her blog with more TERF content.
strelizia.net: Instance “About” page lists MRF policies to reject deletes and run a block-notification bot.; Admin posts anti-Black racism, more blatant racism, and some other slurs in non-reclaimed contexts; Local user “nikiboo” posts blatant anti-Black racism (re-blogged by admin), has a profile photo with Nazi imagery.
subs4social.xyz: blatant antisemitism (transmisia further upthread if you view the canonical link).; Misogyny and anti-Black racism, more anti-Black racism.; Transmisia.; Legitimizing fervor over white genocide by using it as a comparison to fervor over climate change.; All receipts are from the only user to show up in the explore tab.
tastingtraffic.net: Admin account is a high-activity news account full of hashtag spam. Frequently posts far-right transmisia/queermisia, another example. The same content is frequently pasted in multiple posts per day.
theblab.org: Instance explicitly permits, and admin reblogs, openly ethno-nationalist/Nazi content from local users.; TheBlab.org “about” page says: The Blab is the place for refugees of places that claim to be free speech. After the shekelcaust of Gab an alternative was needed. This is that alternative..; Admin profile page contains multiple reblogs of local users posting racial slurs, Nazi imagery, and antisemitism. More racism from local users.
thechimp.zone: Admin sends transmisic pedojacketing harassment to trans users, with racial slurs to boot.; Admin participates in queermisic harassment.; Admin profile contains racial slurs.
thenobody.club: Admin participates in a transmisogynistic harassment campaign.; Racist and antisemitic use of slurs from admin, along with some heavy xenomisia shortly after.; More racist xenomisia from admin.
truthsocial.co.in: Named after Donald Trump’s “Truth Social” network. A glimpse at their local timeline shows mostly far-right content befitting of the instance name. One of the main posters, “Kittruth”, regularly posts racist talking points. Instance seems completely unmoderated, with spambots such as “leoedward” going unnoticed for months.
tsundere.love: Admin profile lists them as an alt of a loli.church user, and has an alt called “wizgroomer” that posts sexually explicit lolicon.; Admin posts explicit anti-blackness and indomisic racism.
usualsuspects.lol: Admin led targeted transmisic bodyshaming harassment against members of a mainly-trans instance. Originally created to be a block-bait Soapbox instance.
vampiremaid.cafe: Admin posts white nationalism, blatant racism, antisemitism, and more racism and antisemitism with unreclaimed slurs.; Admin posts a context-free “HH” and boosts swastikas from Poast.; Note that the instance heavily features suggestive lolicon.
varishangout.net: Instance permits lolicon/shotacon. sample non-graphic thread containing queermisia, esp. transmisia, with staff involvement, another such thread.; Staff member being openly transmisic.; Several members participating in transmisic harassment.
volk.network {volk} OR volk.love: Admin account has a bio of “White Power Alt-Tech” with a Nazi solute in his profile photo. Reblogs local users posting blatant antisemitism, and anti-blackness, and Nazi flags.; volk.love is a PeerTube instance. Its “Team” page mentions the admin of volk.netowrk, links back to volk.network, and its description is blatantly white supremacist.
vtuberfan.social: Racism and other hate-speech, CW for unmarked nudity in profile pictures and banners.; Admin “Sivee” posts blatant racism, and local user “Saige” replies with violent racist bait. Sivee likely went by the same handle on seal.cafe.; Saige posts homomisic bait.
wolfgirl.bar: Admin participates in racist harassment, posting openly Nazi bigoted slur-filled content. Sends Nazi imagery with racial slurs to Jewish users while defending slavery.
yggdrasil.social: The first rule of the yggdrasil.social “about” page says “No LGBTQ. Period. No homosexuality” followed by blatant transmisia.; Profile for “Ricotta”, the current most active user, has a swastika in their display name and a bio that includes “National Socialist” and “TERF”.; Blatant racism from another user.
zhub.link: Admin strolling into mentions of trans lesbians to post queermisia, later doubling down on it, describing transness as “ugly, illogical”. An earlier example claiming to be oppressed for being labelled homomisic for holding homomisic beliefs.; Admin posts Islamomisic pedojacketing.

Tier-0 entries, excluding FediNuke

This section is very unfinished. Receipt criteria and threshold is weaker than FediNuke. I encourage most admins to scroll through this list and decide what is or is not acceptable for their instance.

absolutelyproprietary.org: Admin self-intro is a racial slur. Posts a series of racial caricatures with slurs in this thread.; alt for pwm of crlf.ninja. See crlf.ninja FediNuke entry, featuring pwm.; alt for pernia of cum.salon. See cum.salon FediNuke entry, featuring pernia.; Another user spams BlackMastodon and MutualAid with racial slurs
baraag.net: Very well-known lolicon-friendly instance that recently cleaned up its act enough to re-federate with misskey.io, but still focuses on lolisho artwork and may therefore pose a legal risk, depending on your jurisdiction. Consider blocking media if you wish to federate.
berserker.town: Refuses to moderate hate speech (the post in question has received reports, but the admin tends to dig his heels in when it comes to this stuff). About page doesn’t ban such content.; Permissive policies have made space for anti-diversity eugenics dogwhistles evolving into xenomisic eugenics.
federated.fun OR wikileaks2.org: Blatant transmisia from admin. Admin profile pinned an extremely transmisic post.; Admin switched to running misinformation.wikileaks2.org instead, and continues posting queermisia on the new instance.
firedragonstudios.com: Currently runs an instance on the “pleroma” subdomain.; Used to run a freeze-peach instance under the “freespeech” subdomain, allowing far-right linkspam, anti-vax, and anti-woke users; Got widely blocked as a result before switching domains. Current “pleroma” subdomain seems inactive but still allows registration.
freesoftwareextremist.com: Ableism and antisemitism from local user “dookie”, ableist sui-bait, ableism and queermisia.; Admin often uses anti-Chinese racial slurs, more usage, other anti-asian slurs.; Instance has fully open registration.
freetalklive.com: Instance “about” page self-identifies as unmoderated, except for spam. Connected to the libertarian Free Talk Live show.
kawa-kun.net: Instance rejects deletes. (unfinished entry)
kompost.cz: Racism, more racism, transmisia, queermisia. All from admin.
krackhou.se: Admin makes a blatantly racist TND post, and a second such post. More racial slurs.
maladaptive.art: Blatant racism in a transmisic sui-bait thread.; Same user posting blatant transmisia, misgendering in a transmisic thread, and antisemitism.
novoa.nagoya: Antisemitism from admin.
occultist.space OR enjoyer.network: Run by the same admin as the.usualsuspects.lol (FediNuke). Admin announced the.usualsuspects.lol from the.occultist.space. See confirmation that the enjoyer.network admin is the same.
peister.org: Admin pinned post is blatant gender-critical/TERF nonsense. More TERF posts from admin. Several more receipts available on the admin profile.
shitposter.club OR shitposter.world: Blatant transmisia from user “noyoushutthefuckupdad”, who’s gone on multiple transmisic benders, with admin knowledge. More transmisia from other users.; User “billiam” has a profile with a Confederate battle-flag, antisemitic dog-whistles, and blatant white supremacy in a pinned post; Hosts user “Amerika”, an outspoken eugenicist and nationalist. See receipts for their other account in the FediNuke entry for noagendasocial.com.; User “Nudhul” posts racist spam in the “MutualAid” hashtag.; Admin “Moon” posts racist bait.; Some more racism from user “triodug”.; Note that its freeze-peach environment probably won’t be changing: other users, including the admin, seem fond of it in this thread.; shitposter.world is the successor to shitposter.club following technical difficulties: background information and admin confirmation.; shitposter.world rejects deletes with the NoIncomingDeletes MRF policy; source code of the MRF policy.
shota.house OR burger.rodeo: Instance self-identifies as a freeze peach haven that permits unrealistic/2D lolisho; this may be a legal risk, depending on your jurisdiction.; Staff defends permitting bigotry while dismissing concerns about hate-speech. With that context, reporting won’t address problems like racist Black fetishism from one user.; Harassment risk seems low, however, and admins claim that the instance will moderate harassment but not “opinion”.; lemmy.burger.rodeo is run by the same staff and has the same policies.
soc0.outrnat.nl: Alleging reverse-racism.; Appears to be the former admin of springbo.cc, with a self-professed fascist.; Admin was a member of Prometheus Information Systems.; Admin encourages spamming hashtags, more spam encouragement, defending RMS, the “millions must die” dogwhistle, “they’re not sending their best”, retaliatory CSEM accusations.
someotherguy.xyz: Xenomisic “build the wall” admin.; “Family values” queermisic pedojacketing.
starnix.network: Note: there are multiple Fediverse servers on different subdomains, such as “pl” and “mstdn.”; Staff includes the admin of annihilation.social and dembased.xyz (FediNuke).
whinge.town OR whinge.house: Racism from staff, more racism, even more racism.; Ableist misogyny.; Both instances were set up by the same user (confirmation 1, confirmation 2), who mains on the former.
wideboys.org: There used to be an instance on the “social” subdomain, but it shut down. However, there is still a WriteFreely instance on the “blog” subdomain. The instance on the “social” subdomain has been mostly superseded by beefyboys.win.; On the root domain is a wiki describing how this domain is affiliated with beefyboys.win. The beefyboys.win “about” page confirms this.; Since beefyboys.win is on FediNuke and wideboys.org is part of the same network with staff and member overlap, and wideboys.org still federates on the “blog” subdomain, it’s on the list too. But since it only federates via WriteFreely at the time of writing, it looks like a smaller harassment vector so it’s demoted to my tier-0 list.

Future

The biggest complaint I’ve heard is the lack of reasons and receipts. I’m working on adding them to this page.

I like the idea of a separation between receipt-tracking projects and blocklist-generating projects. Reasons in a blocklist tend to invite retaliatory harassment in an effort to make admins hide their blocklists, often in the form of (very dubious) legal threats (defamation and privacy regulations have come up).

I also hope to see more tier-0 lists crop up. Any instance should be able to make a tier-0 list by sub-setting its own blocklist. When that happens, “Seirdy’s Tier-0 list” will hopefully lose whatever authority it has.

Sui-bait is short for suicide-bait. ↩︎
I did not consider dox attempts against certain neo-Nazis a reason to block. ↩︎
A “contact stance” refers to beliefs around whether it’s okay for adults to have sexual relations with minors when a significant age-gap exists. Pro-contact means support for such relations. I consider this support for CSA. Regardless of contact stances: I generally agree with blocking instances that allow lolicon, shotacon, sexualized babyfur, etc. but FediNuke is for the most extreme cases of every category. ↩︎

The limited utility of the phrase “GNU/Linux”

seirdy@seirdy.one (Seirdy) — Fri, 09 Dec 2022 21:48:49 +0000

The standard fossbro interjection goes:

I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Sensible retorts, such as “Nobody asked you”, “Please leave us alone”, and “Sir, this is a Wendy’s” are useless defenses. Nay, the greatest weapon against misguided pedantry is pedantry itself.

Let’s talk about why not to use the term “GNU/Linux”.

Introduction

“GNU/Linux” is not a useful term to describe a category of operating systems. The phrase distinguishes Linux distributions primarily by the presence of GNU software, which is seldom the most meaningful or practical distinction worth making.

To illustrate the limited utility of “GNU/Linux” we can study seven Linux distributions, some of which are GNU/Linux:

Fedora CoreOS: A server-oriented distribution intended for containerized workloads. Contains a Linux kernel, GNU libc, GNU coreutils, and the Systemd management suite.
Fedora Workstation: A distribution of the Linux kernel, GNU libc, GNU coreutils, and the Systemd management suite
Gentoo: A distribution of the Linux kernel, GNU libc, GNU coreutils, and the OpenRC init system¹
Alpine: A distribution of the Linux kernel, musl libc, Busybox coreutils, and the OpenRC init system
Void Linux, musl edition: A distribution of the Linux kernel, musl libc, some GNU coreutils, and the Runit init system
ChromeOS: A distribution of the Linux kernel, GNU libc, and a UNIX-like userland abstracted away by default. This is the most popular desktop GNU/Linux distribution, to my knowledge.
Qubes OS: A distribution that uses the Linux kernel but is meant to merely host VMs containing their own OSes

The phrase “GNU/Linux” includes all of these distributions except Alpine, and possibly except Void-musl. I argue that drawing this particular line in the sand is hardly ever useful. The right line to draw depends on context.

User experience

The phrase “GNU/Linux” doesn’t meaningfully describe a Linux distribution’s user experience.

When someone says they use “Linux on the desktop”, I assume they’re referring to a category of OSes that includes all the listed Linux distributions except Fedora CoreOS, ChromeOS, and perhaps Qubes OS. One of the included distributions, Alpine, doesn’t ship any GNU software by default. Yet it feels closer to Fedora (a GNU/Linux distribution) than ChromeOS or Qubes OS. The latter two aren’t used like traditional “*nix” systems.

“UNIX-Like” or “POSIX” at least convey the UNIX-like experience and ecosystem of an OS. A “Systemd distribution” would also be a useful term to describe the experience of configuring and administrating an OS.

Operating system design

The phrase “GNU/Linux” doesn’t meaningfully describe a Linux distribution’s high-level design.

GNU coreutils and glibc both have alternatives that should be nearly equivalent. The use of GNU libraries and coreutils typically doesn’t change the design an OS nearly as much as the presence of, say, Systemd. In fact, I would categorize software like GNOME or PulseAudio as targeting “Systemd/Linux” rather than GNU/Linux: non-Systemd distributions must patch them to run without Systemd. “Systemd distribution” or “Non-Systemd Linux” are more useful terms.

Distinguishing Fedora and Alpine by the use of Systemd versus OpenRC makes far more sense than distinguishing them by their C libraries.

NixOS and GuixSD feel similar due to their functional package management, not because of their coreutils or C libraries. If NixOS switched to musl and Busybox, I would still feel comfortable putting it in the same category as GuixSD. “Functionally packaged distribution” would be a more useful term to refer to this pair.

Targeting an OS

The phrase “GNU/Linux” is somewhat meaningful when describing a compilation target; however, “target triplets” are generally more useful.

Ideally, programs should support linking against different libraries conforming to the same standards. A single program should build for either glibc or musl (and either libstdc++ or libc++ when it uses C++). If I make a GTK or Qt program, I can expect it to run on all the listed OSes except ChromeOS. Alpine and Fedora Workstation are part of more-or-less the same ecosystem, and should share a category.

This ideal isn’t always our reality. Complex software, such as browsers and Systemd, typically requires significant patching to run with musl. Patching fast-moving and complex software like Firefox or Chromium is difficult; patched versions often lag behind official releases. I find it fair to categorize such software as specifically targeting GNU/Linux.

Categorizing a target as “GNU/Linux” makes sense when running a pre-compiled binary dynamically linked against glibc (and possibly libstdc++). This is especially relevant for proprietary software shipped exclusively in binary form. Proprietary software tends to be above a certain threshold of complexity; otherwise, it’d be trivial to re-implement. Above that complexity threshold, C and C++ libraries probably aren’t the only relevant dynamic libraries: the software will likely require system graphics (e.g. libwayland), cryptography (e.g. OpenSSL), and messaging (e.g. libdbus) libraries.

Target triplets

When specifying a Linux compilation target, we hardly ever see the term “GNU/Linux”. Instead, most people use a target triplet that specifies the target CPU architecture, kernel, and userland. “x86_64-linux-gnu” and “aarch64-linux-musl” are two examples.

Since the Linux kernel has a stable ABI, it’s common to ship binaries statically-linked, with no system libc dependencies. In these situations, pre-compiled Linux binaries may simply drop the last part of a target triple; the two examples would become “x86_64-linux” and “aarch64-linux”.

Unclear meaning

The difference between “GNU/Linux” and “Non-GNU/Linux” is unclear; this confusion calls into question the value of the term “GNU/Linux”.

GuixSD is an OS developed by the GNU project. It uses the GNU coreutils, GNU libc, GNU Shepherd init system, GNU Guile extension language, and GNU Linux-Libre kernel.² It seems fair to include it in the category of “GNU/Linux” distributions.

In contrast: Void Linux’s musl edition uses some GNU coreutils. Its init system (Runit), shell (the Almquist Shell), and libc (musl) are not GNU software. Would it make more sense to refer to this distribution as GNU/Linux or musl/Linux? How useful is the distinction?

“GNU” alone seems to imply both GNU coreutils and glibc; it doesn’t seem to account for the presence of GNU coreutils and the absence of glibc, or vice versa.

Conclusion

The phrase “GNU/Linux” includes Fedora Workstation, Fedora CoreOS, Gentoo, ChromeOS, and Qubes OS. It’s unclear whether it includes Void’s musl edition, and it excludes Alpine Linux.

Running or compiling a dynamically-linked binary is the only situation warranting such a distinction; this is especially important when distributing pre-compiled software. Beyond that scenario, “GNU/Linux” implies little about the desktop user experience, system administration experience, OS design decisions, or even how much GNU software is present on an OS.

I would much rather see adoption of the following phrases:

freedesktop distribution: Refers to the category of UNIX-like desktop-oriented OSes using the software ecosystem that includes GTK, Qt, the AT-SPI accessibility APIs, and the most important freedesktop.org standards. “freedesktop Linux distribution” could narrow this down to just those with the Linux kernel.
Systemd distribution OR non-Systemd Linux: Refers to the category of Linux distributions that offer a similar configuration and administration experience
POSIX OR UNIX-like: Includes most Linux distributions, the BSDs, Solaris, and others to describe common standards between operating systems’ low-level design.

I won’t insist on this terminology; I have better things to be pedantic about. I merely wrote this article so I could share it whenever the GNU/Linux naming controversy comes up.

If I shared this article with you after you attempted to incorrect someone’s terminology, I’d like to leave you with one last copypasta:

“I use Linux as my operating system,” I state proudly to the unkempt, bearded man. He swivels around in his desk chair with a devilish gleam in his eyes, ready to mansplain with extreme precision. “Actually,” he says with a grin, “Linux is just the kernel. You use GNU+Linux.” I don’t miss a beat and reply with a smirk, “I use Alpine, a distro that doesn’t include the GNU coreutils, or any other GNU code. It’s Linux, but it’s not GNU+Linux.”

The smile quickly drops from the man’s face. His body begins convulsing and he foams at the mouth as he drop to the floor with a sickly thud. As he writhes around he screams “I-IT WAS COMPILED WITH GCC! THAT MEANS IT’S STILL GNU!” Coolly, I reply: “If Windows was compiled with GCC, would that make it GNU?” I interrupt his response with “And work is being made on the kernel to make it more compiler-agnostic. Even if you were correct, you won’t be for long.”

With a sickly wheeze, the last of the man’s life is ejected from his body. He lies on the floor, cold and limp. I’ve womansplained him to death.

— Unknown

If you remain unconvinced: that’s okay. In the end, what really matters is that I managed to distract you with an unnecessarily-long article, giving me enough time to wrap up the discussion you interrupted.

There exist several overlays and configurations to use Gentoo with musl, Busybox, different init systems, and even Clang. I’m only describing default, mainstream setups. ↩︎
I imagine most deployments of GuixSD swap out the default Linux-libre kernel with a mainline version, but I lack the evidence to back this claim up. ↩︎

Stylometric fingerprinting redux

seirdy@seirdy.one (Seirdy) — Sun, 10 Jul 2022 04:49:06 +0000

This is an expanded version of a microblog entry: Stylometric fingerprinting resistance. It contains everything in that entry and more. I am open to feedback, especially from anybody with a more thorough background in the subject; here’s my contact information.

Introduction

Following a recent landmark SCOTUS ruling, many have been trying to publish resources to help people find reproductive healthcare. They often wish to publish anonymously, to avoid being harassed or doxxed by overzealous religious fundamentalists. Some people asked me for help.

There’s no shortage of guides on how to stay anonymous online. I recommend using the Tor Browser in a disposable Whonix VM. The Whonix Wiki has a good guide to anonymous publishing. Few guides cover stylometric fingerprinting.

Stylometric fingerprinting analyzes unique writing style (i.e., it uses stylometry) to identify the author of a work. It’s one of the most common techniques for de-anonymization, used by adversaries ranging from trolls to law enforcement.

For a TL;DR, skip to the “Conclusion” section.

How stylometric fingerprinting works

To paint with a broad brush, we can divide most stylometric fingerprinting into machine- and human-driven techniques.

Machine-driven techniques: These techniques involve analysis of reading level metrics, unusual words, machine-identifiable grammatical and spelling errors, and statistical analysis of writing style. A great amount of recent research studies statistical analysis of writing style; it’s a rapidly-evolving field.
Human-driven techniques: There are some areas in which manual analysis still beats computers. Someone you know may recognize your writing style.

Defense against machine-driven techniques

Common advice is to use offline machine translation to translate works to and from another language. Argos Translate and Marian are two options that come to mind.

Obfuscation and imitation

Adversarial stylometry: Circumventing authorship recognition to preserve privacy and anonymity shows that machine translation alone isn’t nearly as strong a method as manual approaches: obfuscation (hiding your writing style) or imitation (mimicking another author). These approaches have excellent success rates, even among amateur writers. The aforementioned Whonix wiki page lists common stylometric fingerprinting vectors for manual approaches to address.

Limiting unusual vocabulary and sentence structure make for a good start. Using a comprehensive and highly-opinionated style-guide should also help. The Economist has a good one that was specifically written to make all authors sound the same: The Economist Style Guide, 12th edition (application/pdf).

Nearly every respected newspaper has a style guide. Tech companies typically publish or use a style guide for technical writing. I’m a fan of Red Hat’s style guide: Red Hat Technical Writing Style Guide, Edition 5.1.

Good style guides are long, and learning one is tough. Read a large amount of conforming content to help yourself internalize a guide’s rules.

Reading levels

The reading difficulty of a piece is a coarse but extremely simple measure. If the anonymous author of a piece writes at a tenth-grade level, their other writings are likely near a tenth-grade level too.

Check your content’s reading level using common readability metrics. The Flesch-Kincaid Grade Level is one of the most popular. If you write at a given grade level, publish anonymously at a lower grade level. I recommend using a lower grade level rather than a higher one for two reasons:

Artificially inflating the reading level generally produces cringeworthy writing.
Writing at a lower level carries less risk of introducing uncommon fingerprintable words.

Other tips

For any inexperienced writers: opinionated offline grammar checkers such as LanguageTool and RedPen may supplement a manual approach by normalizing any distinguishing “errors” in your language. That being said, nothing beats a human editor. Find someone you trust to review your work.

Here are some resources for further reading:

How we authenticate a document by OrphAnalytics SA.
Unveiling the Anonymous Author: Stylometry Techniques by SerHack.

Defense against human-driven techniques

Human-driven techniques were behind the most high-profile successful cases of stylometric fingerprinting by law enforcement. When the Unabomber published his manifesto, his brother recognized some signature phrases in his manifesto and went to the FBI. One of the largest Australian CSA cases involved recognizing someone’s distinctive greeting of “Hiya”.

While the research I cited seems to indicate that machine translation is a poor way to thwart machine-driven techniques, I’m not convinced that it’s useless. Machine translation may be ineffective at thwarting machine-driven stylometric fingerprinting, but it should be able to highlight or remove uniqueness a human could notice. Let’s look at some examples.

Example: Unabomber manifesto

Here’s a sentence from the Unabomber manifesto:

But it is obvious that modern leftist philosophers are not simply cool-headed logicians systematically analyzing the foundations of knowledge.

David Kaczynski noticed the phrase “cool-headed logicians” as a potential signature identifying his brother. After further analysis, the author was clear.

After I read the first few pages, my jaw literally dropped. One particular phrase disturbed me. It said modern philosophers were not “cool-headed logicians.” Ted had once said I was not a “cool-headed logician,” and I had never heard anyone else use that phrase…We had Linda’s childhood friend Susan Swanson, a private investigator, take two of Ted’s letters to a linguistics expert, who analyzed them and found there was an 80 percent chance the same person had written the letters and the manifesto.

— David Kaczynski, Blood Bond

Let’s run it through Argos Open Translate’s English-Esperanto filter,¹ and then translate it back to English:

But it is evident that modern left-wing philosophers are not simply dehydrated logicians systematically analyzing the foundations of knowledge.

“Dehydrated logicians” obviously isn’t the correct term to use. The fact that the translation algorithm mistook “cool-headed” for “dehydrated” indicates that “cool-headed” was an unusual choice of words to use in this context, and therefore a fingerprinting vector. A more common phrase like “detached” would be safer.

Extreme example: Mario

Let’s look at another phrase:

Whoohoo! It’s a-me, Mario!

“Mario” is a common name, but I have a feeling you know that this “Mario” is the Nintendo character. Running this line through an English-Esperanto and Esperanto-English filter gives us:

Who! It’s me, Mary!

Our findings:

“Whoohoo” is uncommon enough to be unrecognized by the translation algorithm. Replace or remove it.
Saying “a-me” is less common than saying “me”.
“Mario” is less common than “Mary” in an English-speaking context.

Additionally, inflection (e.g., using an exclamation point) can make your writing voice recognizable. Use it with care.

Let’s re-phrase Mario’s line to be less identifiable:

Hey, it’s me. Mario.

That’s a little better.

Example: my fingerprint

I have my share of fingerprintable stylistic and formatting quirks. A non-exhaustive list:

Qualifying lists with words like “non-exhaustive” or “incomplete”.
Putting punctuation outside quotations or hyperlinks whenever acceptable.
Using many colons, semicolons and conjunctive adverbs; for example, this sentence uses the latter two.
Obsessively distinguishing between concepts and implementations of those concepts, resulting in a statistically high use of the word “implementation”.
Introducing some articles with HTML description lists before elaborating on each entry in that list.
Using soft-hyphens so text can wrap to narrow widths.

Writing is a skill

Developing a high-quality writing style is hard. Developing and switching between multiple different styles is even harder. It takes time to master multiple style guides, cultivate a different “voice” free of your usual idiosyncrasies, and keep your different voices from influencing one another. “Getting into character” won’t happen overnight if you don’t have experience.

Translation tools are training-wheels to help you learn to identify idiosyncrasies. As you get better, you might be able to filter out problematic language without their help.

Don’t feel pressured to start soon! If you want to publish under a truly anonymous pseudonym, you should first hone your craft. Alternatively, find a good editor.²

Conclusion

If you wish to write anonymously, I recommend the following:

Analyze your non-anonymous writing, looking for patterns. Write these patterns down. When you review your anonymous publications, refer to your list of identifiable patterns and remove them. Consider asking someone else for help, since your own bias might cause you to overlook some patterns.
Translate your work to and from another language with an offline machine translator. Don’t actually publish the translator’s output; instead, read the output to identify potentially-fingerprintable language you missed in the previous step.
Correct any grammatical or spelling errors; mistakes you make might be unique.
Conform to an opinionated style-guide that you don’t normally use in your other writing.
If, after doing the prior steps, your anonymous work still has a reading level too similar to your non-anonymous writing: reduce the reading level by choosing simpler words.

More information on stylometric fingerprinting resistance is on The Hitchiker's Guide to Online Anonymity.

Stay safe, everyone.

I didn’t pick Esperanto for any particular reason. ↩︎
I am not the best person for this job, sorry. ↩︎

An experiment to test GitHub Copilot's legality

seirdy@seirdy.one (Seirdy) — Sat, 02 Jul 2022 00:30:45 +0000

Preface

I am not a lawyer. This post is satirical commentary on:

The absurdity of Microsoft and OpenAI’s legal justification for GitHub Copilot.
The oversimplifications people use to argue against GitHub Copilot (I don’t like it when people agree with me for the wrong reasons).
The relationship between capital and legal outcomes.
How civil cases seem like sporting events where people “win” or “lose”, rather than opportunities to improve our understanding of law.

In the process, I intentionally misrepresent how the judicial system works: I portray the system the way people like to imagine it works. Please don’t make any important legal decisions based on anything I say.

The only section you should take seriously is “Context: the relevant technologies”.

Introduction

GitHub is enabling copyleft violation ✨at scale✨ with Copilot. GitHub Copilot encourages people to make derivative works of source code without complying with the original code’s license. This facilitates the creation of permissively-licensed or proprietary derivatives of copyleft code.

Unfortunately, challenging Microsoft (GitHub’s parent company) in court is a bad idea: their legal budget probably ensures their victory, and they likely already have a comprehensive defense planned. How can we determine Copilot’s legality on a level playing field? We can create legal precedent that they haven’t had a chance to study yet!

A chat with Matt Campbell about a speech synthesizer gave me a horrible idea. I think I know a way to find out if GitHub Copilot is legal: we could use its legal justification against another software project with a smaller legal budget. Specifically, against a speech synthesizer. The outcome of our actions could set a legal precedent to determine the legality of Copilot.

Context: the relevant technologies

Let’s cover the technologies and actors at play before I start my evil monologue.

Exhibit A: GitHub Copilot

GitHub Copilot is a predictive autocompletion service for writing software. It’s powered by OpenAI Codex, a language model based on GPT-3. It was trained using the source code of public repositories hosted on GitHub, regardless of their licensing. In response to a Request for Comments from the US Patent and Trademark Office, OpenAI claimed that “Artificial Intelligence Innovation”, such as code written by GitHub Copilot, should be considered “fair use”.¹

Many of the code snippets it suggests are exact copies of source code from various GitHub repositories. For an example, see this tweet: I don't want to say anything but that's not the right license Mr Copilot. by Armin Ronacher (here’s an archive link that doesn’t require JavaScript, captured on 2022-07-01) It contains a screen recording of Copilot suggesting this Quake code. When prompted to do so, it obediently fills in a permissive license. That permissive license violates the Quake code’s GPL-2.0 license. Copilot provides no indication that a license violation is taking place.

GitHub performed its own research into the matter.² You can read about it on their blog: GitHub Copilot research recitation, by Albert Ziegler. I’m not convinced that it accounts for the fact that suggested code might have mechanical alterations to match surrounding text, while still remaining close enough to trained data to be a license violation.

Exhibit B: The Eloquence speech synthesizer

I recently had a chat with Matt on IRC about screen readers and different types of speech synthesizers. I mentioned that while I do like some variety, I always find myself returning to the underrated robotic voice of eSpeak NG. He shared some of my fondness, and also shared his preference for a similar speech synthesizer called Eloquence.

Downloads of Eloquence are easy to find (it’s even included with the JAWS screen reader), but I struggle to find any “official” pages about the original Eloquence. Nuance acquired Eloquent Technology, the developer of Eloquence. Microsoft later acquired Nuance.

Eloquence sample audio

Your browser does not support HTML5 audio.

Download audio file eloquence.mp3

Matt recorded this sample audio clip of Eloquence reading some text. The text is from the introduction of Best practices for inclusive textual websites

Toggle audio transcript

Audio transcript

My primary focus is inclusive design. Specifically, I focus on supporting underrepresented ways to read a page. Not all users load a page in a common web-browser and navigate effortlessly with their eyes and hands. Authors often neglect people who read through accessibility tools, tiny viewports, machine translators, “reading mode” implementations, the Tor network, printouts, hostile networks, and uncommon browsers, to name a few. I list more niches in the conclusion. Compatibility with so many niches sounds far more daunting than it really is: if you only selectively override browser defaults and use plain-old, semantic HTML (POSH), you’ve done half of the work already.

I like the Eloquence speech synthesizer. It sounds similar to the robotic yet predictable voice of my beloved eSpeak NG, but with improved overall quality. Unfortunately, Eloquence is proprietary.

Exhibit C: Deep learning speech synthesis

Deep learning speech synthesis is a recent approach to speech synthesizer creation. It involves training a deep neural network on voice samples, and using the trained model to generate speech similar to a real human voice. One synthesizer using deep learning speech synthesis is Mozilla’s TTS.

Zero-shot approaches could allow a pre-trained model to generate multiple different voices. YourTTS is one such example. This could allow us to synthetically re-create a person’s voice more easily.

My horrible plan

My horrible plan revolves around going through two different lawsuits to set some judicial precedents; these precedents could improve the odds of succeeding in a lawsuit against Microsoft for Copilot’s licensing violations.

If this succeeds, we have new legal justification that GitHub Copilot is illegal; if it fails, we have still gained a means to legally re-create proprietary software. It’s a win-win situation.

Part One: set a precedent

Train a modern text-to-speech (TTS) engine using the voice a proprietary one made by a company with a small legal budget. Keep the model’s internals hidden.
Then release the final TTS under a permissive license. Remember, we’re still keeping the machine-learning model hidden!
Wait for that company to file suit.³
Win or lose the case.

Part Two: use that precedent against Microsoft’s Nuance

Our goal here is to get the same legal outcome as the low-stakes “trial run” of Part One.

Microsoft owns Nuance. Nuance previously bought Eloquent Technology, the developers of the Eloquence speech synthesizer.

Repeat Part One against Nuance speech synthesizers, including Eloquence. Go to court.
Have the ruling from Part One cited as legal precedent.
Achieve the same outcome as Part One, demonstrating that we have indeed set precedent that works against Microsoft’s legal department.

Implications of the outcomes

If we win both cases: Microsoft has the legal high ground. Making a derivative of a copyrighted work using a machine-learning algorithm allows us to bypass copyright licenses.

If we lose both cases: Microsoft does not have the legal high ground. We have good judicial precedent against Microsoft to use when filing suit for Copilot’s behavior.

Either way, it’s an absolute win for free software. Taking down Copilot protects copyleft from enabling proprietary derivatives (and by extension, protects software freedom). But if we accidentally win these two low-stakes “test” cases, we still gain something else: we can liberate huge swaths of proprietary software, starting with speech synthesizers.

Update: on satire

This post isn’t “satire through-and-through” like something from The Onion. Rather, my intent was to make some clear points, but extrapolate them to absurdity to highlight other problems. I don’t think I was clear enough when doing this. I’m sorry.

Copilot has been found to suggest significant amounts of code that is dangerously similar to existing works. It does this without disclosing obligations that come with those works’ licenses. Training a model on copyrighted works may not be wrong in and of itself; however, using that model to generate new works that are not sufficiently distinct from original works is where things get problematic. Copilot’s users could apply proprietary licenses to the generated works, defeating the point of copyleft.

When a tool almost exclusively encourages problematic behavior, the makers of that tool should have put thought into its implications. GitHub and OpenAI have not demonstrated a sufficiently careful approach.

I don’t think that “going after” a smaller player just to manipulate our legal system is a good thing to do. The fact that this idea seems plausible to some of my readers shows how warped our perception of the judicial system is. Even if it’s accurate (I doubt it’s accurate, but I’m not certain), it’s sad. Judicial systems incentivise too much predatory behavior.

Corrections

Updated on 2022-07-02: It’s has come to my attention that Eloquence may or may not still belong to Nuance. Further research is needed. Eloquent Technology was acquired by SpeechWorks in 2000.

See Comment Regarding Request for Comments on Intellectual Property Protection for Artificial Intelligence Innovation (application/pdf) submitted by OpenAI to the USPTO ↩︎
I doubt anybody worth their salt would count on a company to hold itself accountable, but at least they tried. ↩︎
If the stars align, you could file an anticipatory suit against the company. It’s common for declaratory judgement regarding intellectual property rights. ↩︎

Two types of privacy

seirdy@seirdy.one (Seirdy) — Sat, 25 Jun 2022 22:25:14 +0000

Preface

Threat modelling provides important context to security and privacy advice. Measures necessary to protect against an advanced threat are different from those effective against unsophisticated threats. Moreover, threats don’t always fall along a simple one-dimensional axis from “simple” to “advanced”. I appreciate seeing communities acknowledge this complexity.

When qualifying privacy recommendations with context, I think we should go further than describing threat models: we should acknowledge different types of privacy. “Privacy” means different things to different people. Even a single person may use the word “privacy” differently depending on their situation. Understanding a user’s unique situation(s), including their threat models, can inform us when we select the best of approach. How do we choose between reducing a footprint’s spread and size?

Toggle table of contents

Introduction

I highlight two main approaches to privacy: “tracking reduction” and “tracking evasion”.

Tracking reduction (TR): TR aims to reduce the amount of data collected about an exposed user. It reduces a footprint’s spread primarily by blocking trackers. Sometimes this can increase the size of a footprint.
Tracking evasion (TE): TE reduces the amount of data exposed by a user. Rather than eliminating data collection itself, TE prevents useful data from being made available in the first place. In other words, it reduces a footprint’s size.¹

There is gray area between these two extremes, and not every privacy measure falls neatly into one of these two categories. I’ll address that later in this article.

Note: this article focuses primarily on Web browsers; however, its concepts can apply to any software capable of tracking users.

Let’s get started:

Tracking reduction (TR)

TR is suitable for casual threat models. These techniques typically aim to remove trackers or to block malicious traffic.

If someone just wants to browse the web with less tracking, they’re probably not expecting a “nuclear option” that removes all their personalization. That user is more likely to be concerned with manipulation by personalized ads, or something vague such as being “followed around” as they browse websites while signed out.

These users are likely okay with being identified by a site; several of their accounts are probably linked to the same identity. However, when they log into “example.com”, they’d rather not ping trackers from “facebook.com” or “amazon-adsystem.com”.

Of course, data-sharing could happen on the backend. Users may accept that there’s little they can do about this beyond reading a privacy policy and filing suit upon violations.

In other words, TR falls closer to “wants” on the (somewhat contrived) “wants versus needs” spectrum. It addresses the gray area between personal preferences and real present threats. Our goal is to reduce tracking where we can, without significantly degrading the user experience.

Sample TR techniques

Badness enumeration: content-blocking and firewalls.
Sending headers such as Global Privacy Control or Do Not Track.
Opting out of tracking when given the choice.
Exercising legal rights (e.g., rights granted under the GDPR or CCPA) to remove information.
Having a preference for services whose privacy policies indicate less data collection and/or sharing.
Turning off telemetry.

Attack surface

I mentioned content-blocking, which typically happens through browser extensions and/or third-party filter lists. These can add attack surface; be mindful of the trade-off. Even trusted extensions like uBlock Origin are no exception; exercise restraint when adding third-party filter lists.

I covered this topic a bit more in A layered approach to content blocking. Safe yet limited approaches to content filtering should lay a foundation, topped off by risky yet powerful approaches that users selectively enable.

Tracking evasion (TE)

TE prevents an adversary from collecting meaningful information tied to one’s identity. Unlike “opting-out” and blocking well-known third-party trackers, tracking evasion distrusts all parties by default. This approach assumes that tracking is equally likely to happen through both first-party and third-party trackers.

Therefore, a list of known third-party trackers is irrelevant to tracking evasion. Users following this approach in its purest form treat every party capable of tracking as a hostile tracker.

TE techniques typically revolve around minimizing the size of one’s fingerprint, either through fingerprint normalization or randomization.²

Sample TE techniques

Using the Tor Browser.
Avoiding identifiable browser extensions.
Randomizing typing behavior (A good example is kloak, a keystroke anonymizer used by Whonix).
Using a coarse scroll interval.

Half-measures are ineffective

If an adversary employs multiple fingerprinting vectors, then normalizing or randomizing a small subset of those vectors might make a user stand out even more.

xkcd comic: license plate

A difficult-to-read licence plate number will stand out, putting the owner at risk. Similarly, TE half-measures could make users more easily identifiable. From xkcd

Toggle comic transcript

Comic transcript

Cueball is walking in from the right holding a license plate up with both hands for an off-panel Megan to see. It is possible to see the plate, but here it looks like all I’s (or 1’s).

Cueball: Check out my personalized license plate!
Megan (off-panel): “1I1-III1”?
Cueball: It’s perfect!
Cueball: No one will be able to correctly record my plate number!
Cueball: I can commit any crime I want!
Megan: Sounds foolproof.

Soon, at a crime scene:

Witness: The thief’s license plate was all “1"s or something.
Police officer 1: Oh. That guy.
Police officer 2: His address is on a post-it in the squad car.

Transcript based on the explain xkcd wiki entry for xkcd #1105.

TE carries the risk of “springing a leak”. While TR presents an incremental solution, TE is much harder: it’s only a slight exaggeration to describe TE as a binary “all-or-nothing” approach.

Conflicts between TR and TE

Good approaches to TR often weaken TE. Conflating the two can have harmful consequences.

Badness enumeration: content blocking

While content blocking through badness enumeration is useful for TR, it’s generally antithetical to TE. A website can use a first-party script and/or inspect server logs to determine information such as:

Which network requests succeed or fail.
Whether certain elements (e.g. certain images) load successfully.
Whether injected content (e.g. from an ad-blocker) is present.³
Whether content-blocking changes which elements are in or near the viewport.⁴

These pieces of information (and others I haven’t included) can tell a website if a browser has a content-blocker, and which filters a user has enabled. The latter piece of information can uniquely identify a user; this compromises TE. Nonetheless, these techniques aren’t in widespread use. I think that sharing first-party fingerprinting data between different organizations is the exception rather than norm. As long as this is the case, content-blocking remains a viable technique for TR.

Badness enumeration shouldn’t be applied in a TE context. The Tor Browser’s design philosophy explicitly includes a “no filters” directive and recommends against their use, to reduce fingerprinting. As of mid-2022, the version of the Tor Browser included in Tails includes a content-filtering extension anyway. The entire point of using the Tor Browser Bundle is to maximize TE; Tails compromises this goal.

Brave has a similar problem. Its content-blocker allows users to create custom filters or activate additional filter lists. Brave also tries to enable TE through fingerprint-randomization. Combining the two likely makes users even more unique. Brave could mitigate this flaw by having its “advanced” level of fingerprinting protection also normalize the content-blocking filters applied.⁵

Do Not Track (DNT)

DNT was an HTTP request header indicating that a user does not wish to be tracked. Unfortunately, unlike Global Privacy Control, there was no legal obligation to obey DNT. The DNT header ended up being used as a fingerprinting vector to track users instead of a way for them to avoid tracking.

WebKit removed DNT support because it was antithetical to TE, and its utility for TR was too low to justify these harms.

Exceptions and overlap

There is grey area between TE and TR. Some techniques don’t neatly fit into one of the two categories. Here’s an incomplete list of those techniques, for illustrative purposes:

Disabling browser features: The fingerprintability of disabling JavaScript, the Reporting API, and hyperlink auditing is typically dwarfed by the the fingerprinting made possible by enabling them. I struggle to categorize this technique. On one hand, feature-toggles represent uncommon browser configuration that may prevent some trackers from running (TR); on the other, it treats all external parties equally and can reduce fingerprinting vectors (TE). I’m inclined to say that feature-disabling is closer to TE than TR only if enough people share the same configuration.⁶
Goodness enumeration: Assuming that all actors are actively hostile might be overkill. A user may follow a TE approach and/or disable browser features, while also maintaining a list of trusted exceptions. Trusted sites may use disabled features or have access to a larger fingerprint. This represents a “middle ground” of sorts between the convenience of TR and the effectiveness of TE.
Amnesia: The most common amnesiac technique is clearing cookies. A more thorough technique is using a disposable VM that’s erased and re-created between sessions. Rather than reduce or evade tracking, these measures reduce the persistence of trackers (and/or malware) that slip through other defenses.

The list goes on. “TR versus TE” is an important perspective to have, but it isn’t the only lens through which we should view privacy-enhancing techniques. Let’s be mindful of the TR/TE framework’s limitations.

How to make privacy recommendations

Privacy-enhancement recommendations need to account for whether a preference for TR over TE exists. Whenever applicable, please do the following:

Clarify if a privacy-enhancing technique has a focus on TR or TE.
When discussing TR techniques, mention any compromises made from a TE perspective.

Most importantly: recognize that different people need to make different trade-offs. Someone with special needs might require some fingerprintable personalizations. If non-negotiable personalizations make tracking-evasion too difficult, you might need to steer the person towards tracking-reduction and explain the trade-offs involved.⁷

A single solution isn’t enough for everyone. In fact, it’s not usually enough for an individual. An individual may switch between multiple tasks, each with a different list of acceptable trade-offs.

For example, you can encourage people to use multiple browsers and browser-profiles for different needs. Users could use a “TR browser” to sign into their school or work accounts, but use a “TE browser” to browse anonymously.

Personally: my “main” browser is a heavily personalized Firefox that trades away some security and privacy; where possible, it employs TR. I browse anonymously in the Tor Browser with “Safest” mode enabled to achieve TE, or using the “Safer” mode in Whonix. Finally, I use certain web apps in Chromium without any privileged extensions: this trades both convenience and privacy for some forms of security.

Threat modelling

Threat modelling is critical when deciding whether TR or TE is relevant, and how far one must go to achieve TE. It’s slightly less relevant when it comes to deciding which TR techniques are effective. This is because TR involves less advanced threat models and addresses needs that blur the lines between security, privacy, and convenience.

Rather than framing discussions explicitly in terms of threats, it makes more sense to frame a TR technique in terms of what the technique improves and worsens regarding privacy, security, and convenience. Take what you can get until things get annoying; save extreme measures for a different browser or browser-profile.

Threat modelling does make sense whenever security trade-offs come into play. It’s relevant when evaluating security trade-offs of TR techniques involving privileged extensions.

Conclusion

Communities are starting to understand that recommendations should be made in the context of threat models, and that security- and privacy-related goals are different despite having significant overlap.

People are complex creatures. When recommending techniques to improve privacy, we should remember that different people have different goals. Moreover, an individual’s goals may vary depending on the situation.

Our recommendations need to take into account the fact that “privacy” means different things to different people. Techniques that aid in tracking-reduction might weaken tracking-evasion. The latter is much more powerful, but it’s also not necessarily what everyone is looking for.

Acknowledgements

My article could be considered a “derivative work” of Recommending Tools by the EFF. That article laid the foundations for my thought process.

This article is an expansion of the ideas I presented in the microblog entry On tracker blocking. That microblog entry was a response to the article Browser Tracking by Madaidan; this article’s coverage of TE draws from that article.

I’d have liked to call this “Tracking prevention”. Unfortunately, that name is taken by a Firefox feature aiming to achieve tracking reduction. Naming things is difficult. ↩︎
I haven’t seen much research comparing these two approaches, but I’m not convinced they’re in conflict. Normalizing all vectors that can be normalized but randomizing the rest sounds like a decent strategy. At least, as long as users don’t significantly adjust which vectors are normalized or randomized. ↩︎
Sites can detect injected content even without scripts by using Content-Security-Policy reporting APIs. For this reason, uBlock Origin includes a preference to disable all CSP reports. That being said, sites can still use first-party scripts to do the same. ↩︎
This is possible without any JavaScript, using lazy-loading directives. Browsers like Firefox disable lazy-loading if JavaScript is also disabled via about:config, to mitigate this. If JavaScript is enabled, assume this is always a possibility. ↩︎
This does present a new issue: filter lists need to get updated at a different cadence than the browser. Not everyone updates at the same time. Imagine that a given browser version at a given time has V versions of a filter list in use across a user-base. Users have N different filters enabled. That’s V×N possible combinations. I’m over-simplifying; the point is that filter lists enabled could add significant entropy to a user’s fingerprint, and that’s before you involve custom filters.

We could reduce the number of combinations by combining all the filter lists into a single list that gets updated all at once. When N=1, we’re at just V possible combinations. Updates could be spread out over a longer cadence, decreasing the value of V. ↩︎
Torbutton aims to allow many Tor Browser users to share the same configuration. See its security settings and the preferences they change. ↩︎
Users of metered connections may need to block large elements. Users with accessibility needs may need to alter inaccessible pages. Users who don’t speak a page’s language may need to use machine translation.⁸ Telling users to just “stop doing this” would be arrogant, yet all three of these examples are fingerprintable. ↩︎
Copying page text and pasting it into a separate translation tool could help, but it’s not always a replacement for full-page translation. Machine translation uses semantic HTML, and plain-text translation often provides worse results. (ooh, is this my first footnote within a footnote?) ↩︎

Best practices for inclusive CLIs

seirdy@seirdy.one (Seirdy) — Sat, 11 Jun 2022 02:24:54 +0000

Preface

This began as a reply to another article by Lucas F. Costa; it lists practices to improve user-experience (UX) of command-line interfaces (CLIs). It comes from a good place, and has some good advice: I particularly like its advice on input-validation and understandable errors. Unfortunately, a number of its suggestions are problematic, particularly from an accessibility perspective.

This is a “living article” that I plan on adding to indefinitely. If you like it, come back in a month or two and check the “changelog” link in the article header.

Note: this article specifically concerns CLIs, not full-blown textual user interfaces (TUIs). It also focuses on utilities for UNIX-like shells; other command-line environments may have different conventions.

Toggle table of contents

Problematic patterns

The “Getting Started Experience” section of Lucas’ article has a GIF video of a CLI utility printing --help output, featuring a decorative border.

Code snippet 4 (console): Lucas’ article leads with an example --help output that’s surrounded by a decorative textual border. This is a transcription of the output, wrapped to a narrower width.

$ tool --help

╔ Getting started ════════════════════════════════════════╗
║                                                         ║
║  To scaffold a new project, run:                        ║
║                                                         ║
║    $ mytool init <directory>                            ║
║                                                         ║
║  If you already have a project set up and would like to ║
║  add, remove, or update its structure, run:             ║
║                                                         ║
║    $ mytool manage                                      ║
║                                                         ║
╚═════════════════════════════════════════════════════════╝

Usage: tool <command> [options]
Commands:
  tool init [directory]	creates a new project
  tool manage	allows you to manage an existing project

Options:
  --help	Show help	[boolean]
  --version	Show version number	[boolean]

Borders in TUIs should always be drawn with characters specifically intended for textual interfaces (e.g., boxdraw characters). While I do think the GIF followed this advice, I think it’s worth explicitly saying it. Accessible terminal emulators can figure out what these mean and factor them into what they report through an accessibility API. But breaking these borders up with descriptive text makes detection of readable text error-prone.
Borders should be used sparingly, as they end up causing issues when the window is re-sized.¹ Re-sizing terminal windows is quite common: think about the combined user-base of tiling window managers, tiling terminal session managers (Tmux, Screen, etc.), multiplexing terminal emulators, and plain old split-windows.
Decorative content in CLI output should be limited, since the output of CLI utilities can be piped through other programs. At the very least, these tools should be able to detect whether their standard output is being re-directed or piped and sanitize output accordingly.

The “Colours, Emojis, and Layouting” (sic) section has similar issues:

Nearly all animated spinners are extremely problematic for screenreaders. A simple progress meter and/or numeric percentage combined with flags to enable/disable them is preferable.
Excessive animation and color can harm users with attention and/or vestibular disorders, and some on the autism spectrum. Many tools offer a --color[=WHEN] flag where WHEN is always, never, or auto. Expecting users to learn all the color configurations for all their tools is unrealistic; tools should respect the NO_COLOR environment variable.

Recommendations

This is a non-exhaustive list of simple, baseline recommendations for designing CLI utilities.

Accessibility

Send your tool’s output through a program like espeak-ng and listen to it. Can you make sense of the output?
Refer to the latest WCAG publication (currently WCAG 2.2) and take a look at the applicable criteria. Many have accompanying techniques for plain-text interfaces.. Avoiding reliance on color in favor of whitespace and/or indentation for pseudo-headings are two sample recommendations from the WCAG.
Make sure your web-based documentation and forge frontends are accessible, or are mirrored somewhere with good accessibility. I love what the Gitea folks are doing, but sadly their web frontend has a number of critical issues.² For now, if your forge has accessibility issues, mirroring to GitHub and/or Sourcehut seems like a good option.
Avoid ASCII-art, and use presentational text sparingly. Include a way to configure output to be friendly to screen-readers and log files alike (if it isn’t already). For example, a simplified output mode can occasionally log a percentage-complete instead of a progress bar.

Familiarity

How “unique” is your tool’s output? Output should look as similar to other common utilities as possible, to reduce the learning curve. Keep it boring.
Follow convention: use POSIX-like options. Consider supplementing them with GNU-style long options if your tool has a significant number of them.³
Avoid breaking changes to you program’s CLI. Remember that its argument parsing is an API, unless documentation explicitly states otherwise.⁴ Semantic versioning is your friend.
Be predictable. Users expect git log to print a commit log. Users do not expect git log to make network connections, write something to their filesystem, etc. Try to only perform the minimum functionality suggested by the command. Naturally, this disqualifies opt-out telemetry.

Documentation

Write man pages! Man pages have a standardized,⁵ predictable, searchable format. Many screen-reader users actually have special scripts to make it easy to read man pages. A man page is also trivial to convert to HTML for people who prefer web-based documentation.⁶ If your utility has a config file with special syntax or vocabulary, write a dedicated man page for it in section 5 and mention it in a “SEE ALSO” section.⁷
Try adding shell completions for your program, so users can tab-complete options. This is particularly helpful in shells like Zsh that support help-text in tab completions, especially when combined with plugins like fzf-tab that enable fuzzy-searching help-text (see code snippet 2).
Related to no. 2: use a well-understood format for -h and --help output. This makes auto-generating shell completions much easier. A great example is the Busybox coreutils’ help output: it is much more concise than man pages, but descriptive enough to serve as a quick reference. Alternatively, delegate the generation of both to a library that follows this advice.
Ensure that the whatis and apropos commands work as intended after installing your man pages. These commands parse the beginnings of man pages to give one-line summaries of programs, and often power advanced tab-completion setups.

Code snippet 5 (console): This is what tab-completion for MOAC looks like with fzf-tab.

$ moac -
> -p
  9/11 (0)
  -P  -- power available to the computer (W)
> -p  -- password to analyze
  -s  -- password entropy
  -h  -- display this help message
  -r  -- interactively enter a password in the terminal; overrides -p
  -T  -- temperature of the system (K)
  -m  -- mass at attacker's disposal (kg)
  -q  -- account for quantum computers using Grover's algorithm

Miscellaneous

Either delegate output wrapping to the terminal, or detect the number of columns and format output to fit. Prefer the former when given a choice, especially when the output is not a TTY.
Be safe. If a tool makes irreversible changes to the outside environment, add a --dry-run or equivalent option.
If your tool has color output: disable color when the output is not a TTY, unless the user explicitly force-enables color via a command-line flag. Many tools support a --color flag that accepts the values “always”, “never”, and “auto”.

More opinionated considerations

These considerations are far more subjective, debatable, and deserving of skepticism than the previous recommendations. There’s a reason I call this section “considerations”, not “recommendations”. Exceptions abound; I’m here to present information, not to think on your behalf.

Remember that users aren’t always at their best when they read --help output; they could be trying to solve a frustrating problem, feeling a great deal of anxiety. Keep the output clean, predictable, boring, and fast. A 2-second delay and spinning fans will probably be extremely unpleasant for already-stressed users, especially if they need to use it often.⁸
Include example usage in your man pages and accompanying documentation. Consider submitting the example usage to the tldr pages project if your tool gets popular.
Include an extended list of example command invocations and expected output. Make that document double as a test suite. My moac testdata and moac-pwgen testdata scripts are good examples. This can serve as a check for API stability, and even as a source of documentation.
Make your man pages as similar to other man pages on the target OS as possible. Many programs parse man pages, and expect them to follow a predictable structure. Try testing your man pages in multiple programs, just as people test Web pages in multiple browser engines. Some examples:
- w3mman (included in w3m) is a good example to make sure auto-hyperlinking works.
- Editors like Vim support looking up man pages for the currently-selected word. Try pressing Shift+k while your caret is on a command name.
- Pandoc is another tool worth testing; it can convert man pages to a variety of different formats.
Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils: model its behavior, help-text, and man pages after ripgrep and fd. If you’re making a linter for Go: copy go vet.
If you want to keep your tool simple, make the output readable to both humans and machines; it should work well when streamed to another program’s standard input and when parsed by a person. This is especially useful when people redirect output streams to log files, and to screen readers.
Consider splitting related functionality between many executables (the UNIX way) and/or sub-commands (like Git). I split MOAC’s functionality across both moac and moac-pwgen, and gave moac three subcommands. The “Consistent commands trees” section of Lucas’ article has good advice.
Don’t conflate CLIs and TUIs. A CLI should be non-interactive; a TUI should be interactive. Exceptions exist for really simple interfaces (e.g. Magic-Wormhole and others like it) that accept user input; however, as the interface grows more complex, consider splitting the program into two sibling programs, one of which can have a “pure” non-interactive CLI.
Go above and beyond by writing separate integrations for environments like Emacspeak.⁹

Name conflicts

This section might be the most important part of this post. If a CLI executable has a binary name conflict, packagers may have to re-name it. Otherwise, users will have to juggle $PATH overrides.¹⁰

Before publishing your software, test for binary name conflicts. Many package managers have built-in functionality to search for package files. I recommend doing so with large repositories to test for conflicts.

Code snippet 6 (console): On Fedora and derivatives, use DNF to query package contents. You can also check cht.sh for other common commands.

$ dnf provides /usr/bin/p
Last metadata expiration check: 0:48:19 ago [...]
perl-App-p-0.0400-19.fc36.noarch : Steroids for your perl one-liners
Repo        : fedora
Matched from:
Filename    : /usr/bin/p

$ curl https://cht.sh/fly
# fly
# Command-line tool for concourse-ci.
# More information: <https://concourse-ci.org/fly.html>.
[...]

Thanks to Emily for reminding me of name conflicts.

References and further reading

Harini Sampath, Alice Merrick, and Andrew Macvean. 2021. Accessibility of Command Line Interfaces. In CHI Conference on Human Factors in Computing Systems (CHI ‘21), May 8–13, 2021, Yokohama, Japan. ACM, New York, NY, USA 10 Pages. DOI 10.1145/3411764.3445544
Techniques for WCAG 2.2. Alastair Campbell, Michael Cooper, Andrew Kirkpatrick. W3C. 2022-05-30.
Command Line Interface Guidelines. Aanand Prasad, Ben Firshman, Carl Tashian, Eva Parish. Commit 89d755c, 2022-04-19.

Yes, it’s possible to support re-sizing by using a TUI library like ncurses. Unfortunately, TUIs are out of scope for this article; I’m focusing mainly on CLIs. ↩︎
See this Fediverse thread about forge accessibility. ↩︎
I need to take my own advice for programs like MOAC. Ugh. ↩︎
For a good example, see Git’s distinction between regular output and porcelain-friendly output. The instability of the former and stability of the latter are explicitly documented in the Git man pages and in the official Git book. ↩︎
Well, they’re somewhat standardized compared to plain stdout. ↩︎
My other article on accessible textual websites is probably relevant when it comes to Web-based documentation ↩︎
For more on man page sections, see the man(1) man page. ↩︎
The slow responses to basic flags like --help is one of many reasons I dislike Java command-line utilities (signal-cli, Nu HTML Checker). I believe I’m not alone when I say this. ↩︎
I used to not-very-seriously claim that Neovim, my preferred $EDITOR, is better than Emacs. Then I tried Emacspeak. I still make the same claim, but more softly and with an exception for Emacspeak. ↩︎
A notable exception is executables that are supposed to conflict with others. Distributions like Fedora, Debian, and derivatives have an “alternatives” system to manage these overrides using symlinks. Examples include toolchains (cc and ld could point to their GCC or Clang implementations) and mail transfer agents (sendmail and mta have been re-implemented many times over). ↩︎

A layered approach to content blocking

seirdy@seirdy.one (Seirdy) — Sun, 05 Jun 2022 05:47:00 +0000

The Chromium team is planning on phasing out Manifest V2, its current set of extension APIs, in favor of Manifest V3. Manifest V3 involves giving extensions less access to page contents. Instead, extensions use new APIs that involve giving the browser simple instructions for page modification. The browser performs those instructions using its own logic; extensions themselves can’t access page contents.

This represents a tremendous trade-off: extensions need to be trusted less, but are also less capable. The implications for content blockers (ad-blockers) caused significant backlash.¹ Mozilla plans on adopting Manifest V3 in Firefox with additional APIs to re-introduce the lost functionality. Discourse on the topic has been polarized, full of oversimplification, and devoid of nuance.

My views on the situation are a bit complicated.

The existing content filtering landscape

uBlock Origin² has advanced content filters, with the ability to inject near-arbitrary stylesheets and a number of scripts into pages. Injecting scripts and stylesheets is often necessary to bypass malicious “anti-adblock” scripts or to skip certain types of video ads on streaming platforms. Unfortunately, this presents a security risk: users must trust every filter to not inject malicious stylesheets. Furthermore, sometimes these extensions don’t run their filters “in time”; a delay in running a filter could allow unwanted content to sneak through. This is especially common during browser launch. Nonetheless, its functionality makes the user-hostile Web considerably less frustrating, and I rely on it every day.

Chromium’s Manifest v3 includes the declarativeNetRequest API, which delegates these functions to the browser rather than the extension. Doing so avoids the timing issues visible in privileged extensions and does not require giving the extension access to the page. While these filters are more reliable and improve privilege separation, they are also substantially weaker. You can say goodbye to more advanced “anti-adblock” circumvention techniques.

Hostname or IP-based based network filtering is the least capable but most reliable approach. Filters are limited to domain names (i.e. you can’t block individual paths from a domain or make cosmetic filters), and they run unconditionally and globally. However, they don’t introduce nearly the same attack surface as other methods. When combined with CNAME-uncloaking, they’re quite effective at what (little) they do. The best part is that they carry little to no overhead; these lists can scale to millions of domains if applied on the DNS level.

Context: extension permissions systems

Firefox allows extensions to declare their own permissions. Extensions decide which sites they can run on and when, with required and optional permissions.

Chromium has a similar system with additional functionality: users can choose to enable an extension only when clicked, only for a certain site, or for all sites globally. Safari takes this a step further and also offers the choice to enable an extension for a limited time period (one day).

On Firefox, users of an extension like Stylus³ would need to grant the extension access to every page. On Chromium, users only need to grant it access to the subset of pages they need to theme.

A layered approach to content filtering

I think content filtering should follow a layered approach. It can have three layers:

Coarse network filters: These can be DNS- or IP-based filters that run globally. They can be applied to an entire network, a device, and/or a given network namespace.
Declarative filters: Simple content-blocking rules that are parsed and enforced by the user-agent. These filters can be restricted to safe blocking rules that don’t inject content into pages.
Privileged extensions: The most powerful and most risky types of page alteration, containing Turing-complete logic. These can make arbitrary page alterations, edit cookie contents, inject scripts and stylesheets, and re-write request URLs. These extensions can alter a page’s Content Security Policy to allow running injected scripts.

DNS- or IP-based filters can run system-wide, and be limited to safe filters that are unlikely to trigger site breakages. Atop these filters, browsers can globally enable extensions that use declarative filters. A browser could be configured to ignore global hostname or IP filters that are already covered by the aforementioned system-wide filters; doing so could improve performance when users enable a high number of filters.

Users can then choose to selectively enable a privileged extension (such as uBlock Origin) only on sites that continue to misbehave, using something resembling Chromium’s extension permission system. Privileged extensions can perform any functionality not covered by the previous two layers. Selectively enabling them significantly reduces attack surface without crippling the ability to modify content.

The safe layers: network and declarative filters

Say a user visits a typical site containing JavaScript and/or WebAssembly, some of which is malicious.⁴ System-wide network filters can block domains serving third-party malware, such as Google Ads or Google Analytics. Overly security conscious users can use built-in browser functionality to block cookies and scripts by default, and enable them on a site-by-site basis.⁵

A user might need to enable these scripts, or some malware might sneak through coarse network filters as first-party content. The site may contain other pure HTML- and CSS-based annoyances like “sign up” modals, cookie notices, sticky headers, dickbars, etc. Declarative filters serve as a second layer of defense to handle these.

The advanced layer: privileged extensions

The final layer is advanced page alteration. Anti-adblock software is the most common offender, but other examples exist.

A page may use a single blob of JavaScript that contains both malware and essential functionality. Simply blocking the script will break the page, but allowing it would cause a user’s device to perform an unwanted action. It’s unreasonable to expect users to reverse-engineer every obfuscated script they come across; plenty would appreciate some sort of automatic filtering.

Maybe the page contains a JavaScript video player with auto-playing media, and the user wants to block auto-playing videos conditionally. The user might have enabled auto-playing videos for the site’s “videos” section but wish to disable auto-playing for its “articles” section.

An extension that can access the page, inject its content, and use complex logic to alter the page can fix these problems. It could replace a malicious script with an alternative that provides the necessary functionality while stubbing off malicious functionality, alter cookies that power paywalls triggered after a given number of “articles read”, or change video player states based on the video’s metadata.

One example I find particularly interesting: a friend of mine has been working on an extension to only load animated GIFs conditionally. Some animated GIFs are fine, but others contain flashing colors that we consider to be overstimulating.⁶ The extension would disable auto-playing GIFs and inspect each one. After inspecting a GIF, it would animate it if consecutive frames fall below a given contrast ratio.

Several more examples are available in uBlock Origin’s resource library. Much of this functionality would be unavailable to Manifest V3 extensions in Chromium.

Frequently-asked questions

I’ll update this section as I collect feedback. Watch this space.

Malicious extensions can still request permission to read the contents of the page. What have you done differently besides adding new APIs?

The difference is that these malicious extensions will require the extra permission to access your data for all websites, while extensions using declarative APIs will not. Security-conscious users can keep that fact in mind. However, we shouldn’t speak for other users with different priorities.

I imagine that an opinionated security-focused browser could make it possible for users to enable privileged extensions only on a site-by-site basis, for those interested (Update: Hexavalent has been discontinued). Personally, I think that it’s probably best to limit scriptlet injection to signed scripts.⁷

Another difference is that while declarative filtering does have reduced functionality, it’s also more effective in some ways. Declarative filters generally have a lower footprint and are less likely to experience the delayed execution that lets some unwanted content slip through.

If we trust our extension developers, is any of this really necessary?

With adblockers, you don’t just trust extension developers; you also trust filter-list contributors. Many filter lists have thousands of entries aggregated from other filter lists, so trust-by-proxy ends up covering a lot of ground. This also applies to userstyle extensions: you have to trust the authors of each theme.

CSS injection is a powerful tool that can be used well or maliciously. Remember that its contributors and extension developers could be well-meaning but still allow a vulnerability to slip through, especially when you account for extensions that alter a site’s CSP.

I still use these privileged extensions, but I try to limit their scope to sites where they’re necessary.

Conclusion

I don’t think Manifest V3 can replace Manifest V2’s privileged extensions, and I don’t think existing APIs should be removed without replacement. However, that doesn’t mean V3’s APIs can’t be useful. While its scope is smaller, its blocking is safer and more reliable. Declarative approaches work well as a complement to other content-blocking techniques in a layered approach to content blocking. I felt the need to write up my thoughts because they didn’t fit in with the current polarized discourse around content blocking.

Rather than using a single tool to perform all content filtering, we should try moving towards a layered approach. Each type of filter should be delegated to the tool best suited for the task. Users should have control over the scope of each layer.

I can already hear adtech-defenders typing a response that explains why choosing how to render downloaded content is problematic or unethical.

Users don’t know the contents of a resource before fetching it, so they can’t provide meaningful consent to any malicious behavior in said contents (e.g. tracking). Content providers must therefore respect user control over downloaded content if such networks are to function.

I start from the notion that when a user downloads a document, they are entitled to do what they wish with it. If it’s broken or malicious, they should be able to fix it. When it comes to accessibility—especially regarding cognitive accessibility for ADHD and anxiety disorders—content blocking isn’t always optional.

Browsers don’t download a rendered page; they download source code. It’s up to the user agent to choose if or how that code renders. As long as users can control their means to browse the web, content “alteration” is a part of the package. ↩︎
Not to be confused with the unrelated extension called “uBlock”. ↩︎
Stylus is an extension that allows injecting special stylesheets (called “userstyles”) into pages to change their appearance. Stylesheets can be applied to specific pages, pages matching a pattern, or globally. ↩︎
I use the term “malicious” loosely here. These scripts could perform tracking without prior informed consent or attempt to distract the user with ads, both of which are malicious. ↩︎
Chromium offers this functionality. If users choose to block all cookies, it exposes controls to allow cookies for the current site that last for the current session or persist until they expire. It offers a similar site-specific toggle for JavaScript. As far as I am aware, Firefox does not expose controls for managing these permissions on the current page: users need to open the preferences page every time they wish to add such a rule, or use a privileged extension. Update 2024-07-02: Firefox does support per-site cookie settings via the site permissions menu, accessible via Page Info. Thanks Noah! ↩︎
Animated custom emotes are a common offender, especially when a post contains several consecutive ones. ↩︎
One point of controversy is that major browsers only allow extensions signed by the browser vendor’s key. I think this is a legitimate concern, best solved by allowing users to easily specify an alternative signing key and sign extensions themselves. ↩︎

The right thing for the wrong reasons: FLOSS doesn't imply security

seirdy@seirdy.one (Seirdy) — Wed, 02 Feb 2022 23:16:00 +0000

Background

I find it quite easy to handle views different from my own. I feel more troubled when I see people agree with me for the wrong reasons.

It’s no secret that I’m a passionate supporter of software freedom: I’ve written two posts about how Free, Libre, and Open-Source software (FLOSS) is necessary but insufficient to preserve user autonomy:

Whatsapp and the domestication of users: The phenomenon of a class of predatory businesses models I call “user domestication” and defense measures: FLOSS, open platforms, and simplicity.
Keeping platforms open: How open platforms can lose their openness, and what measures can prevent this. The Web, XMPP, email, and Matrix are examples that highlight both sides of the issue.

After two posts spanning over 5000 words, I need to add some nuance.

Toggle table of contents

Introduction

One of the biggest parts of the Free and Open Source Software definitions is the freedom to study a program and modify it; in other words, access to editable source code. I agree that such access is essential; however, far too many people support source availability for the wrong reasons. One such reason is that source code is necessary to have any degree of transparency into how a piece of software operates, and is therefore necessary to determine if it is at all secure or trustworthy. Although security through obscurity is certainly not a robust measure, this claim has two issues:

Source code describes what a program is designed to do; it is unnecessary and insufficient to determine if what it actually does aligns with its intended design.
Vulnerability discovery doesn’t require source code.

I’d like to expand on these issues, focusing primarily on compiled binaries. Bear in mind that I do not think that source availability is useless from a security perspective (it certainly makes audits easier), and I do think that source availability is required for user freedom. I’m arguing only that source unavailability doesn’t imply insecurity, and source availability doesn’t imply security. It’s possible (and often preferable) to perform security analysis on binaries, without necessarily having source code. In fact, vulnerability discovery doesn’t typically rely upon source code analysis.

I’ll update this post occasionally as I learn more on the subject. If you like it, check back in a month or two to see if it has something new.

PS: this stance is not absolute; I concede to several good counter-arguments in a dedicated section!

How security fixes work

I don’t think anyone seriously claims that software’s security instantly improves the second its source code is published. The argument I’m responding to is that source code is necessary to understand what a program does and how (in)secure it is, and without it we can’t know for sure.

Assuming a re-write that fundamentally changes a program’s architecture is not an option¹, software security typically improves by fixing vulnerabilities via something resembling this process:

Someone discovers a vulnerability
Developers are informed of the vulnerability
Developers reproduce the issue and understand what caused it
Developers patch the software to fix the vulnerability

Source code is typically helpful (sometimes essential) to Step 3. If someone has completed Step 3, they will require source code to proceed to Step 4. Source code isn’t necessary for Steps 1 and 2; these steps rely upon understanding how a program misbehaves. For that, we use reverse engineering and/or fuzzing.

Reverse engineering

Understanding how a program is designed is not the same as understanding what a program does. A reasonable level of one type of understanding does not imply the other.

Source code² is essential to describe a program’s high-level, human-comprehensible design; it represents a contract that outlines how a developer expects a program to behave. A compiler or interpreter³ must then translate it into machine instructions. But source code isn’t always easy to map directly to machine instructions because it is part of a complex system:

Compilers (sometimes even interpreters) can apply optimizations and hardening measures that are difficult to reason about. This is especially true for JIT compilers that leverage run-time information.
The operating system itself may be poorly understood by the developers, and run a program in a way that contradicts a developer’s expectations.
Toolchains, interpreters, and operating systems can have bugs that impact program execution.
Different compilers and compiler flags can offer different security guarantees and mitigations.
Source code can be deceptive by featuring sneaky obfuscation techniques, sometimes unintentionally. Confusing naming patterns, re-definitions, and vulnerabilities masquerading as innocent bugs have all been well-documented: look up “hypocrite commits” or the Underhanded C Contest for examples.
All of the above points apply to each dependency and the underlying operating system, which can impact a program’s behavior.

Furthermore, all programmers are flawed mortals who don’t always fully understand source code. Everyone who’s done a non-trivial amount of programming is familiar with the feeling of encountering a bug during run-time for which the cause is impossible to find…until they notice it staring them in the face on Line 12. Think of all the bugs that aren’t so easily noticed.

Reading the source code, compiling, and passing tests isn’t sufficient to show us a program’s final behavior. The only way to know what a program does when you run it is to…run it.⁴

Special builds

Almost all programmers are fully aware of their limited ability, which is why most already employ techniques to analyze run-time behavior that don’t depend on source code. For example, developers of several compiled languages⁵ can build binaries with sanitizers to detect undefined behavior, races, uninitialized reads, etc. that human eyes may have missed when reading source code. While source code is necessary to build these binaries, it isn’t necessary to run them and observe failures.

Distributing binaries with sanitizers and debug information to testers is a valid way to collect data about a program’s potential security issues.

Dynamic analysis

It’s hard to figure out which syscalls and files a large program program needs by reading its source, especially when certain libraries (e.g. the libc implementation/version) can vary. A syscall tracer like strace(1)⁶ makes the process trivial.

A personal example: the understanding I gained from strace was necessary for me to write my bubblewrap scripts. These scripts use bubblewrap(1) to sandbox programs with the minimum permissions possible. Analyzing every relevant program and library’s source code would have taken me months, while strace gave me everything I needed to know in an afternoon: analyzing the strace output told me exactly which syscalls to allow and which files to grant access to, without even having to know what language the program was written in. I generated the initial version of the syscall allow-lists with the following command⁷:

strace name-of-program program-args 2>&1 \
	| rg '^([a-z_]*)\(.*' --replace '$1' \
	| sort | uniq

This also extends to determining how programs utilize the network: packet sniffers like Wireshark can determine when a program connects to the network, and where it connects.

These methods are not flawless. Syscall tracers are only designed to shed light on how a program interacts with the kernel. Kernel interactions tell us plenty (it’s sometimes all we need), but they don’t give the whole story. Furthermore, packet inspection can be made a bit painful by transit encryption⁸; tracing a program’s execution alongside packet inspection can offer clarity, but this is not easy.

For more information, we turn to core dumps, also known as memory dumps. Core dumps share the state of a program during execution or upon crashing, giving us greater visibility into exactly what data a program is processing. Builds containing debugging symbols (e.g. DWARF) have more detailed core dumps. Vendors that release daily snapshots of pre-release builds typically include some symbols to give testers more detail concerning the causes of crashes. Web browsers are a common example: Chromium dev snapshots, Chrome Canary, Firefox Nightly, WebKit Canary builds, etc. all include debug symbols. Until 2019, Minecraft: Bedrock Edition included debug symbols which were used heavily by the modding community.⁹

Dynamic analysis example: Zoom

In 2020, Zoom Video Communications came under scrutiny for marketing its “Zoom” software as a secure, end-to-end encrypted solution for video conferencing. Zoom’s documentation claimed that it used “AES-256” encryption. Without source code, did we have to take the docs at their word?

The Citizen Lab didn’t. On 2020-04-03, it published Move Fast and Roll Your Own Crypto (application/pdf) revealing critical flaws in Zoom’s encryption. It utilized Wireshark and mitmproxy to analyze networking activity, and inspected core dumps to learn about its encryption implementation. The Citizen Lab’s researchers found that Zoom actually used an incredibly flawed implementation of a weak version of AES-128 (ECB mode), and easily bypassed it.

Syscall tracing, packet sniffing, and core dumps are great, but they rely on manual execution which might not hit all the desired code paths. Fortunately, there are other forms of analysis available.

Binary analysis

Tracing execution and inspecting memory dumps can be considered forms of reverse engineering, but they only offer a surface-level view of what’s going on. Reverse engineering gets much more interesting when we analyze a binary artifact.

Static binary analysis is a powerful way to inspect a program’s underlying design. Decompilation (especially when supplemented with debug symbols) can re-construct a binary’s assembly or source code. Symbol names may look incomprehensible in stripped binaries, and comments will be missing. What’s left is more than enough to decipher control flow to uncover how a program processes data. This process can be tedious, especially if a program uses certain forms of binary obfuscation.

The goal doesn’t have to be a complete understanding of a program’s design (incredibly difficult without source code); it’s typically to answer a specific question, fill in a gap left by tracing/fuzzing, or find a well-known property. When developers publish documentation on the security architecture of their closed-source software, reverse engineering tools like decompilers are exactly what you need to verify their honesty (or lack thereof).

Decompilers are seldom used alone in this context. Instead, they’re typically a component of reverse engineering frameworks that also sport memory analysis, debugging tools, scripting, and sometimes even IDEs. I use the Rizin framework, but Ghidra is also popular. Their documentation should help you get started if you’re interested.

Example: malware analysis

These reverse-engineering techniques—a combination of tracing, packet sniffing, binary analysis, and memory dumps—make up the workings of most modern malware analysis. See this example of a fully-automated analysis of the Zoom Windows installer. It enumerates plenty of information about Zoom without access to its source code: reading unique machine information, anti-VM and anti-reverse-engineering tricks, reading config files, various types of network access, scanning mounted volumes, and more.

To try this out yourself, use a sandbox designed for dynamic analysis. Cuckoo is a common and easy-to-use solution, while DRAKVUF is more advanced.

Extreme example: the truth about Intel ME and AMT

The Intel Management Engine (ME) is a mandatory subsystem of all Intel processors (after 2008) with extremely privileged access to the host system. Active Management Technology (AMT) runs atop it on the subset of Intel processors with “vPro” branding. The latter can be disabled and is intended for organizations to remotely manage their inventory (installing software, monitoring, remote power-on/sleep/wake, etc).

The fact that Intel ME has such deep access to the host system and the fact that it’s proprietary have both made it the subject of a high degree of scrutiny. Many people (most of whom have little experience in the area) connected these two facts together to allege that the ME is a backdoor, often by confusedly citing functionality of Intel AMT instead of ME. Is it really impossible to know for sure?

I picked Intel ME+AMT to serve as an extreme example: it shows both the power and limitations of the analysis approaches covered. ME isn’t made of simple executables you can just run in an OS because it sits far below the OS, in what’s sometimes called “Ring -3”.¹⁰ Analysis is limited to external monitoring (e.g. by monitoring network activity) and reverse-engineering unpacked partially-obfuscated firmware updates, with help from official documentation. This is slower and harder than analyzing a typical executable or library.

Answers are a bit complex and…more boring than what sensationalized headlines would say. Igor Skochinsky (the developer of me-tools) and Nicola Corna (the developer of me_cleaner) presented their analysis of ME in Intel Me: Myths and Reality (application/pdf); Vassilios Ververis thoroughly analyzed AMT in Security Evaluation of Intel's Active Management Technology (2010, application/pdf). Interestingly, the former pair argues that auditing binary code is preferable to potentially misleading source code: binary analysis allows auditors to “cut the crap” and inspect what software is truly made of. However, this was balanced by a form of binary obfuscation that the pair encountered; I’ll describe it in a moment.

Simply monitoring network activity and systematically testing all claims made by the documentation allowed Ververis to uncover a host of security issues in Intel AMT. However, no undocumented features have (to my knowledge) been uncovered. The problematic findings revolved around flawed/insecure implementations of documented functionality. In other words: there’s been no evidence of AMT being “a backdoor”, but its security flaws could have had a similar impact. Fortunately, AMT can be disabled. What about ME?

This is where some binary analysis comes in. Neither Skochinsky’s ME Secrets presentation nor Intel Me: Myths and Reality seem to enumerate any contradictions with official Intel documentation.

Unfortunately, some components are poorly understood due to being obfuscated using Huffman compression with unknown dictionaries. Understanding the inner workings of the obfuscated components blurs the line between software reverse-engineering and figuring out how the chips are actually made, the latter of which is nigh-impossible if you don’t have access to a chip lab full of cash. However, black-box analysis does tell us about the capabilities of these components: see page 21 of “ME Secrets”. Thanks to zdctg for clarifying this.

Skochinsky’s and Corna’s analysis was sufficient to clarify (but not completely contradict) sensationalism claiming that ME can remotely lock any PC (it was a former opt-in feature), can spy on anything the user does (they clarified that access is limited to unblocked parts of the host memory and the integrated GPU, but doesn’t include e.g. the framebuffer), etc.

While claims such as “ME is a black box that can do anything” are misleading, ME not without its share of vulnerabilities. My favorite look at its issues is a presentation by Mark Ermolov and Maxim Goryachy at Black Hat Europe 2017: How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine (application/pdf).

In short: ME being proprietary doesn’t mean that we can’t find out how (in)secure it is. Binary analysis when paired with runtime inspection can give us a good understanding of what trade-offs we make by using it. While ME has a history of serious vulnerabilities, they’re nowhere near what borderline conspiracy theories claim.¹¹

(Note: Intel is not alone here. Other chips typically have equivalents, e.g. AMD Secure Technology).

Fuzzing

Manual invocation of a program paired with a tracer like strace won’t always exercise all code paths or find edge-cases. Fuzzing helps bridge this gap: it automates the process of causing a program to fail by generating random or malformed data to feed it. Researchers then study failures and failure-conditions to isolate a bug.

Fuzzing doesn’t necessarily depend on access to source code, as it is a black-box technique. Fuzzers like American Fuzzy Loop (AFL) normally use special fuzz-friendly builds, but other fuzzing setups can work with just about any binaries. In fact, some types of fuzz tests (e.g. fuzzing a web API) hardly need any implementation details.

Fuzzing frequently catches bugs that are only apparent by running a program, not by reading source code. Even so, the biggest beneficiaries of fuzzing are open source projects. cURL, OpenSSL, web browsers, text rendering libraries (HarfBuzz, FreeType) and toolchains (GCC, Clang, the official Go toolchain, etc.) are some notable examples.

I’ve said it before but let me say it again: fuzzing is really the top method to find problems in curl once we’ve fixed all flaws that the static analyzers we use have pointed out. The primary fuzzing for curl is done by OSS-Fuzz, that tirelessly keeps hammering on the most recent curl code.

— Daniel Stenberg, A Google grant for libcurl work

If you want to get started with fuzzing, I recommend checking out the quick-start guide for American Fuzzy Loop. Some languages like Go 1.18 also have fuzzing tools available right in the standard library.

Example: CVE-2022-0185

A recent example of how fuzzing helps spot a vulnerability in an open-source project is CVE-2022-0185: a Linux 0-day found by the Crusaders of Rust a few weeks ago. It was discovered using the syzkaller kernel fuzzer. The process was documented on Will’s Root:

CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers by willsroot

I highly encourage giving it a read; it’s the perfect example of fuzzing with sanitizers to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), then diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn’t available, the vendor would assume responsibility for the “find and fix” steps.

The fact that some of the most-used pieces of FLOSS in existence have been the biggest beneficiaries of source-agnostic approaches to vulnerability analysis should be quite revealing. The source code to these projects has received attention from millions of eyes, yet they still invest in fuzzing infrastructure and vulnerability-hunters prefer analyzing artifacts over inspecting the source.

Good counter-arguments

I readily concede to several points in favor of source availability from a security perspective:

Source code can make analysis easier by supplementing source-independent approaches. The lines between the steps I mentioned in the four-step vulnerability-fixing process are blurry.
Patching vulnerabilities is important. Source availability makes it possible for the community, package maintainers, or reporters of a vulnerability to patch software. Package maintainers often blur the line between “packager” and “contributor” by helping projects migrate away from abandoned/insecure dependencies. One example that comes to mind is the Python 2 to Python 3 transition for projects like Calibre.¹² Being able to fix issues independent of upstream support is an important mitigation against user domestication.
Some developers/vendors don’t distribute binaries that make use of modern toolchain-level exploit mitigations (e.g. PIE, RELRO, stack canaries, automatic variable initialization, CFI, etc.¹³). In these cases, building software yourself with these mitigations (or delegating it to a distro that enforces them) requires source code availability (or at least some sort of intermediate representation).
Closed-source software may or may not have builds available that include sanitizers and debug symbols.
Although fuzzing release binaries is possible, fuzzing is much easier to do when source code is available. Vendors of proprietary software seldom release special fuzz-friendly builds, and filtering out false-positives can be quite tedious without understanding high-level design.
It is certainly possible to notice a vulnerability in source code. Excluding low-hanging fruit typically caught by static code analysis and peer review, it’s not the main way most vulnerabilities are found nowadays (thanks to X_CLI for reminding me about what source analysis does accomplish).
Software as a Service can be incredibly difficult to analyze, as we typically have little more than the ability to query a server. Servers don’t send core dumps, server-side binaries, or trace logs for analysis. Furthermore, it’s difficult to verify which software a server is running.¹⁴ For services that require trusting a server, access to the server-side software is important from both a security and a user-freedom perspective

Most of this post is written with the assumption that binaries are inspectable and traceable. Binary obfuscation and some forms of content protection/DRM violate this assumption and actually do make analysis more difficult.

Beyond source code, transparency into the development helps assure users of compliance with good security practices. Viewing VCS history, patch reviews, linter configurations, etc. reveal the standards that code is being held up to, some of which can be related to bug-squashing and security.

Patience on Matrix also had a great response, which I agree with and adapt below:

Whether or not the source code is available for software does not change how insecure it is. However, there are good security-related incentives to publish source code.

Doing so improves vulnerability patchability and future architectural improvement by lowering the barrier to contribution. The fixes that follow can be shared and used by other projects across the field, some of which can in turn be used by the vendor. This isn’t a zero-sum game; a rising tide lifts all boats.
It’s generally good practice to assume an attacker has full knowledge of a system instead of relying on security through obscurity. Releasing code provides strong assurance that this assumption is being made. It’s a way for vendors to put their money where their mouth is.

Both Patience and Drew Devault argue that given the above points, a project whose goal is maximum security would release code. Strictly speaking, I agree. Good intentions don’t imply good results, but they can supplement good results to provide some trust in a project’s future.

Conclusion

I’ve gone over some examples of how analyzing a software’s security properties need not depend on source code, and vulnerability discovery in both FLOSS and in proprietary software uses source-agnostic techniques. Dynamic and static black-box techniques are powerful tools that work well from user-space (Zoom) to kernel-space (Linux) to low-level components like Intel ME+AMT. Source code enables the vulnerability-fixing process but has limited utility for the evaluation/discovery process.

Don’t assume software is safer than proprietary alternatives just because its source is visible; come to a conclusion after analyzing both. There are lots of great reasons to switch from macOS or Windows to Linux (it’s been my main OS for years), but security is low on that list.

All other things being mostly equal, FLOSS is obviously preferable from a security perspective; I listed some reasons why in the counter-arguments section. Unfortunately, being helpful is not the same as being necessary. All I argue is that source unavailability does not imply insecurity, and source availability does not imply security. Analysis approaches that don’t rely on source are typically the most powerful, and can be applied to both source-available and source-unavailable software. Plenty of proprietary software is more secure than FLOSS alternatives; few would argue that the sandboxing employed by Google Chrome or Microsoft Edge is more vulnerable than Pale Moon or most WebKitGTK-based browsers, for instance.

Releasing source code is just one thing vendors can do to improve audits; other options include releasing test builds with debug symbols/sanitizers, publishing docs describing their architecture, and/or just keeping software small and simple. We should evaluate software security through study rather than source model. Support the right things for the right reasons, and help others make informed choices with accurate information. There are enough good reasons to support software freedom; we don’t need to rely on bad ones.

Writing an alternative or re-implementation doesn’t require access to the original’s source code, as is evidenced by a plethora of clean-room re-implementations of existing software written to circumvent the need to comply with license terms. ↩︎
Ideally well-documented, non-obfuscated code. ↩︎
Or a JIT compiler, or a bunch of clockwork, or… ↩︎
For completeness, I should add that there is one source-based approach that can verify correctness: formal proofs. Functional programming languages that support dependent types can be provably correct at the source level. Assuming their self-hosted toolchains have similar guarantees, developers using these languages might have to worry less about bugs they couldn’t find in the source code. This can alleviate concerns that their language runtimes can make it hard to reason about low-level behavior. Thanks to Adrian Cochrane for pointing this out. ↩︎
For example: C, C++, Objective-C, Go, Fortran, and others can utilize sanitizers from Clang and/or GCC. ↩︎
This is probably what people in The Matrix were using to see that iconic digital rain. ↩︎
This command only lists syscall names, but I did eventually follow the example of sandbox-app-launcher by allowing certain syscalls (e.g. ioctl) only when invoked with certain parameters. Also, I used ripgrep because I’m more familiar with PCRE-style capture groups. ↩︎
Decrypting these packets typically involves saving and using key logs, or using endpoints with known pre-master secrets. ↩︎
I invite any modders who miss these debug symbols to check out the FLOSS Minetest, perhaps with the MineClone2 game. ↩︎
See page 127-130 of the Invisible Things Lab’s Quest to the Core slides. Bear in mind that they often refer to AMT running atop ME. ↩︎
As an aside: your security isn’t necessarily improved by “disabling” it, since it still runs during the initial boot sequence and does provide some hardening measures of its own (e.g., a TPM). ↩︎
In 2017, Calibre’s author actually wanted to stay with Python 2 after its EOL date, and maintain Python 2 himself. Users and package maintainers were quite unhappy with this, as Python 2 would no longer be receiving security fixes after 2020. While official releases of Calibre use a bundled Python interpreter, distro packages typically use the system Python package; Calibre’s popularity and insistence on using Python 2 made it a roadblock to getting rid of the Python 2 package in most distros. What eventually happened was that community members (especially Eli Schwartz and Flaviu Tamas) submitted patches to migrate Calibre away from Python 2. Calibre migrated to Python 3 by version 5.0. ↩︎
Linux distributions’ CFI+ASLR implementations rely executables compiled with CFI+PIE support, and ideally with stack-smashing protectors and no-execute bits. These implementations are flawed (see On the Effectiveness of Full-ASLR on 64-bit Linux and Brad Spengler’s presentation comparing these with PaX’s own implementation). ↩︎
The best attempt I know of leverages Trusted Execution Environments, but for limited functionality using an implementation that’s far from bulletproof. ↩︎

Misinfo about Permissions Policy and FLoC

seirdy@seirdy.one (Seirdy) — Sat, 17 Apr 2021 00:28:06 +0000

Update: I’ve amended this post with a valid reason to use the header. More info at the bottom.

This post was written in a hurry in response to some misinformation about Google’s newest Web antifeature, Federated Learning of Cohorts (FLoC). Google’s FLoC is an attempt to track users even when their browsers (rightly) block third-party cookies. The initial blog posts about this issue were quite benign, but online discussions quickly devolved into panic and support for building flawed work-arounds into upstream software. I had to write this before things got out of hand.

A lot of misleading online discussion stems from one not-very-misleading blog post¹ that’s been making rounds, instructing webmasters everywhere to add the following HTTP response headers to all their pages:

Permissions-Policy: interest-cohort=()

Strictly speaking, this advice is correct; including this header will prevent your page form using Google’s FLoC. What the advice misses is that the header isn’t always necessary and isn’t even the ideal way to prevent your page from doing nefarious things.

That advice comes from a post by Plausible Analytics; the author of that post concluded that FLoC is an “opt-out” antifeature by reading the “Opting Out of Computation” section of the WICG’s FLoC README.

If you check that README yourself, you’ll notice the following statement one (1) paragraph above the mention of the HTTP permission policy (emphasis mine):

A site should be able to declare that it does not want to be included in the user’s list of sites for cohort calculation. This can be accomplished via a new interest-cohort permissions policy. This policy will be default allow. Any frame that is not allowed interest-cohort permission will have a default value returned when they call document.interestCohort(). If the main frame does not have interest-cohort permission then the page visit will not be included in interest cohort calculation.

If your website does not include JS that calls document.interestCohort(), it will not leverage Google’s FLoC. Explicitly opting out will not change this.

As per a post on Google’s web development blog, web.dev, FLoC also will be enabled during an origin trial if the page “loads ads or ads-related resource”; i.e., anything that Chromium’s ad tagger classifies as an ad. If your website loads third-party ads, it might end up getting opted-in even if those ads don’t call document.interestCohort().

What explicitly opting out actually entails

What adding this header does is exclude your website from being used when calcualting a user’s cohort. A cohort is an identifier shared with a few thousand other users, calculated locally from browsing history; sites that send this header will be excluded from this calculation. The EFF estimates that a cohort ID can add up to 8 bits of of entropy to a user’s fingerprint.

Being excluded from cohort calculation has a chance to place a user in a different cohort, altering a user’s fingerprint. This new fingerprint may or may not have more entropy than the one derived without being excluded. Excluding some portion of sites from a user’s cohort calculation doesn’t necessarily make a user less unique if a nontrivial number of sites doesn’t opt out.

Given this marginal improvement, I don’t think it’s right to place a burden or blame on webmasters when the burden and blame should rightfully be directed at those responsible for rolling this antifeature out in Chromium. We shouldn’t expect webmasters to add a tag or header every time Google advances the war against its own users.

How Permissions Policy works

I don’t think that every webmaster should have to read every single W3C spec. I do, however, think that people who offer prescriptive advice and interpretations of a spec should be expected to read the relevant spec first.

Here’s a copy of the Permissions Policy spec. Essentially, the Permissions-Policy header allows a webmaster to whitelist which parties (if any) are allowed to leverage certain APIs. If I make a website that doesn’t perform any geolocation directly but I load a third-party widget that does, I can forbid all parties from using Geolocation APIs by setting the following Permissions-Policy:

Permissions-Policy: geolocation=()

In other words, it provides a global override for any page contents requesting too many permissions. It’s ideal for situations in which authors aren’t in control of what content is being loaded.

Using the Permissions Policy to opt out of cohort calculation isn’t really what the Permissions Policy was intended for. That doesn’t seem like a big deal until you consider the history of HTTP headers being used to protect privacy.

This has happened before

Google’s non-standard usage of the Permissions Policy header to opt a site out of cohort calculation is reminiscent of the Do Not Track (DNT) header.

Do Not Track was a non-standard client header used to request websites not to track users. This ended up getting ignored by almost all sites it was intended to target, as adtech companies had no incentive to comply. Several websites initially obeyed the header until eventually dropping support; Reddit is a notable recent example.

Given that non-standard header usage has failed in the client-side fight against surveillance capitalism before, I’m not too optimistic about trying this again from the server side.

Better advice: how not to opt-in

Here’s how not to opt-in to Google’s FLoC:

Don’t load untrusted third-party content that might get classified as an ad (only applies during the origin trial)
Don’t call document.interestCohort(), and don’t load third-party scripts that might call it either.

If you have to resort to adding a Permissions-Policy header to opt your site out of FLoC, it means that you’ve accidentally opted yourself in by including a tracking script (malware) on your page. I’d wager that opting into FLoC wasn’t the only nefarious thing those scripts do; chances are they bundle a host of other fingerprinting measures.

To be extra safe, you can whitelist exactly what scripts can run with a Content Security Policy (CSP); seirdy.one, for instance, has a CSP that blocks all scripts, forms, frames, and third-party resources from loading.

If you’re concerned about Google breaking the spec and opting you in even after you’ve not done so yourself, what reason do you have to believe that they’ll stop there? There’s nothing preventing Google from ignoring your Permissions-Policy header, either.

Take a breath

If you want to be extra safe, you’re free to add this header to your site. Just manage your expectations. However:

Please, don’t spam maintainers of web server/backend software to tell them to include this header by default when it may or may not actually reduce user fingerprints. Don’t tell webmasters that they have a moral obligation to add a Permissions Policy header either.² You don’t need to add this permission policy to every request, just as you don’t need to wear a helmet for every form of physical activity. Knee-jerk reactions like patching upstream software only galvanize Google to start ignoring this non-standard usage of the Permissions Policy header.

Update: a valid reason to add this header

Some IRC discussions and a Hacker News commenter have helped me understand a valid reason to add a Permissions-Policy header: making a statement. Opting your site out of FLoC might not significantly improve user privacy, but it does send a clear message that you’re against it.

I was initially skeptical of this justification for two reasons:

Google is unlikely to care if most of the non-adtech Web disabled FLoC, since they aren’t Google’s customers. If you work at Google, feel free to prove me wrong.
Most websites won’t include the header, so it’s unlikely to make a big difference.

However, I’ve changed my mind for one reason: if enough people implement this header, then anyone looking at HTTP headers will be reminded of the existence of FLoC. Making a statement like this will help spread awareness. I do maintain that effort is better spent getting users off Chromium and Chromium-dependent browsers, though.

Normally, I’d be against making a statement in response header fields; messages meant to be parsed by humans should be sent in the body instead. I’m making an exception because interest-cohort will likely become an official addition to the Permissions-Policy standard.

In short: FLoC is a terrible idea partly because “opting out” your site won’t significantly improve users’ privacy. Opt out of FLoC with the suggested header if you want to make a statement, not because you think you think you’re fulfilling your moral obligation to protect your visitors. If you want to fulfill that obligation, get them off of Chrome and Google.

This isn’t the only post making rounds, but it did hit the front page of a certain orange-colored website. I’m not blaming the author; if I hadn’t encountered the Permissions Policy spec earlier, I probably would have also taken the advice the author read at face-value. ↩︎
I’ve noticed both of these behaviors on several threads online. I’ve decided against linking to them because I think the discourse there has heated past the point of reason. ↩︎

A look at search engines with their own indexes

seirdy@seirdy.one (Seirdy) — Wed, 10 Mar 2021 20:51:06 +0000

Preface

This is a cursory review of all the indexing search engines I have been able to find.

The three dominant English search engines with their own indexes¹ are Google, Bing, and Yandex (GBY). Many alternatives to GBY exist, but almost none of them have their own results; instead, they just source their results from GBY.

With that in mind, I decided to test and catalog all the different indexing search engines I could find. I prioritized breadth over depth, and encourage readers to try the engines out themselves if they’d like more information.

This page is a “living document” that I plan on updating indefinitely. Check for updates once in a while if you find this page interesting. Feel free to send me suggestions, updates, and corrections; I’d especially appreciate help from those who speak languages besides English and can evaluate a non-English indexing search engine. Contact info is in the article footer.

I plan on updating the engines in the top two categories with more info comparing the structured/linked data the engines leverage (RDFa vocabularies, microdata, microformats, JSON-LD, etc.) to help authors determine which formats to use.

Toggle table of contents

About the list

I discuss my motivation for making this page in the Rationale section.

I primarily evaluated English-speaking search engines because that’s my primary language. With some difficulty, I could probably evaluate a Spanish one; however, I wasn’t able to find many Spanish-language engines powered by their own crawlers.

I mention details like “allows site submissions” and structured data support where I can only to inform authors about their options, not as points in engines’ favor.

See the Methodology section at the bottom to learn how I evaluated each one.

General indexing search-engines

Large indexes, good results

These are large engines that pass all my standard tests and more.

Google

The biggest index. Allows submitting pages and sitemaps for crawling, and even supports WebSub to automate the process. Powers a few other engines:

A former version of Startpage, possibly the most popular Google proxy. Startpage now uses Bing²
GMX Search, run by a popular German email provider.
(discontinued) Runnaroo
Mullvad Leta
SAPO (Portuguese interface, can work with English results)
DSearch
13TABS
Zarebin (Persian, can return English results)
Ecosia (choose between Google and Bing providers in settings)
A host of other engines using Programmable Search Engine’s client-side scripts.

Bing

The runner-up. Allows submitting pages and sitemaps for crawling without login using the IndexNow API, sharing IndexNow page submissions with Yandex and Seznam. Its index powers many other engines:

Yahoo (and its sibling engine, OneSearch)
DuckDuckGo³ (offers a Tor onion service, a JS-free version, and a TUI-browser-friendly “lite” version making it a good way to use Bing anonymously)
AOL
Qwant (partial)⁴
Ecosia (choose between Google and Bing providers in settings)
Ekoru
Privado
Findx
Disconnect Search⁵
PrivacyWall
Lilo
SearchScene
Peekier (not to be confused with Peekr, a metasearch engine with its own index)
Oscobo
Million Short
Yippy search⁶
Lycos
Givero
Swisscows
Fireball
Netzzappen
You.com⁷
Vuhuv
Partially powers MetaGer by default; this can be turned off
ChatGPT Search⁸
At this point, I mostly stopped adding Bing-based search engines. There are just too many.

Yandex

Originally a Russian search engine, it now has an English version. Some Russian results bleed into its English site. It allows submitting pages and sitemaps for crawling using the IndexNow API, sharing IndexNow page submissions with Bing and Seznam. Powers:

Epic Search (went paid-only as of June 2021)
Occasionally powers DuckDuckGo’s link results instead of Bing (update: DuckDuckGo has “paused” its partnership with Yandex, confirmed in Hearing on “Holding Big Tech Accountable: Legislation to Protect Online Users”
Petal, for Russian users only.

Mojeek

Seems privacy-oriented with a large index containing billions of pages. Quality isn’t at GBY’s level, but it’s not bad either. If I had to use Mojeek as my default general search engine, I’d live. Partially powers eTools.ch. At this moment, I think that Mojeek is the best alternative to GBY for general search.

Google, Bing, and Yandex support structured data such as microformats1, microdata, RDFa, Open Graph markup, and JSON-LD. Yandex’s support for microformats1 is limited; for instance, it can parse h-card metadata for organizations but not people. Open Graph and Schema.org are the only supported vocabularies I’m aware of. Mojeek is evaluating structured data; it’s interested in Open Graph and Schema.org vocabularies.

Smaller indexes or less relevant results

These engines pass most of the tests listed in the “methodology” section. All of them seem relatively privacy-friendly. I wouldn’t recommend using these engines to find specific answers; they’re better for learning about a topic by finding interesting pages related to a set of keywords.

Stract: My favorite generalist engine on this page. Stract supports advanced ranking customization by allowing users to import “optics” files, like a better version of Brave’s “goggles” feature. Stract is fully open-source, with code released under an AGPL-3.0 license. The index is isn’t massive but it’s big enough to be a useful supplement to more major engines. Stract started with the Common Crawl index, but now uses its own crawler. Plans to add contextual ads and a subscription option for ad-free search. Discovered in my access logs.
Right Dao: Very fast, good results. Passes the tests fairly well. It plans on including query-based ads if/when its user base grows.⁹ For the past few months, its index seems to have focused more on large, established sites rather than smaller, independent ones. It seems to be a bit lacking in more recent pages.
Alexandria: A pretty new “non-profit, ad free” engine, with freely-licensed code. Surprisingly good at finding recent pages. Its index is built from the Common Crawl; it isn’t as big as Gigablast or Right Dao but its ranking is great.
Yep: An ambitious engine from Ahrefs, an SEO/backlink-finder company, that “shares ad profit with creators and protects your privacy”. Most engines show results that include keywords from or related to the query; Yep also shows results linked by pages containing the query. In other words, not all results contain relevant keywords. This makes it excellent for less precise searches and discovery of “related sites”, especially with its index of hundreds of billions of pages. It’s far worse at finding very specific information or recent events for now, but it will probably improve. It was known as “FairSearch” before its official launch.
SeSe Engine: Although it’s a Chinese engine, its index seems to have a large-enough proportion of English content to fit here. The engine is open-source; see the SeSe back-end Python code and the SeSe-ui Vue-based front-end. It has surprisingly good results for such a low-budget project. Each result is annotated with detailed ranking metadata such as keyword relevance and backlink weight. Discovered in my access logs.
greppr: Its tagline is “Search the Internet with no filters, no tracking, no ads.” At the time of writing, it has over 3 million pages indexed. It’s surprisingly good at finding interesting new results for broad short-tail queries, if you’re willing to scroll far enough down the page. It appears to be good at finding recent pages.

Yep supports Open Graph and some JSON-LD at the moment. A look through the source code for Alexandria and Gigablast didn’t seem to reveal the use of any structured data. The surprising quality of results from SeSe and Right Dao seems influenced by the crawlers’ high-quality starting location: Wikipedia.

Smaller indexes, hit-and-miss

These engines fail badly at a few important tests. Otherwise, they seem to work well enough for users who’d like some more serendipity in less-specific searches.

Peekr (formerly SvMetaSearch, not to be confused with Peekier): Originally a SearxNG metasearch engine that also included results from its own index, it’s since diverged. It now appears to return all results from its own growing ElasticSearch index. Open source, with an emphasis on self-hostability.
seekport: The interface is in German but it supports searching in English just fine. The default language is selected by your locale. It’s really good considering its small index; it hasn’t heard of less common terms, but it’s able to find relevant results in other tests. It’s the second-fastest-improving engines in this section.
Exalead: Slow, quality is hit-and-miss. Its indexer claims to crawl the DMOZ directory, which has since shut down and been replaced by the Curlie directory. No relevant results for “Oppenheimer” and some other history-related queries. Allows submitting individual URLs for indexing, but requires solving a Google reCAPTCHA and entering an email address.
ExactSeek: Small index, disproportionately dominated by big sites. Failed multiple tests. Allows submitting individual URLs for crawling, but requires entering an email address and receiving a newsletter. Webmaster tools seem to heavily push for paid SEO options. It also powers SitesOnDisplay and Blog-search.com.
Burf.co: Very small index, but seems fine at ranking more relevant results higher. Allows site submission without any extra steps.
ChatNoir: An experimental engine by researchers that uses the Common Crawl index. The engine is open source. See the announcement on the Common Crawl mailing list (Google Groups).
Secret Search Engine Labs: Very small index with very little SEO spam; it toes the line between a “search engine” and a “surf engine”. It’s best for reading about broad topics that would otherwise be dominated by SEO spam, thanks to its CashRank algorithm. Allows site submission.
Gabanza: A search engine from a hosting company. I found few details abou the search engine itself, and the index was small, but it was suitable for discovering new pages related to short broad queries.
Jambo: Docs, blog posts, etc. have not been updated since around 2006 but the engine continues to crawl and index new pages. Discovered in my access logs. Has a bias towards older content.
search.dxhub.de: While Gigablast seems dead, a version of it was open-source. This is based on that version of Gigablast. Its index is small but results are still useful for surfing new unseen corners of short-tail queries. Found via my access logs.
Fynd: Does not appear to support full-page search, but does search page titles and description meta-tags. Supports URL submission. Found in my access logs. Currently in a prototype/experimental stage.

Fledgling engines

Results from these search engines don’t seem particularly relevant; indexes in this category tend to be small.

Yessle: Seems new; allows page submission by pasting a page into the search box. Index is really small but it crawls new sites quickly. Claims to be private.
Bloopish: Extremely quick to update its index; site submissions show up in seconds. Unfortunately, its index only contains a few thousand documents (under 100 thousand at the time of writing). It’s growing fast: if you search for a term, it’ll start crawling related pages and grow its index.
YaCy: Community-made index; slow. Results are awful/irrelevant, but can be useful for intranet or custom search.
Scopia: Only seems to be available via the MetaGer metasearch engine after turning off Bing and news results. Tiny index, very low-quality. As of 2024-09-10, MetaGer is paid-only after losing its advertising contract with Yahoo.
Artado Search: Primarily Turkish, but it also seems to support English results. Like Plumb, it uses client-side JS to fetch results from existing engines (Google, Bing, Yahoo, Petal, and others); like MetaGer, it has an option to use its own independent index. Results from its index are almost always empty. Very simple queries (“twitter”, “wikipedia”, “reddit”) give some answers. Supports site submission and crowdsourced instant answers.
Active Search Results: Very poor quality. Results seem highly biased towards commercial sites.
Crawlson: Young, slow. In this category because its index has a cap of 10 URLs per domain. I initially discovered Crawlson in the seirdy.one access logs. This is often down; if the current downtime persists, I’ll add it to the graveyard.
Anoox: Results are few and irrelevant; fails to find any results for basic terms. Allows site submission. It’s also a lightweight social network and claims to be powered by its users, letting members vote on listings to alter rankings.
Yioop!: A FLOSS search engine that boasts a very impressive feature-set: it can parse sitemaps, feeds, and a variety of markup formats; it can import pre-curated data in forms such as access logs, Usenet posts, and WARC archives; it also supports feed-based news search. Despite the impressive feature set, Yioop’s results are few and irrelevant due to its small index. It allows submitting sites for crawling. Like Meorca, Yioop has social features such as blogs, wikis, and a chat bot API.
Spyda: A small engine made by James Mills, described in So I’m a Knucklehead eh?. It’s written in Go; check out its MIT-licensed Spyda source code.
Slzii.com: A new web portal with a search engine. Has a tiny index dominated by SEO spam. Discovered in the seirdy.one access logs.
Weblog DataBase: A metadata search engine for technical blogs. Very small index and ranking seems poor, but it seems to have different goals from most search engines: it encourages filtering search results iteratively until finding the desired subset of results. The index updates weekly and not all features are implemented yet.

Semi-independent indexes

Engines in this category fall back to GBY when their own indexes don’t have enough results. As their own indexes grow, some claim that this should happen less often.

Brave Search

Many tests (including all the tests I listed in the “Methodology” section) resulted results identical to Google, revealed by a side-by-side comparison with Google, Startpage, and a Searx instance with only Google enabled. Brave claims that this is due to how Cliqz (the discontinued engine acquired by Brave) used query logs to build its page models and was optimized to match Google.¹⁰ The index is independent, but optimizing against Google resulted in too much similarity for the real benefit of an independent index to show. Furthermore, many queries have Bing results mixed in; users can click an “info” button to see the percentage of results that came from its own index. The independent percentage is typically quite high (often close to 100% independent) but can drop for advanced queries. Update 2023-08-15: Brave’s Bing contract appears to have expired as of April 2023.

I can’t in good conscience recommend using Brave Search, as the company runs cryptocurrency, has held payments to creators without disclosing that creators couldn’t receive rewards, has made dangerously misleading claims about fingerprinting resistance,¹¹ is run by a CEO who spent thousands of dollars opposing gay marriage, and has rewritten typed URLs with affiliate links.

Brave Search offers a Tor onion service and doesn’t require JS. Powers:

Ghostery Private Search (identical results in my tests).¹²
Partially powers Kagi (documented in 2023, unclear after docs removed main sources after 2024-05-01).
Powers GOOD Search (archived homepage).

Plumb

Almost all queries return no results; when this happens, it falls back to Google. It’s fairly transparent about the fallback process, but I’m concerned about how it does this: it loads Google’s Custom Search scripts from cse.google.com onto the page to do a client-side Google search. This can be mitigated by using a browser addon to block cse.google.com from loading any scripts. Plumb claims that this is a temporary measure while its index grows, and they’re planning on getting rid of this. Allows submitting URLs, but requires solving an hCaptcha. This engine is very new; hopefully as it improves, it could graduate from this section. Its Chief Product Officer previously founded the Gibiru search engine which shares the same affiliates and (for now) the same index; the indexes will diverge with time.

Qwant

Qwant claims to use its own index, but it still relies on Bing for most results. It seems to be in a position similar to Neeva. Try a side-by-side comparison to see if or how it compares with Bing.

Kagi Search

The most interesting entry in this category, IMO. Like Neeva, it requires an account and limits use without payment. It’s powered by its own Teclis index (Teclis can be used independently; see the non-commercial section below), and claims to also use results from Google and Bing. The result seems somewhat unique: I’m able to recognize some results from the Teclis index mixed in with the mainstream ones. In addition to Teclis, Kagi’s other products include the Kagi.ai intelligent answer service and the TinyGem social bookmarking service, both of which play a role in Kagi.com in the present or future. Unrelatedly: I’m concerned about the company’s biases, as it seems happy to use Brave’s commercial API (allowing blatant homophobia in the comments) and allow its results to recommend suicide methods without intervention. I reject the idea that avoiding an option that may seem politically biased is the same as being unbiased if such a decision has real political implications.

PriEco

A metasearch engine with one option for using its own index. Found in my access logs. All other sources can be turned off, allowing you to see its unique results. At the time of writing, its own index is unfortunately quite tiny.

Non-generalist search

These indexing search engines don’t have a Google-like “ask me anything” endgame; they’re trying to do something different. You aren’t supposed to use these engines the same way you use GBY.

Small or non-commercial Web

Marginalia Search: My favorite entry on this page. It has its own crawler but is strongly biased towards non-commercial, personal, and/or minimal sites. It’s a great response to the increasingly SEO-spam-filled SERPs of GBY. Partially powers Teclis, which in turn partially powers Kagi. Update 2022-05-28: Marginalia.nu is now open source.
Ichido: An engine that just rolled out its own independent index, with a lot of careful thought put into its ranking algorithm. Like Marginalia, it’s biased towards the non-commercial Web: it downranks ads, CAPTCHAs, trackers, SEO, and obfuscation. More info about Ichido is in a blog post.
Teclis: A project by the creator of Kagi search. Uses its own crawler that measures content blocked by uBlock Origin, and extracts content with the open-source article scrapers Trafilatura and Readability.js. This is quite an interesting approach: tracking blocked elements discourages tracking and advertising; using Trafilatura and Readability.js encourages the use of semantic HTML and Semantic Web standards such as microformats, microdata, and RDFa. It claims to also use some results from Marginalia. The Web interface has been shut down, but its standalone API is still available for Kagi customers.
Clew: a FOSS new engine with a small index of several thousand pages. It focuses on independent content and downranks ads and trackers; there seems to be a real focus on quality over quantity, which makes it excellent for short-tail searches (especially around technical concepts). Ranking is more egalitarian than other engines, making it better for discovery and surfing than research. It’s designed to be small and lightweight, with a compact index. Discovered in the seirdy.one access logs.
Lixia Labs Search: A new engine that focuses on indexing technical websites and blogs, with a minimal JavaScript-free front-end. Discovered in my access logs. Surprisingly good results for broad technical keyword queries.

Site finders

These engines try to find a website, typically at the domain-name level. They don’t focus on capturing particular pages within websites.

Kozmonavt: The best in this category. Has a small but growing index of over 8 million sites. If I want to find the website for a certain project, Kozmonavt works well (provided its index has crawled said website). It works poorly for learning things and finding general information. I cannot recommend it for anything serious since it lacks contact information, a privacy policy, or any other information about the org/people who made it. Discovered in the seirdy.one access logs.
search.tl: Generalist search for one TLD at a time (defaults to .com). I’m not sure why you’d want to always limit your searches to a single TLD, but now you can.¹³ There isn’t any visible UI for changing the TLD for available results; you need to add/change the tld URL parameter. For example, to search .org sites, append &tld=org to the URL. It seems to be connected to Amidalla. Amidalla allows users to manually add URLs to its index and directory; I have yet to see if doing so impacts search.tl results.
Thunderstone: A combined website catalog and search engine that focuses on categorization. Its about page claims: We continuously survey all primary COM, NET, and ORG web-servers and distill their contents to produce this database. This is an index of sites not pages. It is very good at finding companies and organizations by purpose, product, subject matter, or location. If you’re trying to finding things like ‘BillyBob’s personal beer can page on AOL’, try Yahoo or Dogpile. This seems to be the polar opposite of the engines in the “small or non-commercial Web” category.
sengine.info: Only shows domains, not individual pages. Developed by netEstate GmbH, which specializes in content extraction for inprints and job ads. Also has a German-only version available. Discovered in my access logs.
Gnomit: Allows single-keyword queries and returns sites that seem to cover a related topic. I actually kind of enjoy using it; results are old (typically from 2009) and a bit random, but make for a nice way to discover something new. For instance, searching for “IRC” helped me discover new IRC networks I’d never heard of.

Other

High Browse: Uses a non-traditional ranking algorithm which does an excellent job of introducing non-SEO-optimized serendipity into search results. One of my favorite “surf-engines”, as opposed to traditional “search-engines”.
Keybot: A must-have for anyone who does translation work. It crawls the web looking for multilingual websites. Translators who are unsure about how to translate a given word or phrase can see its usage in two given languages, to learn from other human translators. My parents are fluent English speakers but sometimes struggle to express a given Hindi idiom in English; something like this could be useful to them, since machine translation isn’t nuanced enough for every situation. Part of the TTN Translation Network. Discovered in my access logs.
Quor: Seems to mainly index large news sites. Site is down as of June 2021; originally available at www dot quor dot com.
Semantic Scholar: A search engine by the Allen Institute for AI focused on academic PDFs, with a couple hundred million papers indexed. Discovered in my access logs.
Bonzamate: A search engine specifically for Australian websites. Boyter wrote an interesting blog post about Bonzamate.
searchcode: A code-search engine by the developer of Bonzamate. Searches a hand-picked list of code forges for source code, supporting many search operators.
StarFinder: A search engine that focuses on Open Graph Protocol metadata, searching for domains that have OGP information and rendering link previews for them. A good surf-engine once you grok how to build sufficiently broad queries. Has a large and growing index of 4.8 million sites at the time of writing. Allows site submission.

Other languages

I’m unable to evaluate these engines properly since I don’t speak the necessary languages. English searches on these are a hit-or-miss. I might have made a few mistakes in this category.

Big indexes

Baidu: Chinese. Very large index; it’s a major engine alongside GBY. Offers webmaster tools for site submission.
Qihoo 360: Chinese. I’m not sure how independent this one is.
Toutiao: Chinese. Not sure how independent this one is either. Its index appears limited outside of its own content distribution platform.
Sogou: Chinese
Yisou: Chinese, by Yahoo. Appears defunct.
Naver: Korean. Allows submitting sitemaps and feeds. Discovered via some Searx metasearch instances.
Daum: Korean. Also unsure about this one’s independence.
Seznam: Czech, seems relatively privacy-friendly. Discovered in the seirdy.one access logs. It allows site submission with webmaster tools. Seznam supports IndexNow; it shares IndexNow-submitted pages with Bing and Yandex.
Cốc Cốc: Vietnamese
go.mail.ru: Russian
LetSearch.ru: Russian. Allows URL submission

Smaller indexes

ALibw.com: Chinese, found in my access logs.
Vuhuv: Turkish. alt domain
search.ch: Regional search engine for Switzerland; users can restrict searches to their local regions.
fastbot: German
SOLOFIELD: Japanese
kaz.kz: Kazakh and Russian, with a focus on “Kazakhstan’s segment of the Internet”

Almost qualified

These engines come close enough to passing my inclusion criteria that I felt I had to mention them. They all display original organic results that you can’t find on other engines, and maintain their own indexes. Unfortunately, they don’t quite pass because they don’t crawl the Web; most limit themselves to a specific set of sites.

wiby.me OR wiby.org: I love this one. It focuses on smaller independent sites that capture the spirit of the “early” web. It’s more focused on “discovering” new interesting pages that match a set of keywords than finding a specific resources. I like to think of Wiby as an engine for surfing, not searching. Runnaroo occasionally featured a hit from Wiby (Runnaroo has since shut down). If you have a small site or blog that isn’t very “commercial”, consider submitting it to the index. Does not qualify because it seems to be powered only by user-submitted sites; it doesn’t try to “crawl the Web”.
Mwmbl: Like YaCy, it’s an open-source engine whose crawling is community-driven. Users can install a Firefox addon to crawl pages in its backlog. Unfortunately, it doesn’t qualify because it only crawls pages linked by hand-picked sites (e.g. Wikipedia, GitHub, domains that rank well on Hacker News). The crawl-depth is “1”, so it doesn’t crawl the whole Web (yet).
Search My Site: Similar to Marginalia and Teclis, but only indexes user-submitted personal and independent sites. It optionally supports IndieAuth. Its API powers this site’s search results; try it out using the search bar at the bottom of this page. Does not qualify because it’s limited to user-submitted and/or hand-picked sites.
Kukei.eu: A curated search engine for web developers, which crawls a hand-picked list of sites. As it does not index the whole Web, it doesn’t qualify. I still find it interesting.
Unobtanium Search: A fledgling search engine by Slatian. At the time of writing, it crawls hand-curated sites: personal, technical, indie wiki, and German hacker community sites. It may eventually crawl government/public-service sites. More documentation will be on its website.

Misc

Ask.com: The site is back. They claim to outsource search results. The results seem similar to Google, Bing, and Yandex; however, I can’t pinpoint exactly where their results are coming from. Also, several sites from the “ask.com network” such as directhit.com, info.com, and kensaq.com have uniqe-looking results.
Infinity Search: Partially evaluated. Young, small index. It recently split into a paid offering with the main index and Infinity Decentralized, the latter of which allows users to select from community-hosted crawlers. I managed to try it out before it became a paid offering, and it seemed decent; however, I wasn’t able to run the tests listed in the “Methodology” section. Allows submitting URLs and sitemaps into a text box, no other work required.

Search engines without a web interface

Some search engines are integrated into other appliances, but don’t have a web portal.

Apple’s search engine is usable in the form of “Siri Suggested Websites”. Its index is built from the Applebot web crawler. If Apple already has working search engine, it’s not much of a stretch to say that they’ll make a web interface for it someday.
Amazon bought Alexa Internet (a web traffic analysis company, at the time unrelated to the Amazon Alexa virtual assistant) and discontinued its website ranking product. Amazon still runs the relevant crawlers, and also have a bot called “Amazonbot”. While Applebot powers the Siri personal assistant, Amazonbot powers the Alexa personal assistant to answer even more questions for customers. Crawling the web to answer questions is the basis of a search engine.

Graveyard

These engines were originally included in the article, but have since been discontinued.

Petal Search: A search engine by Huawei that recently switched from searching for Android apps to general search in order to reduce dependence on Western search providers. Despite its surprisingly good results, I wouldn’t recommend it due to privacy concerns: its privacy policy describes advanced fingerprinting metrics, and it doesn’t work without JavaScript. Requires an account to submit sites. I discovered this via my access logs. Be aware that in some jurisdictions, it doesn’t use its own index: in Russia and some EU regions it uses Yandex and Qwant, respectively. Inaccessible as of June 2023.
Neeva: Formerly in the “semi-independent” section. Combined Bing results with results from its own index. Bing normally isn’t okay with this, but Neeva was one of few exceptions. Results were mostly identical to Bing, but original links not found by Bing frequently popped up. Long-tail and esoteric queries were less likely to feature original results. Required signing up with an email address or OAuth to use, and offered a paid tier with additional benefits. Acquired by Snowflake and announced its shut-down in May 2023.
Gigablast: It’s been around for a while and also sports a classic web directory. Searches are a bit slow, and it charges to submit sites for crawling. It powers Private.sh. Gigablast was tied with Right Dao for quality. Shut down mid-2023.
wbsrch: In addition to its generalist search, it also had many other utilities related to domain name statistics. Failed multiple tests. Its index was a bit dated; it had an old backlog of sites it hadn’t finished indexing. It also had several dedicated per-language indexes.
Gowiki: Very young, small index, but showed promise. I discovered this in the seirdy.one access logs. It was only available in the US. Seems down as of early 2022.
Meorca: A UK-based search engine that claims not to “index pornography or illegal content websites”. It also features an optional social network (“blog”). Discovered in the seirdy.one access logs.
Ninfex: A “people-powered” search engine that combines aspects of link aggregators and search. It lets users vote on submissions and it also displays links to forums about submissions.
Marlo: Another FLOSS engine: Marlo is written in Haskell. Has a small index that’s good enough for surfing broad topics, but not good enough for specific research. Originally available at marlo.sandymaguire.me.
websearchengine.org OR tuxdex.com: Both were run by the same people, powered by their inetdex.com index. Searches are fast, but crawls are a bit shallow. Claims to have an index of 10 million domains, and not to use cookies. The pages are currently down and the domains re-direct to porn sites; I’m not aware of any official notice.
Entfer: a newcomer that let registered users upvote/downvote search results to customize ranking. Didn’t offer much information about who made it. Its index was small, but it did seem to return results related to the query.
Siik: Lacked contact info, and the ToS and Privacy Policy links were dead. Seemed to have PHP errors in the backend for some of its instant-answer widgets. If you scrolled past all that, you’d find web results powered by what seems to be its own index. These results did tend to be somewhat relevant, but the index seemed too small for more specific queries.
Blog Surf: A search engine for blogs with RSS/Atom feeds. Originally in “almost qualified”. It did not qualify because all blogs submitted to the index require manual review, but it seemed interesting. Its “MarketRank” algorithm gave it a bias towards sites popular on “Hacker” “News”.
Infotiger: Was one of my favorites. It offered advanced result filtering and sports a somewhat large index. It allowed site submission for English and German pages. Infotiger also had a Tor hidden service.

Dead engines I don’t have an extended description for:

Parsijoo: Persian search engine.
Moose.at: German (Austria-based). The site is still up but redirects searches to Brave.

Upcoming engines

Exclusions

Three engines were excluded from this list for having a far-right focus.

One engine was excluded because it seems to be built using cryptocurrency in a way I’d rather not support.

Some fascinating little engines seem like hobbyist proofs-of-concept. I decided not to include them in this list, but watch them with interest to see if they can become something viable.

Rationale

Why bother using non-mainstream search engines?

Conflicts of interest

Google, Microsoft (the company behind Bing), and Yandex aren’t just search engine companies; they’re content and ad companies as well. For example, Google hosts video content on YouTube and Microsoft hosts social media content on LinkedIn. This gives these companies a powerful incentive to prioritize their own content. They are able to do so even if they claim that they treat their own content the same as any other: since they have complete access to their search engines’ inner workings, they can tailor their content pages to better fit their algorithms and tailor their algorithms to work well on their own content. They can also index their own content without limitations but throttle indexing for other crawlers.¹⁴

One way to avoid this conflict of interest is to use search engines that aren’t linked to major content providers; i.e., use engines with their own independent indexes.

Information diversity

There’s also a practical, less-ideological reason to try other engines: different providers have different results. Websites that are hard to find on one search engine might be easy to find on another, so using more indexes and ranking algorithms results in access to more content.

No search engine is truly unbiased. Most engines’ ranking algorithms incorporate a method similar to PageRank, which biases them towards sites with many backlinks. Search engines have to deal with unwanted results occupying the confusing overlap between SEO spam, shock content, and duplicate content. When this content’s manipulation of ranking algos causes it to rank high, engines have to address it through manual action or algorithm refinement. Choosing to address it through either option, or choosing to leave it there for popular queries after receiving user reports, reflects bias. The best solution is to mix different ranking algorithms and indexes instead of using one engine for everything.

Methodology

Discovery

I find new engines by:

Monitoring certain web directories for changes in their search engine listings.
Checking other curated lists of “good/bad bots” to spot search engines.
Using search engines to discover search engines: searching for the names of less-popular engines often pulls up similar lists.
Receiving suggestions from readers
Compiling a list of regular expressions for user-agent strings I’m familiar with. Before I delete my server access logs, I extract user-agents that don’t match that list along with the pages they request.
Checking the Searx and Searxng projects for new integrations.

Criteria for inclusion

Engines in this list should have their own indexes powered by web crawlers. Original results should not be limited to a set of websites hand-picked by the engine creators; indexes should be built from sites from across the Web. An engine should discover new interesting places around the Web.

Here’s an oversimplified example to illustrate what I’m looking for: imagine somone self-hosts their own personal or interest-specific website and happens to get some recognition. Could they get automatically discovered by your crawler, indexed, and included in the first page of results for a certain query?

I’m willing to make two exceptions:

Engines in the “semi-independent” section may mix results that do meet the aforementioned criteria with results that do not.
Engines in the “almost qualified” section may use indexes primarily made of user-submitted or hand-picked sites, rather than focusing primarily on sites discovered organically through crawling.

The reason the second exception exists is that while user submissions don’t represent automatic crawling, they do at least inform the engine of new interesting websites that it had not previously discovered; these websites can then be shown to other users. That’s fundamentally what an alternative web index needs to achieve.

I’m not usually willing to budge on my “no hand-picked websites” rule. Hand-picked sites will be ignored, whether your engine fetches content through their APIs or crawls and scrapes their content. It’s fine to use hand-picked websites as starting points for your crawler (Wikipedia is a popular option).

I only consider search engines that focus on link results for webpages. Image search engines are out of scope, though I might consider some other engines for non-generalist search (e.g., Semantic Scholar finds PDFs rather than webpages).

Evaluation

I focused almost entirely on “organic results” (the classic link results), and didn’t focus too much on (often glaring) privacy issues, “enhanced” or “instant” results (e.g. Wikipedia sidebars, related searches, Stack Exchange answers), or other elements.

I compared results for esoteric queries side-by-side; if the first 20 results were (nearly) identical to another engine’s results (though perhaps in a slightly different order), they were likely sourced externally and not from an independent index.

I tried to pick queries that should have a good number of results and show variance between search engines. An incomplete selection of queries I tested:

“vim”, “emacs”, “neovim”, and “nvimrc”: Search engines with relevant results for “nvimrc” typically have a big index. Finding relevant results for the text editors “vim” and “emacs” instead of other topics that share the name is a challenging task.
“vim cleaner”: should return results related to a line of cleaning products rather than the Correct Text Editor.
“Seirdy”: My site is relatively low-traffic, but my nickname is pretty unique and visible on several of the highest-traffic sites out there.
“Project London”: a small movie made with volunteers and FLOSS without much advertising. If links related to small independent projects like this show up, the index has really good coverage of movies.
“oppenheimer” versus “J Robert Oppenheimer”: a name that could refer to many things. Without context, it could refer to a high-budget movie or the physicist who led the Manhattan Project in Los Alamos. Other historical queries: “magna carta” (intermediate), “the prince” (very hard).

(Update: I don’t use these queries anymore; I’ve found better tests in recent months).

Some less-mainstream engines have noticed this article, which is great! I’ve had excellent discussions with people who work on several of these engines. Unfortunately, this article’s visibility also incentivizes some engines to optimize specifically for any methodology I describe. I’ve addressed this by keeping a long list of test queries to myself. The simple queries above are a decent starting point for simple quick evaluations, but I also test for common search operators, keyword length, and types of domain-specific jargon. I also use queries designed to pull up specific pages with varying levels of popularity and recency to gauge the size, scope, and growth of an index.

Professional critics often work anonymously because personalization can damage the integrity of their reviews. For similar reasons, I attempt to try each engine anonymously at least once by using a VPN and/or my standard anonymous setup: an amnesiac Whonix VM with the Tor Browser. I also often test using a fresh profile when travelling, or via a Searx instance if it supports a given engine. When avoiding personalization, I use “varied” queries that I don’t repeat verbatim across search engines; this reduces the likelihood of identifying me. I also attempt to spread these tests out over time so admins won’t notice an unusual uptick in unpredictable and esoteric searches. This might seem overkill, but I already regularly employ similar methods for a variety of different scenarios.

Unique results without unique indexes

Some engines, like Kagi and the Ask.com family of engines, have unique-looking results from external indexes. Unique results alone don’t always imply independence, as an engine could alter ranking or add filters (something that very few engines are permitted to do; Google and Microsoft generally impose a strict ToS forbidding modification).

Another possible indicator I look for is word substitutions. Nearly every engine supports substitutions for verb tense or singular/plural word forms, but more advanced semantic substitutions are less common. Returning the same results for “matza gebrent” and “matzo brei” requires a deep understanding of related food topics. Google and Bing return nearly identical results for the two queries, but engines like Mojeek return entirely different results. I often compare an engine’s word substitutions to see if they’re similar to another engine’s, and see how many results from the top 20 are not present in the top 30-40 on other engines. I have a working list of other word substitutions I test.

Caveats

I didn’t try to avoid personalization when testing engines that require account creation. Entries in the “hit-and-miss” and “unusable” sections got less attention: I didn’t spend a lot of effort tracking results over time to see how new entries got added to them.

I avoided “natural language” queries like questions, focusing instead on keyword searches and search operators. I also mostly ignored infoboxes (also known as “instant answers”).

Findings

What I learned by building this list has profoundly changed how I surf.

Using one engine for everything ignores the fact that different engines have different strengths. For example: while Google is focused on being an “answer engine”, other engines are better than Google at discovering new websites related to a broad topic. Fortunately, browsers like Chromium and Firefox make it easy to add many search engine shortcuts for easy switching.

When talking to search engine founders, I found that the biggest obstacle to growing an index is getting blocked by sites. Cloudflare was one of the worst offenders, although it has since launched a “verified bots” program to improve things. Too many sites block perfectly well-behaved crawlers, only allowing major players like Googlebot, BingBot, and TwitterBot; this cements the current duopoly over English search and is harmful to the health of the Web as a whole.

Too many people optimize sites specifically for Google without considering the long-term consequences of their actions. One of many examples is how Google’s JavaScript support rendered the practice of testing a website without JavaScript or images “obsolete”: almost no non-GBY engines on this list are JavaScript-aware.

When building webpages, authors need to consider the barriers to entry for a new search engine. The best engines we can build today shouldn’t replace Google. They should try to be different. We want to see the Web that Google won’t show us, and search engine diversity is an important step in that direction.

Try a “bad” engine from lower in the list. It might show you utter crap. But every garbage heap has an undiscovered treasure. I’m sure that some hidden gems you’ll find will be worth your while. Let’s add some serendipity to the SEO-filled Web.

Acknowledgements

Some of this content came from the Search Engine Map and Search Engine Party. A few web directories also proved useful.

Matt Wells from Gigablast also gave me some helpful information about GBY which I included in the “Rationale” section. He’s written more about big tech in the Gigablast blog.

A 2021 List of Alternative Search Engines and Search Resources by Nicholas Ferrell from The New Leaf Journal is a great post on alternative search engines. He also gave me some useful details about Seznam, Naver, Baidu, and Goo.

Yes, “indexes” is an acceptable plural form of the word “index”. The word “indices” sounds weird to me outside a math class. ↩︎
Update: A Startpage support article updated on 2023-03-08 claims that Startpage uses Microsoft (probably Bing) too. In my own tests, I still see Google results. I’ll update its placement if this changes. ↩︎
DuckDuckGo has a crawler called DuckDuckBot. This crawler doesn’t impact the linked results displayed; it just grabs favicons and scrapes data for a few instant answers. DuckDuckGo’s help pages claim that the engine uses over 400 sources; my interpretation is that at least 398 sources don’t impact organic results. I don’t think DuckDuckGo is transparent enough about the fact that their organic results are proxied. Compare DuckDuckGo side-by-side with Bing and Yandex and you’ll see it’s sourcing organic results from one of them (probably Bing). Update, March 2022: DuckDuckGo has the ability to downrank results on its own; it was previously working with Bing to get Bing to remove misinformation and spam. ↩︎
Qwant claims to also use its own crawler for results, but it’s still mostly Bing in my experience. See the “semi-independent” section. ↩︎ ↩︎
Disconnect Search allows users to have results proxied from Bing or Yahoo, but Yahoo sources its results from Bing. ↩︎
Yippy claims to be powered by a certain IBM brand (a brand that could correspond to any number of products) and annotates results with the phrase “Yippy Index”, but a side-by-side comparison with Bing and other Bing-based engines revealed results to be nearly identical. ↩︎
I’m in the process of re-evaluating You.com. It claims to operate a crawler and index. It seems very much like DuckDuckGo⁴ to me: organic results look like they’re from Bing, while infoboxes (“apps”) seem to be scraped or queried from hand-picked websites. I’m not currently seeing results from “around the web” like the other engines that do pass my inclusion criteria. I might be wrong! I’m re-evaluating it to see if this isn’t actually the case.

Update: You.com seems to source organic link results from Bing, and only interleaves those results with its own curated infoboxes

Update: during a recent Bing outage, I found some organic link results on You.com that didn’t look like they came from Bing. More research is needed again. ↩︎
See the ChatGPT Search help article: ChatGPT searches based on your prompts and may share disassociated search queries with third-party search providers such as Bing. ↩︎
This is based on a statement Right Dao made in on Reddit (archived). ↩︎
More information can be found in this HN subthread and some posts on the Cliqz tech blog (one, two). ↩︎
I will explain my thinking in another post later, and then edit this with a link to that post. ↩︎
Ghostery’s documentation at the time of writing is extremely misleading, using clever language that seems to heavily imply the use of an independent index and crawler while not saying so outright: Ghostery says it gets you objective results from a unique search index and that it will crawl it’s [sic] search index. Privacy claims require trust, and word games do little to build it. ↩︎
Some search engines support the site: search operator to limit searches to subpages or subdomains of a single site or TLD. site:.one, for instance, limits searches to websites with the “.one” TLD. ↩︎
Matt from Gigablast told me that indexing YouTube or LinkedIn will get you blocked if you aren’t Google or Microsoft. I imagine that you could do so by getting special permission if you’re a megacorporation. ↩︎

Keeping platforms open

seirdy@seirdy.one (Seirdy) — Tue, 23 Feb 2021 19:54:00 +0000

This article is the second entry of series of posts exploring situations in which FLOSS alone isn’t enough to secure user freedom.

Introduction

My previous article, Whatsapp and the domestication of users, got more attention than I was expecting. Some responses gave me a lot to think about,¹ especially regarding actions we can take. I suggest reading that article first; it explained what “user domestication” is and why it’s a problem. It enumerated three countermeasures: FLOSS, simplicity, and open platforms.

Hard problems, by definition, lack easy solutions. Simply choosing (or creating) a platform that avoids user domestication isn’t enough if that platform can change. The price of freedom is eternal vigilance; in addition to settling on the right platform, we must ensure that it honors its users in both the present and the future. Keeping a platform FLOSS and simple is more straightforward² than keeping a platform “open”.

How do we keep an open platform from becoming a closed platform in the future?

How open platforms become closed

There are three ways to close an open platform:

A forced migration onto a different platform.
A single implementation growing dominant, blurring the line between specification and implementation.
Dominant implementations adopting too many unstandardized features and behaviors.

These three approaches overlap: they frequently feature platform monoculture and a single vendor controlling both clients and servers.

Forced migration

A boxed platform is a subset of a larger open platform that can evolve at its own pace, without concern for compatibility or interoperability.

When one vendor controls all parts of a service (e.g., both a client and server), it has the means to create a boxed platform. Controlling both the server and client allows a vendor to update the client and server without worrying about breaking compatibility with other clients/servers in the larger network. It could update the client to point users to a server that uses a completely different, closed protocol. This is what happened to many XMPP users in the early 2000s.

Case study: the boxing of XMPP

XMPP (formerly known as Jabber) is an open and federated instant-messaging protocol; anybody can set up their own XMPP server and talk to users on different XMPP servers, preventing one organization from owning the platform. Between 2005 and 2014, many proprietary chat platforms supported it: Google Talk, AOL Instant Messenger (AIM), Facebook Chat (later known as Facebook Messenger), and Skype were some well-known examples. Some of these platforms even enabled server-to-server federation.

Unfortunately, users of these proprietary services were boxed. Not many Google Talk users talked to Skype users, and Skype users didn’t typically talk to AIM users. Users stayed in their own sub-platforms. The result was that all users limited themselves to talking exclusively using their provider’s software: one provider controlled the entire messaging flow, from a sender’s client to the server to a recipient’s client. Users were only ever exposed to a single XMPP implementation offered by a single provider.

Each of the listed platforms eventually locked in their users by migrating away from XMPP. This wouldn’t have been possible if multiple implementations and providers interacted with each other. Imagine Bob uses BobClient and BobServer to talk to Alice, and Alice uses AliceClient and AliceServer. BobClient, BobServer, AliceClient, and AliceServer would all have to remain compatible and use the same protocol; a forced migration would be unlikely to occur since it would break compatibility.

Compare the situation with email: despite Gmail’s dominance, other email providers remain popular. Gmail users need to be able to communicate with non-Gmail users, and vice versa. Email is far less “boxed” than the aforementioned proprietary XMPP platforms. As a result, Google hasn’t been able to control the email platform as easily; Google can’t simply migrate Gmail users to a non-email platform that’s incompatible with the rest of the email landscape to further domesticate its users.

XMPP is still alive and well, but its current popularity is a fraction of what it once was.

Implementation clout

Standards are a form of agreements made to ensure compatibility between implementations. Such agreements need to be agreed upon by the implementations themselves. When one implementation grows dominant, so too does its leverage in the decision-making process over shared standards. Too much dominance can create a monoculture in which the dominant implementation is the only implementation that conforms to the spec.

With enough leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically quite helpful, serving as a source of truth to test other implementations against. Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.

Case study: Matrix and Element

One example of this phenomenon is Matrix. Matrix is an open and federated instant-messaging platform similar to XMPP, with a very large spec boasting many features: server-side history, replies, rich text, reactions, room versions, E2EE, avatars, display names, typing indicators, read receipts, device verification…the list goes on and grows every month.³ The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it’s developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn’t supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.

Since there aren’t any third-party clients and servers that can replace the official ones, one vendor is close to controlling all parts of the platform. The growing complexity required of clients and servers can also further entrench these dominant implementations, as I previously explained. Matrix is close to being a boxed platform because the official client and server can iterate independently of the greater ecosystem.

I don’t think that Matrix is going to become a fully closed platform anytime soon; the blog post “On Privacy versus Freedom” seems to put it on the right side of the closed/open spectrum. Clients like gomuks and FluffyChat seem to keep up with Element well enough to serve as partial replacements. I do, however, find its current state problematic and much closer to “closed” on the closed/open spectrum than XMPP, IRC, and email.

Unstandardized feature creep

Platforms are more than their protocols. Different implementations have unique behavior to distinguish themselves. Problems arise when dominant implementations’ unique unstandardized features grow past a certain point to make a closed superset of an open platform.

Case studies: email providers

After reading my previous article, a few people contacted me to ask for my thoughts regarding certain email providers. There’s not much that can set a standard email provider apart if it just hosts a simple email server. To distinguish themselves, email providers often implement many features beyond email standards compliance.

The vast majority of email accounts come from a small handful of dominant providers backed by large companies (Gmail, Yahoo! Mail, Yandex Mail, Mail.ru, iCloud, and others). Providers such as Gmail are notorious for implementing advanced spam filters prejudiced against non-mainstream email providers. Users who self-host email servers or use small providers frequently trigger false positives and end up having their messages incorrectly labeled as spam until they can build up a “reputation”.⁴ The addition of such a complex spam-prevention filter strengthens the email oligopoly by creating a barrier to entry for newcomers. Low-volume senders are discriminated against, as Migadu found out:

We’ve already seen our share of bad spam filters and misconfigured servers. In some cases recipient servers intentionally rejected correct emails just because we are a low volume sender. Ironically that is how an ideal sender should be. To improve the “receiveability” they of course offer their own hosted email service at a hefty price.

— How's Migadu's Deliverability?, section “So, Finally, How’s The Deliverability?”

Another example: email providers such as Hey.com, Protonmail, and Tutanota offer many features that are incompatible with IMAP/POP3. Protonmail and Tutanota use their own non-standard E2EE implementation (rather than focusing on improving the UX for vanilla PGP), and Hey.com offers server-side mail organization. Users of these services must use official Web, desktop, and mobile clients.⁵ These three providers control both the client and the server, giving them the means for vendor lock-in. Of course, there’s a limit to the amount of lock-in these providers can achieve: as I explained in the XMPP case study, these providers still need to support SMTP to stay compatible with the wider email landscape.

Solutions

That’s enough doom-and-gloom. Let’s focus on actions that users and vendors can take to keep platforms open.

What users can do

As a user, consider using clients and servers made by different groups of people to make platform boxing more difficult. Pick implementations that suffer from less feature creep beyond spec compliance. What distinguishes a client shouldn’t be what features it has, but how it implements its features. Obviously, having some unique features is great; problems arise when the number of unique features crosses a certain threshold. Following both these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather than “innovation”. Choose boring technology over shiny new features.

Try venturing outside the mainstream by taking a look at a less popular provider or client. All implementations start somewhere, and a diversity of implementations prevents a rule by oligopoly.

When picking a client and provider, consider the provider’s incentives. Who do your vendors serve? Do they serve users or investors? Have they scaled past the point of financial sustainability?

I’m not arguing that average users are doing something “wrong” by doing otherwise; expecting average users to change their behavior for the greater good is naive. This advice is targeted at the subset of users technical and willing enough to put some thought into the platforms they choose, and indirectly targeted towards the people they can influence.

What vendors can do

Rather than focusing too much on scaling, focus on making server-side software easy to install and federate. Close sign-ups if your instance grows too big, and encourage people to check out different providers. Many Fediverse instances already practice this. I’m not saying that scaling is unimportant; rather, I’m saying that decreasing the barrier to entry for new providers is an effective alternate approach to scaling.⁶

Consider copyleft licensing. Copyleft is one of the most powerful tools we have to protect user freedom by preventing the creation of derivative works that seek to restrict user freedom. This makes it more difficult for alternative implementations to keep changes to themselves in an effort to “box” users. The GNU AGPLv3 is particularly effective since it requires distribution of server-side code for networked services; a viral proliferation of AGPLv3-licensed software could have mitigated the boxing of XMPP users in the early 2000s.

Reference implementations are fine if they aren’t too dominant. Make sure that other implementations can catch up. If necessary, slow down the evolution of a spec, let developers of other implementations participate in the decision-making process, and lend them a hand to improve their implementations. Moving fast and breaking things isn’t the best approach.

For example, Element and the Matrix.org Foundation would alleviate most of my concerns by doing the following:

Wind down new sign-ups on the matrix.org homeserver, pointing users to alternative servers run by different people instead.
Adopt a very conservative approach to new features until more server- and client- implementations reach parity with Element, Synapse, and Dendrite.
Focus on reducing the system requirements to host a server, reducing the barrier to entry for new providers. This is already underway with the development of Dendrite.

Drawbacks

The biggest drawback to the advice I’ve presented is development speed. Keeping compatibility and spec compliance slows down the rate at which new features can be added. As Moxie argues, Signal might not have been able to implement as many features if it was an open platform; spec-constrained development is, by definition, constrained. Users are limited by the lowest common denominator among popular participating implementations.

Open platforms with multiple providers and implementations often suffer from poorer usability, especially with regards to onboarding. Instead of just opening the official app/website, users need to choose from multiple clients and providers. This can be a turn-off for casual users just wanting to try something out. One of the best ways to improve the onboarding experience is to offer recommendations to your non-technical friends; you know them well and can probably help them make an informed decision.

Parallels to other situations

Programming languages driven by a standard rather than a reference implementation typically have greater portability, many good implementations, and are unlikely to fade away with time. Examples include C, C++, Common Lisp, JavaScript, and POSIX Shell. Compare this with a language like Python: so many packages depend on the CPython reference implementation’s approach to C extensions that alternative implementations such as PyPy must perpetually remain second-class citizens.

The standards- and consensus-driven approach to platform development and the inefficiency that comes with it is a trade-off visible in many places outside software development. Most forms of democracy suffer from bureaucracy and in-fighting that stifle progress. Some have argued that democracy’s inefficiency is a feature, not a bug. As Nathan Myhrvold puts it:

The reason societies with democratic governments are better places to live in than their alternatives isn’t because of some goodness intrinsic to democracy, but because its hopeless inefficiency helps blunt the basic potential for evil. The constraint of maintaining constant popularity is simply too large a burden to bear. So, happily, very little gets done that is extremely bad–or extremely good.

— Nathan Myhrvold, The Virtue of Inefficient Government

Perhaps the biggest benefit to abandoning the “move fast and break things” mindset is that in addition to making it hard to rapidly improve a service, abandoning the mindset also makes it hard to rapidly worsen a service.

Acknowledgements

Denver Gingerich helped me brainstorm early in the writing process and provided useful information for the section about XMPP.

Thanks to Barna Zsombor and carbolymer for giving good feedback over IRC.

This Hacker News comment in particular planted quite a few seeds for this article. ↩︎
Please note that the words “straightforward” and “easy” are not interchangeable, though they do have some overlap. ↩︎
See This Week in Matrix, a weekly blog of updates to the Matrix landscape. In particular, see the spec updates: new MSCs get merged every month. ↩︎
The official advice from Google and AWS describes this behavior in more detail. ↩︎
Protonmail offers its own “bridge” program which “translates” the Protonmail API into IMAP, allowing users to use their preferred mail clients. This still doesn’t change the fact that users must use official clients; in this case, the official client is the bridge program itself. ↩︎
I decided against using the cheeky sub-heading “Scaling considered harmful” because I worried that readers on a certain orange-colored website might take the joke too seriously. ↩︎

WhatsApp and the domestication of users

seirdy@seirdy.one (Seirdy) — Thu, 28 Jan 2021 00:13:36 +0000

Introduction

Update: I wrote a follow up: Keeping platforms open. Check it out if you found this article interesting.

I have never used WhatsApp, and never will. Despite this, I still feel the need to write an article about WhatsApp since it’s the perfect case study to help understand a class of businesses models I call “user domestication”. The domestication of users is high on my list of problems plaguing the human race, and is worth a detailed explanation.

WhatsApp wasn’t the first instant messenger of its kind, and probably won’t be the last. I simply chose to focus on WhatsApp since its recent privacy issues have made it a hot topic.

With the meta-explanation out of the way, let us begin.

WhatsApp’s rise

For those unfamiliar, WhatsApp is a tool that makes it convenient and easy to help Facebook further its core mission: the optimization and auctioning of human behavior (colloquially known as “targeted advertising”). It originally persuaded people to consent to this by allowing them to send text to each other over the Internet, something that was already possible, and combining an easy-to-learn UI with successful marketing. It then expanded to include features such as free voice and video calls. Free calls helped it grow to become the de-facto communication platform in many regions. I’m stunned at its ubiquity every time I visit my extended family in India; I’m frequently greeted by looks of confusion when I remind them that I don’t use WhatsApp.

Having its own proprietary chat system incompatible with other clients allowed WhatsApp to build a network effect: WhatsApp’s existing users were held captive by the fact that leaving WhatsApp meant losing the ability to communicate with WhatsApp users. People switching from WhatsApp must convince all their friends to switch, too; this includes less technically inclined friends who had a hard time learning WhatsApp in the first place.

In a WhatsApp world, people who want to keep in touch must abide by the following rules:

Everyone can only use the proprietary WhatsApp client to send messages; developing alternative clients isn’t supported.
Everyone’s mobile device must run an operating system supported by said client. Since WhatsApp developers will only write a client for popular operating systems, the Android and iOS duopoly strengthens.
Users fully depend on WhatsApp developers. If WhatsApp developers decide to include user-hostile features in the app, users must go with it. They can’t switch to a different server or client without switching away from WhatsApp and losing the ability to communicate with all their WhatsApp contacts.

User domestication

WhatsApp rose by trapping previously-free beings in their corral and changing their habits to create dependence on masters. Over time, this made it difficult or impossible to return to their previous lifestyle. That process should sound familiar: it’s eerily similar to the domestication of animals.

I call this type of vendor lock-in user domestication: the removal of user autonomy to trap users into serving vendors.

I chose this metaphor because animal domestication is a gradual process that isn’t always deliberate, and typically revolves around one group becoming dependent upon another. For example: there’s evidence that domestication of dogs began with socialization, resulting in not-entirely-artificial selection promoting genes that resulted in more friendliness with and dependence upon humans.¹

Whether it happens on purpose or by accident, user domestication almost always follows the same three steps:

A high level of dependence given from users to a software vendor
An inability for users to control their software, through at least one of the following methods:
1. Preventing modification of the software
2. Preventing migration onto a different platform
The exploitation of now-captive users who are unable to resist

The completion of the first two steps left WhatsApp users vulnerable to user domestication. With investors to answer to, they had every incentive to implement user-hostile features without consequence.

So, of course, they did.

WhatsApp’s descent

Domestication has a purpose: it enables a master species to exploit the domesticated species for its own gain.

Recently, WhatsApp updated its privacy policy to allow sharing data with its parent, Facebook. Users who agreed to use WhatsApp under its previous privacy policy had two options: agree to the new policy or be unable to use WhatsApp again. The WhatsApp privacy policy update is a classic bait-and-switch: WhatsApp lured users in with a sleek interface and the impression of privacy, domesticated them to remove their autonomy to migrate, and then backtracked on its previous commitment to privacy with minimal consequence. Each step in this process enabled the next; had user domestication not taken place, it would be easy for most users to switch away with minimal friction.

Those of us who were sounding the alarm a few years ago experienced a brief moment of sadistic bliss when our titles were upgraded from “annoying and paranoid conspiracy theorists” to just “annoying”.

An attempt at damage control

The bait-and-switch operation incurred backlash significant enough for a noticeable minority of users to actually migrate; this number turned out to be slightly more than the rounding error WhatsApp was likely expecting. In response, WhatsApp delayed the change and published an ad to improve its image.

Whatsapp Ad

WhatsApp ad, taken from Answering your questions about WhatsApp’s Privacy Policy (archived: Wayback Machine 2021-01-21 snapshot)

Toggle image transcript

Image transcript

WhatsApp Protects and Secures Your Personal Messages.

WhatsApp cannot see your personal messages or hear your calls and neither can Facebook.
WhatsApp does not keep logs of who everyone is messaging or calling.
WhatsApp cannot see your shared location and neither can Facebook.
WhatsApp does not share your contacts with Facebook.
WhatsApp groups remain private.
You can set your messages to disappear.
You can download your data.

The ad lists various data that WhatsApp doesn’t collect or share. Allaying data collection concerns by listing data not collected is misleading. WhatsApp doesn’t collect hair samples or retinal scans either; not collecting that information doesn’t mean it respects privacy because it doesn’t change the information WhatsApp does collect.

The ad denies “keep[ing] logs of who everyone is messaging or calling”. Collecting data is not the same as “keeping logs”; it’s possible for metadata to be fed into an algorithm before being discarded. A model can thus learn that two users call each other frequently without keeping logs of the metadata for each call. The fact that they specifically chose to phrase this line around logging implies that WhatsApp either already collects this class of data or has deliberately left the door open to collecting it in the future.

A stroll through WhatsApp’s actual privacy policy at the time reveals that they do collect considerable metadata used for marketing through Facebook.

Software freedom

With user domestication, providing useful software to users is a means to the end of exploiting them. The alternative is simple: make serving users the end in and of itself.

To avoid being controlled by software, users must be in control. Software that allows users to be in control is called free software or libre software. The word “free” in this context refers to freedom rather than price. Software freedom is similar to the concept of open-source; the latter is an offshoot of the former focused on more business-friendly practical benefits rather than ethics. A less ambiguous term that neutrally refers to free, libre, and open-source software is FLOSS.²

Others have explained the fundamental concepts underpinning free software and its importance better than I can, so I won’t go into detail. It comes down to four essential freedoms:

The freedom to run the program as you wish, for any purpose
The freedom to study how the program works, and change it so it does your computing as you wish
The freedom to redistribute copies so you can help others
The freedom to distribute copies of your modified versions to others

Making money with FLOSS

The most common objection I hear is that FLOSS makes it harder to make money.

The key to making money with FLOSS is to make software a commoditized complement of other, more profitable services. Examples of such services include selling support, customization, consulting, training, managed hosting, hardware, and certifications. Plenty of companies use this approach instead of building proprietary software: Red Hat, Collabora, System76, Purism, Canonical, SUSE, Hashicorp, Databricks, and Gradle are some names that come to mind.

Managed hosting isn’t a basket worth all your eggs if giants like AWS can do the same at a lower price. Being the developer can give an edge in areas like customization, support, and training; it doesn’t offer as obvious an advantage when it comes to hosting.

FLOSS isn’t always enough

Free software is a necessary but sometimes insufficient requirement to build domestication immunity. Two more measures include simplicity and open platforms.

Simplicity

When software grows too complex, it needs to be maintained by a large team. Users who disagree with a vendor can’t easily fork and maintain a multi-million-line codebase, especially if the software in question potentially contains security vulnerabilities. Dependence on the vendor can grow quite problematic when complexity causes development costs to skyrocket; the vendor might resort to implementing user-hostile features to stay afloat.

Complex software that can’t be developed by a different group of people creates dependence, step one of user domestication. That alone is enough to open the door to problematic developments.

Case study: Mozilla and the Web

Mozilla was a ray of hope in the browser wars, a space dominated by adtech, surveillance, and vendor lock-in. Unfortunately, developing a browser engine is a monumental task difficult enough for Opera and Microsoft to give up and re-skin Chromium. Browsers are more than the document readers they were meant to be: they’ve evolved into application runtimes with their own stacks for GPU acceleration, Bluetooth, permissions, device enumeration, bundled media codecs, DRM³, extension APIs, developer tools…the list goes on. It takes billions of dollars a year to respond to vulnerabilities in such a massive attack surface and keep up with a standard that grows at such a worrying rate. Those billions have to come from somewhere.

Mozilla ended up having to make major compromises to stay afloat. It cut search deals with blatantly user-hostile companies, and bundled the browser with ads and bloatware such as a partially ad-funded proprietary bookmarking SaaS called Pocket. Since acquiring Pocket (to diversify its sources of income), Mozilla hasn’t yet delivered on its earlier statements saying it would open-source its code: while the clients have been open-sourced, the server code remains proprietary. Open-sourcing this and re-writing portions if necessary would understandably be a large task due in part to Pocket’s complexity.

Substantial forks such as Pale Moon are unable to keep up with the growing complexity of modern Web standards such as Web Components. In fact, Pale Moon recently had to migrate its code off of GitHub since GitHub began using Web Components, a feature too complex for Pale Moon to support. It’s nigh-impossible to start a new browser from scratch and catch up with behemoths that have been running on ridiculous annual sums for decades. Users can pick between a browser engine developed by Mozilla, an adtech company (Blink by Google), or a walled-garden vendor (WebKit by Apple). WebKit doesn’t seem too bad, but users will be helpless if Apple ever decides to backtrack.

To summarize: the complexity of the Web platform forced Mozilla, the only browser engine developer claiming to serve “people, not profit”, to implement user-hostile features in its browser. The Web’s complexity has left users with limited choice between three big players with conflicts of interest whose positions grow more entrenched with time.

For the record, I don’t think Mozilla is a bad organization; rather, I think it’s surprising that they’re able to do so much without further compromise in a system that practically requires it. Their core product is still FLOSS, and very lightly patched third-party builds remove antifeatures.

Open platforms

To prevent a network effect from turning into vendor lock-in, software that naturally encourages a network effect needs to be part of an open platform. In the case of messaging software, it should be possible to make alternative clients and servers that are compatible with each other to prevent completion of user domestication’s first two steps.

Case study: Signal

Ever since a certain car salesman tweeted “Use Signal”, large numbers of users have been obediently switching. At the time of writing, the Signal clients and servers are FLOSS and use some of the best E2EE out there; however, I’m not a fan.

Although Signal’s clients and servers are FLOSS, Signal is still a closed platform. Signal co-founder Moxie Marlinspike is quite critical of open and federated platforms, describing his rationale for keeping Signal a closed platform in a blog post.⁴ This means that there’s no supported way to develop an alternative server that’s supported by Signal clients, or an alternative client that supports Signal servers. Step one to user domestication is nearly complete.

In addition to there being a single client and server implementation, there’s only one Signal server provider: Signal Messenger LLC. Users’ dependence on this central server provider blew up in their faces when Signal’s recent growth caused downtime for over a day, rendering every Signal user unable to send messages until the single vendor fixed the issue.

People still tried to develop alternative clients: a Signal fork called LibreSignal attempted to make Signal work on privacy-friendly Android builds without proprietary Google Play Services. That fork shut down after Moxie made it clear that he wasn’t okay with a third-party app using Signal’s servers. Moxie’s decision is understandable, but the situation could have been avoided if Signal didn’t have to rely on a single server provider.

If Signal decides to update its apps to include a user-hostile feature, users will be just as helpless as they now are with WhatsApp. Although I don’t think this is likely, Signal’s closed platform leaves users vulnerable to user domestication.

Despite not liking Signal, I still recommended it to my non-technical friends because it was the only messenger private enough for me and simple enough for them. If it had literally any onboarding (account creation, manually adding contacts, etc.), one of my friends would have stuck with Discord or WhatsApp. I’d say something cheeky like “you know who you are” if there was any chance he’d make it this far in the article.

Food for thought

Both of the prior two case studies—Mozilla and Signal—are examples of well-meaning organizations unintentionally leaving users vulnerable to user domestication. The former represents a lack of simplicity but the presence of an open platform. The latter represents a closed platform with a higher degree of simplicity. Intent isn’t in the picture when examining the three steps and countermeasures to user domestication.

paulsnar pointed out a potential conflict between simplicity and open platforms:

I feel like there’s some tension between simplicity and open platforms; to take Signal, in a way it’s simple precisely because it’s a de-facto-closed platform, or at least so Moxie has argued. In turn, Matrix is superficially simple, but the protocol is actually (imho) fairly complex exactly because it’s an open platform.

I don’t have a simple answer to this dilemma. It’s true that Matrix is extremely complex (compared to alternatives such as IRC or even XMPP), and it’s true that it’s harder to build an open platform. That being said, it’s certainly possible to keep complexity on a leash while developing an open platform: Gemini, IRC, and email are examples. While email standards aren’t nearly simple as Gemini and IRC, they evolve slowly; this keeps implementations from having to play catch-up the way Web browsers and Matrix clients/servers do.

Not all software needs to rake in billions. Federation allows services and networks like the Fediverse and XMPP to scale up to large numbers of users without forcing a single behemoth to sell its soul to foot the bill. Although anti-domestication business models are less profitable, they still allow the creation of the same technologies that were enabled by user domestication. All that’s missing is an advertising budget; the biggest advertising some of these projects get is long unpaid blog posts.

Maybe we don’t need to chase growth and try to “make it big”. Maybe we can stop after achieving sustainability and financial security, and make it possible for people to do more with less.

Closing notes

Before it turned into a manifesto of sorts, this post was intended to be an expanded version of a comment I left under a Fediverse post by Binyamin Green.

I initially decided to expand it to its current form for personal reasons. Nowadays, people demand a thorough explanation every time I refuse to use something that “everybody” uses (WhatsApp, Microsoft Office, Windows, macOS, Google Docs…). They’ll usually ignore the explanation, but they expect one anyway. By the next time I meet them, they’ll have forgotten our prior conversation and will re-enact the same dialogue again. Justifying all my life choices by sending logically correct statements into the void—knowing that everything I say will be ignored—is an emotionally draining process that has taken a toll on my mental health for the past few years; sending my friends this article and changing the subject should save me a few gray hairs in the years to come.

This article extends the guiding philosophies of the Free Software and Copyleft movements. Thanks to Barna Zsombor for giving good feedback over IRC.

Since 2900 words wasn’t quite enough, I wrote a follow-up: Keeping platforms open. Check it out if you found this article interesting.

Translations

Translations are always welcome.

Евгений Кузнецов translated this article to Russian: WhatsApp и одомашнивание пользователей.
The Framalang translators at Framasoft translated this article to French: WhatsApp et la domestication des utilisateurs.
Licaon Kter translated this article to Romanian: WhatsApp și domesticirea utilizatorilo.
David Jimenez translated this article to Spanish: WhatsApp y la domesticación de usuario.
Skariko from Le Alternative translated this article to Italian: WhatsApp e l’addomesticamento degli utent.
puer robustus translated this article to German: WhatsApp und die Domestizierung von Nutzern.

Pierotti, R.; Fogg, B. (2017). The First Domestication: How Wolves and Humans Coevolved. Yale University Press. ↩︎
Many within the free software movement dislike the term “open source” for a number of reasons; others use the terms “free” and “open source” interchangeably. Finally, many vendors use the word “free” to refer to price rather than freedom, prompting some free software supporters to adopt the term “libre” instead. All this can be quite confusing, which is why I prefer acronyms like FLOSS to describe these terms’ intersection. ↩︎
See Defective by Design. DRM is another classic example of user domestication. For the record, Mozilla opposed making DRM a Web standard. It implemented DRM support after it lost to the other W3C members. This doesn’t excuse putting DRM in a browser, but at least there wasn’t malicious intent. The same can’t be said for the pro-DRM members of the W3C. ↩︎
Moxie’s blog post generated many responses. Two good follow-ups are on Linux Weekly News and a blog post by Matrix.org ↩︎

Becoming physically immune to brute-force attacks

seirdy@seirdy.one (Seirdy) — Tue, 12 Jan 2021 08:03:10 +0000

Preface

This is a tale of the intersection between thermal physics, cosmology, and a tiny amount of computer science to answer a seemingly innocuous question: “How strong does a password need to be for it to be physically impossible to brute-force, ever?”

TLDR at the bottom.

Note: this post contains equations. Since none of the equations were long or complex, I decided to just write them out in code blocks instead of using images or MathML the way Wikipedia does.

Update: I implemented the ideas in this blog post (and more) in a program/library, MOAC

Toggle table of contents

Introduction

I realize that advice on password strength can get outdated. As supercomputers grow more powerful, password strength recommendations need to be updated to resist stronger brute-force attacks. Passwords that are strong today might be weak in the future. How long should a password be in order for it to be physically impossible to brute-force, ever?

This question might not be especially practical, but it’s fun to analyze and offers interesting perspective regarding sane upper-limits on password strength.

Asking the right question

Let’s limit the scope of this article to passwords used in encryption/decryption. An attacker is trying to guess a password to decrypt something.

Instead of predicting what tomorrow’s computers may be able to do, let’s examine the biggest possible brute-force attack that the laws of physics can allow.

A supercomputer is probably faster than your phone; however, given enough time, both are capable of doing the same calculations. If time isn’t the bottleneck, energy usage is. More efficient computers can flip more bits with a finite amount of energy.

In other words, energy efficiency and energy availability are the two fundamental bottlenecks of computing. What happens when a computer with the highest theoretical energy efficiency is limited only by the mass-energy of the entire observable universe?

Let’s call this absolute unit of an energy-efficient computer the MOAC (Mother of All Computers). For all classical computers that are made of matter, do work to compute, and are bound by the conservation of energy, the MOAC represents a finite yet unreachable limit of computational power. And yes, it can play Solitaire with amazing framerates.

How strong should your password be for it to be safe from a brute-force attack by the MOAC?

Quantifying password strength.

A previous version of this section wasn’t clear and accurate. I’ve since removed the offending bits and added a clarification about salting/hashing to the Caveats and estimates section.

A good measure of password strength is entropy bits. The entropy bits in a password is a base-2 logarithm of the number of guesses required to brute-force it.¹

A brute-force attack that executes 2ⁿ guesses is certain to crack a password with n entropy bits, and has a one-in-two chance of cracking a password with n+1 entropy bits.

For scale, AES-256 encryption is currently the industry standard for strong symmetric encryption, and uses key lengths of 256-bits. An exhaustive key search over a 256-bit key space would be up against its 2²⁵⁶ possible permutations. When using AES-256 encryption with a key derived from a password with more than 256 entropy bits, the entropy of the AES key is the bottleneck; an attacker would fare better by doing an exhaustive key search for the AES key than a brute-force attack for the password.

To calculate the entropy of a password, I recommend using a tool such as zxcvbn or KeePassXC.

The Problem

Define a function P. P determines the probability that MOAC will correctly guess a password with n bits of entropy after using e energy:

P(n, e)

If P(n, e) ≥ 1, the MOAC will certainly guess your password before running out of energy. The lower P(n, e) is, the less likely it is for the MOAC to guess your password.

Caveats and estimates

I don’t have a strong physics background.

A brute-force attack will just guess a single password until the right one is found. Brute-force attacks won’t “decrypt” stored passwords, because they’re not supposed to be stored encrypted; they’re typically salted and hashed.

When estimating, we’ll prefer higher estimates that increase the odds of it guessing a password; after all, the point of this exercise is to establish an upper limit on password strength. We’ll also simplify: for instance, the MOAC will not waste any heat, and the only way it can guess a password is through brute-forcing. Focusing on too many details would defeat the point of this thought experiment.

Quantum computers can use Grover’s algorithm for an exponential speed-up; to account for quantum computers using Grover’s algorithm, calculate P(n/2, e) instead.

Others are better equipped to explain encryption/hashing/key-derivation algorithms, so I won’t; this is just a pure and simple brute-force attack given precomputed password entropy, assuming that the cryptography is bulletproof.

Obviously, I’m not taking into account future mathematical advances; my crystal ball broke after I asked it if humanity would ever develop the technology to make anime real.

Finally, there’s always a non-zero probability of a brute-force attack guessing a password with a given entropy. Literal “immunity” is impossible. Lowering this probability to statistical insignificance renders our password practically immune to brute-force attacks.

Computation

How much energy does MOAC use per guess during a brute-force attack? In the context of this thought experiment, this number should be unrealistically low. I settled on kT. k represents the Boltzmann Constant (about 1.381×10^-23 J/K) and T represents the temperature of the system. Their product corresponds to the amount of heat required to create a 1 nat increase in a system’s entropy.

A more involved approach to picking a good value might utilize the Plank-Einstein relation.

It’s also probably a better idea to make this value an estimate for flipping a single bit, and to estimate the average number of bit-flips it takes to make a single password guess. If that bothers you, pick a number b you believe to be a good estimate for a bit-flip-count and calculate P(n+b, e) instead of P(n, e).

What’s the temperature of the system? Three pieces of information help us find out:

The MOAC is located somewhere in the observable universe
The MOAC will be consuming the entire observable universe
The universe is mostly empty

A good value for T would be the average temperature of the entire observable universe. The universe is mostly empty; T is around the temperature of cosmic background radiation in space. The lowest reasonable estimate for this temperature is 2.7 degrees Kelvin.² A lower temperature means less energy usage, less energy usage allows more computations, and more computations raises the upper limit on password strength.

Every guess, the MOAC expends kT energy. Let E = the total amount of energy the MOAC can use; let B = the maximum number of guesses the MOAC can execute before running out of energy.

B = E/(kT)

Now, given the maximum number of passwords the MOAC can guess B and the bits of entropy in our password n, we have an equation for the probability that the MOAC will guess our password:

P(n,B) = B/2ⁿ

Plug in our expression for B:

P(n,E) = E/(2ⁿkT)

Calculating the mass-energy of the observable universe

The MOAC can use the entire mass-energy of the observable universe.³ Simply stuff the observable universe into the attached 100% efficient furnace, turn on the burner, and generate power for the computer. You might need to ask a friend for help.

Just how much energy is that? The mass-energy equivalence formula is quite simple:

E = mc²

We’re trying to find E and we know c, the speed of light, is 299,792,458 m/s. That leaves m. What’s the mass of the observable universe?

Calculating the critical density of the observable universe

Critical density is smallest average density of matter required to almost slow the expansion of the universe to a stop. Any more dense, and expansion will stop; any less, and expansion will never stop.

Let D = critical density of the observable universe and V = volume of the observable universe. Mass is the product of density and volume:

m = DV

We can derive the value of D by solving for it in the Friedman equations:

D = 3Hₒ²/(8πG)

Where G is the Gravitational Constant and Hₒ is the Hubble Constant. Hₒd is the rate of expansion at proper distance d.

Let’s assume the observable universe is a sphere, expanding at the speed of light ever since the Big Bang.⁴ The volume V of our spherical universe when given its radius r is:

V = (4/3)πr³

To find the radius of the observable universe r, we can use the age of the universe t:

r = ct

Hubble’s Law estimates the age of the universe to be around 1/Hₒ

Solving for E

Let’s plug in all the derived values into our original equation for the mass of the observable universe m:

m = DV

Remember when I opened the article by saying that none of the equations would be long or complex?

I lied.

m = (3Hₒ²/(8πG))(4/3)π(ct)³
m = c³/(2GHₒ)

E = mc²
E = c⁵/(2GHₒ)

Yay, we found an expression for the total energy the MOAC can consume!

Final Solution

P(n,E) = E/(2ⁿkT)
P(n, c⁵/(2GHₒ)) = c⁵/(2GHₒ*2ⁿkT)

Let’s copy and paste the values for those constants from Wikipedia and Wolfram Alpha:

c = 299,792,458 m/s
G ≈ 6.67408×10^-11 m³/kg/s²
Hₒ ≈ 2.2×10^-18 Hz (uncertain; look up the Hubble tension)
T ≈ 2.7 K
k ≈ 1.38065×10^-23 J/K

Plugging those in and simplifying:

P(n) ≈ 2.21×10⁹² / 2ⁿ

Here are some sample outputs:

P(256) ≈ 1.9×10¹⁵ (password certainly cracked after burning 1.9 quadrillionth of the mass-energy of the observable universe).
P(306.76) ≈ 1 (password certainly cracked after burning the mass-energy of the observable universe)
P(310) ≈ 0.11 (about one in ten)
P(326.6) ≈ 1.1×10^-6 (about one in a million)

If your threat model is a bit smaller, simulate putting a smaller object into the MOAC’s furnace. For example, the Earth has a mass of 5.972×10²⁴ kg; this gives the MOAC a one-in-ten-trillion chance of cracking a password with 256 entropy bits and a 100% chance of cracking a 213-bit password.

Sample unbreakable passwords

According to KeePassXC’s password generator, each of the following passwords has an entropy between 330 and 340 bits.

Using the extended-ASCII character set:

¦=¦FVõ)Çb^ÄwÎ¡=,°m°B9®;>3[°r:t®Ú"$3CG¨/Bq-y\;

Using the characters on a standard US QWERTY layout:

%nUzL2XR&Tz5hJfp2tiYBoBBX^vWo3`g6H#JSC#N6gWm#hVdD~ziD$YHW

Using only alphanumeric characters:

tp8D69CGWE5t5a9si5XNsw32CKyCafh8qGrKWLwE6KJHpGyUtcJDWpgRz5mFNx

An excerpt from a religious text with a trailing space:

I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux,

Don’t use actual excerpts from pre-existing works as your password.

Conclusion, TLDR

Question: How much entropy should a password have to ensure it will never be vulnerable to a brute-force attack? Can an impossibly efficient computer—the MOAC—crack your password?

Answer: limited only by energy, if a computer with the highest level of efficiency physically possible is made of matter, does work to compute, and obeys the conservation of energy:

A password with 256 bits of entropy is practically immune to brute-force attacks large enough to quite literally burn the world, but is quite trivial to crack with a universe-scale fuel source.
A password with 327 bits of entropy is nearly impossible to crack even if you burn the whole observable universe trying to do so.

At that point, a formidable threat would rather use other means to unlock your secrets.

Acknowledgements

Thanks to Barna Zsombor and Ryan Coyler for helping me over IRC with my shaky physics and pointing out the caveats of my approach. u/RisenSteam on Reddit also corrected an incorrect reference to AES-256 encryption by bringing up salts.

My notes from Thermal Physics weren’t enough to write this; various Wikipedia articles were also quite helpful, most of which were linked in the body of the article.

While I was struggling to come up with a good expression for the minimum energy used per password guess, I stumbled upon Applied Cryptography by Bruce Schneier. An excerpt on his blog involving setting the minimum energy per computation to kT. I chose a more conservative estimate for T than Schneier did, and a much greater source of energy.

James Massey (1994). “Guessing and entropy” (PDF). Proceedings of 1994 IEEE International Symposium on Information Theory. IEEE. p. 204. ↩︎
Assis, A. K. T.; Neves, M. C. D. (3 July 1995). “History of the 2.7 K Temperature Prior to Penzias and Wilson” ↩︎
The MOAC 2 was supposed to be able to consume other sources of energy such as dark matter and dark energy. Unfortunately, Intergalactic Business Machines ran out of funds since all their previous funds, being made of matter, were consumed by the original MOAC. ↩︎
This is a massive oversimplification; there isn’t a single answer to the question “What is the volume of the observable universe?” Using this speed-of-light approach is one of multiple valid perspectives. The absolute size of the observable universe is much greater due to the way expansion works, but stuffing that into the MOAC’s furnace would require moving mass faster than the speed of light. ↩︎

Best practices for inclusive textual websites

seirdy@seirdy.one (Seirdy) — Mon, 23 Nov 2020 20:21:35 +0000

Before you begin

The following applies to minimal websites that focus primarily on text. It does not apply to websites that have a lot of non-textual content. It also does not apply to websites that focus more on generating revenue or pleasing investors than being inclusive.

This is a “living document” that I add to as I receive feedback. See the updated date and changelog after the post title.

If you find the article too long, just read the introduction and conclusion. The table of contents should help you skim.

Toggle table of contents

Introduction

I realize not everybody’s going to ditch the Web and switch to Gemini or Gopher today (that’ll take, like, at least a month /s). Until that happens, here’s a non-exhaustive, highly-opinionated list of best practices for websites that focus primarily on text. I don’t expect anybody to fully agree with the list; nonetheless, the article should have at least some useful information for any web content author or front-end web developer.

Inclusive design

My primary focus is inclusive design. Specifically, I focus on supporting underrepresented ways to read a page. Not all users load a page in a common web-browser and navigate effortlessly with their eyes and hands. Authors often neglect people who read through accessibility tools, tiny viewports, machine translators, “reading mode” implementations, the Tor network, printouts, hostile networks, and uncommon browsers, to name a few. I list more niches in the conclusion. Compatibility with so many niches sounds far more daunting than it really is: if you only selectively override browser defaults and use plain-old, semantic HTML (POSH), you’ve done half of the work already.

One of the core ideas behind the flavor of inclusive design I present is inclusivity by default. Web pages shouldn’t use accessible overlays, reduced-data modes, or other personalizations if these features can be available all the time. Personalization isn’t always possible: Tor users, students using school computers, and people with restrictive corporate policies can’t “make websites work for them”; that’s a webmaster’s responsibility.

At the same time, many users do apply personalizations; sites should respect those personalizations whenever possible. Balancing these two needs is difficult. Some features conflict; you can’t display a light and dark color scheme simultaneously. Personalization is a fallback strategy to resolve conflicting needs. Disproportionately underrepresented needs deserve disproportionately greater attention, so they come before personal preferences instead of being relegated to a separate lane.

Restricted enhancement

Another focus is minimalism. Progressive enhancement is a simple, safe idea that tries to incorporate some responsibility into the design process without rocking the boat too much. I don’t find it radical enough. I call my alternative approach “restricted enhancement”.

Restricted enhancement limits all enhancements to those that solve specific accessibility, security, performance, or significant usability problems faced by people besides the author. These enhancements must be made progressively when possible, with a preference for using older or more widespread features, taking into account unorthodox user agents. Purely-cosmetic changes should be kept to a minimum.

I’d like to re-iterate yet another time that this only applies to websites that primarily focus on text. If graphics, interactivity, etc. are an important part of your website, less of the article applies. My hope is for readers to consider a subset of this page the next time they build a website, and address the trade-offs they make when they deviate. I don’t expect—or want—anybody to follow all of my advice, because doing so would make the Web quite a boring place!

Our goal: make a textual website maximally inclusive, using restricted enhancement.

Prior art

You can regard this article as an elaboration on existing work by the Web Accessibility Initiative (WAI).

I’ll cite the WAI’s Techniques for WCAG 2.2 a number of times. Each “Success Criterion” (requirement) of the WCAG has possible techniques. Unlike the Web Content Accessibility Guidelines (WCAG), the Techniques document does not list requirements; rather, it serves to non-exhaustively educate authors about how to use specific technologies to comply with the WCAG. I don’t find much utility in the technology-agnostic goals enumerated by the WCAG without the accompanying technology-specific techniques to meet those goals.

I’ll also cite Making Content Usable for People with Cognitive and Learning Disabilities, by the WAI. The document lists eight objectives. Each objective has associated personas, and can be met by several design patterns.

Why this article exists

Performance and accessibility guidelines are scattered across multiple WAI documents and blog posts. Moreover, guidelines tend to be overly general and avoid giving specific advice. Guidelines from different places tend to contradict each other, especially when they have different goals (e.g., security and accessibility). They also tend to be focused on large corporate sites rather than the simple text-oriented content the Web was made for.

I wanted to create a single reference with non-contradictory guidelines, containing advice more specific and opinionated than existing material. I also wanted to approach the very different aspects of site design from the same perspective and in the same place, allowing readers to draw connections between them.

Security and privacy

One of the defining differences between textual websites and advanced Web 2.0 sites/apps is safety. Most browser vulnerabilities are related to modern Web features like JavaScript and WebGL. The simplicity of basic textual websites should guarantee some extra safety; however, webmasters need to take additional measures to ensure limited use of “modern” risky features.

TLS

Hostile networks are the norm, and your site is an attack vector. All of the simplicity in the world won’t protect a page from unsafe content injection by an intermediary. Proper use of TLS protects against page alteration in transit and ensures a limited degree of privacy. Test your TLS setup with testssl.sh and Webbkoll.

If your OpenSSL (or equivalent) version is outdated or you don’t want to download and run a shell script, SSL Labs’ SSL Server Test should be equivalent to testssl.sh. Mozilla’s HTTP Observatory offers a subset of Webbkoll’s features and is a bit out of date (and requires JavaScript), but it also gives a beginner-friendly score. Most sites should strive for at least a 50, but a score of 100 or even 120 shouldn’t be too hard to reach.

A false sense of security is far worse than transparent insecurity. Don’t offer broken TLS ciphers, including TLS 1.0 and 1.1. Vintage computers can run TLS 1.2 implementations such as BearSSL surprisingly efficiently, leverage a TLS terminator, or they can use a plain unencrypted connection. Ancienne 2.0 brings TLS 1.3 to 90s-era machines. A broken cipher suite is security theater.

Scripts and the Content Security Policy

Consider taking hardening measures to maximize the security benefits made possible by the simplicity of textual websites, starting with script removal.

JavaScript and WebAssembly are responsible for the bulk of modern web exploits. If that isn’t reason enough, most non-mainstream search indexes have little to no support for JavaScript. Ideally, a text-oriented site can enforce a scripting ban at the Content Security Policy (CSP) level.

Code snippet 12: this is the CSP for my main website, with hashes removed for readability.

default-src 'none';
img-src 'self';
media-src 'self';
style-src 'sha256-HASH';
frame-ancestors 'none';
base-uri 'none';
form-action FORM_DESTS;
manifest-src 'self';
upgrade-insecure-requests;
sandbox allow-same-origin allow-forms

default-src: 'none' implies script-src: 'none', causing a compliant browser to forbid the loading of scripts. Furthermore, the sandbox CSP directive forbids a wide variety of risky actions. While script-src restricts script loading, sandbox can also restrict script execution with stronger defenses against script injection (e.g. by a browser add-on).¹ I added the allow-same-origin parameter so that signed scripts (e.g. from add-ons) will still be able to function.²

If you’re able to control your HTTP headers, then use headers instead of a <meta http=equiv> tag. In addition to not supporting certain directives, a CSP in a <meta> tag might let some items slip through.

At the time of inserting the meta element to the document, it is possible that some resources have already been fetched. For example, images might be stored in the list of available images prior to dynamically inserting a meta element with an http-equiv attribute in the Content security policy state. Resources that have already been fetched are not guaranteed to be blocked by a Content Security Policy that’s enforced late.

— HTML Living Standard, section 4.2.5.3: Pragma directives, Content Security Policy state

If you must enable scripts

Please use progressive enhancement (PE)³ throughout your site; every feature possible should be optional, and scripting is no exception.

I’m sure you’re a great person, but your readers might not know that; don’t expect them to trust your website. Your scripts should look as safe as possible to an untrusting eye. Avoid requesting permissions or using sensitive APIs.

Finally, consider using your CSP to restrict script loading. If you must use inline scripts, selectively allow them with a hash or nonce. Some recent CSP directives restrict and enforce proper use of trusted types.

Third-party content

Third-party content will complicate the CSP, allow more actors to track users, possibly slow page loading, and create more points of failure. Some privacy-conscious users actually block third-party content: while doing so is fingerprintable, it can reduce the amount of data collected about an already-identified user. Avoid third-party content, if at all possible.

Some web developers deliver resources using a third-party content delivery network (CDN), such as jsDelivr or Unpkg. Traditional wisdom held that doing so would allow different websites to re-use cached resources; however, mainstream browsers partition their caches to prevent this behavior.

If you must use third-party content, use subresource integrity (check the SRI specification). This prevents alteration without your consent. If you wish to be extra careful, you could use SRI for first-party resources too.

Be sure to check the privacy policies for the third party services and subscribe to updates, as their practices could impact the privacy of all your users.

For embedded third-party content (e.g. images), give extra consideration to the “Beyond alt-text” section. Your page should be as useful as possible if the embedded content becomes inaccessible.

Optimal loading

Nearly every Internet user has to deal with unreliable connections every now and then, even the most privileged. Developing regions lack modern Internet infrastructure; high-ranking executives travel frequently. Everybody hits the worst end of the bell-curve.

Reducing load time is especially useful to poorly-connected users. For much of the world, connectivity comes in short bursts during which loading time is precious. Chances of a connection failure or packet loss increase with time.

Optimal loading is a complex topic. Broadly, it covers three overlapping categories: reducing payload size, delivering content early, and reducing the number of requests and round trips.

Blocking resources

HTML is a blocking resource: images and stylesheets will not load until the user agent loads and parses the HTML that calls them. To start loading above-the-fold images before the HTML parsing finishes, send a link HTTP header.

Code snippet 13: my website includes a link header to load the image that serves as my IndieWeb photo and favicon. The header includes a priority hint so the browser starts downloading the resource right away.

link: </favicon.HASH.svg>; rel=preload; as=image; fetchpriority=high

Don’t count on the cache

The browser cache is a valuable tool to save bandwidth and improve page speed, but it’s not as reliable as many people seem to believe. Don’t focus too much on “repeat view” performance.

Out of privacy concerns, most browsers no longer re-use cached content across sites; refer back to the section on third-party content for more details. Privacy-conscious users (including all users using “private” or “incognito” sessions) will likely have their caches wiped between sessions.

Requesting a high number of cached resources can decrease performance of the cache, causing browsers to bypass the cache. The effect is especially pronounced on low-end phones and mechanical hard drives. Firefox calls this feature “Race Cache With Network”, documented in Mozilla Bug 1358038.

One way to help browsers decide which disk-cached resources to prioritize is to use immutable assets. Include the immutable directive in your cache-control headers, and cache-bust modified assets by changing their URLs. You can also keep your asset counts low by combining textual assets (e.g. CSS) and inlining small resources.

Code snippet 14: I mark my website’s assets as “immutable” and cache-bust them by including checksums in their filenames.

cache-control: max-age=31557600, immutable

Inline content

In addition to HTML, CSS is also a blocking resource. You could pre-load your CSS using a link header. Alternatively: if your compressed CSS is under a kilobyte consider inlining it in the <head> using a <style> element. Simply inlining stylesheets can pose a security threat, but the style-src CSP directive can mitigate this if you include a hash of your inline stylesheet sans trailing whitespace.

Consider inlining images under 250 bytes with a data: URI; that’s the size at which cache-validation requests might outweigh the size of the image. My 32-pixel PNG site icon is under 150 bytes and inlines quite nicely. On this site’s hidden service, it’s often the only image on a page (the hidden service replaces SVGs with PNGs; see the section on the Tor Browser). Inlining this image and the stylesheet allows my hidden service’s homepage to load in a single request, which is a welcome improvement given the round-trip latency that plagues onion routing implementations.

Transfer size and user flows

I find advice on page weight to be too simplistic. I prefer the perspective of what the industry calls “user flows”.

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

— WCAG 2.2, Success Criterion 2.4.5 Multiple Ways

Here are some example flows that start with loading a homepage:⁴

A homepage has a link to a list of pages in a category. Your reader loads the homepage, navigates to the list page, and then navigates to the target page.
A homepage contains a link to a post which has “next post” and “previous post” links at the bottom. Your reader navigates to the post and clicks “next post” until they reach the target page.
A homepage has a “search” box. The reader searches for the target page and clicks a result on the result page.

Assume one of your readers has caching enabled, but their current cache is empty. They have a link to your homepage. Your reader should be able to perform at least two different flows to reach a target page, starting with navigating to your homepage. The total size transferred across their entire flow is the metric worth optimizing, not the weight of a single page. Set a performance budget for this flow. A “home, posts list, target page” flow can take a user from my homepage to this page using under 150 KiB.

Data is a scarce resource on metered connections; don’t waste it on unnecessary information. At least half the data transferred across the flow should be semantically-meaningful compressed markup. Try testing a “lite” version of a page with non-semantic markup removed: strip any <div> or <span> elements, or attributes that don’t have semantic value. Compare this “lite” page’s compressed markup size with the total download size of an actual page. Do this for every page across a flow.

I personally found this to be too much work. I skipped the creation of “lite” pages by removing non-semantic markup from my HTML: with the exception of utility classes that describe content rather than structure, my markup is made of semantically-relevant POSH, ARIA, Microdata, and microformats classes.⁵

Core Web Vitals aren’t enough

Download size matters, especially on metered connections. There’s no shortage of advice concerning minimizing this easy-to-understand metric. Unfortunately, it alone doesn’t give us the full picture: download size is not the exact same thing as time taken to deliver useful content to users.

Google’s answer to this problem is “Core Web Vitals” containing metrics such as the Speed Index. These metrics aren’t useless, but they are incredibly naive: they only take into account user-perceivable speed with an emphasis on user engagement, placing too little emphasis a page’s actual resource use. Plenty of other factors exist.

SpeedIndex is based on the idea that what counts is how fast the visible part of the website renders. It doesn’t matter what’s happening elsewhere on the page. It doesn’t matter if the network is saturated and your phone is hot to the touch. It doesn’t matter if the battery is visibly draining. Everything is OK as long as the part of the site in the viewport appears to pop into view right away.

Of course, it doesn’t matter how fast the site appears to load if the first thing the completed page does is serve an interstitial ad. Or, if like many mobile users, you start scrolling immediately and catch the ‘unoptimized’ part of the page with its pants down.

There is only one honest measure of web performance: the time from when you click a link to when you’ve finished skipping the last ad.

Everything else is bullshit.

— Maciej Cegłowski, The Website Obesity Crisis

Round trips

This sub-section is overkill for most use-cases.

A supplementary metric to use alongside download size is round trips. Estimate the number of bytes and round-trips it takes to do the following:

Begin downloading the final blocking resource
Finish downloading all blocking resources
Finish downloading two screenfuls of content
Finish downloading the full page.

Understanding round-trips requires understanding your server’s approach to congestion control.

Historically, TCP congestion control approaches typically set an initial window size to ten TCP packets and grew this value with each round-trip. Under most setups, this meant that the first round-trip could include 14.6 kilobytes. The following round-trip could deliver under thirty kilobytes.⁶ Try to ensure that all non-markup blocking resources and your document’s <head> fit within this 14.6 kilobyte budget.

Nowadays, servers employ BBR-based congestion control. It allows for regular “spikes” in window size, but the initial window size is still small. Find more details in the slides from TCP and BBR (application/pdf) by Geoff Huston from APNiC.

HTTP/3 uses QUIC instead of TCP, which makes things a bit different; the important thing to remember is that user agents should be aware of all blocking resources before finishing the earliest possible round-trip.

The golden kilobyte

One of the benefits of HTTP/2 and HTTP/3 is multiplexing: multiple resources can download over a single connection. Try to initiate downloads for blocking resources as soon as possible.

A TCP packet is 1460 bytes. Your first TCP packet will be partly taken up by a stapled TLS certificate, leaving you with under one kilobyte to work with.⁷ Make good use of this golden kilobyte; most or all of it will likely be taken up by HTTP headers.⁸ Ideally, the first kilobyte transferred should inform the client of all blocking resources required, possibly using preload directives; all of these resources can then begin downloading over the same multiplexed HTTP/2 connection before the current round-trip finishes! Note that this works best if you took my advice to avoid third-party content.

Apply these strategies in moderation. Including extra preload directives in your document markup might not help as much as you think, since their impact on page size could negate minor improvements. Micro-optimizations have diminishing returns; past a certain point, your effort is better spent elsewhere.

Layout shifts

Loading content of unknown dimensions, such as images, can create layout shifts; the WICG’s Layout Instability API describes the phenomenon in detail. Avoid layout shifts by including dimensions in HTML attributes. The simplest way to do so is by including unitless width and height values, but the style attribute could work too. I recommend staying away from the style attribute, or at least selectively allowing its use with the style-src-attr CSP directive.

Other server-side tweaks

In-depth server configuration is a bit out of scope, so I’ll keep each improvement brief.

Compression—especially static compression—dramatically reduces download sizes. My full-text Atom feed is almost a megabyte, but the Brotli-compressed version is under one-quarter of that size. Caddy supports this with a precompressed directive; Nginx requires the ngx_brotli module for Brotli compression.

When serving many resources at once (e.g., if a page has many images), HTTP/2 could offer a speed boost through multiplexing; use it if you can, but expect many clients to only support HTTP/1.1. HTTP/3 is unlikely to help textual websites much, so run a benchmark to see if it’s worthwhile.

Consider caching static assets indefinitely with a year-long duration in their cache-control headers, possibly with an immutable parameter. If you have to update a static asset, cache-bust it by altering the URL. This approach should eliminate the need for an etag header on static assets.

Using OCSP stapling eliminates the need to connect to a certificate authority, saving users a DNS lookup and allowing them to instead re-use a connection.

Consider the trade-offs involved in enabling 0-RTT for TLS 1.3. On one hand, it shaves off a round-trip during session resumption; on the other hand, it can enable replay attacks. 0-RTT shouldn’t be too unsafe for idempotent GET requests of static content. For dynamic content, evaluate whether your backend is vulnerable to replay attacks described in appendix E.5 of the spec.

Against lazy loading

Lazy loading may or may not work. Some browsers, including Firefox and the Tor Browser, disable lazy-loading when the user turns off JavaScript. Turning it off makes sense because lazy-loading, like JavaScript, is a fingerprinting vector. Specifically, it identifies idiosyncratic scrolling patterns.

Loading is only deferred when JavaScript is enabled. This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user’s approximate scroll position throughout a session, by strategically placing images in a page’s markup such that a server can track how many images are requested and when.

— <img>: The Image Embed element on MDN, the loading attribute

If you can’t rely on lazy loading, your pages should work well without it. If pages work well without lazy loading, is it worth enabling?

The scope of this article is textual content supplemented by images. In that context, I don’t think lazy loading is worthwhile because it often frustrates users on slow connections. I think I can speak for some of these users: mobile data near my home has a number of “dead zones” with abysmal download speeds, and my home’s Wi-Fi repeater setup used to result in packet loss rates surpassing 60% (!!).

Users on poor connections have better things to do than idly wait for pages to load. They might open multiple links in background tabs to wait for them all to load at once, and/or switch to another task and come back when loading finishes. They might also open links while on a good connection before switching to a poor connection. For example, I often open several links on Wi-Fi before going out for a walk in a mobile-data dead-zone. A Reddit user reading an earlier version of this article described a similar experience riding the train.

Unfortunately, pages with lazy loading don’t finish loading off-screen images in the background. To load this content ahead of time, users need to switch to the loading page and slowly scroll to the end to ensure that all the important content appears on-screen and starts loading. Website owners shouldn’t expect users to have to jump through these ridiculous hoops.

Against speculative pre-loading

Update 2024-04-06: I’ve updated my stance on this. If you use the Speculation Rules API, preloading will obey user preferences in a standard cross-site way.

A common objection to my case against lazy-loading is that users may be more likely to click a link than scroll to the end, so pages should prioritize pre-loading the link. Pre-loading a page’s essential resources is fine. Speculatively pre-loading content on separate pages isn’t.

Many users with poor connections also have capped data, and would prefer that pages don’t decide to predictively load many pages ahead-of-time for them. The overlap between these two groups grows especially pronounced as data cap overages trigger throttling; this is enough to trigger a seasonal pattern in Japan.

Some go so far as to disable this behavior to avoid data overages. Savvy privacy-conscious users (including Tor Browser users) also generally disable speculative pre-loading since pre-loading behavior is fingerprintable.

Users who click a link choose to download its contents, within a reasonable size limit. Loading pages that a user hasn’t navigated to is making a choice for that user. I encourage adoption of “link” HTTP headers to pre-load essential and above-the-fold resources when possible, but doing so does not resolve the issues with lazy-loading: the people who are harmed by lazy loading are more likely to have pre-fetching disabled.

Moreover, determining the pages to prioritize for speculative pre-loading typically requires analytics and/or A/B testing. Enrolling users in a study (e.g. by collecting information about their behavior) without prior informed consent in terms they fully understand demonstrates a disrespect for their autonomy. Furthermore: analytics typically represent all users equally, when developers should be giving disproportionate attention to marginalized users (e.g., disabled users). The convenience of the majority should not generally outweigh the needs of the minority. Many marginalized groups don’t wish to broadcast the fact that they have special needs, so don’t rely on being able to figure out who’s whom.

Can’t users on poor connections disable images?

I have two responses:

If an image isn’t essential, don’t include it in the page. If an image is essential, assume sighted users want to see it.
Yes, users could disable images. That’s their choice. If your page uses lazy loading, you’ve effectively (and probably unintentionally) made that choice for a large number of users.

Nonetheless, expect some readers to have images disabled. Refer to the “Beyond alt-text” section to see how to best support this case.

Pages should finish making all GET network requests while loading. This makes it easy to load pages in the background before disconnecting. I singled out lazy-loading, but other factors can violate this constraint.

One example is pagination. It’s easier to download one long article ahead of time, but inconvenient to load each page separately. Displaying content all at once also improves searchability. The single-page approach has obvious limits: don’t expect users to happily download a single-page novel.

Another common offender is infinite-scrolling. In addition to requiring JavaScript, infinite-scrolling also makes it difficult for readers to find their old place upon re-visiting a page. This creates harsh consequences for accidental navigation. WordPress documentation lists more problems with infinite scrolling.⁹

A hybrid between the two is paginated content in which users click a “load next page” link to insert the next page at the end of the current page (typically using “dynamic content replacement”). It’s essentially the same as infinite scrolling, except additional content is loaded after a click rather than by scrolling. This is only slightly less bad than infinite scrolling; it still has the same fundamental issue of allowing readers to lose their place.

I’ve discussed loading pages in the background, but what about saving a page offline (e.g. with Ctrl + s)? While lazy-loading won’t interfere with the ability to save a complete page offline, some of these related issues can. Excessive pagination and inline scrolling make it impossible to download a complete page without manually scrolling or following pagination links to the end.

xkcd comic: infinite scrolling

Infinite-scroll means that accidental navigation to a link results in losing your place. From xkcd

Toggle comic transcript

Comic transcript

Megan stands at a desk, touching a book gingerly. Cueball stands behind her.

Cueball: Why are you turning the pages like that?
Megan: If I touch the wrong thing, I’ll lose my place and have to start over.
Caption below the panel: If books worked like infinite-scrolling webpages

Long-page performance

Deferring network requests is a bad idea, as established in the previous “Against lazy loading” section. There are other ways to improve large-page performance.

An alternative to the loading attribute that I do recommend is the decoding attribute. I typically use decoding="async" so that image decoding can be deferred.

CSS containment

Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS specification.¹⁰

CSS containment allows authors to isolate sub-trees of the DOM. This lets browsers make more informed optimizations: they can delay painting off-screen content or reduce re-calculations when isolated nodes change. Combined with a property like content-visibility, it enables browsers to defer all rendering of less essential below-the-fold content.

content-visibility: auto is a more complex directive than content-visibility: hidden; rather than being similar to display: none, it adaptively hides/displays an element’s contents as they become relevant to the user. It also doesn’t hide its skipped contents from the user agent, so screen readers, in-page search, and other tools can still interact with it.

— CSS Containment Module Level 2, section 4.2: Using content-visibility: auto

Leveraging containment and content-visibility is a progressive enhancement, so there aren’t any serious implications for older browsers. I use content-visibility to defer rendering off-screen entries in my archives. Doing so allows me to serve long archive pages instead of resorting to pagination, with page-length limited only by download size. In my tests using Lighthouse with Chromium Devtools’ simulated CPU throttling,¹¹ this article rendered faster with containment-enabled CSS than without any custom stylesheets at all.

Using content-visibility for content at the end of the page is relatively safe. Using it for content earlier in the page risks introducing minor layout shifts and scrollbar-jumping. Eliminate the layout shifts by calculating a value for the contain-intrinsic-size property. Calculating ‘contain-intrinsic-size’ for ‘content-visibility’, by Thijs Terluin from Teluin Webdesign, is a comprehensive guide to calculating intrinsic size values. The scrollbar is less likely to jump around noticeably on extra-long pages, so sufficient page-length could let you get away with setting contain-intrinsic-size to a rough estimate.

Performance of assistive technologies

Eric Bailey’s presentation The intersection of performance and accessibility describes how computing the accessibility tree can be expensive if a page has too many DOM nodes and custom elements. Browsers use complex heuristics to determine which elements to report, to reduce the size of the accessibility tree. Now that all major browsers are moving to multi-process architectures, some browser components interface with assistive technology (AT) in a separate process. Data about the page’s semantics needs to cross process boundaries, incurring additional overhead.

Re-calculating nodes in the accessibility tree can create small delays for user interaction. These delays add up, causing the accessibility tree to fall out-of-sync with the actual page state. In extreme cases, an out-of-control accessibility tree may crash the AT. Moreover, speech synthesizers may be slow to start speaking when the CPU is under load. Delayed speech synthesis is incredibly annoying because it tends to omit words while “warming up”.

When pages grow long, keep performance in check by doing the following:

Prefer semantic HTML over custom elements. The browser’s accessibility-tree-generation and element-filtering is optimized for semantic HTML; it has to do more guesswork to decipher custom elements.
Avoid scripts that delay user-input or cause complex DOM mutations. These will introduce delays that can cause significant AT usability issues.
Remember that CSS can impact the accessibility tree. Avoid using scripts to alter properties such as display and visibility.
Test with screen readers on underpowered hardware. Examples include old entry-level Android phones and netbooks with aggressive thermal throttling.

Old browsers

People do not use your site exclusively with the latest stable versions of Chrome, Firefox, or Safari. If you use metrics, they will be biased against users who avoid your site due to incompatibilities.

Old browsers in use

Plenty of reasons exist for using older versions of each of the mainstream browsers:

Firefox: In addition to Firefox’s “Stable”, “Beta”, and “Nightly” channels, Firefox includes an “Extended Support Release” (ESR). Firefox ESR receives only bugfixes and major security patches for over one year. It’s the default browser in Debian and the basis for the Tor Browser. In other words: if you want people to be able to browse your site anonymously (i.e. with the Tor Browser), you need to support Firefox ESR versions for over 15 months after their release (sometimes longer¹²). If that wasn’t enough: the latest version of KaiOS uses Firefox 84, while older versions (still being sold in 2022!) use Firefox 49.¹³
Safari and WebKit: On Linux, WebKitGTK powers various browsers, RSS readers, and in-app browsers. WebKitGTK versions are limited by a distribution’s release model; LTS distributions will not have the shiniest new WebKit features. Safari versions are similarly limited by iOS and macOS versions. For instance, the iPhone 7 will not be able to run iOS 16 or Safari 16, just four years after it was discontinued; it’ll only receive occasional security patches for Safari 15.x. The only way for iPhone-7-and-earlier users to use Safari 16+ features is to buy a new phone. Expecting users to buy a new device every few years just to display a webpage needlessly contributes to the rampant consumerism and throw-away culture in the consumer electronics industry.
Chromium: Google Chrome’s “Extended stable” channel releases half as often as its “Stable” channel. Moreover, Chromium is the basis for QtWebEngine, the Web engine of the Qt UI toolkit. QtWebEngine powers a host of Web browsers: Qutebrowser, Falkon, Nyxt, Angelfish, Otter Browser, and others. Like WebKit2GTK, QtWebEngine powers various RSS readers and in-app browsers. The latest version of Qt typically includes a QtWebEngine several versions behind upstream Chromium, and most distributions don’t ship the latest version of Qt. Finally, Android’s Chromium-based WebView implementations are still sometimes locked to a vendor’s abandoned version of Android and woefully out of date; in-app browsers are often even worse, sometimes shipping a version of Chromium that’s years old.
Opera: Opera switched away from its in-house Presto browser engine a few years ago, in favor of becoming a Chromium fork. However, Opera Presto is still being kept alive by Opera Mini. Opera Mini’s “extreme” mode uses a proxy server to render pages; that server runs Opera’s Presto rendering engine, which hasn’t added new Web standards in years.

How to support old browsers

I recommend testing with a pre-2013 version of WebKit, as those WebKit versions are ancestors to both Chromium and Safari. Old versions of Opera and Firefox are still available for download. Obviously, I wouldn’t recommend using these browsers outside of a heavily sandboxed environment (e.g. a confined VM) unless you disable unnecessary features and limit their use to testing.

Always use progressive enhancement: everything besides your semantic markup and the occasional legacy image format should be an optional enhancement. Test with CSS, scripts, new image formats, etc. disabled.

Restrict markup to the subset of the WHATWG’s HTML Living Standard that also appears in the W3C’s HTML 5.1 standard. This should provide a slower-moving base than the raw Living Standard that’s also friendlier to older browsers. I don’t recommend referencing the W3C’s HTML 5.1 standard directly, since the Living Standard has since made several important clarifications, corrections, and removals.¹⁴

CSS offers multiple equivalent ways to do the same thing; prefer older versions when possible. A non-exhaustive list of ways to make stylesheets work in older browsers:

Use em units rather than the more convenient rem
Avoid CSS variables and custom properties; keep track of values by using increments, or use a post-processor to replace references to variables.
Use the @supports at-rule to progressively replace an older feature with a newer one.
Explicitly define the display property for the hidden attribute, for browsers that don’t support hidden.

When in doubt: Can I Use and MDN’s browser compatibility data are excellent resources to track feature support across all the mainstream browser engines.¹⁵ Feel free to go wild when adding strictly-optional features.

The Tor Browser

Many people use Tor out of necessity. On Tor, additional constraints apply.

Constraints of the Tor Browser

Tor users are encouraged to set the Tor Browser’s security settings to “safest”. This disables scripts, MathML, remote fonts, SVG images, and other unsafe Firefox features. If your site has any SVG images, the Tor browser will download these just like Firefox would (to avoid fingerprinting) but will not render them.

If you must use scripts, ensure that they perform well with just-in-time (JIT) compilation disabled. The Tor Browser’s “safer” mode, iOS Lockdown mode, and Microsoft Edge’s “enhanced” security mode all disable JIT compilation by default.¹⁶

Additionally, hopping between nodes in Tor circuits incurs latency, worsening the impacts of requiring multiple requests and round-trips. Try to minimise the number of requests to view a page.

If you use a CDN or some overcomplicated website security stack, make sure it doesn’t block Tor users or require them to enable JavaScript to complete a CAPTCHA. Tor Browser users are supposed to avoid fingerprinting vectors like JS and browser extensions, so requiring a JavaScript-based CAPTCHA will effectively block many Tor users.

Tor users are unable to leverage media queries or client-hints to signal special needs. Pages need to be as accessible as possible by default, as per the “inclusive by default” directive outlined earlier. This should be a given, but it’s doubly important when serving fingerprinting-averse readers.

Hidden services

To go above and beyond, try mirroring your site to a Tor hidden service to reduce the need for exit nodes. Mirroring allows you to keep a separate version of your site optimized for the Tor browser.

Normally, optimizing specifically for a given user agent’s quirks (especially in a separate version of a website) is a bad practice; however, the Tor Browser is a special case because there’s no alternative available: Tor users should all use the same browser to avoid standing out. Sometimes, the Tor Browser pretends to have Firefox’s capabilities: progressive enhancement and graceful degradation won’t work when a browser lies about its functionality.

For example, my website’s clearnet version uses some SVG images. Some browsers can’t handle a given image format. The typical solution is to use a <picture> element containing <source> children of varying formats and a fallback <img> element using a legacy image format.

The Tor browser will download whichever format Firefox would, rather than whichever formats it actually supports. A <picture> element containing an SVG and a raster fallback won’t help: the Tor browser will avoid fingerprinting by selecting the SVG format, not a fallback format. The image will not be rendered, so users will have downloaded the image only to see a white box.

I address the issue by not using any SVG images on my hidden service.

In-page search

In-page search (e.g., using Ctrl + f) has been a basic feature in document readers well before browsers, and continues to be an essential feature today.

Searchability is a good reason to prefer conveying information textually, when possible: video (especially without accurate captions), pictures of text, etc. aren’t so easily searchable.

Web pages that hide content behind “show content” widgets are difficult to search through: users need to toggle “show content” for each item they wish to search. Often, in-page search highlights are hidden; Reddit’s atrocious redesign is a serious offender. If you need to hide some content for performance reasons, I described a less hostile way to do so in the “Long-page performance” section.

Searching for the word “good” before and after a “see more” link is clicked. Both situations show a match, but only one of them allows us to view the match. Both screenshots are from the Reddit redesign.

The importance of proofreading

Correct, consistent spelling is important to readers who use search. In-page search doesn’t currently pick up misspelled words. If in-page search implementations develop such a feature, some users may wish to sometimes turn it off; even Google Search implemented a “verbatim” mode for exact matches.

Moreover, some search implementations (such as the one built into Firefox) support case-sensitive matching. Inconsistent capitalization of proper nouns, acronyms, and initialisms can make searching difficult.

Problematic overrides

Search is so essential to some users’ ability to navigate that some desktop users enable “type-ahead” search, to automatically begin a search upon typing multiple characters.¹⁷ If you ignored my advice to avoid JavaScript, at least think twice before using it to define custom keyboard shortcuts which interfere with this type of functionality. I singled out type-ahead search, but there are countless other examples of uncommon keyboard behavior that JavaScript overrides interfere with.

Another problematic override is scroll-behavior. Enforcing smooth-scrolling (e.g., with the scroll-behavior CSS property) can interfere with the use of in-page search by slowing down jumps between matches. Rapidly darting around the page with smooth scrolling can cause motion sickness. Simply relying on users to override default behaviors violates the “inclusive by default” directive I encourage, since user preferences are fingerprintable and shift responsibility away from developers.

There’s a complex solution to turn off smooth scrolling for un-focused elements, but it doesn’t address separate issues such as anchor-link navigation.

About fonts

I recommend setting the default font to sans-serif. system-ui causes issues among readers whose system fonts don’t cover your website’s charset.

If you really want, you could use serif instead of sans-serif; however, serif fonts tend to look worse on low-res monitors. Not every screen’s DPI has three digits. Accommodate users’ default zoom levels by keeping your font size the same as most similar websites.

To ship custom fonts is to assert that branding is more important than user choice. That might very well be a reasonable thing to do; branding isn’t evil! That being said, textual websites in particular don’t benefit much from branding. Beyond basic layout and optionally supporting dark mode, authors generally shouldn’t dictate the presentation of their websites; that should be the job of the user agent. Most websites are not important enough to look completely different from the rest of the user’s system.

A personal example: I set my preferred browser font to sans-serif, and map it to my preferred font in my computer’s fontconfig settings. Now every website that uses sans-serif will have my preferred font. Sites with sans-serif blend into the users’ systems instead of sticking out.

But most users don’t change their fonts…

The “users don’t know better and need us to make decisions for them” mindset isn’t without merits; however, in my opinion, it’s overused. Using system fonts doesn’t make your website harder to use, but it does make it smaller and stick out less to the subset of users who care enough about fonts to change them. This argument isn’t about making software easier for non-technical users; it’s about branding by asserting a personal preference.

Moreover, third-party fonts may not always work. The Tor Browser’s “Safer” and “Safest” modes and iOS 16’s “Lockdown Mode” disable them. Content-blockers like Firefox Focus and uBlock Origin prominently expose remote-font toggles. If you ship remote fonts, you’ll need to test your site with remote and system fonts.

Stylesheet overrides aren’t an excuse

It’s not a good idea to require users to automatically override website stylesheets to see their preferred fonts. Doing so would break websites that use fonts such as Font Awesome to display vector icons. We shouldn’t have these users constantly battle with websites the same way that many ad- and script-blocking users (myself included) already do when there’s a better option.

That being said, many users do actually override stylesheets. We shouldn’t require them to do so, but we should keep our pages from breaking in case they do. Pages following this article’s advice will probably work perfectly well in these cases without any extra effort.

Font fingerprinting concerns

Some people raised fingerprinting concerns when I suggested using the default “sans-serif” font. Websites could see which font this maps to in order to identify users.

You can’t do font enumeration or accurately calculate font metrics without JavaScript. Since text-based websites that follow these best-practices don’t send requests after the page loads and have no scripts, they shouldn’t be able to fingerprint via font identification.

Other websites can still fingerprint via font enumeration using JavaScript. They don’t need to stop at seeing what sans-serif maps to: they can see available fonts on a user’s system,¹⁸ the user’s canvas fingerprint, window dimensions, etc. Some of these can be mitigated by Firefox’s protections against fingerprinting, but these protections understandably override user font preferences.

Ultimately, surveillance self-defense on the web is an arms race full of trade-offs. If you want both privacy and customizability, the web is not the place to look; try Gemini or Gopher instead.

Zoom and font size

Browsers allow users to zoom by adjusting size metrics. Additionally, most browsers allow users to specify a minimum font size. Minimum sizes don’t always work; setting size values in px can override these settings.

In your stylesheets, avoid using px where possible. Define sizes and dimensions using relative units (preferably em). Exceptions exist for rare items that that shouldn’t scale with zoom (e.g. decoration, minimum margins).¹⁹

Code snippet 15 (CSS): set font size and line-spacing with a percentage and a unitless value, respectively.

font: 107.5%/1.5 sans-serif;

Beyond alt-text

Expect some readers to have images disabled or unloaded. Examples include:

Blind readers.
Users with metered connections: sometimes they disable all images, and other times they only disable images surpassing a size.²⁰
People experiencing packet loss who fail to download some images.
Users of textual browsers.

Accordingly, follow good practices for alt-text:

Concisely summarize the image content the best you can, without repeating the surrounding content.
Images should usually have alt-text under 100 ch.²¹ Save longer descriptions for a caption or aria-describedby. Exceptions exist; this is just a weak norm. If longer descriptions elsewhere aren’t an option, disregard this advice and make alt-text as long as it needs to be.
Don’t include significant information that isn’t present in the image; I’ll cover how to handle supplementary information in the next subsections.

The WAI provides some guidelines in An alt Decision Tree. It’s a little lacking in nuance, but makes for a good starting point. Remember that guidelines and “good practices” always have exceptions.

Alt text isn’t just for blind readers; sighted readers who can’t load an image will see alt-text in its place. This alt text might be confined to the image container, so small images should have shorter alt text.²²

Putting images in context

Alt text should be limited to describing content of the image. It lacks context. To make things worse, images can contain a great deal of information. Sighted people can “filter” this information and find areas to focus on; alt text should capture this detail. However, sighted users’ understanding of this detail can be informed by surrounding less-essential detail.

Blind users might struggle to view images in context; they can’t easily scan the text before and after an image non-linearly if there’s no semantic connection between them. Charles McCathieNevile described this experience by comparing screen reading to reading through a drinking straw.

Being sighted and loading images can introduce issues of its own. Sometimes, sighted readers might focus on the wrong part of an image. How can you give readers the missing context and tell them what to focus on?

The best solution comes in two parts:

Before the image, supply context that prepares readers for what to expect.
After the image, describe your interpretation of important details.

This is somewhat similar to the way most students in primary and secondary schools are taught to cite evidence in essays. On that note: remember that these are weak norms, not rules. Deviate where appropriate, just as students should as they learn to write.

Figures

A figure is any sort of self-contained information that is referenced by—but somewhat distinct from—body content. Items that make for good figures are often found in floating blocks of print material.

Consider using a <figure> element when employing the previous section’s two-part strategy. Place one of the two aforementioned pieces of information in a <figcaption>; the caption can come before or after the image.

Figures aren’t just for images; they’re for any self-contained referenced content that’s closer to the surrounding body than an <aside>. Some example items that could use a caption:

Blockquote: Captioned with a citation
Code snippet: Captioned with its purpose or a link to the larger file from which the snippet was borrowed
Mathematical notation: Sometimes captioned with a brief explanation of its behavior, purpose, or significance. Remember to add alt-text.

Figures and captions have loose guidelines, and nearly everything I said on the matter is full of exceptions. A figure need not have a caption, but the majority benefit from one. It need not contain a single main element, but most probably should.

I personally try to maintain the flow of an article even if its figures and captions are completely removed or moved to an appendix. A figure is a “self-contained” block: user agents may re-position figure captions relative to the main figure content, or move the entire figure elsewhere; this is especially common in reading-mode implementations. The HTML specification explicitly notes this behavior; Pandoc’s HTML-to-LaTeX conversion and PrintFriendly are examples of software that moves figure elements around to improve pagination.

When a figure is referred to from the main content of the document by identifying it by its caption (e.g., by figure number), it enables such content to be easily moved away from that primary content, e.g., to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document.

If a figure element is referenced by its relative position, e.g., “in the photograph above” or “as the next figure shows” then moving the figure would disrupt the page’s meaning. Authors are encouraged to consider using labels to refer to figures, rather than using such relative references, so that the page can easily be restyled without affecting the page’s meaning.

— HTML Living Standard, section 4.4.12: The figure element

Image transcripts

Some images contain text. I describe best practices for preparing pictures of text in the “Pictures of text” section. Only use pictures of text if the visual appearance of the text is an essential part of what you wish communicate. If the content of the text is also important, include a transcript.

Image transcripts aren’t just useful for the visually impaired; they also help users relying on machine-translation, since translation tools rely on textual content. These users won’t read alt-text; have an alternative way to discover a transcript.

If the image is a screenshot of text from a website, link to that website to allow users to read its contents in context; this can serve as an “image transcript” of sorts.

A longdesc attribute used to be another way to reference an image transcript. The longdesc attribute contained a hyperlink (often an anchor link) to a location with more information about an image. This attribute has been obsoleted in the HTML Living Standard.

The recommended way to link to a transcript is by hyperlinking the image (i.e., wrapping it with <a>) or semantically grouping the image with its transcript. Put a short summary in the alt-text, and mention the availability of a transcript in a visible caption.

A StackOverflow thread about comic transcripts outlines a good approach to semantically grouping images and transcripts, and my approach is similar. I group an image, alt-text, and caption in a <figure> element and follow it with a transcript in a <details> element. I use aria-describedby to semantically link the figure and the transcript.²³

An image, alt-text, figure caption, and transcript combine to form a complex relationship that should be grouped together in a single landmark. I put all three inside a <section> with a heading, and give the group an aria-label that indicates the presence of the three sub-elements. Using a section landmark ensures that the figure and caption remain together as a single unit. The html code for the xkcd comic earlier in the page is a representative example.

Code snippet 16 (HTML): here’s a simplified version of the HTML used to embed a comic in this article. Of course, I take care of most of the boilerplate with shortcodes.

<section aria-label="comic, caption, and transcript">
  <h4>Infinite scrolling</h4>
  <figure>
    <img src="SRC"
      aria-describedby="transcript-xkcd-1309"
      alt="Comic: infinite-scrolling books require
           careful page-turns to avoid losing the page.">
    <figcaption>
      Infinite-scroll means that accidental navigation
      to a link results in losing your place.
    </figcaption>
  </figure>
  <details>
    <summary>Toggle transcript</summary>
    <div id="transcript-xkcd-1309">
      <p>Megan stands at a desk, touching a book
         gingerly. Cueball stands behind her.</p>
      <dl>
        <dt>Cueball</dt>
        <dd>Why are you turning the pages like that?</dd>
        <dt>Megan</dt>
        <dd>If I touch the wrong thing, I’ll lose my
            place and have to start over.</dd>
        <dt>Caption below the panel</dt>
        <dd>If books worked like infinite-scrolling
            webpages</dd>
      </dl>
    </div>
  </details>
</section>

About custom colors

Always remember that any color palette you define in your stylesheets is merely a suggestion. Any colors you don’t define could fall back to arbitrary defaults; all colors you define could be overridden by the user agent or operating system.

Default colors

Some users’ browsers set default page colors that aren’t black-on-white. For instance, Linux users who enable GTK style overrides might default to having white text on a dark background. Websites that explicitly set foreground colors but leave the default background color (or vice-versa) end up being difficult to read. The same phenomenon occurs on pages with text foregrounds with image backgrounds.

A second opinion: Chris Siebenmann describes this in more detail in A Web Colours Problem. In short: when setting colors, always set both the foreground and the background color. Don’t set just one of the two.

Chris also describes the importance of visited link colors in Visited Links Usability.

Example unreadable palette

This is an unreadable screenshot of Better Motherfucking Website. I had set my browser foreground and background colors to white and dark gray, respectively. The website overrode the foreground colors while assuming that everyone browses with a white background.

Toggle screenshot transcript

Screenshot transcript

A little less contrast.

Black on white? How often do you see that kind of contrast in real life? Tone it down a bit, asshole. I would’ve even made this site’s background a nice #EEEEEE if I wasn’t so focused on keeping declarations to a lean 7 fucking lines.

Color overrides and accessibility

Even if you set custom colors, ensure that the page is compatible with color overrides: elements shouldn’t be distinguished solely by foreground and background color. Technique C25 for the Web Content Accessibility Guidelines (WCAG) 2.2 describes how doing so can meet the WCAG 2.2’s Success Criterion 1.4.8. Specifically, it describes using default colors in combination with visible borders. The latter helps distinguish elements from surrounding content without relying on a custom color palette.

This page’s canonical location is an example application of Technique C25 (and the related Technique G148). It only uses non-default colors when a user agent requests a dark color scheme (using the prefers-color-scheme CSS media query; see the next subsection) and for lightening borders. Any image with a solid background may match the page background; to ensure that their dimensions are clear, I surrounded them with borders. Most browsers will render these borders with the default foreground color, which should be visually distinct from the background. I included borders and/or horizontal rules to break up some sections, since heading-based delineation is either unavailable or insufficient for them. When overriding color schemes, the page layout remains clear.

Color overrides go well beyond simple foreground and background color changes. Windows High Contrast Mode (WHCM) is perhaps the best example. WHCM makes advanced modifications to color palettes: it colors elements with a user-specified palette, all according to semantic markup while ignoring ARIA overrides.²⁴

WHCM leads the standardization process for the forced-colors CSS media feature, but it isn’t the only implementation of the underlying idea. If you navigate to about:preferences in Firefox and activate the Colors button in the “Language and Appearance” section, you’ll be presented with the option to override website palettes with your own default colors.

Not all approaches completely discard a designer’s specified color palette. The CSS Working Group is working on a specification for stylesheet processing in CSS Color Adjustment Module Level 1. The Chromium team’s in-progress auto dark mode will use this specification to darken websites globally. Websites can opt out with the color-scheme property, but they really shouldn’t have to: stylesheets should be robust enough to handle re-coloring.

Win HCM is a collection of user defined color themes that overwrite your definitions in CSS.

It’s not about design but readability.

Some stuff will disappear in Win HCM, some won’t. Best advice is to use semantic HTML to keep things visible.

You can use transparent outline to keep things visible like focus indicators and surface boundaries or use currentColor to maintain SVG fill colors in Win HCM.

You can use a special media query combined with special CSS color keywords to give elements the user defined colors.

— Martin Mengele, Accessibility Issues concerning Windows High Contrast Mode

Dark themes

If you do explicitly set colors, please also include a dark theme using a media query: @media (prefers-color-scheme: dark). For more info, read the prefers-color-scheme docs on MDN. Dark themes are helpful for readers with migraines, photosensitivity (like me!), or dark environments.

If you include a theme-color directive in your document <head>, then recent browsers will automatically switch their default stylesheets to dark-mode. Unfortunately, some older browsers (like Firefox-ESR) don’t support this directive, and WebKit’s default dark stylesheet has unreadable links. WebKit versions in the wild are often out of date, so a fixed stylesheet would need to be out for many years before I would consider using default dark stylesheets.

WebKit’s default dark stylesheet uses dark-colored links that are difficult to read.

CSS filters such as invert are expensive to run, so use them sparingly. Simply inverting your page’s colors to provide a dark theme could slow it down or cause a user’s fans to spin.

Darker backgrounds draw less power on devices with OLED screens; however, backgrounds should never be solid black. White text on a black background causes halation, especially among astigmatic readers. Halation comes from the word “halo”, and refers to a type of “glow” or ghosting around words. There has been some experimental color research and plenty of anecdotal evidence from astigmatic users to support this.

This image is an approximation of what halation looks like, cropped from Essential Accessibility.

“Just disable dark mode” is a poor response to users complaining about halation: it ignores the utility of dark themes described at the beginning of this section.

If you can’t bear the thought of parting with your solid-black background, worry not: there exists a CSS media feature and client-hint for contrast preferences called prefers-contrast. It takes the parameters no-preference, less, and more. You can serve increased-contrast pages to those who request more, and vice versa. Check section 11.3 of the W3C Media Queries Level 5 specification for more information.

I personally like a foreground and background of #E9E9E9 and #191919, respectively. These shades seem to be as far apart as possible without causing accessibility issues: #191919 is barely bright enough to create a soft “glow” capable of minimizing halos among slightly astigmatic users, but won’t ruin contrast on cheap displays. I also support a prefers-contrast: less media query which lightens the background to #333.²⁵

Use the Advanced Perceptual Contrast Algorithm

Color is a nuanced topic that deserves more attention than current guidelines give.

When setting colors, especially for a dark background, I recommend checking your page’s contrast using Accessible Perceptual Contrast Algorithm (APCA) values. You can do so in an online APCA checker (requires JavaScript) or Chromium’s developer tools (you might have to enable them in a menu for experimental preferences). I recommend using the web app.

The APCA takes several factors into account:

The human retina has few blue-sensitive cone cells, so blue appears “darker” than green and red. Yellow appears brightest.
Small, thin fonts are difficult to see and require greater contrast.
It’s possible to have too much contrast, especially for large/bold text (note that the APCA version built into Chromium does not yet take this into account).

Note that the APCA isn’t fully mature as of early 2022. Until version 3.0 of the WCAG is ready, pages that are required to comply with the WCAG should also conform to the contrast ratios described in the WCAG 2.2’s success criteria 1.4.3 (Contrast: Minimum, level AA) or 1.4.6 (Contrast: Enhanced, level AAA). This site’s dark-mode stylesheet is an example of a palette that conforms to both the WCAG 2.2 AAA contrast requirements and APCA recommendations.

What contrast algorithms don’t cover: over-saturation

Even if the APCA is much better than the WCAG’s current naive contrast algorithms, it still doesn’t account for all aspects of the relationship between perceptual contrast and color. Discussion no. 74 on the SAPC-APCA repository covers some shortcomings. For instance, the current APCA version does not account for the Helmholtz–Kohlrausch effect: highly-saturated colors appear “brighter” than de-saturated colors with the same brightness. Excessive perceptual brightness against dark backgrounds can trigger halation, eye-strain, and overstimulation.

Yellow may have great contrast on dark backgrounds, but vivid yellow and red can cause problems among people who deal with overstimulation; this includes many on the autism spectrum. Lē Silveus McNamara wrote about the issue on the TPGi blog: Beyond WCAG: Losing Spoons Online.²⁶

If you want to use significant amounts of “emergency colors” like yellow and red, de-saturate them so their color feels muted. This site’s dark theme uses very pale, washed-out yellow and violet for maximum contrast with minimal harshness.

Accounting for halation, overstimulation, and high-contrast needs is hard to do if you prioritize minute aesthetics before inclusivity.

Contrast under different conditions

Color palettes need to be effective for different types of vision deficiencies (e.g. color blindnesses) and screens. Color blindness is a far more nuanced topic than “the inability to see some colors”. Rob Pike describes his experience in Color blindness. Color blindness manifests in complex ways. Testing in grayscale is a great start, but it doesn’t account for all kinds of color vision deficiencies.

Different screens and display-calibrations render color differently; what may look like a light-gray on a cheap monitor could look nearly black on a high-end OLED screen. Try to test on both high- and low-end displays, especially when designing a dark color scheme.²⁷

Color schemes should also look good to users who apply gamma adjustments. Most operating systems and desktop environments bundle a feature to reduce the screen color temperature at night, while some individuals may select a higher one in the morning.

Visible interactive semantics

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

— WCAG 2.2, section 1.4.1

A basic WCAG Level A requirement is for information to not be conveyed solely through color. Both the presence and type of interactivity need to be visually communicated by other means. Links should not look like buttons, and vice-versa.

In defense of link underlines

Some typographers insist that underlined on-screen text is obsolete,²⁸ and that hyperlinks are no exception. I disagree.

Readers already expect underlined text to signify a hyperlink. Don’t break fundamental affordances for aesthetics. Underlines are also necessary to distinguish the beginnings and ends of multiple consecutive links, especially among color-blind users.

It’s impossible to discern the number of links in a sequence without some sort of separator. Whitespace alone isn’t sufficient.

Moreover, several parts of Making Content Usable for People with Cognitive and Learning Disabilities recommend underlining links.

Some users have trouble when controls have a different look, color, or shape than they have used before. For example, when links do not have underlines and blue or purple text some users will not know there is a link (even if this appears with focus).

— Making Content Usable for People with Cognitive and Learning Disabilities, section 4.2.5.3: Clearly Identify Controls and Their Use: How it Helps

This stance is not absolute. Users are familiar with very common design patterns, such as navigation bars and search results. Underlines are still preferable, but I find their absence less concerning in these cases.

Buttons versus links

Buttons are another type of interactive element. Users are accustomed to recognizing buttons by their visually distinct interactive region. While hyperlinks are only signified by color and a text underline, buttons are signified by a background-color change and/or a visible border. Do not conflate the two!

The purpose of a hyperlink is to navigate to a different location. If a button exists to do the same thing, it shouldn’t be a button; it should have both hyperlink semantics and presentation instead. Otherwise, the consequences of element activation are unclear.

Use a clear and recognizable design for controls. Make it clear what elements are controls and how to use them.

This includes:

Using a common style on controls (for example, links being underlined).

Using common design patterns on links and controls (for example, clicking on a link takes you to the page).

Making the borders of controls clear. Links in text do not need borders if identified properly (for example, a help icon has a border).

Making controls large enough so that users can click on it and not the item next to it.

Ensuring items that are not clickable do not look like links or controls.

When this is not possible, provide instructions that explain how to use the control.

— Making Content Usable for People with Cognitive and Learning Disabilities, section 4.2.5.2: Clearly Identify Controls and Their Use: What to Do

One key difference between buttons and links is the cursor appearance. Buttons should not turn the cursor into a “hand” or “pointer” icon. The article Some pointers on default cursors by Hidde de Vries covers both sides of the issue. Personally, I think it’s best to respect the convention of the browser and OS rather than break it.

Read more about the differences between buttons and links in Buttons vs. Links by Eric Eggbert.

Visible non-interactive semantics

In addition to offering ample non-interactive space, ensure that non-interactive and interactive regions are visually distinct. Avoid making interactive elements with many children.

GitHub’s mobile website is a serious offender; see this screenshot of the GitHub bug tracker for an example.

The background region of the visible issue is interactive, and so are its contents.
The header of the issues list has a non-interactive background that looks the same as the aforementioned interactive background.
Visual appearance does not convey the difference between a button and a hyperlink: The “enhancement” link looks like a button
The “enhancement” link points to a unique location, yet it loses its interactivity on narrow viewports with no visual change; tapping it navigates to a different location depending on viewport width.

Screenshot of the GitHub issues for waifu2x-ncnn-vulkan.

Someone using the GitHub issues interface for the first time will struggle to identify interactive regions and discern whether they trigger navigations or different actions.

Against focusable containers

Screen readers like iOS VoiceOver²⁹ fail to follow in-page links whose targets are not focusable. Designers often work around this by annotating link targets with the tabindex="-1" HTML attribute. This is a good idea when a link target is a heading or piece of phrasing content. Unfortunately, making large containers focusable ruins keyboard-navigability.

Normally, if you select some text in a page and press Tab, the tab-focusable element after the selected text will receive focus. However, if the selectable text is inside a focusable container—even a container with a negative tabindex—pressing Tab will move focus to the start of the container. If you’re reading this on a desktop browser, you can experience this first-hand: select some text in this paragraph and press Tab. Then, do the same in this snapshot of an excellent Smashing Magazine article.³⁰

Two screenshots of the aforementioned Smashing Magazine article after I selected the title text, before and after pressing Tab. The focus moves backwards to the start of the container because the container is focusable. The focus should have moved to an element after the selected text.

This behavior is particularly frustrating on long pages. Imagine if pressing Tab took you to the start of this article!

Image optimization

Some image optimization tools I use:

pngquant: lossy PNG compression. Can reduce the size of the color palette.
gifsicle: Optimizes GIF images, static or animated. Supports many dithering options and advanced optimization options for animations.
didder: Offers more advanced dithering options than gifsicle and pngquant.
oxipng: Lossless PNG compression. It’s like a parallelized version of OptiPNG that also supports an implementation of ZopfliPNG compression
jpegoptim: Lossless or lossy JPEG compression. Note that JPEG is an inherently lossy format; the lossless features of jpegoptim only shrink the size of existing JPEG files by removing unnecessary metadata.
cwebp: The reference WebP encoder; has dedicated lossless and lossy modes. Lossy WebP compression isn’t always better than JPEG, but lossless WebP consistently beats PNG.
avifenc: The reference AVIF encoder, included in libavif.³¹ AVIF lossless compression is typically useless, but its lossy compression is pretty unique in that it leans towards detail removal rather than introducing compression artifacts. Note that AVIF is not supported by Safari or most WebKit-based browsers. It also seems unsupported in Microsoft Edge.³²

I put together a quick script to losslessly optimize images using these programs. For lossy compression, I typically use GNU Parallel to mass-generate images using different options before selecting the smallest image at the minimum acceptable quality. Users who’d rather avoid the command line while performing lossy compression can instead check out Squoosh, a JavaScript app that bundles WebAssembly-compiled encoders; I’ve heard good things about it.

You also might want to use the HTML <picture> element, using JPEG/PNG as a fallback for more efficient formats such as WebP or AVIF, but only if the size savings (or quality improvements at a similar size) are significant. More info is in the MDN <picture> docs

Most of my images will probably be screenshots that start as PNGs. My typical flow:

Re-size and crop the PNG. Convert to grayscale if color isn’t important.
Lossy compression with pngquant
Losslessly optimize the result with oxipng and its Zopfli backend (slow)
Also create a lossless WebP from the lossy PNG and a lossy WebP from the source image, using cwebp. Pick the smaller of the two.
Include the resulting WebP in the page, with a fallback to the PNG using a <picture> element.
Create a lossy AVIF image from the cropped full-color PNG, and include it in the <picture> element if it’s smaller than the WebP. If color isn’t important, use the YUV400 color space.
If the image is too light, repeat for a dark version of the image to display in response to a prefers-color-scheme: dark media query.

In general, avoid loading images just for decoration. Only use an image if it has a clear purpose that significantly adds to the content in a way that text can’t replace, and provide alt-text as a fallback. Any level of detail that isn’t necessary for getting the point across should be removed by lossy compression and cropping.

If you want to include a profile photo (e.g., if your website is part of the IndieWeb and uses an h-card), I recommend re-using one of your favicons. Doing so should be harmless since most browsers will fetch and cache favicons anyway.

If you really want to take PNG optimization to the next level, try Efficient Compression Tool.

Code snippet 17 (shell): this is a sample command to compress a PNG image using ImageMagick, pngquant, and oxipng. It shrinks the image, turns it grayscale, reduces the color palette, and then applies lossless Zopfli compression.

convert ORIGINAL_FILE \
  -resize 75% -colorspace gray -format png - \
  | pngquant -s 1 12 - \
  | oxipng -o max -Z --fix - --out OUTPUT_FILE

Breaking conventional wisdom

Some conventional wisdom for image compression doesn’t hold up when compressing this aggressively; for instance, I’ve found that extremely aggressive dithering and PNG compression of small black-and-white images consistently surpasses JPEG compression.

Most resources on image optimization recommend progressive rendering. I don’t recommend progressive rendering for below-the-fold images; if you optimize an image to just a few kilobytes, it should fully load in time. It’s not worth the overhead for resources of less than 20 kb.

These resources also encourage authors to include different image variants for different viewport sizes, screen resolutions, and pixel densities. They often skip the caveats:

Using different image files for different viewport sizes can cause the page to request more images as users re-size their window.
Sending requests dependent on viewport and display characteristics is a fingerprinting vector, allowing servers to identify users by these properties.

Rather than create separate lanes for different users, I prefer making the defaults as inclusive as possible. A single image should look good under a variety of downscaling algorithms. It should be as small as it can be without losing essential information.

It might seem odd to create a lossless WebP from a lossy PNG, but I’ve found that it’s often the best way to get the smallest possible image at the minimum acceptable quality for screenshots containing solid backgrounds.

Enforce image compression

The “Document Policy” HTTP header has experimental directives lossless-images-max-bpp and lossy-images-max-bpp. In this context, “bpp” refers to “bytes per pixel”; a 256-by-256 pixel image that’s 6.6 kilobytes large would have a “bpp” of 0.1. If it’s a lossy image, then sending lossy-images-max-bpp=0.1 would forbid the image from loading if it’s over 6.6 kilobytes in size.

Currently, these directives are disabled-by-default in Chromium; you can enable them by navigating to chrome://flags and toggling “Experimental Web platform features”. I don’t think these directives are perfect, but they are quite useful.

Dark image variants

Bright images on an otherwise dark page distract readers, especially readers like me with ADHD. The human iris adjusts to average amounts of light; an object far brighter than its surroundings causes eye strain even among readers with healthy vision.

A <picture> element allows selection of sources based on any CSS media query. When images have light backgrounds, I like to include dark variants to complement a dark stylesheet using an HTML media attribute: it selects a dark variant when the user has selected dark mode and is using a screen media type. Requiring the screen media type prevents selection of dark variants when printing. Printer paper is almost always white, so dark images could waste ink. Ink waste is a sensitive issue among many students: school printers sometimes charge students who exceed a given ink quota. Ask me how I know!

Light and dark variants of legacy formats (PNG, JPG, GIF), WebP, and AVIF can cause some of my <picture> imagesets to have up to six image variants. I could fully automate the process using my static site generator (Hugo) if I wanted to. Since I do want to inspect each image and compress to the minimum acceptable quality, I settled for partial automation using shell scripts and a Hugo shortcode.

Code snippet 18 (HTML): A minimal example of a picture containing a dark variant and two image formats.

<picture>
<source type="image/webp" srcset="/p/light.webp">
<source type="image/webp" srcset="/p/dark.webp"
  media="screen and (prefers-color-scheme: dark)">
<source type="image/png" srcset="/p/dark.png"
  media="screen and (prefers-color-scheme: dark)">
<img src="/p/light.png" alt="ALTERNATIVE_TEXT."
  width="WIDTH" height="HEIGHT">
<picture>

SVG images

I only recommend using SVG in images; avoid using them in embeds, objects, or directly in the body. Remember that users may save images, and open them in a non-browser image viewer with reduced SVG compatibility. To maintain maximum compatibility, stick the subset of the secure static processing mode of SVG Static. Specifically, the subset that appears in the SVG Tiny Portable/Secure (PS) spec. SVG Tiny PS is a subset of SVG Tiny 1.2, which is a supported export format in most vector drawing programs. Ignore the elements specifically required for SVG Tiny PS; your image can be a standard SVG that only utilizes a tiny subset of the full SVG spec.

This advice might seem daunting, but it’s usually easy to use existing tools to generate an SVG Tiny file and manually edit it to support the SVG secure static mode. SVGs that conform to this subset should be compatible with Qt5’s SVG implementation, librsvg (used by Wikipedia and GNOME), and most operating systems’ icon renderers. Moreover, tools like usvg can simplify complex SVGs to a tiny subset of the SVG spec.

Two tools that can optimize the size of an SVG file are SVGO and the now-discontinued svgcleaner. Too much lossy SVG compression can sometimes reduce the effectiveness of gzip and Brotli compression. Compress in moderation.

Layout

Page layout should be simple, predictable, consistent, familiar, and static. Avoid anything too unusual, since novelty could introduce a learning curve.

Accessible skimming

Keep the source order, DOM order, and visual order identical to ensure consistent behavior when navigating with the mouse, keyboard, assistive-technology, et al. Doing so should also result in a logical Tab order.

Guideline 2.4 Navigable of the WCAG lists multiple criteria related to identifying and skipping sections of your pages, and for good reason:

Users of switch access controls find it slow and frustrating to navigate long lists of focusable items.
Screen readers make it difficult to consume poorly-organized content non-linearly.
Clients that don’t support CSS can’t prioritize content using a supplied stylesheet.

The list goes on: nearly every reader reliant upon assistive technologies (AT) struggles to skim through poorly-organized pages.

Related items need to be semantically grouped together. Group navigation links together in <nav> elements; sections under headings and landmarks; lists under <ol>, <ul>, or <dl>; etc. to give assistive technologies the means to skip over multiple items at once.

The first or second heading in the DOM, and the highest heading level, should be the page title marking the start of your main content (i.e. it should come after the site title, site navigation links, etc). Use elements like <main>, <nav>, and <article> to provide landmarks. If multiple navigation elements exist, give your main navigation element an aria-label or a heading.

Remember that not all landmarks are announced by screen readers; for instance, many screen readers don’t announce the ending of a <header> element in an article. An <hr> element is a good way to force the ending of a landmark to be visible: it introduces a thematic break between sections that is visible to assistive technologies and user-agents that don’t support CSS.

Consider adding a “skip link” if some pages require many Tab keystrokes to reach the main content.³³ Visually-impaired users generally prefer navigating by headings or landmarks, but screen reader beginners and motor-impaired users still benefit from a skip link. Skip links are especially helpful when pure heading- and landmark-based navigation isn’t optimal.

If your skip link toggles visibility states when focused, ensure that it doesn’t move any existing content; see the “Layout shifts” section for more details. If it appears over existing content, it needs to have a solid background; if you set the background color, set a foreground color too as described in the “About custom colors” section.

Users of ATs such as screen readers primarily navigate through landmarks, headings, and paragraphs. Sometimes they also navigate between links. Headings and link names need to be unique and descriptive enough to serve as navigational aids; paragraphs shouldn’t be too long.

Try using a tool to view a list of all your link names. Just about every screen reader and some browser extensions should offer this functionality. Minimize links with ambiguous names, and ensure that identical link names have identical destinations.

Think twice before placing important content immediately after skippable content such as nested landmarks, long code snippets, figures, and large lists. AT users who wish to skip content may jump directly to the next heading, glossing over anything between the skippable content and subsequent heading; this is especially common on mobile devices.³⁴ When it makes sense to do so, place skippable content in its own sections and/or at the end of its parent section.

Single-column layout

The remainder of the “Layout” section is possibly the most subjective part of this article, and the part with the most exceptions. Consider it more of a weak suggestion than hard advice. Use your own judgement.

A simple layout looks good at a variety of window sizes, rendering responsive layout changes unnecessary. Textual websites really don’t need more than a single column; readers should be able to scan a page top-to-bottom, side-to-side exactly once to read all its content.

Verify this using the horizontal-line test: mentally draw a horizontal line across your page, and make sure it doesn’t intersect more than one landmark. Ideally it shouldn’t intersect multiple different grouping elements either. The “source order viewer” in Chromium’s DevTools can assist with this process.

Keeping a single-column layout that doesn’t require responsive layout changes ensures smooth window re-sizing. Doing so while keeping an identical source, DOM, and visual order ensures layout consistency: spatial references such as “the paragraph above this heading” or “the bottom image of a section” will be unambiguous to screen reader, phone, and desktop users. It also ensures that selection behavior and caret movements during caret navigation remain predictable. Achieving this type of layout entails using the WCAG 2.2 techniques C27: Making the DOM order match the visual order as well as C6: Positioning content based on structural markup.

Nontrivial use of width-selectors, in CSS queries or imagesets, is actually a powerful vector for JS-free fingerprinting. This is one of the reasons why I didn’t recommend resolution- or dimension-aware imagesets in the image optimization section.

Exceptions exist: one or two very simple responsive changes won’t hurt. The main anti-patterns are adjusting the relative order of elements, layout shifts dramatic enough to cause confusion, and making requests based on media queries that reveal fingerprintable information.

Sidebars are probably unnecessary, and can be quite annoying to readers who re-size windows frequently. This is especially true for tiling window manager users like me: we frequently shrink windows to a fraction of their original size. When this happens to a website with a sidebar, one of two things happens:

The site’s responsive design kicks in: the sidebar vanishes and its elements move elsewhere. This can be quite CPU-heavy, as the browser has to both re-wrap the text and handle a complex layout change. Frequent window re-sizers will experience lag and battery loss, and might need a moment to figure out where everything went.
The site doesn’t use responsive design. The navbar and main content are now squeezed together. Readers will probably close the page.

Neither situation looks great.

Low Vision User Accessibility Requirements by the WAI is a work-in-progress document that describes issues caused by significant responsive changes. It encourages designers to “maintain point of regard” during responsive changes (the “point of regard” is the place a reader is looking at). Unfortunately, it’s not always possible to “guess” whether the point of regard is the main content or a sidebar.

Common items in sidebars include tag clouds, an author bio, and an index of entries; these aren’t useful while reading an article. Consider putting them in the article footer or—even better—dedicated pages. This does mean that readers will have to navigate to a different page to see that content, but they probably prefer things that way; almost nobody who clicked on “An opinionated list of best practices for textual websites” did so because they wanted to read my bio.

Don’t boost engagement by giving readers information they didn’t ask for; earn engagement with good content, and let readers navigate to your other pages after they’ve decided they want to read more.

Line length

As words-per-line decrease (by increasing zoom or narrowing the viewport), line lengths grow more varied. Justifying text will cause uncomfortable amounts of whitespace. In fact, Text is not justified is explicitly mentioned in the WCAG Success Criterion 1.4.8.

The WCAG recommends a max line length of 80 characters (40 characters for CJK languages) as a AAA success criterion (SC 1.4.8). However, studies seem to have mixed results; some people find it easier to read lines around 90 characters long, while others struggle beyond the 50-character mark.

I think the WCAG over-simplified a complex issue to make this success criterion easier to understand. The guideline in its current form encourages wrapping lines at uneven lengths, since proportional text can take up varying amounts of space for a given character count. It would be better to specify an average character length, allowing lines with narrow characters (e.g. “I”, “l”) to exceed it. Then again, the AAA level was never intended to be a blanket requirement.

Some of my links display long link-text; short line lengths can break these link texts too much, which can slightly hurt readability. Of course, narrow viewports will obviously make short line lengths non-negotiable. I decided to give article bodies a width of 36em, which corresponds to just over 80 characters on most default stylesheets. I opted to use em instead of ch for consistency and for better compatibility with some uncommon browsers (NetSurf, Dillo, old versions of mainstream browsers, and others).

I also ensured that my site supports CSS overrides, window-resizing, zoom levels past 200%, and most “reading mode” implementations. This should help accommodate a wide range of line-length preferences while still looking accessible enough by default.

When setting max line lengths, use a CSS media query to ensure that printed versions of a page use the full page width. This should save some paper.

Code snippet 19 (CSS): I opted to wrap all max-width rules in a media query to ensure that they only get called for the screen media type:

@media screen {
  html {
    max-width: 45em;
    padding: 0 3%;
  }

  div[itemprop='articleBody'] {
    margin: auto;
    max-width: 36em;
  }
}

Small viewports

People read on a variety of viewport sizes. Page structure must be simple enough to handle these layouts smoothly.

Narrow viewports are popular

Not every phone has a giant screen: millions of people around the world use Web-enabled feature phones. The Jio Phone 2, for instance, is narrow enough to fall through a belt loop: it sports a screen that’s just over 3.6 cm (1.44 inches) wide. Furthermore, some programs sport browser windows in sidebars (c.f. Mozilla’s side view, Vivaldi Web Panels). Users who leverage floating or tiling windows rather than maximizing everything could use viewports of arbitrary dimensions.

Nowadays, even tiny smartwatches have built-in browsers; users who navigate to links in smartwatch message and email apps will use simplified browsers that fit on their wrists. Apple published a video about WebKit on WatchOS (here’s a text summary of the video, starting at the “New types of devices” section). The Apple Watch Series 6 has a viewport that’s 162 CSS pixels wide; it emulates an iPhone’s viewport and shows a zoomed-out version of the page unless the page includes a “device-adjust” meta tag, the same way phones emulate desktop viewports without a “viewport” meta tag. Samsung Internet is a popular option for Wear OS users, whose viewports are often just 150 CSS pixels.

Wide items

A single element wider than the viewport will trigger horizontal scrolling for the entire page. This is especially problematic for long pages that already require excessive vertical scrolling.

Long words, especially in headings, can trigger horizontal overflow. Test in a viewport that’s under 240 pixels wide (DPR=1) and observe any words that trail off of the edge of the screen. Add soft hyphens to these words using the  entity.

Most modern browsers support the hyphens CSS 3 property, but full automatic hyphenation is usually an overkill solution with a naive implementation. Automatic hyphenation will insert hyphens wherever it can, not necessarily between the best syllables. At the time of writing, humans are still better at hyphenating than most software implementations. I only enable full hyphenation on the narrowest of viewports.

Users employing machine translation will not benefit from your soft hyphens, so don’t expect them to always work as intended. Translation tools might also replace short words with long ones. Soft hyphens and automatic hyphenation are both flawed solutions, but I find soft hyphens to be less problematic.

Where long inline <code> elements can trigger horizontal scrolling, consider a scrollable <pre> element instead. Making a single element horizontally scrollable is far better than making the entire page scrollable in two dimensions. Hard-wrap code blocks so that they won’t horizontally scroll in most widescreen desktop browsers.

Be sure to test your hyphens with NVDA or Windows Narrator: these screen readers’ pronunciation of words can be disrupted by poorly-placed hyphens. Balancing the need to adapt to narrow screens against the need to sound correctly to a screen reader is a complex matter.³⁵ The best place to insert a hyphen is between compound words. For example, splitting “Firefighter” into “Fire-fighter” is quite safe. Beyond that, try listening to hyphenated words in NVDA to ensure they remain clear.

Keeping text together

Soft hyphens are great for splitting up text, but some text should stay together. The phrase “10 cm”, for instance, would flow poorly if “10” and “cm” appeared on separate lines. Splitting text becomes especially painful on narrow viewports. A non-breaking space keeps the surrounding text from being re-flowed. Use the   HTML entity instead of a space: 10 cm. Practical Typography by Matthew Butterick, describes where to use the non-breaking space in more detail.

One exception to the rules from Practical Typography: don’t use a non-breaking space if it would trigger two-dimensional scrolling on a narrow viewport. Between broken text and two-dimensional scrolling, broken text is the lesser evil. I personally set a cutoff at 2.5 cm (1 inch) at 125% zoom.

Pictures of text

You should only use pictures of text when the visual presentation of the text is part of the information you’re trying to convey. Always be sure to test how such an image looks on a narrow screen.

Images do not reflow their text. When the viewport is narrower than the image dimensions, you can instruct the browser to do one of three things:

Allow the image to exceed the viewport width, triggering two-dimensional scrolling for the whole page.
Shrink the image to fit the viewport, causing the text in the image to shrink with it.
Allow the image to horizontally overflow.

I already covered the first option in the prior subsection. If you expect viewers to read the text in the image and you don’t link an image transcript, the second option isn’t ideal. Overflow is almost never what we want.

The best compromise is to ensure that the image isn’t too wide, and can support large text on a narrow viewport. Lines of text in images should contain as few characters as possible. For a good example, see the “In defense of link underlines” section.

If the text needs to be readable, check its APCA levels. At large sizes, the contrast shouldn’t be too high; at small sizes, it shouldn’t be too low.

Indented elements

Most browser default stylesheets were not optimized for narrow viewports, so narrow-viewport optimization is one of few good reasons to override the defaults. The best example of widescreen bias in browser stylesheets is indentation.

The HTML standard’s section 4.4.4 covers blockquotes. It recommends placing a <blockquote> element inside a <figure> and citations in a <figcaption> to show a semantic relationship between a quotation and its citation.

Browser default stylesheets typically give <figure> elements extra margins on either side. <blockquote> elements have a large indent. Combining these two properties gives the final quotation an excessive visual indent, wasting precious vertical screen space. When quoted text contains list elements (<ol>, <dl>, <ul>), the indentation alone may fill most of a narrow viewport!

I chose to remove the margins in <figure> elements for quotations and code snippets. If you’re reading this page with its own stylesheet enabled, in a CSS 2 compliant browser, you might have noticed the blockquotes on it have a minimal indent and a thick border on the left rather than a full indent. These two adjustments allow blockquotes containing bulleted lists to fit on most narrow viewports, even when wrapped by a <figure> element.

Indented elements can be difficult to distinguish when nested. A <blockquote> may not be visible if it contains an <ol> or <ul>. My left-border approach resolves this ambiguity.

Another example: outside the Web, I prefer indenting code with tabs instead of spaces. Tab widths are user-configurable, while spaces aren’t. HTML pre-formatted code blocks, however, are best indented with two spaces. Default browser stylesheets typically represent tabs with an excessive indent, which can be annoying on narrow viewports.

Short viewports

Designers often use figures to “break up” their content, and provide negative space. This is good advice, but I don’t think people pay enough attention to the flipside: splitting up content with too many figures can make reading extremely painful on a short viewport. Design maxims usually lack nuance.

Small phones typically support display rotation. When phones switch to landscape-mode, vertical space becomes precious. Fixed elements (e.g. dickbars) become a major usability hazard. Ironically, the WCAG’s own interactive Techniques reference is a perfect example of how fixed elements impact usability on short screens.

When filtering criteria on the Quickref Reference page, a dickbar lists active filters. I increased the zoom level; you may have to add more filters to fill the screen with a smaller font.

Keeping the most important content above the fold (the part of the page that’s visible without scrolling) is hard on small screens. Nonetheless, it’s an important element of cognitive accessibility. Users may struggle to identify a page or navigate a site if the title and navigation links are below the fold. The WAI’s mobile accessibility guidelines share this recommendation.

Make important tasks and features on the site stand out and easy to find.

This includes:

[…]

Placing the tasks/features towards the top of the page so the user does not have to scroll to see them.

Placing the tasks/features toward the top of the content so assistive technology finds them quickly.

[…]

Including key tasks at a top level of the main navigation.

— Making Content Usable for People with Cognitive and Learning Disabilities, section 4.3.1: Make it Easy to Find the Most Important Tasks and Features of the Site

Spacing

The previous “small viewports” section may tempt you to make your content as dense as possible. Please don’t overdo it.

There’s an ideal range somewhere between “cramped” and “spaced-apart” content. Finding this range is difficult. The best way to resolve such difficult and subjective issues is to ask your readers for feedback, giving disproportionate weight to readers with under-represented needs (especially disabled readers).

Non-interactive space

Excessive indentation makes reading difficult on narrow viewports, but preserving some indentation is still useful.

For now, I’ve decided to keep some indentation on list elements (<ol>, <dl>, <ul>) since I often fill them with links (see this article’s table of contents for an example). This indentation provides important non-interactive negative space.

Readers with hand tremors depend on this space to scroll without accidentally selecting an interactive element; Axess Lab described the issue in Hand Tremors and the giant button problem. Readers who double-tap to jump or zoom can’t do so if there’s no screen region that’s “safe to tap”. Having clearly distinguished links also helps users decide safe places to tap the screen; see the section on link underlines for more information.

I made sure to leave enough non-interactive space in my homepage’s webring list to accommodate a 48 px tap target, with extra space in between.

Always make sure one non-interactive region exists on the screen at a time, 48 CSS pixels in either dimension; that’s the size of a tap target.

Tap targets

Tap targets should be at least 44 pixels tall and wide according to the WCAG; this is large enough to easily tap on a touchscreen. The WCAG makes an exception for inline targets, like links in a paragraph.

Google has more aggressive tap-target recommendations: it recommends raising the limit 48 px with with 8 px gaps, going so far as to make tap target size a ranking factor in search.

The edges of a touch screen are often tap-targets (the top edge might toggle navigation or scroll to the top, the bottom may have home/back buttons, and the right side may have a scrollbar), so keep elements slightly away from those. Keeping away from edges is doubly important on phones: they may have rounded edges that are easy to miss-tap, or reinforced cases that make the very edge of a screen difficult to reach.

On lists with many links, I had to find other ways to ensure adequate tap-target size and provide sufficient non-interactive space for readers with hand-tremors to scroll. Some examples:

The webmention list after this article separates links with timestamps and some paragraph spacing.
Some list items have links with extra padding. These include description terms (<dt>) and navigation elements, such as the table of contents or the site header and footer,
The posts list and the list of related articles at the beginning of one of my posts separates links with non-interactive text descriptions
This list separates two list-items containing links with a third list-item that lacks links.

Line spacing

Increasing the line-spacing a bit will make tap targets larger and improve comprehension by readers with cognitive disabilities. A WCAG AAA Success Criterion is to allow 1.5 space units between lines; the WAI’s Cognitive and Learning Disabilities Accessibility Task Force recommends changing this Success Criterion’s level, finding it too important to be relegated to AAA status.

Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

— WCAG 2.2, Success Criterion 1.4.8 Visual Presentation

Non-browsers: reading mode

Fully standards-compliant browsers aren’t the only programs people use. They also use “reading mode” tools and services.

Reading modes leverage article extractors such as Readability (integrated into Firefox, Epiphany, Brave, Vivaldi, and others), DOM Distiller (integrated into Chromium), Brave SpeedReader, and Trafilatura (powers a variety of tools and services). A host of other proprietary options exist: Diffbot powers services like Instapaper, Mozilla’s Pocket has its own secret parsers, and countless “send to e-reader” services have amassed loyal users. Safari’s proprietary fork of Readability has grown quite complex compared to upstream; Edge’s Immersive Reader is a mystery to me, with a problematic stylesheet.

I don’t recommend catering to each tool’s non-standard quirks. Studying their design reveals that they observe open standards, to varying degrees. Readability, DOM Distiller, and Trafilatura understand plain-old, semantic HTML (POSH).

POSH should be enough for most use-cases, but some authors want to go further. For example, they may want a byline or published date to show up in these modes.

Most extractors fetch these values using open standards for structured data. The most well-supported option is microformats (Readability is one of the few that supports the newer microformats2). Some support schema.org vocabularies in microdata or JSON-LD syntaxes, or Dublin Core vocabularies in RDFa. Most parse <meta> tags from the document <head>, but others don’t due to misuse and overly aggressive SEO.

Sorry, that was a lot of jargon for a single paragraph. Unfortunately, describing those terms is out of scope for this post. If you’d like to dive down this rabbit hole, read about the “Semantic Web”.

Some reading-mode implementations also support DPUB-ARIA, but I’d caution against using ARIA when POSH is sufficient: “bad ARIA” can be far more harmful to screen readers than “no ARIA”. Only use ARIA to fill in gaps left by POSH.

Again: avoid catering to non-standard implementations’ quirks, especially undocumented proprietary ones. Let’s not repeat the history of the browser wars. Remember that some implementations have bugs; consider reporting issues when one arises. More information about standard and non-standard behavior of reading modes is in the article Web Reading Mode: The non-standard rendering mode by Daniel Aleksandersen.

Reading modes aren’t the only non-browser user agents out there. Plain-text feed readers and link previewers are some other options. I singled out reading modes because of their widespread adoption and value. Decide which other kinds of agents are important to you (if any), and see if they expose a hole in your semantics.

Machine translation

Believe it or not, the entire world doesn’t speak your website’s languages. Browsers like Chromium, Microsoft Edge, and Safari have integrated machine translation to translate entire pages. Users can also leverage online website translators such as Google Translate or Bing. These “webpage translators” are far more complex than their plain-text predecessors.

Almost every word on your site can be re-written. Prepare for headings to change length, paragraphs to grow and shrink, or hyphenation to disappear. Your site’s layout should make sense even when the length of each textual element is changed.

Machines can’t reliably translate images of text, since OCR is error-prone. See the image transcripts section for remedies.

Incorrect spelling and poor grammar in an original work can reduce the accuracy of a machine-translated derivative. Be sure to proofread.

POSH helps translation engines

To ensure that pages get machine-translated properly, make proper use of semantic HTML. Daniel wrote about this topic too in Semantic markup improves the quality of machine-translated texts; I highly encourage giving his article a read.

Elements to pay close attention to include <code>, <samp>, <var>, <kbd>, <abbr>, and <address>. The semantic information conveyed by these elements supplies important context to translation algorithms.

Only after POSH is insufficient should you attempt to “override” behavior with the translate HTML attribute. Setting translate="no" or translate="yes" should override the behavior of standards-compliant translation engines. If you’re unsure whether or not to use a translate attribute, search the relevant word or phrase on Keybot to see how human translators approached it.

For example: machine translation will leave <code> and <samp> blocks as-is. Perhaps you could annotate comments within code with a translate="yes" attribute. However, translation engines should leave variables within those comments as-is.

Google’s style guide recommends annotating format placeholders in code blocks with the <var> element; consider doing so and adding a translate="yes" attribute to placeholder values, at your discretion. For an example, check this article’s code sample describing my PNG optimization pipeline. Most implementations do not yet support translate="yes" embedded inside untranslated blocks, but I’m counting on this changing.

Changing text direction

Consider the implications of translating between left-to-right (LTR) and right-to-left (RTL) languages. Do a search through your stylesheets for keywords like “left” and “right” to ensure that styles don’t depend too heavily on text direction. Once you’ve cleared the low-hanging fruit, try translating the page to a language like Arabic.

Websites following this page’s layout advice shouldn’t need much adjustment. Ahmed Shadeed’s RTL Styling 101 is a comprehensive guide to what can go wrong and how to fix issues.

Current limitations

Machine translation is always improving. Today, it has some limitations which I expect will be resolved with time.

translate="yes" attributes nested inside un-translated blocks (code snippets, blocks with translate="no", etc.) are not yet supported by most translation tools. It’s a relatively new attribute, so flaky support is understandable.

Machine translators often skip aria-label and aria-description. For this reason, authors prefer using aria-labelledby and aria-describedby instead.

Microsoft Edge is the only browser I know of to adjust text-direction during translation, but it breaks when faced with inline <code> and <span> elements.

Inaccessible default stylesheets

Simple sites should err on the side of respecting default stylesheets. With rare exceptions, there are only two times I feel comfortable overriding default stylesheets:

Gently adjusting a parameter rather than completely changing an element’s appearance. Typically, this involves adjusting dimensions.
Fundamentally altering an element’s appearance. I only feel comfortable doing this when the defaults are truly inaccessible, or clash with another accessibility enhancement I made.

My previous advice regarding line spacing and maximum line length fell in the first category. My approach to re-styling <blockquote> elements, adding borders, and using sans-serif fell in the latter category.

This section contains miscellaneous advice regarding the latter category of stylesheet overrides.

Monospace handling

By default, most browsers render monospace text at a reduced size. If you want your monospace text to be readable, set its font family to monospace, monospace (sic).

Font family alone is not enough to distinguish an element from its surroundings. For <pre>, <code>, and <samp> elements, I recommend supplementing the font family change with a soft border. As described in the “Color overrides and accessibility” section, borders are preferable to background colors because they don’t override the user-agent’s preferred foreground and background colors.

Finally, it’s important to distinguish <kbd> from <code>, <samp>, and regular body text.

Code snippet 20 (CSS): How I distinguish <code> and <samp>, <pre>, and <kbd> from each other and from body text.

code, kbd, samp {
  font-family: monospace, monospace;
}

pre,
:not(pre) > code, :not(pre) > samp {
  border: 1px solid;
}

/* Dark borders in text are harsh */
:not(pre) > code, :not(pre) > samp {
  border-color: #999;
}

kbd {
  font-weight: bold;
}

Focus indicators

The default focus indicators are hard to see in certain browsers (e.g. Firefox and WebKit), especially when the focused element already has a border. We can override them to make them more accessible.

Firefox 99’s default focus indicator, before and after my adjustments.

On one hand, users who need enhanced focus visibility may override the default focus indicators in their browser preferences; I’d like to support such overrides. On the other hand, relying on these customizations would violate the “accessible by default” directive. This would exclude Tor Browser and fingerprinting-averse readers, as well as anybody who has to borrow a machine or browser they don’t own or haven’t customized yet. This is another one of the few areas where I’d recommend overriding browser default stylesheets.

The WCAG Success Criterion 2.4.12 recommends making focus indicators 2 px thick. While this success criterion is only AAA-level, it’s easy enough to meet and beneficial enough to others that we should all meet it.

You can use :focus and :focus-visible to highlight selected and keyboard-focused elements, respectively. Take care to only alter styling, not behavior: only keyboard-focusable elements should receive outlines. Modern browser stylesheets use :focus-visible instead of :focus; old browsers only support :focus and re-style a subset of focusable elements. Your stylesheets should do the same, to match browser behavior.³⁶

Code snippet 21 (CSS): I do not re-style :focus when :focus-visible works, to match existing behavior. I also override :focus styling only on the subset of focusable elements that would normally show an outline. Based on the post :focus-visible and backwards compatibility by TPGi.

a:focus,
[tabindex]:focus {
  outline: 3px solid;
}

@supports selector(:focus-visible) {
  a:focus:not(:focus-visible),
  [tabindex]:focus:not(:focus-visible) {
    outline: none;
  }
}

:focus-visible {
  outline: 3px solid;
}

Update: Firefox 104 has adopted a much better 2-color focus indicator; supplying a custom indicator will be less important in 2023 once a Firefox ESR version above 104 becomes available.

This section focuses on ways to improve screen reader support that have not already been covered. The most important measures (semantic HTML, good alt-text and image context, correct spelling, etc.) have already been covered in previous sections.

Try reading your screen through a drinking straw for an hour to get an idea of the limited context that a blind user has. You simply cannot scan the entire page at a glance with a screenreader - you have to listen to the structure of it carefully and remember all that, or read through the entire thing to find stuff, unless there are explicit associations such as longdesc.

— Charles McCathieNevile, longdesc Re: Clarification of rational for deprecation…

Split elements and possessive hyperlinks

Some screen readers split up sections by HTML elements. This means HTML elements in the middle of a sentence will trigger pauses. The problem comes up frequently on sites that use excessive inline formatting.

This is especially concerning on my website, where I tend to hyperlink peoples’ names (a common practice on the IndieWeb): making names possessive with an “apostrophe + s” creates pronunciation issues. “Seirdy’s Home” could be read as “Seirdy. Link. S. Home” if the word “Seirdy” is a hyperlink.

A workaround is to use the “text” ARIA role to remove the semantics of elements. This workaround doesn’t work in certain screen readers, including Orca, so don’t count on it.

Code snippet 22 (HTML): An example of using role="text" to prevent splitting in a multi-line heading. By Hampus Sethfords from Axess Lab, Text Splitting Causes Screen Reader Problems

<h1>
  <span role="text">Digital accessibility, <br>
    for everyone.
  </span>
</h1>

If you’re unfamiliar with ARIA, always remember the First Rule of ARIA: No ARIA is better than Bad ARIA. ARIA exposes a host of accessibility hazards when used improperly, so only use this approach when there’s no good alternative. Furthermore, role="text" isn’t actually standard ARIA; its proposed inclusion into the ARIA specification was controversial. See issue 870 of WAI-ARIA for some problems with it.

The best solution for possessive nouns is to include the “apostrophe + s” inside the hyperlink.

Future users

The number of people using your site in the future is hopefully greater than the number of people using your site in the present. Accordingly, your pages need to work correctly in the future.

Much of this section borrows from the article This Page is Designed to Last; I highly recommend giving it a read.

Third parties

I’ve already made a privacy and performance case against third-party resources in an earlier “Third-party content” subsection. Another reason to avoid third-party resources is longevity. Third-party scripts, styles, frames, and images all depend on someone else’s host keeping the resource available at the same URL; over time, these tend to disappear. Sticking to first-party content reduces these points of failure.

Third-party content is especially problematic when it’s hosted on modest hardware. If your site “goes viral”, your traffic could take down the third-party site or prompt them to disable hotlinking. Serve assets yourself.

Dead links

On the same note: your internal and external links to other pages need to change with time. Use a broken-link checker regularly to ensure that your content stays alive. I recommend checkers like lychee and htmltest because they can cache results. My site has a bit under two thousand links at the time of writing; checking all of them at once would be exhausting, but using a week-long cache allows me to split this over seven days.

Whenever you link to a page, try to archive a snapshot of it. The Wayback Machine, archive.today, and Ghostarchive are popular options. Archival is one of the few times I recommend using a third-party service; a service like the Wayback Machine will likely outlive your website. That being said, self-hosted solutions like ArchiveBox do exist.

If you link often enough, archival might be something worth automating. The Wayback Machine offers an API, and allows registered users to mass-archive archive all outlinks in a page.

Reproducibility

Imagine your typical “modern” website’s deployment pipeline. It requires thousands of dependencies to build. It uses bespoke tools to deploy to a service provider with a custom non-standard stack (e.g. Fly.io, Heroku, Cloudflare Workers, AWS Lambda).

Ten years from now, how much of this will still work?

Try to ensure that your website can be archived, and/or easily re-built and served on an ordinary server. This way, your work can still be made accessible after you’re gone. For example: all my site requires to build is a tarball of statically-linked binaries, a POSIX shell, and a decent Make implementation (bmake and GNU make work) to build; see my build manifest. To serve, it just needs a static web server.

Testing

If your site is simple enough, it should automatically handle the vast majority of edge-cases. Different devices and browsers all have their quirks, but they generally have one thing in common: they understand POSH.

No matter how simple a page is, I don’t think simplicity eliminates the need for testing. I outlined the need to analyze actual run-time behavior in another post exploring how code alone doesn’t give the full picture.

Automated tests

Automated tests—especially accessibility tests—are a supplement to manual tests, not a replacement for them. Think of them as time-savers that bring up issues for further research, containing both false positives and false negatives.

These are the tools I use regularly. I’ve deliberately excluded tools that would be redundant.³⁸

Nu HTML checker: The W3C’s official HTML validator. Valid HTML ensures broader compatibility with a wider range of agents. Note that it uses Jigsaw under the hood for CSS validation, which hasn’t implemented support for certain CSS features I’ve recommended elsewhere on this page. Watch out for false positives.
axe-core: The current standard in accessibility testing. Most website auditors that run accessibility checks use this library under the hood.
Lighthouse: An auditing tool by Google that uses the DevTools protocol in any Chromium-based browser. Skip the “Accessibility” category, since it just runs a subset of axe-core’s audits. The most useful audit is the tap target size check in its “SEO” category. It’s also convenient for measuring performance with CPU throttling, to simulate low-end mobile devices. Note that your sandbox CSP directive will need to include allow-scripts for it to function.
Webhint: Similar to Lighthouse. Again, you can ignore the accessibility audits if you already use axe-core. I personally disagree with some of its hints: the “unneeded HTTP headers” hint ignores the fact that the CSP can have an effect on non-hypertext assets, the “HTTP cache” hint has an unreasonable bias against caching HTML, and the “Correct Content-Type header” recommends charset attributes a bit too aggressively.³⁹
IBM Equal Access Accessibility Checker: Has a scope similar to axe-core. Its “Sensory Characteristics” audit seems unique.
AInspector: A Firefox addon that displays audits in the sidebar. In my experience, it does have many false-positives (especially regarding DPUB-ARIA; see issue 3 for the OpenA11y Evaluation Library); however, it has caught a few issues missed by all other tools.
Firefox’s Accessibility Inspector: Supports some very basic audits for contrast, keyboard access, and text labels. The accessibility tree is also a useful way to ensure that elements have accessible names. The keyboard audits have false-positives on non-interactive elements with scrollable overflow, which need to be focusable.
Chromium’s CSS Overview: Can show some basic accessibility violations, including contrast violations. I recommend enabling the APCA-based contrast algorithm in the DevTools experimental settings first. Note that this uses an earlier version of APCA and does not account for contrast that is too high.
testssl.sh (cli) OR SSL Labs’ SSL Server Test (web, proprietary): Basically equivalent tools for auditing your TLS setup. I prefer testssl.sh.
Webbkoll: Basic security checks, focusing on HTTP headers. I consider it a spiritual successor to Mozilla’s HTTP Observatory.
Check Your Website: Slower, more in-depth website checks with an emphasis on security. It covers name server configurations, DNSSEC, DANE, email DNS records, MTA-STS, well-known paths, redirects, certificate transparency, subresource integrity, caching, and well-known ports.
Internet.nl: Possibly the harshest website security and modernity check on this list, and my personal favorite. Checks for IPv6 reachability, modern cipher suites and key-exchange params, DNSSEC, and RPKI. It also has handy tools to check an email server, and your own personal connection.

Unorthodox tests

In addition to standard testing, I recommend testing with unorthodox setups that are unlikely to be found in the wild. If a website doesn’t work well in one of these tests, there’s a good chance that it uses an advanced Web feature that can serve as a point of failure in other cases. Simple sites should be able to look good in a variety of situations out of the box.

Your page should easily pass the harshest of tests without any extra effort if its HTML meets basic standards for well-written code (overlooking bad formatting and a lack of comments). Even if you use a complex static site generator, the final HTML should be simple, readable, and semantic.

These tests begin reasonably, but gradually grow absurd. Once again, use your judgement.

Test in all three major browser engines: Blink, Gecko, and WebKit.
Evaluate the heaviness and complexity of your scripts (if any) by testing with your browser’s JIT compilation disabled.⁴⁰
Test using the Tor Browser’s safest security level enabled (disables JS and other features).
Load just the HTML. No CSS, no images, etc. Try loading without inline CSS as well for good measure.
Print some pages in black-and-white, preferably with a simple laser printer.
Test with assistive technologies such as screen readers, magnifiers, and switch controls.
Ensure the page responds correctly to browser zoom. No sizes or dimensions should remain “fixed” across zoom levels.
Test keyboard navigability with the Tab key and caret navigation. Even without specifying tab indexes, tab selection should follow a logical order if you keep the layout simple.
Test in textual browsers: lynx, links, w3m, ELinks, edbrowse, EWW, Netrik, etc.
Test in an online website translator tool.
Test your feeds (RSS, Atom, JSON, etc.) in multiple readers to ensure they render your markup correctly. Microsoft Outlook uses Word’s Internet-Explorer-based HTML engine to display these contents; Newsboat uses its own custom HTML renderer. Most don’t support CSS.
Read the (prettified and indented) HTML source itself and parse it with your brain. See if anything seems illogical or unnecessary. Imagine giving someone a printout of your page’s <body> along with a whiteboard. If they have a basic knowledge of HTML tags, would they be able to draw something resembling your website?
Test with unorthodox graphical browser engines, like NetSurf, Dillo, Servo, or the Serenity OS browser.
Test how your page renders in ancient browsers, like Netscape Navigator or Tkhtml. Use a TLS terminator or serve over HTTP from localhost.
Try printing out your page in black-and-white from an unorthodox graphical browser.
Download your webpage and test how multiple word processors render and generate PDFs from it.⁴¹
Combine conversion tools. Combine an HTML-to-EPUB converter and an EPUB-to-PDF converter, or stack multiple article-extraction utilities. Be creative and enjoy breaking your site. When something breaks, examine the breakage and see if it’s caused by an issue in your markup, or a CSS feature with an equivalent alternative.
Build a time machine. Travel decades—or perhaps centuries—into the future. Keep going forward until the WWW is breathing its last breath. Test your site on future browsers. Figuring out how to transfer your files onto their computers might take some time, but you have a time machine so that shouldn’t be too hard. When you finish, go back in time to meet Benjamin Franklin.

I’m still on step 17, trying to find new ways to break this page. If you come up with a new test, please share it.

This page in the SerenityOS web browser. TLS 1.2 support isn’t finished yet; I loaded it from a mirror with a compatible cipher suite.

Future updates

This article is, and will probably always be, an ongoing work-in-progress. Some areas I have yet to cover:

How purely-cosmetic animations harm readers with learning and cognitive disabilities (e.g. attention disorders).
How exposing new content on hover is inaccessible to users with magnifiers, hand tremors, switch access, and touchscreens.
Notes on improving support for braille displays.
How to work well with caret-based navigation.
How to choose phrasings such that some meaning can be inferred without understanding numbers, for dyscalculic readers. This is more applicable to posts whose main focus is not mathematical or quantitative.
How to include mathematical notation in a way that maximizes compatibility and accessibility.
Keypad-based navigation on feature phones (c.f. KaiOS devices).
How keyboard navigation can be altered by assistive tools such as screen readers.
How to avoid relying too much on formatting, for user agents that display unformatted text (e.g. textual feed readers like Newsboat)
Elaboration on how authors should delegate much of their formatting to the user agent, and how CSS resets are a symptom of a failure to do so.
Keyboard-driven browsers and extensions. Qutebrowser, Luakit, visurf, Tridactyl, etc.
Ways to support non-mainstream and older browsers by supporting subsets of specifications and using progressive enhancement.
Avoiding _blank targets in URLs unless absolutely necessary.
Ways to improve comprehension by readers who struggle to understand non-literal language (certain cognitive disabilities, non-native speakers unfamiliar with idioms, etc.). I might wait until the WAI-Adapt: Help and Support Module draft specification matures and its vocabularies gain adoption before going in depth.
Spatial navigation
The principle of redundant coding
Other accessible writing tips, maybe after I get a copy of Writing Is Designing by Michael Metts and Andy Welfe. A relevant excerpt on writing accessibly is on A List Apart.
Rules for descriptive link text, for screen reader navigation and for user-agents that display links as footnotes (e.g. some textual browsers with the dump flag).

Conclusion

There are so many ways to read a page; authors typically cater only to the mainstream ones. Some ways to read a page I covered include:

Screen readers
Switch access
Navigating with the Tab key
Caret navigation
Navigating with hand-tremors
Content extractors or “Reader Mode”
Low-bandwidth connections
Unreliable, lossy connections
Metered connections
Hostile networks
Using in-page search
Downloading offline copies
Extra-narrow viewports
Mobile devices in landscape mode
Frequent viewport-resizers
Printouts with rationed paper or ink
Textual browsers
Disabling JavaScript
The Tor Browser’s “Safest” mode
Non-mainstream browser engines
Browsing without CSS
Altering, injecting, or replacing CSS
Non-default color palettes
Forced color palettes
Adblockers, with various filter-lists
Blocking third-parties
Disabling frames, images, and cookies
User-selected custom fonts
Machine translators

Each of these may be dismissed as a “niche”, especially given a profit motive (or worse, a growth imperative). Yet many niches add up to a large population. Every person who grows old becomes disabled; every long-distance traveller experiences poor connections.

Moreover, I don’t think that the size of a disadvantaged population should always matter. I understand weighing population size if you have to make a trade-off between two conflicting special needs, but I don’t think the aesthetic preferences of the majority are more important than supporting a disadvantaged minority.

Before you throw up your hands and decide you can’t help everyone, take another skim through this page. Notice how much repetition exists between sections. Nearly every bullet-point I listed benefits tremendously from plain-old, semantic HTML (POSH). If your page is usable with nothing but POSH, you’ve done half the work already.

Acknowledgements and further reading

Initial versions of this page were inspired by existing advocates for web minimalism.

Parts of this page can be thought of as an extension to David Copeland’s principles of Brutalist Web Design.

Raw content true to its construction:

Content is readable on all reasonable screens and devices.

Only hyperlinks and buttons respond to clicks.

Hyperlinks are underlined and buttons look like buttons.

The back button works as expected.

View content by scrolling.

Decoration when needed and no unrelated content.

Performance is a feature.

— David Copeland, Brutalist Web Design

The 250kb club gathers websites at or under 250kb, and also rewards websites that have a high ratio of content size to total size.

The 10KB Club did the same with a 10kb homepage budget (excluding favicons and webmanifest icons). It also had guidelines for noteworthiness, to avoid low-hanging fruit like mostly-blank pages.

My favorite website club has to be the XHTML Club by Bradley Taunt, the creator of the original 1mb.club.

Also see Motherfucking Website. Motherfucking Website inspired several unofficial sequels that tried to gently improve upon it. My favorite is Best Motherfucking Website.

The Web Bloat Score calculator is a JavaScript app that compares a page’s size with the size of a PNG screenshot of the full page content, encouraging site owners to minimize the ratio of the two.

One resource I found useful (that eventually featured this article!) was the “Your page content” section of Your Personal Website by Bill Dietrich.

If you’ve got some time on your hands, I highly recommend reading the Web Content Accessibility Guidelines (WCAG) 2.2. The WCAG 2 standard is technology-neutral, so it doesn’t contain Web-specific advice. For that, check the How to Meet WCAG (Quick Reference). It combines the WCAG with its supplementary list of techniques.

The WCAG are an excellent starting point for learning about accessibility, but make for a poor stopping point. Much of the content on this page simply isn’t covered by the WCAG. One of my favorite resources for learning about what the WCAG doesn’t cover is Axess Lab’s articles.

I’ve learned about a great number of underrepresented ways to browse from the Fediverse, particularly from this subthread asking people to share (requires JavaScript; plaintext mirror). Several responses informed updates to this page.

An early version of this article received useful responses when I posted it to Lobsters; I incorporated some feedback shortly afterward.

A special thanks goes out to GothAlice for the questions she answered in #webdev on Libera.Chat.

Many addons function by injecting content into pages; this significantly weakens many aspects of the browser security model (e.g. site and origin isolation) and should be avoided if at all possible. For content such as public key fingerprints, I recommend setting a blank sandbox directive even if it means breaking these addons. ↩︎
Some addons will have reduced functionality; for instance, Tridactyl can’t create an <iframe> for its command window. I consider this to be worthwhile since the most important functionality is still available, and because authors shouldn’t feel compelled to support security weakening. I say this as someone who uses Tridactyl often.

Moreover, the sandbox directive exposes some bugs in WebKit (i.e. Safari and most GTK-based browsers). On content governed by a sandbox directive without the allow-same origin and allow-scripts directives, some WebKit browser features won’t work. One example is media controls. One page on my site has an audio element; I added allow-scripts to that page so it will work in WebKit-based browsers. WebKit bug 237281 documents the general issue; WebKit bug 225865 and WebKit bug 218086 document specific instances. ↩︎
Here’s an overview of PE and my favorite write-up on the subject. ↩︎
Each of these flows can be visually displayed using a breadcrumbs list; doing so can meet the WCAG Success Criterion 2.4.8: Location. I opted to meet the criterion a different way. Since all my pages are linked by my site’s global navigation or my “posts” page (also in the global navigation), I just used aria-current and made the currently-relevant entry in my global navigation a <strong> element. However, I later introduced breadcrumbs anyway because I don’t think a simple <strong> element conveys this information clearly enough. ↩︎
One example is a utility class for the image-rendering property. I use it on images that look better with pixelated rendering. This is a property of the image contents, not the image semantics or placement; a class makes sense. ↩︎
Technically, this is only true in idealized circumstances and if you have 0-RTT enabled. If your requests are not idempotent, you probably should stick with 1-RTT. A TCP handshake actually involves one additional round-trip, so you could probably start off with a 30-kilobyte window on HTTP/2 with 0-RTT. HTTP/3 servers with 0-RTT do use a true “zero-round-trip” connection, but they use QUIC instead of TCP. QUIC uses similar sizing logic but I’m not sure about the exact values.

High-Performance Browser Networking by Ilya Grigorik gives a great introduction to how TCP works, if you’d like more details. ↩︎
This one-kilobyte limit is a semi-arbitrary rule-of-thumb I came up with. It’s a simple number easier to work with than the number of bytes remaining in the earliest contentful round-trip, yet it typically falls within that quota. ↩︎
HPACK and QPACK header compression includes dictionaries containing common header names, and some common header values; HPACK lists them in “Appendix A” of RFC 7541. If these dictionaries contain a given header name or name-value pair, the header name/value’s effective size can be reduced to a single byte. If a header has a value that isn’t covered by the table, consider minifying it by removing unnecessary whitespace.

Remember that if your golden first kilobyte already lists all essential resources, these could be considered premature optimizations. Real bottlenecks lie elsewhere. ↩︎
Ironically, that page doesn’t load the main text without JavaScript despite citing a JavaScript requirement as a downside. If you can’t load the page, the same issues with infinte scroll are outlined in the “Accessibility concerns for infinite scroll” section of Infinite Scroll without Layout Shifts by Addy Osmani. ↩︎
The benefits of containment are especially noticeable when injecting styles into a page. “Dark mode” and “userstyle” extensions perform noticeably better when enough elements receive layout and paint containment. Containment allows browsers to handle changes to an element independently of the rest of the DOM. ↩︎
See the “Lighthouse” entry in the “Automated tests” section. Lighthouse benchmarks my machine with a score of around 1320; with that score, it recommends throttling my machine by just under 3.1x to simulate a target mobile device. The Chromium team came up with the throttling formula under idealized conditions (the phone isn’t overheating, battery-saver mode is off, etc); I go further and throttle between 12x and 13x, still shooting for a perfect performance score. This article is the largest page on my site; it often gets a perfect performance score (100) with my stylesheet enabled, but never reaches 100 when I disable CSS containment or remove my stylesheet. ↩︎
Version 12.0 of the Tor Browser was a rebase from Firefox 91.x ESR to Firefox 102.x ESR. It was released more than two months after Firefox 91.x ESR reached End Of Life, almost 16 months after Firefox 102.0 was initially released. ↩︎
KaiOS is the third most popular mobile OS, after Android and iOS; it’s the second-most popular mobile OS in India. Firefox updates are tied to operating-system updates in KaiOS. Since most manufacturers don’t support KaiOS devices for long (they’re budget feature phones for emerging markets), don’t expect KaiOS users to mass-upgrade their ancient Firefox versions anytime soon. The last KaiOS Firefox update was from version 49 to 84, almost one year after Firefox 84 came out. ↩︎
The most recent such removal was the Document Outline algorithm. For years after it was standardized, the Document Outline was ignored by every browser engine. Finally, the WHATWG replaced the Document Outline algorithm with a revised version that involved multiple heading levels. The revised version matches what user-agents and good authors have been doing for decades. ↩︎
Can I Use is operated by a single person; check their site footer for donation information. ↩︎
There’s actually a surprising amount of overlap between iOS Lockdown mode and the Tor Browser’s security levels. Both disable WebGL, WebRTC, MathML, remote fonts, and JIT compilation. I recommend avoiding reliance features dangerous enough for privacy- and security-conscious users to disable. ↩︎
Firefox users can enable “find as you type” by toggling a preference in about:config. Chromium (and derivatives) users can install an extension like Type-ahead-find; note that it requires full-page access and performs script injection to work. ↩︎
Iterating through a list of font names to see if each one is available on a user’s system is a slow but effective way to determine installed fonts without being granted permission to use the Font Access API. BrowserLeaks has a demo of this approach. Warning: the page might hog your CPU for a while. ↩︎
Decoration is more than cosmetic. The color overrides and accessibility sub-section describes how some decorations, like borders, improve accessibility. ↩︎
uBlock Origin is a popular browser extension for content filtering; it’s the most popular Firefox add-on. It includes a built-in feature to block all media elements exceeding a user-configurable size threshold. ↩︎
WebAIM and the University of Illinois recommend 100 characters; Tangaru recommends an even smaller limit of 80 characters. I sometimes exceed 100 characters for detailed images but usually stay below 80. ↩︎
Browser support for displaying alt-text in place of broken images seems good. More information about support for alt-text exposure can be found on Alternative Text for CSS Generated Content. That post seems to indicate that Firefox 81 on macOS 10.15 didn’t display alt-text, but users report correct alt-text display in more recent Firefox versions. ↩︎
Once it gains basic support across all browsers and screen readers, I might recommend using aria-details instead of aria-describedby for more complex descriptions. At the time of writing, aria-details is only supported by JAWS. WAI-ARIA 1.2 describes aria-details with an example similar to the one I gave in code snippet 5. ↩︎
Since WHCM sets colors independently of explicitly-defined ARIA roles, it’s a good way to test adherence to the First Rule of ARIA. ↩︎
An earlier version of this article recommended a background of #111, but two helpful readers sensitive to overstimulation and halation found #191919 preferable. ↩︎
Lē also shared their experience in A11y Rules, one of my favorite podcasts ↩︎
When making an earlier version of this site’s dark-mode color palette, I made the mistake of exclusively testing in cheap or poorly-calibrated displays with bright black points. I mistakenly thought that my #0b0b0b background was bright enough to prevent halation. Only after testing on a better screen did I realize that it would look almost completely black; I subsequently lightened the background to #111 to strike a good balance. ↩︎
Practical Typography only renders invisible text without JavaScript. You can use a textual browser, screen reader, copy-paste the page contents elsewhere, use a reader-mode implementation, or “view source” to read it without enabling scripts. All of these options will ironically override the carefully-crafted typography of this website about typography.

I find Practical Typography quite useful for printed works, and incorporated a more moderate version of its advice on soft-hyphens into this page. With a few such exceptions, I generally find it to be poor advice for Web content. ↩︎
I can’t confirm if this is also an issue on VoiceOver for macOS, because I haven’t borrowed the hardware required to test it. ↩︎
I linked to a snapshot from the Wayback Machine in hopes that the live version of the Smashing Magazine site will get fixed. ↩︎
libavif links against libaom, librav1e, and/or libsvtav1 to perform AVIF encoding and decoding. libaom is best for this use-case, particularly since libaom can link against libjxl to use its Butteraugli distortion metric. This lets libaom optimize the perceptual quality of lossy encodes much more accurately. ↩︎
I find it quite odd that Microsoft Edge doesn’t support AVIF. Chromium has supported AVIF for a long time, and Edge is based on Chromium. AVIF is a royalty-free format; I don’t know why Microsoft would remove support for it, especially since Microsoft allows adding AVIF support to Windows. I think Edge also removed Chromium’s experimental, off-by-default support for JPEG-XL. ↩︎
I say that a skip link is useful to reduce the amount of Tab keystrokes required, but I don’t know a good “threshold number” to signify “too many keystrokes”. If it takes ten keystrokes to reach the main content, it’s probably time to add a skip-link. ↩︎
ATs typically let users navigate by headings, landmarks, paragraphs, and links. Most users prefer skipping article content with heading-based navigation. Keyboard users can bind different keys to different modes of navigation, but mobile users can only access one navigation mode at a time.

Mobile users wishing to temporarily switch modes have to stop, change their navigation mode, perform a navigation gesture, and switch back. Mobile users trying to skim an article don’t always find this worth the effort and sometimes stick to heading-based navigation even when a different mode would be optimal. ↩︎
At least, it will be until NVDA bug 9343 gets resolved. ↩︎
If you’d like to learn more, A guide to designing accessible, WCAG-compliant focus indicators by Sara Soueidan has far more details on making accessible focus indicators. ↩︎
Screen readers aren’t alone here. Several programs strip inline formatting: certain feed readers, search result snippets, and textual browsers invoked with the -dump flag are some examples I use every day. ↩︎
I excluded PageSpeed Insights and GTMetrix since those are mostly covered by Lighthouse. I excluded Hardenize and CryptCheck, since their scope is covered by Internet.nl.

I excluded Security Headers, since its approach seems to be recommending headers regardless of whether or not they are necessary. It penalizes forgoing the Permissions-Policy header even if the CSP blocks script loading and execution; see Security Headers issue #103. I personally find the Permissions-Policy header quite problematic, as I noted in August 2021 on webappsec-permissions-policy issue #189. Finally, Security Headers doesn’t have in-depth checks of the values of headers; Internet.nl does a much better job of that. Security should be a thoughtful process, not a checklist. ↩︎
My site caches HTML and RSS feed for a few hours. I disagree with webhint’s recommendations against this: cache durations should be based on request rates and how often a resource is updated. I also disagree with some of its content-type recommendations: you don’t need to declare UTF-8 charsets for SVG content-type headers if the SVG is ASCII-only and called from a UTF-8 HTML document. You gain nothing but header bloat by doing so. ↩︎
Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnerabilities. In Firefox, navigate to about:config and toggle some flags under javascript.options.
Code snippet 12: Firefox prefs to turn off JIT compilation
```
javascript.options.ion
javascript.options.baselinejit
javascript.options.native_regexp
javascript.options.asmjs
javascript.options.wasm
```
In Chromium and derivatives, run the browser with --js-flags='--jitless'; in the Tor Browser, set the security level to “Safer”. ↩︎
LibreOffice can also render HTML but has extremely limited support for CSS. OnlyOffice seems to work best, but doesn’t load images. If your page is CSS-optional, it should look fine in both. ↩︎

Resilient Git, Part 1: Hydra Hosting

seirdy@seirdy.one (Seirdy) — Thu, 19 Nov 2020 02:31:15 +0000

This is Part 1 of a series called Resilient Git

Introduction

The most important part of a project is its code. Resilient projects should have their code in multiple places of equal weight so that work continues normally if a single remote goes down.

Many projects already do something similar: they have one “primary” remote and several mirrors. I’m suggesting something different. Treating a remote as a “mirror” implies that the remote is a second-class citizen. Mirrors are often out of date and aren’t usually the preferred place to fetch code. Instead of setting up a primary remote and mirrors, I propose hydra hosting: setting up multiple primary remotes of equal status and pushing to/fetching from them in parallel.

Having multiple primary remotes of equal status might sound like a bad idea. If there are multiple remotes, how do people know which one to use? Where do they file bug reports, get code, or send patches? Do maintainers need to check multiple places?

No. Of course not. A good distributed system should automatically keep its nodes in sync to avoid the hassle of checking multiple places for updates.

Adding remotes

This process should pretty straightforward. You can run git remote add (see git-remote(1)) or edit your repo’s .git/config directly:

[remote "origin"]
	url = git@git.sr.ht:~seirdy/seirdy.one
	fetch = +refs/heads/*:refs/remotes/origin/*
[remote "gl_upstream"]
	url = git@gitlab.com:seirdy/seirdy.one.git
	fetch = +refs/heads/*:refs/remotes/gl_upstream/*
[remote "gh_upstream"]
	url = git@github.com:seirdy/seirdy.one.git
	fetch = +refs/heads/*:refs/remotes/gh_upstream/*

If that’s too much work—a perfectly understandable complaint—automating the process is trivial. Here’s an example from my dotfiles.

Seamless pushing and pulling

Having multiple remotes is fine, but pushing to and fetching from all of them can be slow. Two simple git aliases fix that:

[alias]
	pushall = !git remote | grep -E 'origin|upstream' | xargs -L1 -P 0 git push --all --follow-tags
	fetchall = !git remote | grep -E 'origin|upstream' | xargs -L1 -P 0 git fetch

Now, git pushall and git fetchall will push to and fetch from all remotes in parallel, respectively. Only one remote needs to be online for project members to keep working.

Advertising remotes

I’d recommend advertising at least three remotes in your README: your personal favorite and two determined by popularity. Tell users to run git remote set-url to switch remote locations if one goes down.

Before you ask…

Q: Why not use a cloud service to automate mirroring?

A: Such a setup depends upon the cloud service and a primary repo for that service to watch, defeating the purpose (resiliency). Hydra hosting automates this without introducing new tools, dependencies, or closed platforms to the mix.

Q: What about issues, patches, etc.?

A: Stay tuned for Parts 2 and 3, coming soon to a weblog/gemlog near you™.

Q: Why did you call this “hydra hosting”?

A: It’s a reference to the Hydra of Lerna from Greek Mythology, famous for keeping its brain in a nested RAID array to protect against disk failures and beheading. It could also be a reference to a fictional organization of the same name from Marvel Comics named after the Greek monster for similar reasons.

Resilient Git, Part 0: Introduction

seirdy@seirdy.one (Seirdy) — Tue, 17 Nov 2020 21:13:03 +0000

Recently, GitHub re-instated the youtube-dl git repository after following a takedown request by the RIAA under the DMCA. Shortly after the takedown, many members of the community showed great interest in “decentralizing git” and setting up a more resilient forge. What many of these people fail to understand is that the Git-based project setup is designed to support decentralization by being fully distributed.

Following the drama, I’m putting together a multi-part guide on how to leverage the decentralized, distributed nature of git and its ecosystem. I made every effort to include all parts of a typical project.

I’ll update this post as I add articles to the series. At the moment, I’ve planned to write the following articles:

Hydra Hosting: repository hosting.
Community feedback (issues, support, etc.)
Community contributions (patches)
CI/CD
Distribution

The result of the workflows this series covers will be minimal dependence on outside parties; all members of the community will easily be able to get a copy of the software, its code, development history, issues, and patches offline on their machines with implementation-neutral open standards. Following open standards is the killer feature: nothing in this workflow depends on a specific platform (GitHub, GitLab, Gitea, Bitbucket, Docker, Nix, Jenkins, etc.), almost eliminating your project’s “bus factor”.

Providing a way to get everything offline, in a format that won’t go obsolete if a project dies, is the key to a resilient git workflow.

Before we start: FAQ

Q: What level of experience does this series expect?

A: Basic knowledge of git, and a very basic understanding of email. If you have a few repos and can use a third-party email client, you’re good.

Q: Do you think you can get hundreds and thousands of people to drop Git{Hub,Lab,tea} and use a different workflow?

A: No, but that would be nice. If only five people who read this series give this workflow a spin and two of them like it and keep using it, I’d be happy.

Q: Is this workflow more difficult than my current one?

A: “Difficult” is subjective. I recommend TRYING this before jumping to conclusions (or worse, sharing those conclusions with others before they have a chance to try it).

Q: I’m not interested in trying anything new, no matter what the benefits are.

A: First of all, that wasn’t a question. Second, this series isn’t for you. You should not read this. I recommend doing literally anything else.

Next: Resilient Git, Part 1: Hydra Hosting

Hello World

seirdy@seirdy.one (Seirdy) — Mon, 02 Nov 2020 19:06:56 +0000

Hello, world! This is my first post.

It looks like I managed to somehow get this site working. You can look forward to a few more posts in the coming weeks.

Posts on Seirdy’s Home

Post-OCSP certificate revocation in the Web PKI

Introduction

Motivation

Target audience

xkcd comic: Average Familiarity

Comic transcript

Table of Contents

Certificate Revocation Lists

Online Certificate Status Protocol (OCSP)

OCSP Stapling and Must-Staple

OCSP Expect-Staple

Poor implementations

Querying CRL shards

Client-side summarized CRLs

Google’s approach: CRLSets

Mozilla’s approach: CRLite

Apple’s approach: valid.apple.com

Shortcomings of summarized CRLs

Let’s Revoke

ACME Renewal Information (ARI)

Short-lived certificates

ACME-STAR

Delegated credentials

ACME-STAR Delegation

My proposals

Eliminating single points of failure

Enforcing short-term certificates

Incremental change: shorter long-lived certificates

Requesting a shorter lifetime

Conclusion

Aside: browser wars

Ack­nowledge­ments

Takeaways from the Google Content Warehouse API documentation leak

Introduction

Thoughts on individual ranking factors

Small personal sites and commercial sites

Font size‽

Chrome user data

Manual review

Bias against new sites

Truncation

Author name mismatches

A cold shower: this isn’t as significant as some SEOs claim

Conclusion: my takeaways

MDN’s AI Help and lucid lies

Introduction

Conflating common and uncommon angles

Example: assistive technology performance tips

Conflating broad and specific questions

Example: asking about specific page speed metrics

Blurring the lines classifying LLM lies

Combined example: specific information, conflation, and hallucination.

Conclusion

Conclusions about MDN’s AI Help

Implications for LLMs as a whole

Ack­nowledge­ments

Proposal: an HTML element for spoilers

Introduction

Table of Contents

Prior art

Comparison with details

Semantics

Behavior

Presentation

Use-cases

Potential attributes

Considerations

Considerations for user-agents

Considerations for authors

Privacy considerations

Further work

Snarky thoughts: conflicts of interests

Ack­nowledge­ments

De-federating P92

Privacy concerns

Incompatible values and complicity

My Fediverse blocklists

Table of Contents

How Tier-0 and FediNuke work

Acknowledgements

Acknowledgements

Comparison with `details`

Acknowledgements

Introduction

Introduction