-
Notifications
You must be signed in to change notification settings - Fork 58
Review origin policy. #127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@mikewest, just checking — is this still in progress? |
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. |
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:
|
I'm confused at the first bullet above -- Manifests are a very different thing and the use cases shouldn't be combined just because they look like each other. The 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. |
As discussed in Tokyo F2F: @mnot the TAG concedes your point on Also, agreed webapp manifest is different in that you can have multiple webapp manifests on one origin and the location is user-settable. |
One other interesting question that came up was how this interacts with suborigins (if they become a thing). |
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. |
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. |
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):
We think there are two advantages to this:
@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 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 We're curious what others think about these ideas. |
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. |
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 |
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. |
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). |
@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:
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. |
FWIW there was also this discussion (thread): |
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. |
Maybe. But do you want to block consumption of all other responses from that origin until it's completely consumed? |
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. |
Discussed 2017-05-23 with Mike West, will follow up next f2f |
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. |
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?
The text was updated successfully, but these errors were encountered: