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

[jpchase]

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.

That's correct, the 0.5% limit does not apply.

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?

Each token is effectively immutable (write-once on generation). When you renew, it generates a new token that is intended to replace the previous token. The previous token remains valid until its expiry date, so you can continue to use it where already deployed. Eventually, the renewed token must be provided on any web pages where you wish to continue enabling the trial. You can provide multiple tokens on a web page. We've seen some developers choose to deploy both old and renewed tokens on the same page, especially when it takes multiple days for changes to rollout to all users.

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

Yes, the trial is currently set to end in Chrome 85. You should reach out to the trial contacts on the I2E to find out if any changes are planned.

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.

The token is indeed self-contained, and is verified by Chrome on device, without any server calls or network access. Obviously, it's not free to verify tokens, but I would expect that the performance impact would not be observable on any page. Verifying a token requires some parsing/decoding of the token and a crytpo call. Our past tests have shown the crypto to be fast, and have negligible impact. If there were dozens/hundreds of tokens on a page, I suppose there might be an observable impact. We've had trials (e.g. SW Navigation Preload) where participating developers were very performance-sensitive, and haven't had any reports of issues due to token verification.

We don't have any documentation on the verification. If you're interested in the implementation details, reading the source code is your best bet. As above, I'd argue this isn't necessary.

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.

I would say there are no observable impacts. For (1), the 0.5% limit is applied by monitoring global usage, and disabling the trial if exceeded. That is largely a server-side process, which would result in pushing out an update, asynchronously, to Chrome clients (i.e. using the component update infrastructure). If the trial was to be disabled, it does mean that token verification would still be attempted, as checking for disabled trials is part of verification. As above, the cost of token verification is minimal. Similarly for (2), the trial would not be enabled, with the minimal cost of token verification.

[ssshah5]

Thank you @jpchase for the detailed response. This is very helpful.