Introducing Persistent Origin Trials

[Peter Birk Pakkenberg]

Hi,

I am working on implementing Persistent Origin Trials (https://crbug.com/1257579) as a means to run origin trials for browser changes that need to be made before the first request is made to the browser - the use case so far has been adapting request header information based on trial participation.

As part of the launch review process, it was suggested that I reach out to this group to discuss how future feature launches that use Persistent Origin Trials should be handled.

Changes

Persistent Origin Trials work by storing the origin trial token data in the browser’s persistent storage when navigating to a participating site, provided the trial in question is marked as persistent. The stored token information is overwritten on every navigation, and if the site does not set the Origin-Trial header, the stored tokens are cleared.

This allows an origin to enable a trial much like a standard origin trial, except that the enablement is available until the next navigation, making it possible to run trials with request headers, where trial participation needs to be made before a response can be received from the origin.

To bootstrap participation, the feature also includes a new request header, “Critical-Origin-Trial”. This header should contain the name of one or more critical origin trials, and provided the request also contains the corresponding valid origin trial tokens in the Origin-Trial header, the browser will restart the request if the trial was not already enabled when the initial request was sent. The design of this header was inspired by the “Critical-CH” header, which serves a similar purpose for client hints.

Recommendation for amendments to feature launch review

In my opinion, a feature should receive extra scrutiny if it relies on a Persistent Origin Trial for its launch, for two reasons:

First, most features probably don’t need persistence. Since the Persistent Origin Trial feature makes origin trials easier to access in the browser process, it may be the case that some feature developers will use it by default simply because it is available, without needing the persistence it provides. Outside of modifying request headers, I struggle to think of use cases where the browser needs to alter behaviour before receiving a response from the server.

Secondly, keeping the trial token information on the device increases the memory footprint and disk space required by the browser. I estimate approximately 120 bytes of raw information per trial token stored. It is worth noting that at least one of the proposed use cases is for a deprecation trial, which would likely have a large number of interested origins, meaning that the storage requirement could easily become noticeable.

Closing

Please let me know if there are any questions about the change we are proposing. The code has been submitted, and is hidden behind the “kPersistentOriginTrials” feature flag.

Sincerely,

Peter Birk Pakkenberg Software Engineer pb...@google.com +447469379358

[Mike Taylor]

I'm very happy to see this work progressing - I know of 3 OTs/Deprecation trials that would have used this if available at the time: UA Reduction, CHIPS, Storage Partitioning (my hand wavey understanding of this one is we need to have localStorage/sessionStorage in memory before we have possible state on a trial).

thanks,
Mike

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CACvTYjt1NhNitfGUbBgSAW72fXCT8cf_m7CQCHtw4L7CORgTjA%40mail.gmail.com.

[Peter Birk Pakkenberg]

Ah, good to get an example of a use case that isn't directly request header related.

Sincerely,

Peter Birk Pakkenberg Software Engineer pb...@google.com +447469379358

[Alex Russell]

+1; glad to see this expansion of OTs

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CACvTYjtypt_%2BprE3mkGO3DEaLNe67VX8CAKcRtC6nsBCMVUiew%40mail.gmail.com.

[Peter Birk Pakkenberg]

I am happy to hear that there is excitement about the feature :)

Does this mailing list have any concerns about how this will fit into the Chrome release process?

Sincerely,

Peter Birk Pakkenberg Software Engineer pb...@google.com +447469379358

[Mike West]

The only logistical question I have is whether a persistent origin trial requires approval above and beyond the single LGTM necessary for a regular OT. We've required 3 LGTMs for deviations from the norm in the past, but it might be reasonable to consider the security review implicit in landing the CL to be a sufficient gate for this kind of OT. I think that's enough, FWIW.

-mike

[Yoav Weiss]

A single LGTM makes sense to me, as the OT's persistency slightly changes its characteristics, but not the level of its web exposure. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DevGDQhCOoHXWMdU4yF6e9s5XDWrqBo1LLAnXPSVcCCGQ%40mail.gmail.com.

[Mike Taylor]

Agree with Yoav and Mike - no need for additional LGTMs for this kind of OT variation.