Specifying trial tokens in HTTP headers

[Marijn Kruisselbrink]

Unless somebody else is working on this already, I'm starting to look into/work on making it possible to specify origin trial tokens in HTTP headers, since this is something I'll need for both foreign fetch and the related link rel=serviceworker support.

I think there are three parts to implementing this:

1) code in blink to make sure tokens in http headers are treated as if there were <meta> elements in the document

2) code in blink to add support for tokens in shared workers/service workers (and dedicated workers? although that might be separate if the conclusion was for those to inherit their tokens from the document that owns them).

3) API accessible from the browser process to validate tokens

I'm primarily interested in 2 and 3, since that's what will be needed for the features I'm working on, but it would probably be confusing if 1 isn't also implemented (and that part should be pretty easy anyway).

For 3 though, why does all the origin trial token related code currently live in content/renderer? I would have at least expected this to be in content/child, but for almost all of this code I don't understand why it isn't just in content/common instead. Any objections to just moving the code there?

Some related questions:

- name of the header? Probably something like X-Origin-Trials would work for now?

- when the header is supported it probably makes sense to change the meta tag to require <meta http-equiv=x-origin-trials" (or just "origin-trials") rather than <meta name="origin-trials" as it is now?

[Jason Chase]

Marijn,

As discussed on the Intent to Ship thread, there is an existing issue for adding support for an HTTP header (crbug.com/582045). No one is working on that yet, so it'd be great if you can get started. I am going to work on changing the meta tag to use http-equiv in M50 (see crbug.com/590349).

Separately, you mentioned the design doc for installing service workers. I did review earlier, but didn't really have any comments at the time. I'll need to dig in deeper, to make sure I'm understanding the relevant code.  The problem of code duplication is relevant to the EF as well. Both for the HTTP header vs meta tag, and for checks in the browser vs in Blink.  If you can solve that duplication that would certainly help.

Other comments inline below.

Thanks,

Jason

On Thursday, February 25, 2016 at 4:30:05 PM UTC-5, Marijn Kruisselbrink wrote:

Unless somebody else is working on this already, I'm starting to look into/work on making it possible to specify origin trial tokens in HTTP headers, since this is something I'll need for both foreign fetch and the related link rel=serviceworker support.

I think there are three parts to implementing this:

1) code in blink to make sure tokens in http headers are treated as if there were <meta> elements in the document

2) code in blink to add support for tokens in shared workers/service workers (and dedicated workers? although that might be separate if the conclusion was for those to inherit their tokens from the document that owns them).

3) API accessible from the browser process to validate tokens

I'm primarily interested in 2 and 3, since that's what will be needed for the features I'm working on, but it would probably be confusing if 1 isn't also implemented (and that part should be pretty easy anyway).

Hopefully it is easy to implement :-).  I think it might be more complicated, because we want to change how meta tags are currently handled.  As in crbug.com/588151, the current implementation unintentionally allows for meta tags injected via JavaScript. We need to fix that, and initial thinking was to move the extraction of meta tags to the preload scanner (or somewhere earlier in the page life cycle).

For 3 though, why does all the origin trial token related code currently live in content/renderer? I would have at least expected this to be in content/child, but for almost all of this code I don't understand why it isn't just in content/common instead. Any objections to just moving the code there?

Ian could add more details, if needed. As I recall, at least some of the trial token code was in content/common. But, there were some layering violations, and reviewer feedback that asked for it to be moved to content/renderer, until there was actually code using trial tokens outside of the renderer.

Some related questions:

- name of the header? Probably something like X-Origin-Trials would work for now? 

- when the header is supported it probably makes sense to change the meta tag to require <meta http-equiv=x-origin-trials" (or just "origin-trials") rather than <meta name="origin-trials" as it is now?

As above, I'm working on changing to http-equiv. I'm not sure about best practices for naming extension meta tags with a corresponding HTTP header. As suggested by Phistuck in the other thread, ideally the meta tag format would be stable starting with M50. I'm fine with X-Origin-Trials for the header, but if that implies using "x-origin-trials" for the meta tag, it would be good to sort that out now.

[Marijn Kruisselbrink]

On Fri, Feb 26, 2016 at 3:53 PM, Jason Chase <cha...@chromium.org> wrote:

Marijn,

As discussed on the Intent to Ship thread, there is an existing issue for adding support for an HTTP header (crbug.com/582045). No one is working on that yet, so it'd be great if you can get started. I am going to work on changing the meta tag to use http-equiv in M50 (see crbug.com/590349).

Sounds good. 

 

Separately, you mentioned the design doc for installing service workers. I did review earlier, but didn't really have any comments at the time. I'll need to dig in deeper, to make sure I'm understanding the relevant code.  The problem of code duplication is relevant to the EF as well. Both for the HTTP header vs meta tag, and for checks in the browser vs in Blink.  If you can solve that duplication that would certainly help.

I don't think there really is much of a risk of code duplication with regards to the EF. The actual token validation code can just move to content/common. Extracting tokens from various places is all pretty straightforward as well, since these will just be comma-separated lists, both in the header and in the meta tag. On the renderer side there are APIs to check if an experiment is enabled in an ExecutionContext, on the browser side I would at least want an API to check if an experiment is enabled in a net::URLRequest. But both those APIs will just delegate to the same "is this token valid for this experiment on this origin" API that already mostly exists.

 

Other comments inline below.

Thanks,

Jason

On Thursday, February 25, 2016 at 4:30:05 PM UTC-5, Marijn Kruisselbrink wrote:

Unless somebody else is working on this already, I'm starting to look into/work on making it possible to specify origin trial tokens in HTTP headers, since this is something I'll need for both foreign fetch and the related link rel=serviceworker support.

I think there are three parts to implementing this:

1) code in blink to make sure tokens in http headers are treated as if there were <meta> elements in the document

2) code in blink to add support for tokens in shared workers/service workers (and dedicated workers? although that might be separate if the conclusion was for those to inherit their tokens from the document that owns them).

3) API accessible from the browser process to validate tokens

I'm primarily interested in 2 and 3, since that's what will be needed for the features I'm working on, but it would probably be confusing if 1 isn't also implemented (and that part should be pretty easy anyway).

Hopefully it is easy to implement :-).  I think it might be more complicated, because we want to change how meta tags are currently handled.  As in crbug.com/588151, the current implementation unintentionally allows for meta tags injected via JavaScript. We need to fix that, and initial thinking was to move the extraction of meta tags to the preload scanner (or somewhere earlier in the page life cycle).

It actually seems like it is less complicated because of those planned changes? If you're changing how meta tags are handled, adding header support on top should really be rather trivial. Presumably you'll somehow store a list of trial tokens in the Document (or maybe more generally ExecutionContext?) at which point to support headers all that would be needed is to add those tokens to that same list.

 

For 3 though, why does all the origin trial token related code currently live in content/renderer? I would have at least expected this to be in content/child, but for almost all of this code I don't understand why it isn't just in content/common instead. Any objections to just moving the code there?

Ian could add more details, if needed. As I recall, at least some of the trial token code was in content/common. But, there were some layering violations, and reviewer feedback that asked for it to be moved to content/renderer, until there was actually code using trial tokens outside of the renderer.

Hmm, okay. Sounds like there should be no problems then to move code content/common where applicable.

 

Some related questions:

- name of the header? Probably something like X-Origin-Trials would work for now? 

- when the header is supported it probably makes sense to change the meta tag to require <meta http-equiv=x-origin-trials" (or just "origin-trials") rather than <meta name="origin-trials" as it is now?

As above, I'm working on changing to http-equiv. I'm not sure about best practices for naming extension meta tags with a corresponding HTTP header. As suggested by Phistuck in the other thread, ideally the meta tag format would be stable starting with M50. I'm fine with X-Origin-Trials for the header, but if that implies using "x-origin-trials" for the meta tag, it would be good to sort that out now.

Actually looking at this more, X-Origin-Trials would be bad, we should just use Origin-Trials (nor sure about plural/singular though) for the header and tag. See also https://tools.ietf.org/html/rfc7231#section-8.3 for the process for defining new http headers, and the explicit comment not to use "X-" for internet exposed headers. To register the header in the IANA registry we'd of course need to come up with an actual spec (although for a "provisional" registration it seems that spec can just be any document on the internet. For a "permanent" registration that spec would need to be more formal afaict).

[Jason Chase]

On Friday, February 26, 2016 at 7:20:15 PM UTC-5, Marijn Kruisselbrink wrote:

On Fri, Feb 26, 2016 at 3:53 PM, Jason Chase <cha...@chromium.org> wrote:

Marijn,

As discussed on the Intent to Ship thread, there is an existing issue for adding support for an HTTP header (crbug.com/582045). No one is working on that yet, so it'd be great if you can get started. I am going to work on changing the meta tag to use http-equiv in M50 (see crbug.com/590349).

Sounds good. 

 

Separately, you mentioned the design doc for installing service workers. I did review earlier, but didn't really have any comments at the time. I'll need to dig in deeper, to make sure I'm understanding the relevant code.  The problem of code duplication is relevant to the EF as well. Both for the HTTP header vs meta tag, and for checks in the browser vs in Blink.  If you can solve that duplication that would certainly help.

I don't think there really is much of a risk of code duplication with regards to the EF. The actual token validation code can just move to content/common. Extracting tokens from various places is all pretty straightforward as well, since these will just be comma-separated lists, both in the header and in the meta tag. On the renderer side there are APIs to check if an experiment is enabled in an ExecutionContext, on the browser side I would at least want an API to check if an experiment is enabled in a net::URLRequest. But both those APIs will just delegate to the same "is this token valid for this experiment on this origin" API that already mostly exists.

Sounds like a good plan. Minor quibble is that the design/implementation is currently one token per meta tag, with multiple meta tags used to specify more than one token.

 

Other comments inline below.

Thanks,

Jason

On Thursday, February 25, 2016 at 4:30:05 PM UTC-5, Marijn Kruisselbrink wrote:

Unless somebody else is working on this already, I'm starting to look into/work on making it possible to specify origin trial tokens in HTTP headers, since this is something I'll need for both foreign fetch and the related link rel=serviceworker support.

I think there are three parts to implementing this:

1) code in blink to make sure tokens in http headers are treated as if there were <meta> elements in the document

2) code in blink to add support for tokens in shared workers/service workers (and dedicated workers? although that might be separate if the conclusion was for those to inherit their tokens from the document that owns them).

3) API accessible from the browser process to validate tokens

I'm primarily interested in 2 and 3, since that's what will be needed for the features I'm working on, but it would probably be confusing if 1 isn't also implemented (and that part should be pretty easy anyway).

Hopefully it is easy to implement :-).  I think it might be more complicated, because we want to change how meta tags are currently handled.  As in crbug.com/588151, the current implementation unintentionally allows for meta tags injected via JavaScript. We need to fix that, and initial thinking was to move the extraction of meta tags to the preload scanner (or somewhere earlier in the page life cycle).

It actually seems like it is less complicated because of those planned changes? If you're changing how meta tags are handled, adding header support on top should really be rather trivial. Presumably you'll somehow store a list of trial tokens in the Document (or maybe more generally ExecutionContext?) at which point to support headers all that would be needed is to add those tokens to that same list.

I haven't really thought through what the implementation will look like.  But your idea sounds reasonable, so maybe it will be relatively simple. I guess I was defaulting to unknown = hard. 

 

 

For 3 though, why does all the origin trial token related code currently live in content/renderer? I would have at least expected this to be in content/child, but for almost all of this code I don't understand why it isn't just in content/common instead. Any objections to just moving the code there?

Ian could add more details, if needed. As I recall, at least some of the trial token code was in content/common. But, there were some layering violations, and reviewer feedback that asked for it to be moved to content/renderer, until there was actually code using trial tokens outside of the renderer.

Hmm, okay. Sounds like there should be no problems then to move code content/common where applicable.

 

Some related questions:

- name of the header? Probably something like X-Origin-Trials would work for now? 

- when the header is supported it probably makes sense to change the meta tag to require <meta http-equiv=x-origin-trials" (or just "origin-trials") rather than <meta name="origin-trials" as it is now?

As above, I'm working on changing to http-equiv. I'm not sure about best practices for naming extension meta tags with a corresponding HTTP header. As suggested by Phistuck in the other thread, ideally the meta tag format would be stable starting with M50. I'm fine with X-Origin-Trials for the header, but if that implies using "x-origin-trials" for the meta tag, it would be good to sort that out now.

Actually looking at this more, X-Origin-Trials would be bad, we should just use Origin-Trials (nor sure about plural/singular though) for the header and tag. See also https://tools.ietf.org/html/rfc7231#section-8.3 for the process for defining new http headers, and the explicit comment not to use "X-" for internet exposed headers. To register the header in the IANA registry we'd of course need to come up with an actual spec (although for a "provisional" registration it seems that spec can just be any document on the internet. For a "permanent" registration that spec would need to be more formal afaict).

