Review origin policy.

[mikewest]

Strawman spec: https://mikewest.github.io/origin-policy/

WICG thread at https://discourse.wicg.io/t/proposal-set-origin-wide-policies-via-a-manifest/1617

public-webappsec@ thread at https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0046.html

Initial conversations seem pretty positive: perhaps this is something I can briefly introduce tomorrow, @torgo?

[hadleybeeman]

@mikewest, just checking — is this still in progress?

[mikewest]

The document moved to https://wicg.github.io/origin-policy/, but otherwise yes. I owe @mnot some feedback on his suggestions in the thread starting at https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0553.html, and I don't think it's on our implementation roadmap for Q1, but feedback would be very welcome. I think it's an important primitive, and I think y'all might have helpful ideas with regard to the interaction with app manifest/everything else.

[triblondon]

Picked up at Boston F2F. We found a number of issues we wanted to discuss, so we invited @mikewest to join us, and he was kind enough to do so. Despite connection difficulties on the call, we covered:

• Use of /.well-known/: We don't really like using hard coded paths, and also feel that there's an element of making things difficult intentionally to avoid foot-guns. However, this technique guarantees that the author controls the origin, and enables pre-fetching. We didn't come to a conclusion on that.
• Path prefixes / URL tree subsetting: Could we see potential for a sub-origin policy? Maybe not, but it would be good to reason about this.
• Headers vs content body tags: Making this settable only via a header is unfortunate but understandable. On the performance basis, it wouldn't be reasonable to make a synchronous request later in page processing and as regards ownership, we note that control over headers is frequently argued to indicate server environment ownership (vs. control of content, which often does not). We'd like to discourage other specs from adopting this pattern without similar justification, tho.
• Combinability with web app manifest: It seems like these should be the same thing, maybe with origin policy living under a single top level key in the manifest data model. Some practical issues here but we'd like to see this overcome if possible to avoid the complexity of having different techniques.
• Vary header: We were not sure why a Vary header was needed on the response. Answer is because for clients that don't support origin policies, the server would need to include all the normal headers that would otherwise be omitted.
• HTTP2 header caching: We are not sure how much value there is in origin policy when HTTP/2 will eliminate all the header cruft in practice anyway via header compression and caching.

[mnot]

I'm confused at the first bullet above -- .well-known has been through the standards process, and the TAG didn't object to it at the time. W3C has used "hard coded paths" in the past (e.g., P3P.xml). Sometimes it's necessary to have origin-specific data in a priviledged place; that's what wellknown is for.

Manifests are a very different thing and the use cases shouldn't be combined just because they look like each other.

The Vary header is necessary because of intermediary caches, and because that's how HTTP works.

HTTP/2 is not a license to have verbose headers; they compression context is limited in size, and can't expand infinitely (as this becomes a server resource issue). As I explained in my draft, H2 header compression is oriented to the connection -- meaning a server has to keep a compression context per connection -- whereas origin policy is oriented to the origin, so only one per origin has to be kept server side.

[torgo]

As discussed in Tokyo F2F:

@mnot the TAG concedes your point on .well-known.

Also, agreed webapp manifest is different in that you can have multiple webapp manifests on one origin and the location is user-settable.

[dbaron]

One other interesting question that came up was how this interacts with suborigins (if they become a thing).

[annevk]

It doesn't interact with them. We could make it pre-requisite for suborigins and flip the design of suborigins. That would give us per-suborigins cookies possibly, but nobody expressed a desire for that.

One thought I had reading this issue summary is that "origin policy" is awfully close to "same-origin policy", but maybe that's not a big deal.

[dbaron]

Maybe "origin-wide policy" would be a less ambiguous name?

I admit I don't know enough of what the plan is for suborigins to know what your response ("flip the design") means, but I'm happy about it if people who understand the design of both think things are ok.

[dbaron]

So the TAG just had a bit more discussion about the interaction between origin-policy and web app manifest. A number of ideas got thrown around (probably starting with the first and then moving to the second):

• the possibility of putting web app manifest stuff into the origin policy
• the possibility that a developer could, on their own, choose to use the same file as both the origin policy file and the web app manifest file (and even have the origin policy link to itself as the web app manifest by adding a site-wide Link: header). This just requires that the two specs have lenient parsing (we think they do) and avoid conflicting keys.

We think there are two advantages to this:

• reduction in round trips to the server
• reduction in developer complexity for what we think will be common cases, where there's a 1:1 mapping between the origin and the webapp

