googlechrome / origintrials

Enabling safe experimentation with web APIs

Origin Trials

Origin trials are an approach to enable safe experimentation with web platform features.

Briefly, the web needs new features, and iteration yields the best designs and implementations for those features. However, previous efforts have seen experiments prematurely become de-facto standards, with browser vendors scrambling to implement the features, and web developers coming to rely on these features. These experimental features became burned-in, and resistant to change (or removal), even though better implementations were identified/available.

One of the root causes was that experimental features were available too widely, and thus usage grew unchecked as a result. Ideally, it should be easier to expose and iterate on new features, but reliably limit the experimental population. With a test population of developers committed to providing feedback, and limits in user base size and experiment duration, iteration can happen faster, but without the risk of burn-in.

The origin trial feature is still security-reviewed, tested and launched as a production feature, just time and usage limited to allow for evolving the feature with developer feedback, minimizing the risk of it prematurely becoming a defacto standard.

Please see the explainer to learn more about the problem, and why origin trials is a good solution.

Signing up for an origin trial

Developers can use the developer console to request a token to access a feature currently available as an Origin Trial.

Contents

In addition to describing the problem, and solution, you'll find information for implementing features as experiments, participating in experiments, and details about how it works in Chrome.

• Motivation/Explainer - Detailed discussion of the problem, the history and why we think origin trials are a good solution
• Web Developer Guide - For web developers looking to participate in a trial
• Feature Author Guide - For browser engineers looking to experiment with their feature

origintrials's Issues

https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting-experiment/#join-the-discussion

Origin Trials doesnt work in Google Chrome/Canary/Chromium browser

Im tying to fetch a page from AIOQUIC server through browser. As specified i generate the token and give it in the html head tag(tried giving as http header too).

<title>aioquic</title> When i try to open up a browser from command line, i dont see the page that is fetched from the server.Either the connection is refused or ERR_QUIC_PROTOCOL_ERROR shows up in the browser. ./Chromium \ --enable-quic \ --origin-to-force-quic-on=127.0.0.1:4433 \ https://127.0.0.1:4433

Is there any way to cross check if origin trial is enabled or not. Any suggestion?

[Questions] - Allow Sync XHR In Page Dismissal Origin Trial