It appears that registering the header is the easy part :-). The HTML spec defines http-equiv as an enumerated attribute (https://www.w3.org/TR/html5/document-metadata.html#pragma-directives). I'm taking that to mean we shouldn't simply add a new http-equiv value. For 100% correctness, it seems we would have to make changes to the HTML spec.  Given we're just launching the MVP, I think it's premature to start down that path. We should certainly get an understanding of what would be involved from a standards perspective. In the meantime, anyone gone through this, or similar, before?

Pending the outcome of the standardization issue, I think we should likely leave it as is for M50, with <meta name="origin-trials">.  Unless we have a firm answer on future standardization, we could end up making changes in the future anyway.

[Marijn Kruisselbrink]

On Mon, Feb 29, 2016 at 9:10 AM, Jason Chase <cha...@chromium.org> wrote:

On Friday, February 26, 2016 at 7:20:15 PM UTC-5, Marijn Kruisselbrink wrote:

On Fri, Feb 26, 2016 at 3:53 PM, Jason Chase <cha...@chromium.org> wrote:

Marijn,

As discussed on the Intent to Ship thread, there is an existing issue for adding support for an HTTP header (crbug.com/582045). No one is working on that yet, so it'd be great if you can get started. I am going to work on changing the meta tag to use http-equiv in M50 (see crbug.com/590349).

Sounds good. 

 

Separately, you mentioned the design doc for installing service workers. I did review earlier, but didn't really have any comments at the time. I'll need to dig in deeper, to make sure I'm understanding the relevant code.  The problem of code duplication is relevant to the EF as well. Both for the HTTP header vs meta tag, and for checks in the browser vs in Blink.  If you can solve that duplication that would certainly help.

I don't think there really is much of a risk of code duplication with regards to the EF. The actual token validation code can just move to content/common. Extracting tokens from various places is all pretty straightforward as well, since these will just be comma-separated lists, both in the header and in the meta tag. On the renderer side there are APIs to check if an experiment is enabled in an ExecutionContext, on the browser side I would at least want an API to check if an experiment is enabled in a net::URLRequest. But both those APIs will just delegate to the same "is this token valid for this experiment on this origin" API that already mostly exists.

Sounds like a good plan. Minor quibble is that the design/implementation is currently one token per meta tag, with multiple meta tags used to specify more than one token.

Ah, okay. In the header case comma-separated values and multiple headers should both be supported (and do the same), so it might make sense to do the same for the meta tag, but it's probably fine to require separate meta tags for multiple tokens as well.

 

Other comments inline below.

Thanks,

Jason

On Thursday, February 25, 2016 at 4:30:05 PM UTC-5, Marijn Kruisselbrink wrote:

Unless somebody else is working on this already, I'm starting to look into/work on making it possible to specify origin trial tokens in HTTP headers, since this is something I'll need for both foreign fetch and the related link rel=serviceworker support.

I think there are three parts to implementing this:

1) code in blink to make sure tokens in http headers are treated as if there were <meta> elements in the document

2) code in blink to add support for tokens in shared workers/service workers (and dedicated workers? although that might be separate if the conclusion was for those to inherit their tokens from the document that owns them).

3) API accessible from the browser process to validate tokens

I'm primarily interested in 2 and 3, since that's what will be needed for the features I'm working on, but it would probably be confusing if 1 isn't also implemented (and that part should be pretty easy anyway).

Hopefully it is easy to implement :-).  I think it might be more complicated, because we want to change how meta tags are currently handled.  As in crbug.com/588151, the current implementation unintentionally allows for meta tags injected via JavaScript. We need to fix that, and initial thinking was to move the extraction of meta tags to the preload scanner (or somewhere earlier in the page life cycle).

It actually seems like it is less complicated because of those planned changes? If you're changing how meta tags are handled, adding header support on top should really be rather trivial. Presumably you'll somehow store a list of trial tokens in the Document (or maybe more generally ExecutionContext?) at which point to support headers all that would be needed is to add those tokens to that same list.

I haven't really thought through what the implementation will look like.  But your idea sounds reasonable, so maybe it will be relatively simple. I guess I was defaulting to unknown = hard. 

 

 

For 3 though, why does all the origin trial token related code currently live in content/renderer? I would have at least expected this to be in content/child, but for almost all of this code I don't understand why it isn't just in content/common instead. Any objections to just moving the code there?

Ian could add more details, if needed. As I recall, at least some of the trial token code was in content/common. But, there were some layering violations, and reviewer feedback that asked for it to be moved to content/renderer, until there was actually code using trial tokens outside of the renderer.

Hmm, okay. Sounds like there should be no problems then to move code content/common where applicable.

 

Some related questions:

- name of the header? Probably something like X-Origin-Trials would work for now? 

- when the header is supported it probably makes sense to change the meta tag to require <meta http-equiv=x-origin-trials" (or just "origin-trials") rather than <meta name="origin-trials" as it is now?

As above, I'm working on changing to http-equiv. I'm not sure about best practices for naming extension meta tags with a corresponding HTTP header. As suggested by Phistuck in the other thread, ideally the meta tag format would be stable starting with M50. I'm fine with X-Origin-Trials for the header, but if that implies using "x-origin-trials" for the meta tag, it would be good to sort that out now.

