Proposal to relax origin trial constraints for token validation

[cha...@chromium.org]

TL;DR

I propose relaxing two constraints in the origin validation of trial tokens:

1. For deprecation trials only, ignore the origin when content comes from a file URL. That is, allow file URLs to enable a trial with any valid token, regardless of the specified origin in the token.

2. Match only the scheme and host, ignoring the port number, for non-reserved ports (i.e. > 1024).

These constraints have the potential to cause, or have already caused, undue friction for web developers. I believe that relaxing the constraints doesn't materially impact the ability of origin trials to limit usage of features and attribute usage to specific web developers.

Longer version

1. Allow file URLs to enable trials, for deprecation trials only

As described in High-Usage API Deprecation, it's important for a trial for a deprecated feature to re-enable the feature anywhere it previously worked. File URLs are not supported by the origin trials framework, because they do not have a well-defined origin (e.g. the URL spec). This is tracked in crbug.com/1025782, and is particularly problematic for the WebComponents V0 deprecation. For WCv0, there are sites that heavily rely on having content work locally from file URLs (see crbug.com/1021137).

Given that file URLs can change arbitrarily, as well as the contents of a saved file, it's difficult to come up with a reliable way to derive an "origin" for validation. In theory, we could generate a hash of the file contents when downloaded, embed in the file somehow, and later validate that the contents haven't changed. After initial investigation, that seems possible to implement in Chrome, but definitely non-trivial.

The more feasible approach is to ignore the origin check for file URLs. This was prototyped by masonfreed@ in:

https://chromium-review.googlesource.com/c/chromium/src/+/1904762

By ignoring the origin check, an otherwise valid token is still required. This means that the web developer would have to make some change to their content, which implies awareness of the deprecation (at least implicitly). This approach makes it possible for a developer to blindly copy/paste any token (e.g. from code snippet found elsewhere), but that would only work for the saved file. The web site as served would not work, which makes it much less likely a developer wouldn't sign up for their own token.

I propose to implement logic similar to the prototype, but instead of hard-coding a trial name, it would allow for any trial explicitly marked as a deprecation. We could also add metrics to track how much this is used, to see if it might become a problem.

2. Match only the scheme and host, ignoring the port number

We've learned that the internal Google test infrastructure makes it difficult (impossible?) to serve test web content from a known and consistent port number. We've run into this problem at times with the Chromium test infrastructure, but were able to work around it (e.g. origin_trials_browsertest.cc). We don't have explicit reports from other web developers, but it seems likely it would affect others. Tracking bug is crbug.com/1046826.

We already allow subdomain matching in tokens, as a relaxation of the strict origin check. Part of the rationale was that a subdomain token still provides reasonable attribution, because it's not possible for different entities (i.e. web developers), to register different subdomains on the same domain.

The port number is also optional in the trial registration process. It's possible to specify a port, but not required, and the port number is then defaulted to 80 (http) or 443 (https).

I propose to implement validation logic for port numbers similar to that for subdomains: either the port matches the token exactly OR the current port number is > 1024. While subdomain matching requires an explicit opt-in from the web developer, I don't see that as necessary for port numbers. It seems unlikely that a web developer would be serving a website on two different ports, and want to make a distinction in enabling a trial by port number.

What do the API owners think?

Thanks,

Jason

[Mason Freed]

Thank you Jason for the well thought out response to the needs posed by the WCv0 deprecation (among others). I'm sure this is obvious, but I wholeheartedly support both proposals. They sound reasonable, limited to only what's needed, and relatively low-risk.

Assuming you get agreement from the API owners, what is your target milestone for implementing these changes? I'm happy to help, if needed/desired.

Thanks,

Mason

[cha...@chromium.org]

On Wednesday, January 29, 2020 at 1:13:50 PM UTC-5, Mason Freed wrote:

Thank you Jason for the well thought out response to the needs posed by the WCv0 deprecation (among others). I'm sure this is obvious, but I wholeheartedly support both proposals. They sound reasonable, limited to only what's needed, and relatively low-risk.

Assuming you get agreement from the API owners, what is your target milestone for implementing these changes? I'm happy to help, if needed/desired.

I have a WIP CL for supporting file URLs (cl 2028935). If we get agreement on the proposal soonish, that's a candidate for M81 (assuming a merge is approved). Implementing the relaxed port matching seems straightforward, based on a draft CL I have (not uploaded). 

[cha...@chromium.org]

Pinging this thread. Any thoughts from the API owners?

Is there more data/research needed as input to a discussion? Or other next steps?

Thanks,

Jason

[Yoav Weiss]

#1 seems totally reasonable and is likely to affect developers everywhere. I'd also be supportive of applying it for non-deprecation trials, as it would make local verification easier. I also wonder if localhost shouldn't be included in it.

#2 has a bit more of a specific workaround feel to it - ignoring the port means that we're no longer indexing on origins, and at the same time, it's not looking at site as well (in the "same site" sense).

Is there another solution for the #2 problem? Have we talked to web security folks about potential implications here? (I can't think of any, but that doesn't mean they aren't there) 

--
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/515353d1-531c-4a59-acab-5b1efa3a469f%40chromium.org.