Motivation and Explainer

This document describes why we feel it is important to enable browser vendors and standards designers to experiment on the web, and how we believe it is possible to do safely.

Note: If you’re a developer interested in how to use origin trials, see this guide. New origin trials are announced on developers.google.com/web/updates, and a list of active trials are posted here.

The problem

It is well known that iteration and fast feedback cycles are key to designing high quality software. The process of development is one of designing interfaces and abstractions, attempting to use them or have your friends and colleagues use them, realizing they’re leaky or broken, fixing those problems, and then repeating the cycle.

This works great in an environment where you can cycle through the process many times, but this process is very challenging in some cases, especially when:

Interestingly, the web is approximately a worst case example of all of the above:

The resulting situation is one in which features shipping on the web take a long time to design, and are then frozen into standards well before they have been significantly road-tested by real web developers.

This has resulted in a number of unfortunate situations such as us spending years designing a declarative disaster when we should have been iterating to design a programmable proxy.

To summarize, we believe it would be hugely beneficial to the web if we had a safe way to enable browser vendors to iteratively develop features using feedback from web developers.

The risks and past attempts to solve the problem

This problem is difficult to solve. Browser vendors previously attempted to solve it with vendor prefixes, which allowed browser vendors to ship features prior to standardization. The theory was that this would allow developers to provide early feedback and give vendors the ability to change APIs before standardizing them. The intention was that the ugly appearance of prefixes would make it obvious that developers shouldn’t depend on the features in production.

Unfortunately, what actually happened was that developers didn’t consider these experimental but rather used prefixed features in production sites that have survived for years and years. As a result, the web is now full of sites that in the worst case only support some features in the browsers that happened to have a prefixed form at the time, and in the best case ship huge CSS files full of redundant vendor prefixes.

This experience makes it clear that any system to enable experimentation should also converge to eventual interoperability for successful features.

Conversely, for unsuccessful features we should ensure that any system to enable experimentation prevents designs we later regret from being baked into the web.

The risks don’t stop there though. Assuming we did ship a feature experimentally, how can we prevent one large company from adopting it and relying on it at scale, making deprecation or changes to the feature much more difficult? How can we ensure experimental features maintain our high privacy and security standards?

A sketch of a solution

When reflecting on the problem we outlined earlier, it’s clear that we can’t change the fact that web browser engineers are fundamentally different people to web developers. For that reason, we focused our design efforts on coming up with a safe way to encourage web developers to try new features and provide us feedback while maintaining our ability to modify designs, ensure successful experiments result in eventual interoperability and ensure unsuccessful experiments are not baked into production websites.

We believe these constraints are solvable with ‘origin trials’. In summary, with origin trials:

This design is expanded in detail later, but first consider how this satisfies the constraints we outlined earlier:

And when considering those additional risks we were worried about:

This design also has the additional benefit that developers cannot simply copy paste code using experimental APIs from Stack Overflow as was possible with prefixes.

To summarize this document so far: in order to design good features on the web, the web developer feedback needs to be the most important voice in the standards process. We have been very careful in designing origin trials and are tentatively declaring we believe it is safe way to make that possible.

High-level design of the solution

Earlier, we outlined two key aspects of the origin trials solution. First, using registration to establish a communication channel with developers. Second, using automated usage limits to prevent burn-in of experimental features and maintain flexibility in implementation. Here, we describe the high-level design of the solution. For more details on the design, see Origin Trials Framework Design Outline.

The high-level process for experimental features is:

Trial tokens

After considering other mechanisms, we settled on using trial tokens to provide limited access to experimental features. We wanted a mechanism that provided a few important capabilities:

Trial tokens are self-contained, verifiable blobs of text, which can safely be embedded in web pages. Each token is issued for a specific combination of origin and feature. It is not possible for a developer to use one token to enable multiple experimental features on their origin. As well, a token issued for a given origin and feature cannot be used to enable that same feature on a different origin.

Monitoring and limiting usage

As above, we’ve defined a cap that usage of a single experimental feature cannot exceed 0.5% of all Chrome page loads

To enforce these limits, usage for each feature with an active origin trial will be monitored regularly. The primary source of data will be anonymous usage statistics collected by Chrome (i.e. UseCounter). With these usage statistics, we can determine if the limit is exceeded for each feature.

When the usage limits are exceeded for a feature, the feature will be disabled for future use. As features are enabled by self-contained trial tokens, a separate mechanism is needed to revoke/override the access provided by otherwise valid tokens. In general we intend to use:

There are further steps we can take if there is some unforseen issue with the above kill switches, for example:

All the above mechanisms make use of the existing infrastructure in Chrome to push out information to installed browsers. For the feature-implemented switches, this makes use of the field trials infrastructure. For the origin trials revocation lists/signing key replacement, this makes use of the infrastructure for component updates.

Different mechanisms will be used to disable a feature, depending on how the usage limits were exceeded. Initially, the feature-implemented switch will most commonly be used to disable the specific overused feature.

Collecting developer feedback

One of the main goals of origin trials is to enable browser vendors to collect developer feedback to help iterate on new features. With the registration process, we will be able to establish a communication channel with developers.

The primary means for collecting feedback will be structured surveys during the course of each trial. Using surveys will allow feature authors to collect both qualitative and quantitative data about various aspects of their feature, such as the effectiveness and ergonomics in addressing a particular developer pain point. Initially, we’ll have a separate survey for each feature. Over time, we expect to provide a consistent survey approach across features. The collected feedback will be anonymized and aggregated, and we’ll make a summary of the feedback publicly available.

Beyond surveys, we hope that developers will participate in the community around each experimental feature. Feedback is always valuable, so we’ll encourage developers to provide informal/adhoc feedback during the trial, or join the mailing list/GitHub repo/etc. for each feature.


Why does this project exist?

Will all of these experiments ship eventually?

What happens if a large site such as a Google service starts depending on an experimental API?

Isn’t this just vendor prefixing all over again?

Does this change impact how we think about security or privacy on the web?

Is there any restriction on which websites can sign up to use experimental APIs?

Is there any review process for signing up a website to access an experimental API?

Can one large website prevent anyone from accessing an origin trial (either maliciously or inadvertently)?

What is the structure of trial tokens?

What happens to the developer feedback collected in surveys?

Why shouldn’t browsers just use A/B experimentation techniques to test out web platform features