Actually looking at this more, X-Origin-Trials would be bad, we should just use Origin-Trials (nor sure about plural/singular though) for the header and tag. See also https://tools.ietf.org/html/rfc7231#section-8.3 for the process for defining new http headers, and the explicit comment not to use "X-" for internet exposed headers. To register the header in the IANA registry we'd of course need to come up with an actual spec (although for a "provisional" registration it seems that spec can just be any document on the internet. For a "permanent" registration that spec would need to be more formal afaict).

It appears that registering the header is the easy part :-). The HTML spec defines http-equiv as an enumerated attribute (https://www.w3.org/TR/html5/document-metadata.html#pragma-directives). I'm taking that to mean we shouldn't simply add a new http-equiv value. For 100% correctness, it seems we would have to make changes to the HTML spec.  Given we're just launching the MVP, I think it's premature to start down that path. We should certainly get an understanding of what would be involved from a standards perspective. In the meantime, anyone gone through this, or similar, before?

I don't think http-equiv is any different from the existing <meta name=>. There is a whatwg wiki page to register new http-equiv values, similar to the one for new name values.

 

Pending the outcome of the standardization issue, I think we should likely leave it as is for M50, with <meta name="origin-trials">.  Unless we have a firm answer on future 

standardization, we could end up making changes in the future anyway.

Agreed. 

--
You received this message because you are subscribed to the Google Groups "experimentation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/d3908b78-f8c1-4d68-bfde-bd745496eee5%40chromium.org.

[Jason Chase]

We consulted with some standards gurus with respect to changing to use http-equiv on the meta tags. The overall guidance was to go ahead and make the change in M50 to use http-equiv. That is, we shouldn't block the change on waiting for standardization, and cause churn for developers later. For HTML standardization/spec changes, it was suggested that we can defer that until we decide that the EF itself should be standardized across browsers.  This means that sites using the EF will not pass conformance checks, but if needed we could explain that away in developer documentation (tradeoff for participating in experimentation).

Given this guidance, I'm going to work on the meta http-equiv change, with the goal of getting that into M50. It seems pretty clear we want that change, to line up with the HTTP header support.

Thanks,

Jason

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.

[Jason Chase]

I have a CL ready to change to use http-equiv on the meta tags (https://codereview.chromium.org/1756193002/). There was a question about whether the HTTP header name is finalized, if we want to avoid change in the future.

I realize we hadn't made an explicit decision about the header name. In my CL I was assuming we're still using "origin-trials" as the name. From earlier in this thread, we ruled out using an "X-" prefix on the HTTP header name. Another question was about a singular vs plural name. I think that the plural name makes the most sense, as the HTTP header will support a list of tokens, and the meta tag could be extended to do the same.

I'm going with "origin-trials" as the header name, and will update the related issues to reflect this naming (crbug.com/582045 and crbug.com/590349). If anyone has a different opinion, feel free to weigh in on one of the issues. However, I'm planning to land the CL today, so it can merged to M50 as soon as possible.

Thanks,

Jason

[Marijn Kruisselbrink]

I don't feel particularly strongly either way with regard to singular vs plural, but I'd slightly lean towards singular. Most existing HTTP headers seem to be singular, and the comma separated syntax is mostly just a shortcut for having multiple copies of the same header. But if you prefer plural that's fine with me too, assuming the meta tag will actually allow multiple tokens in one tag as well.

Jason

Thanks,

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/d3908b78-f8c1-4d68-bfde-bd745496eee5%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "experimentation-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation...@chromium.org.
To post to this group, send email to experimen...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/3b6d8b58-ab46-4ed5-88b9-881160f54558%40chromium.org.

[Jason Chase]

That's a reasonable argument for using a singular name. I don't have a good counter argument, other than I'm used to seeing "origin-trials" :-)  Going back to when it was "api-experiments", I believe the plural was an explicit choice over singular, but I don't remember a good reason (coin flip?).

After looking at test pages using "origin-trial" vs "origin-trials", I'm becoming more convinced that singular makes more sense. Also, it's easier to explain if we don't get around to allowing multiple tokens in one meta tag.

So, let's go with <meta http-equiv="origin-trial">.  Updates to the various issues to follow, for posterity.

Thanks,

Jason

Jason

Thanks,

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/experimentation-dev/d3908b78-f8c1-4d68-bfde-bd745496eee5%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "experimentation-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to experimentation-dev+unsub...@chromium.org.
To post to this group, send email to experimentation-dev@chromium.org.