@triblondon also suggested the name "origin manifest" to replace "origin policy", which a bunch of us seem to like.

@triblondon also suggested more merging of the formats, where the manifest concept has two different levels of what can be set, app-wide, and origin-wide. I'm a little concerned about the potential confusion that some manifests (those not in .well-known) wouldn't be able to set the origin-wide ones.

We had some discussion about HSTS and whether the ability to set HSTS from any page in the origin (without, e.g., the ability to control /.well-known/) is a mistake that this specification offers a path to fixing (i.e., that applying HSTS to the entire origin belongs in the origin policy instead).

We're curious what others think about these ideas.

[domenic]

Just speaking as a lurker, I like the idea of merging the two files via developers taking advantage of the lenient parsing. I don't know about going further; I think it makes sense to let it just occur as a happy accident of compatible formats for origin-wide web apps.

This requires a bit of coordination to avoid top-level key clashes, of course. That might be a tricky coordination problem that sinks the idea in the end, but it's worth investigating at least.

[triblondon]

It's also worth noting that we acknowledge the sync/async differences in the delivery mechanisms for web app manifest and origin policy / origin manifest, and accept that the proposed mechanism for the latter is necessary to enable some synchronous behaviours defined in the policy, while also acknowledging the performance trade off. If a developer wanted only web app properties, they would still be able to use the async link method, but if they intend to use properties such as headers, and therefore opt to use the sync link method, then there's no performance downside to adding the web app properties in there as well.

[annevk]

I personally think that manifests were designed incorrectly for this reason and that we should therefore slowly let origin-wide policy (I like it) take over.

[annevk]

To explain a bit on suborigins. Currently a suborigin is created once you see a response for a request that ends up creating a global object of sorts, based on a header that contains an identifier. So you don't know ahead of time whether something will end up being a suborigin and therefore you can't do things like give them different cookies.

Now, if you changed that and required an origin-wide policy, you could say how URLs within an origin map to a suborigin and the user agent would then know that ahead of time. That has some benefits in that you can do things like suborigins cookies. Drawbacks are gating the feature on origin-wide policy working out and making it harder to setup new suborigins on large sites (as it's tightly coupled with management of a single resource).

[mnot]

@triblondon I'm not sure what you're saying above, but I think we agree.

Origin policy is currently defined to be loaded before a browser interacts with a site:

User agents can be instructed to synchronously download and process this manifest before completing a navigation to an origin’s resources, ensuring that the policy contained therin will be safely applied to each resource, and allowing the server to skip the overhead of including the relevant headers with each response. Typically, the server can speed things up even more by using HTTP/2 Server Push ([RFC7540], section 8.2) to proactively send the manifest file along with the response to the user agent’s first request.

Since it's on the critical path for a first page load, it's performance-critical, and I'd be wary of putting information in it that isn't necessary for that purpose.

AFAICT, Manifest's use cases can be met by loading something synchronously in the background, or upon a user interaction that triggers needing it. It doesn't need to be in OP, and indeed might hurt there.

It might make sense to reuse OP's syntax and processing, but separate out Manifest's use cases into a separate resource whose load time is tailored to Manifest's use cases.

I'd also caution against making OP a directory of every possible interaction with the origin (e.g., putting links to other things in it); that will cause bloat pretty quickly.

[mnot]

FWIW there was also this discussion (thread):
http://www.w3.org/mid/FCDFC352-5D68-456F-AFF4-39E9E1697AF2@mnot.net

[annevk]

AFAICT, Manifest's use cases can be met by loading something synchronously in the background, or upon a user interaction that triggers needing it. It doesn't need to be in OP, and indeed might hurt there.

I think that's only the case if you take the installation view of manifests, which is probably how they've been implemented thus far (I haven't really followed closely). If you take them as providing UI information about the site you're about to visit, it's definitely information you want to be able to display to the user as soon as possible.

[mnot]

Maybe. But do you want to block consumption of all other responses from that origin until it's completely consumed?

[annevk]

Yeah, you're correct that there's a substantial difference between requesting a subresource and navigating. Maybe that difference needs to be exposed somehow so the response can be appropriately tuned.

[plinss]

Discussed 2017-05-23 with Mike West, will follow up next f2f

[domenic]

Hi TAG,

We've revived work on this after a couple years off. Would the TAG be interested in a new review (e.g. following the latest issue template), or do we feel that things were settled last time around?

The changes made to the spec since then have mostly not been in areas that drew the TAG's attention according to the above discussion.