Add a new manifest key to include a origin trial token

[patrickkettner]

Chrome and Firefox both have the concept of an Origin Trial. Normally, these are registered via either an HTTP header, or a meta tag. For background pages, this can be done via a meta tag. But for background service workers, or the different worlds of content scripts, this is not currently able to be done.

The Chrome team is supportive of this, but we are still figuring out prioritization of the work. Here is the implementation tracking bug

Is anyone against the concept?

[bershanskiy]

A new manifest key with origin token(s) for Origin/Deprecation Trials does sound very reasonable, especially since it would allow introduction of new APIs without fear of ossification and deprecation of old behaviors (e.g., edge cases) without fear of breakage. Do you happen to have a concrete syntax in mind yet?

[hanguokai]

But for background service workers, or the different worlds of content scripts, this is not currently able to be done.

1. Do you mean that extension's origin trial token can be applied to content scripts? That is out of extension's origin.

2. Other Chromium-based browsers also support OT except Edge which has it's own OT and Extension Store?

3. OT usually lasts for a few months. Once it expires, will the extension be removed from Extension Store if it doesn't release a new version?

[patrickkettner]

@bershanskiy

> Do you happen to have a concrete syntax in mind yet?

nothing written yet, however I assume it would be something like

  "trial_token": "AxujKG9INjsZ8/gUq8+dTruNvk7RjZQ1IFhhgQbcTJKDnZfbzSTE81wvC2Hzaf3TW4avA76LTZEMdiedF1vIbA4AAABueyJvcmlnaW4iOiJodHRwczovL2ltYXNkay5nb29nbGVhcGlzLmNvbTo0NDMiLCJmZWF0dXJlIjoid293WW91QXJlRGVkaWNhdGVkVG9UaGlzIiwiZXhwaXJ5IjoxNjk1NjU4MjQ5LCJpc1RoaXJkUGFydHkiOnRydWV9"

inside of the manifest.json.

@hanguokai > Do you mean that extension's origin trial token can be applied to content scripts? That is out of extension's origin.

To be investigated - if the MAIN world has an active origin trial, I was not able to confirm that isolated worlds inherit it.

> Other Chromium-based browsers also support OT except Edge which has it's own OT and Extension Store?

I am not sure I understand - are you asking a question?

> OT usually lasts for a few months. Once it expires, will the extension be removed from Extension Store if it doesn't release a new version?

No, the value would just be ignored.

[hanguokai]

My second question is whether other chromium-browsers(except Chrome) can support this feature? for example: they

• support this manifest key, and support Chrome's origin trial
• support this manifest key, but ignore it (no effect)
• don't support this manifest key

I don't know if other chromium-browsers support OT, so I thought of this question. Because OT needs to check the registration data on a Chrome website.

[patrickkettner]

> My second question is whether other chromium-browsers(except Chrome) can support this feature? for example: they

They should, at least I don't think we would engineer it in a way where it would not be possible. Nothing is written, as of now. Just bringing it to the group to make sure it made sense to proceed.

> support this manifest key, but ignore it (no effect) don't support this manifest key

Yep! That would be the goal. But you bring up a meta issue of how to handle unsupported keys. It would be great to define that behavior in the specification/testing threads that are going on (i.e. unknown keys should warn, not error in a blocking manner (most of the time))

> I don't know if other chromium-browsers support OT, so I thought of this question. Because OT needs to check the registration data on a Chrome website.

Anyone that uses the chromium origin trial registration should work without modification. Any chromium browser that builds their own infrastructure for trial registration may have to do something, but since this is not written yet, this is TBD.

[dotproto]

Do you mean that extension's origin trial token can be applied to content scripts? That is out of extension's origin.

To be investigated - if the MAIN world has an active origin trial, I was not able to confirm that isolated worlds inherit it.

I'm interested in better understanding how an extension's origin trials interact with the website they're injected into and how a website's origin trials interact with extensions that are injected on them.

One of the extensions I advise is very interested in participating in an upcoming origin trial in order to leverage a new web API being developed on the websites they interact with. Exposing an extension's origin trial in the isolated world and not in the main world sounds like an ideal balance for that developer's purposes.

[patrickkettner]

Exposing an extension's origin trial in the isolated world and not in the main world sounds like an ideal balance for that developer's purposes.

my guess is that that does not happen today. Very brief talks with some Chrome eng folks makes it harder to implement, but haven't spoke with extension eng about it yet.

[dotproto]