Hello! I have been actively following/tracking the chromium v80 changes especially related to disallowing of sync XHR during unload (https://bugs.chromium.org/p/chromium/issues/detail?id=827324). We have a feature that heavily relies on synchronous XHR. We tried the suggested sendBeacon() approach but are currently facing some issues with 64K limit and will need more time to work on an alternate solution.
Hence, for the short-term, we want to continue using sync XHR for unloads and hence we started looking into the origin-trials. I have already generated the tokens for this origin-trial but would really appreciate some more answers to the following points as I wasn't able to find them through online resources:

• Would this trial (https://developers.chrome.com/origintrials/#/view_trial/4391009636686233601) be subjected to the 0.5% usage limitation that is described in the documentation? The comment here (https://bugs.chromium.org/p/chromium/issues/detail?id=827324#c39) indicates that it won't be subjected to 0.5% limitation since it is an opt-out but I just wanted to confirm this.

• If we renew the token before it expires (renew them as soon as we get the email reminder about it)...would we still need to change the token in the codebase? When would a code-change/token-change be needed?

• When would this trial end? The documentation points to v85 but just wanted to check since some of the comments hints to v88.

• Are there any performance impact for having the token in the meta tag of our page? I went through the code-base but wasn't sure how the token-check is made. I realize that the token is "self-contained" and has information about the origin/feature but would there be any XHR or server calls made to chrome servers to verify the token? We are trying to see if there would be any performance impact to our end-users by having this token in the meta tag since we have a large number of users for these domains. It would be great if you can point me to some documentation on how the verification works.

• Are there any performance impacts for any of these scenarios - 1. We reach 0.5% limit and we still have the token 2. When the token is invalid i.e. it has expired OR we have the wrong token or something.

Automate/Formalize the OT signup process

Currently the way to get OT tokens is to fill out a google docs survey and then wait for a human to eventually read your request and send you an email.

I'd suggest that this be changed in the following fashion:

• provide a real website/service
• automate token issuance
• document the OT trial token API so it can be automated by website authors

Display active OT token expiry in token registration page

Background

OT token "Expiry" is an important piece of information that will determine whether an OT token's "Valid Until" date can be extended further or whether a new token will need to be generated. Although this has been covered in the FAQ, we missed this important detail and expected to see the same token renewed with an extension to the "Valid Until" date. Because of this misunderstanding we renewed the token a bit late and deploying a new OT token took several days (because of unrelated issues in our CI/CD pipelines).

Request

Include an "Expiry Time" field on the OT token registration page along with some "help" text explaining how a token cannot be extended beyond the expiry date. This will hopefully:

• Make it easy to find a token expiration date (which currently requires using other debug links to figure out)
• help avoid a similar misunderstanding and also avoid a gap in OT participation for other developers in OTs

Revisit “Origin Trials” naming

The naming of “Origin Trials” seems unusual and, from my view, makes it surprisingly unclear what they’re about—it suggests origins would be tested (which is inaccurate), only to then beg the question what “origins” actually are (in the spirit of the documentation it seems web properties or projects).

The history and thinking behind the naming could be interesting to learn more about (was it or could it be documented somewhere?), but as the name seems so confusing I’d like to add three suggestions:

• “(Web) Feature Trials,” in the web dev context, could create a lot of clarity by expressing what’s being tested.
• “Website Trials” would solve the “origin" naming issue, though “website” is very specific and could look like it didn’t apply to web apps or other web properties.
• “Vendor Trials” would build on the bridge that vendor-specific extensions have set up, and allow for an easier mental connection there.

(Personally, I think “Web Feature Trials” would be distinct and clear and therefore raise far fewer questions.)

It seems unusual to make this suggestion, now, this way, but so unusual seems to be the naming. Thanks for considering.

Why send renewal notices if the Renew button is disabled?

I received a link to renew. I click it, log in and the renew button is disabled.

Move this repo to shared organization?

Perhaps it's time to make this repo a little more official, WDYT? This is all Chrome specific so probably not a good fit for the WICG (or other standards) org. Maybe just the GoogleChrome org?

App developer

If GitHub and Google and in any other company or business that provides apps you have to keep your developers and compliance or charge them a fine to the same compliance that you stand to if not they need to be fined and they have to submit a test through your program to make sure that's in compliance with your compliance of mine.
William Steve McGowan Jr

Private Network Access from non-secure contexts not working

Added token for Private Network Access from non-secure contexts but did not resolve the cors error. Worked before chrome 94 and works fine on all other browsers.

Update available-trials.md with WebVR (For Chrome M59+)

The Origin Trials signup page has an option WebVR (For Chrome M59+) that is not listed or described on the available-trials.md.

The original Intent to Experiment post was updated by @toji on 2017-03-15 requested that the trial be extended through M58 and a new trial would be started. I assume this new trial corresponds to the WebVR (For Chrome M59+) option listed in the signup form feature selection drop-down.

From my confirmation email, the WebVR (For Chrome M59+) trial will end on Oct 17, 2017.

It would be helpful if the available-trials.md reflected this information.

Error in developer guide

Under "For example this may look something like:", the example meta tag doesn't render because the browser interprets it as an actual meta tag. Result is the reader can't read it.

http://googlechrome.github.io/OriginTrials/developer-guide.html#how-do-i-enable-an-experimental-feature-on-my-origin

WebVR origin trial enables navigator.getVRDisplays but Promise never returns

I've received my Origin Trial code and have added it to my page, but I'm not sure it's working as intended. I'm running Chrome 56.0.2924.18 dev (64-bit) in Windows 10, with a Rift+Touch.

Some observations:

• As expected, on a page without an Origin Trial token navigator.getVRDisplays() is undefined
• On a page with an Origin Trial token, the navigator.getVRDisplays() promise is never fulfilled, nor is the error callback called
• This affects the WebVR samples as well, eg https://webvr.info/samples/00-hello-webvr.html

Am I jumping the gun here, and when we say M56 it actually means this will only be available once the 56.x branch hits the stable channel?

Origin trial only lasted 7 days

I received my last origin trial token 7 days before it expired and I have not yet received the new one. I was going crazy trying to figure out why my code doesn't work properly. You really make things hard on developers when you abuse things like this.

Are multi-subdomain tokens still restricted to default ports?

https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#13-i-have-multiple-testingstaging-domains-or-subdomains-that-are-programmatically-generated-do-i-need-to-request-a-token-for-every-subdomain doesn't mention any port restrictions. Since people sometimes use non-default ports when developing, e.g. https://mybox.corp.google.com:8443, it would be good to know whether this works.

Web bluetooth token not working

Hi, I just receive my token and I can't get it to work.

The only reason I can think of is that my domain is not running on default https port.

To explain: In sign-up form I stated my domain: https://some-domain.com. And now I'm running my experiment on https://some-domain.com:12345/experiment. I 'm not that familiar with token to know if this can be a problem.

thx, matija

Ability to check that an original trial is properly enabled?

I'm experimenting with the Priority Hints origin trial. Unlike origin trials that add JS APIs, this one merely changes browser behaviour. As a result, I can't find a good way to verify that this origin trial is properly enabled. I.e. that my token is set up properly for my domain, the browser is seeing it and enabling the origin trial.

Is there an undocumented JS API, or Chrome feature that would let me verify that the origin trial is enabled for the current pageload? It can be something local only, I just need a way to check that it's working properly.

Origin Token has valid for 2 weeks

As the document, the token should have valid for 6 weeks but in my case, the token has valid only for 2 weeks as the screenshot from 14hJan to 29Jan.
thanks.

Enabling an origin trial in WebPageTest

Is it possible to enable an origin trial in a lab tool like WebPageTest, for example by starting Chrome with a command line flag or similar, specifically for origins outside of our control? This would be useful for A/B testing and transparency tools that rely on WPT like the HTTP Archive.

My understanding of opting in to an OT is that each origin receives a token which is included in the HTML as a meta tag or response header. But is there a way to do this for an arbitrary origin on an ad hoc basis just for synthetic testing purposes?

cc @igrigorik

add "Web Locks" and "EME Extension - Policy Check" to `available-trials.md`

The list of experiments in available-trials.md does not include Web Locks nor EME Extension - Policy Check, but they are both options on the Origin-Trial Signup Page.

---

Questions: local development

I see the (great!) developer guide suggests two ways to experiment with a new feature locally.
You can get started experimenting with the new feature on localhost either by flipping the flag locally or requesting an origin trials token for localhost.

Two questions:

1. What are pros and cons of the two ways? When would you recommend each approach? What about third-party origin trials, does this change anything?
   Things I could think of:

• Benefits of localhost tokens over flags:
  • Token can be shared across a team. No need to replace the token when checking out the code of a small prototype (one gotcha though: port- and protocol-dependent)
  • No need to restart the browser / turn flags on and off
  • Work across Chrome and Edge without extra setup
• Benefits of flags over tokens:
  • Faster to set up
  • Easier to troubleshoot / No troubleshooting: "if a flag is in chrome://flags and I activate it, the feature will be on" (vs.: if I'm using an expired flag, I'll need to troubleshoot this).

2. Do you think it would be useful to add a brief "When to use flags and when to use a localhost token for local development" in the developer guide under how-can-i-experiment-with-the-new-feature-locally? Or to highlight with a one-liner the one benefit of each approach?

Is Web Share API experimental end?

When I received the renewal email about to a new token, this email had a information about to end experimental test. So, did experimental test is end? If you answer it "yes", Do you know when the Web Share API coming on Chrome official?

WebXR is not listed on Token Sign-Up Form

1. In the available-trials.md document, notice both WebXR and WebVR are listed:
   
2. Published on Monday, April 30, this Chromium Blog post also mentions the WebXR Origin Trial:
   
3. Load the Token Sign-Up Form, and notice WebXR is missing from the Feature drop-down menu choices:
   

WebVR support no longer working in Chrome 69

Is this intended? Everything is working great in Chrome 68 and earlier.

Wrong Origin Error While Origin is correct for USER-AGENT-REDUCTION

The user agent reduction solution is not working and keeps giving error in chrome console saying "WRONG ORIGIN"

SendFullUserAgentAfterReduction ValidTokenNotProvided
Token Status WrongOrigin
Origin https://*******************
Expiry Time September 24, 2023 at 4:59:59 AM GMT+5
Usage Restriction None
Third Party true
Subdomain Matching true**

Link to Orgin Trial sign up form

I find it incredibly hard to find out where I am supposed to sign up outside of the articles that we write.

Would it be possible to add the liinks to the sign-up form on https://github.com/jpchase/OriginTrials/blob/gh-pages/available-trials.md just to make it a tad easier. I know we don't want to broadcast it too much but it would certainly save a lot of time.

Cors error on HTTP2 in google chrome

Access to XMLHttpRequest at ‘https://admin.example.com/’ from origin ‘https://admin.example.com/’ has been blocked by CORS policy: Request had a target IP address space of unknown yet the resource is in address space public.

From the last update of google chrome, version: 102.0.5005.63 it only throws the mentioned error and not the functions it does not fulfill correctly…

I have read this official update note: Private Network Access update: Introducing a deprecation trial - Chrome Developers

Implement the necessary headers but the error persists on any apache website
Access-Control-Allow-Private-Network: true
Access-Control-Request-Private-Network: true

Limitation of use of third-party token

It seems that a third-party token can not be valid as the wrong origin when it is written in the document as the first-party origin token.

If so, please clarify it in the FAQ that the third-party token can be used only loaded from the script.

Pište ve svém jazyce pomocí Gboardu

K psaní v jazycích lendu (Psaní rukou), Čeština (QWERTZ), ladino (Izrael) (QWERTY), lendu (AZERTY), sasak (aksara bali) (sasakština), angličtina (Velká Británie) (Psaní rukou), angličtina (Velká Británie) (QWERTY), bišnuprijskomanipurština (abc → বিষ্ণুপ্রিয়া মণিপুরী), lendu (Dvorak), dolnolužická srbština (QWERTZ), bišnuprijskomanipurština (bišnuprijskomanipurština), lendu (Colemak), lendu (PC), lendu (QWERTY) a lendu (QWERTZ) používám aplikaci Gboard. Můžete ji vyzkoušet zde: https://gboard.app.goo.gl/H9CZn

TODO: Update documentation to say usage stats will be posted to intent to experiment thread

I.e. at each Beta point we will share the usage stats from the previous release

Origin Trial is not cross UA compatible

If other UAs should decide to use origin trial, they have a problem, because they cannot use the Origin-Trial header/http-equiv, since that is already taken by Google.

I'd suggest changing the OT semantic to allow issuance of many tokens on the Origin-Trial header so that other UAs can join that semantic.

TODO: Determine exactly where feedback we collect should be shared

WICG? blink-dev? The experiment's mailing list? Etc?

`check-token.html` says "Valid" in green for expired tokens.

Screenshot:

I think this should show either "Invalid" or "Expired" instead.

If "Valid" is only meant to refer to e.g. the signature, then it should say something like "Signature valid".

(Motivated by chromium/permission.site#26 (comment))

Can a third party opt into an Origin Trial?

Hi,

I was wondering if a third party can opt into an origin trial in the following situations:

1. a cross origin third party script in the main document.
2. a cross origin third party script in a cross origin iframe.
3. a cross origin third party script in a cross origin iframe in a cross origin iframe in a...

My guesses:

• Situation 1: No. Reason: a dynamically inserted meta tag would not allow access to an OT feature.
• Situation 2: Depends. Yes (?) if OT opt-in is not limited to top level document/origin, No otherwise (the third party would have its key as a meta tag in the iframe or as a header on the iframe resource). The OT feature would be available in the iframe context.
• Situation 3: similar to 2. The OT feature would be available in the nested iframe context.

Any thoughts?

Renewing tokens inconvenient with offline-first PWAs

We have an offline-first PWA which loads primary from a Service Worker cache which is kept long-term in between major releases (which could be a few months apart).

It's difficult to update an origin trial token since the old token is kept in the SW cache. When it expires it keeps using the expired token and so disables the feature, even after we renewed it and deployed the updated token to production.

We have an opt-in experiment to use the new Native Filesystem API, and in practice this means users see the feature disappear when our old token expires. These users can resort to flipping the flag, or clearing the cache - which is dangerous since our PWA also allows saving your work to IndexedDB, and if you pick the wrong settings, it'll also wipe all their work from storage. Therefore it seems safer for us to tell users to resort to flipping the flag instead - which then enables it for the whole web.

In particular the Native Filesystem API origin trial appears to be running longer than usual, meaning it appears likely this problem will happen repeatedly during the origin trial.

I'd suggest adding the ability to renew the same token, rather than having to change it.

Token renewal with changing usage restrictions

We would like to renew the exiting token with changing usage restrictions from Standard Limit to Exclude a subset of users.
In the developer console, token renewal keeps these features the same as the previous one.
I tried to register a new token but it was rejected with the warning that the domain already exists.

How can we do it?
Should we remove the existing token and register a new one?

Document how to let a third-party script use an OT feature

@beaufortfrancois asked that https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md mention that when Origin 1 <script src>'s a script from Origin 2, Origin 1 needs to be opted into the Origin Trial for the Origin 2 script to be able to call functions from it.

DisableThirdPartyStoragePartitioning Trial Test isn't working

Hey Everyone,
I am trying to the DisableThirdPartyStoragePartitioning for a third-party iframe with 0 success.
I did everything in the right order.
I have the following HTML Page:
`

<script src="https://www.example.com/test.js"></script> aaa `

Which rendered as an iframe with test.js content as:
`const TOKEN = 'TOKEN';

const otMeta = document.createElement('meta');
otMeta.httpEquiv = 'origin-trial';
otMeta.content = TOKEN;
document.head.append(otMeta);
console.log(localStorage);
localStorage.test=1;
console.log(localStorage)
`

When I open the Chrome dev tools on the Application I can see that everything is working

But when I am running the test on two different top TLD's I get two different localStorages which means that the test is failing and I can't understand why as everything is in green.

Validation date does not update after feedback submission

Im not certain this is the appropriate place to submit my issue, but for some reason, after the feedback submission this specific trial doesnt not update the validation period.