Intent to Implement: Origin Policy

[Daniel Hausknecht]

Contact emails

dhaus...@google.com, mk...@chromium.org

Spec

https://wicg.github.io/origin-policy/

https://github.com/w3ctag/design-reviews/issues/127

https://github.com/w3ctag/meetings/blob/a9c7fc4109bb2ec58c632de8bdfd7ab209e74b8f/raw-minutes/2017-05-23-minutes.md

Summary

Origin Policy aims to provide servers with the ability to configure various settings with origin-wide impact. The goal is to provide a home for existing origin-wide configuration options like Strict-Transport-Security (HSTS), and extend those configurations with other useful settings. For example, it will give developers the ability to set a baseline Content Security Policy (CSP), assert default CORS settings, and so on.

Motivation

Web servers can set HTTP headers with origin-wide impact, for examples Strict-Transport-Security (HSTS) or Public-Key-Pins (HPKP). A clean way to define such settings is missing from the platform as it applies today. A seemingly harmless response of a slightly misconfigured web app can dramatically impact everything  else under the same origin. Origin Policy aims to fill this gap by providing a centralized configuration point for the entire origin.

But Origin Policy has the potential to do even more. We envision

• baseline options which apply to every response. For example a HSTS header must no longer be sent with every response which highly reduces redundancy.

• fallback options which apply whenever a configuration was not explicitly set. For example a web app might forget to set a CSP for its error page. A fallback CSP however can step in at this point and secure the page.

• CORS settings which can boost performance by providing preflight responses.

Origin Policy will not be limited to the above mentioned headers and options but also seems like a useful primitive which will give us a flexible extension point for the configuration options we want to add to the web platform in the future.

Interoperability and Compatibility Risk

None. The mechanism is designed such that it notifies the server if the user agent implements it. The server can then decide to use this feature or not. We therefore do not see any risks for interoperability and compatibility.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

ttps://crbug.com/751996

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5708023506927616

Requesting approval to ship?

No.

[Daniel Hausknecht]

The design doc can be found on https://docs.google.com/a/google.com/document/d/1boSantI96cOefT4UUSdEMzniXn_Es6UvxSbLzsASLwQ/edit?usp=sharing

Please note that we intent to rename it. Therefore everything is named Origin Manifest instead of Origin Policy in this document. This hopefully avoids confusion with the same-origin policy.

[Daniel Hausknecht]

Please ignore the previously posted link which is not accessible (my sincere apologies).

The design doc can be found on https://docs.google.com/document/d/e/2PACX-1vQpEp41ygL1sA6EL2roPEk8UK3hT-HEQD7Sr-W13e6DNetp49mQ_L6M57thFWyl-bIuMNGZOMwfHa5z/pub

Please note that we intent to rename it. Therefore everything is named Origin Manifest instead of Origin Policy in this document. This hopefully avoids confusion with the same-origin policy.

On Friday, August 4, 2017 at 3:09:31 PM UTC+2, Daniel Hausknecht wrote:

[Lucas Garron]

For any automated scanners that check HSTS headers for a given domain, how do we best determine "the HSTS header" for a given domain?

From what I can tell, getting it from the origin policy goes like this:

1. Make a request to / and see if there's a Sec-Origin-Manifest header.

2. If so, follow that URL and parse the JSON for the "headers" field and search the list inside it for the desired name.

The HSTS spec specifies that the first HSTS header is to be processed:

https://tools.ietf.org/html/rfc6797#section-8.1

Is it/should it be against spec to specify an HSTS header more than once in the origin policy?

If Sec-Origin-Policy is sent in addition to one or more HSTS headers, which takes precedent?

Does the order of the first HSTS header and the Sec-Origin-Policy header matter?

While we're at it, how should clients handle multiple Sec-Origin-Policy headers?

Should clients still expect to see the headers in the origin policy on the request itself, if they don't indicate that they support (or have cached) an origin policy?

If the site specifies an origin policy but no HSTS header to *all user agents*, then Firefox will not pick up preloaded entries unless they upgrade their preload list roller to take into account the origin policy. Do we expect them to?

Also, should we expect to see `origin-polici` in the well-known URI list soon?

http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

Apologies if any of the questions are naïve, but I want to be careful not to make HSTS less fragile than it already is.

(There are already lots of cases where sites are not sending headers that match best practice, often by accident. And of course there is still no great standard way to tell a user agent to pick up HSTS for a related origin.)

»Lucas

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/94366565-7dbf-4797-b86d-0dff0592f129%40chromium.org.

[Daniel Hausknecht]

Thanks Lucas for your interesting questions. Generally speaking we do not introduce new behaviour to mechanisms which already exist. But we take our freedom to parse the manifest file as we see fit. That is, in case of multiple "hsts" in the manifest file, this is what we need to solve internally.

That much said, let me answer your particular questions.

> Is it/should it be against spec to specify an HSTS header more than once in the origin policy?

> If Sec-Origin-Policy is sent in addition to one or more HSTS headers, which takes precedent?

> Does the order of the first HSTS header and the Sec-Origin-Policy header matter?

We currently implement a JSON schema which is based on https://github.com/WICG/origin-policy/issues/19#issuecomment-321229817. Basically we moved away from a list of headers to a object with the keys as the configuration option. So implicitly the have a behaviour through JSON (only the last definition is taken into account). But I think it should be explicitly defined nevertheless as you motivate with your questions. I filed a bug on Github https://github.com/WICG/origin-policy/issues/35

> While we're at it, how should clients handle multiple Sec-Origin-Policy headers?

ATM this is not explicitly defined. I also filed a bug on https://github.com/WICG/origin-policy/issues/36

> Should clients still expect to see the headers in the origin policy on the request itself, if they don't indicate that they support (or have cached) an origin policy?

Your question is which headers should be set when actually downloading the manifest file, correct? In the end it is a basic file download. So we do not do anything fancy here. For example in case a `Sec-Origin-Policy` header is set we simply ignore it because this is what we are currently doing anyway. Similar for HSTS since we only support this whole mechanism when going over HTTPS. CSP is never applied since there is no context etc.

> If the site specifies an origin policy but no HSTS header to *all user agents*, then Firefox will not pick up preloaded entries unless they upgrade their preload list roller to take into account the origin policy. Do we expect them to?

The mechanism we define is a better way to configure your origin (actually there is no good way atm). In case HSTS is not configured as part of a manifest file it is like not sending the HTTP header. Therefore we guarantee to download the manifest file before the response is processed to make it as if the header was actually set in the response itself.

> Also, should we expect to see `origin-polici` in the well-known URI list soon?

Hopefully yes. But I personally want to see the spec / draft to mature a bit first. Your questions certainly helped already a bit :-)

> Apologies if any of the questions are naïve

Absolutely not. You ask the right questions and I would be happy to get even more!

With that, thanks again for your feedback. Best

-Daniel

[Lucas Garron]

Thanks for the reply, and for filing the bugs!

I'll follow those bugs and file some more if I think of more complications. 😊

»Lucas