nothing written yet, however I assume it would be something like

  "trial_token": "AxujKG9INjsZ8/gUq8+dTruNvk7RjZQ1IFhhgQbcTJKDnZfbzSTE81wvC2Hzaf3TW4avA76LTZEMdiedF1vIbA4AAABueyJvcmlnaW4iOiJodHRwczovL2ltYXNkay5nb29nbGVhcGlzLmNvbTo0NDMiLCJmZWF0dXJlIjoid293WW91QXJlRGVkaWNhdGVkVG9UaGlzIiwiZXhwaXJ5IjoxNjk1NjU4MjQ5LCJpc1RoaXJkUGFydHkiOnRydWV9"

inside of the manifest.json.

My first reaction was that a new top level key named trial-token or origin-trial may be too browser specific, but after a bit more research and consideration I'm supportive of this direction.

One of the topics we discussed at TPAC was browser-specific naming for manifest keys. I believe Chrome expressed a desire use generic naming where appropriate moving forward, but there was an open question about what "where appropriate" meant. To my knowledge the Origin Trial system is not Chrome specific. In https://github.com/GoogleChrome/OriginTrials/issues/23#issuecomment-266564140 @mkruisselbrink states

[Other UAs should be able to use the Origin-Trial header/http-equiv.] Our implementation just ignores any tokens that aren't signed by our keys/that aren't in our format. It's always been our intention to allow other UAs to do the same thing with the same headers.

I don't want to derail this with bike shedding, but my main concern with the current suggestion is that the name trial_token strongly implies the presence of a single token. That presents problems for both Chrome extensions participating in multiple trials and cross-browser extensions that wish to participate in trials exposed by multiple browsers.

The Origin Trials Developer Guide starts that it's possible to "provide multiple tokens for a given page."

You can add multiple tokens in different ways:

• Add multiple tags to the page, where each tag contains a single token.
• Include multiple Origin-Trial response headers, where each header contains a single token.
• Include a single Origin-Trial response header, with comma-separated tokens.

In ordre to cleanly support multiple origin trial tokens, I'd suggest that the top level key should be named origin_trial_tokens and it should accept an array of strings. This makes it possible for multiple browsers to participate by ignoring invalid tokens, allows a single extension to register for multiple trials, and still makes it possible to define a single token with minimal additional syntax.

Single token

  "origin_trial_tokens": ["Axuj...dWV9"]

Multiple tokens

  "origin_trial_tokens": [
    "Axuj...dWV9",
    "mNvb...LCJp"
  ]

[xeenon]

I am supportive of this as trial_tokens with an array. I would prefer to not include the word "origin", since that in my mind is tied more closely to web origins, not extensions.

[zombie]

We support this proposal, though since Firefox has a much more limited repertoire of experiments exposed through the OT mechanism, not sure this would be a priority.

Also agree with Timothy about naming, in Firefox the tokens would need to refer to the extension's ID, and not the actual origin, since we use basically a per-instance generated UUID instead (similar to Safari).

[bershanskiy]

Update: Chromium already has an implementation of trial_tokens which is available on Google Chrome Canary. The implementation right now just extracts the tokens from manifest.json during install/startup and stores them internally for later use.

Here is the summary of validation code, to save you time:

• the new manifest.json key is called trial_tokens
• trial_tokens MUST be a non-empty list of non-empty strings, otherwise error is thrown (installation failure)
• if a token (string) is very long (longer than 6144 chars, value is arbitrary), it is skipped (and a benign warning is logged and installation continues)
• if there are very many trial tokens, then only the first 100 valid tokens are processed (the rest is ignored and a benign warning is logged and installation continues)

I hope we can agree about the first two bullet points before shipping to non-canary channels. If needed, I can create a CL changing the validation logic in Chromium.

[patrickkettner]

Hi @bershanskiy.

Chrome's position is that errors should be only used in the case of non recoverable manifest parsing issues. So the error associated with the second point should be a warning.

[bershanskiy]

@patrickkettner Thank you for the comment. Could you please look at this test and identify which of these cases should be converted from an install-blocking error to a benign warning? As a reminder, trial_tokens is available on Google Chrome Canary but not on other channels. I want to ensure everyone is on the same page before we advance it to Beta and only after that to Stable. Hopefully someone from Firefox and Safari teams would comment as well.

[patrickkettner]

@bershanskiy all of them would be warnings

thanks again for taking care of it!

[bershanskiy]

@patrickkettner Here is the relevant CL: https://chromium-review.googlesource.com/c/chromium/src/+/5224727