I gave you some feedback in e-mail and never heard back, I imagine you’re busy
Sorry for the delay, @mnot. As it happens, I have been the opposite of busy! Beaches are nice.
Using JSON means that encoding / decoding needs to happen, which means that errors (especially authoring errors) are more likely. My inclination is to just reuse HTTP headers’ textual format; it’s the lowest-friction way to do this, rather than having to worry about converting UTF-8 to ASCII, etc.
I agree that plaintext ASCII is simpler to parse than JSON. I think I disagree that that complexity would introduce authoring errors, simply because JSON is very well-understood by the developer audience I’m targeting. There’s good tooling available for the format in itself, validators could be written, etc. From an authoring perspective, the difference between:
is pretty trivial. It’s not nothing, certainly, but it doesn’t seem fatal.
This more structured format also enables the
baseline distinction on a per-header basis, which seems pretty valuable in terms of allowing per-resource overrides of origin-level defaults. This could, of course, be added to your proposal via some structure. I don’t think the format is really the major difference in approach.
Your spec adds origin-wide flags (
unsafe-cors-preflight-with-credentials) that are specific to this format. I’m not crazy about having yet another configuration mechanism that people need to understand; one of the big benefits of relating the well-known location’s contents to headers was that It’s Just Headers.
This is the big difference, and as it turns out, this is actually the thing I like most about my proposal.
I agree that “It’s Just Headers” is super-appealing. However, I don’t think we can/should build features like the CORS bits with headers. Headers are resource-specific, and allowing them to assert origin-wide properties is problematic.
If we want to create a mechanism for setting site-wide policy, I think we ought to do it explicitly by divorcing those policies from resource-specific headers. That is, I’d prefer to deprecate existing origin-wide headers like
Strict-Transport-Security by moving them to this kind of inherently origin-wide policy declaration.
It’s important to consider what happens when responses that omit headers are cached; that probably involves requirements to emit
Very true. I didn’t think about that at all. I added a tiny note in https://github.com/mikewest/origin-policy/commit/6ad70deeb2bd3ea428d9b3f6711a60e3d23e274d#diff-117d6498d2aa8019cc0abf5eeb87a9fa, and I’ll expand upon it going forward.
How does this interacts with intermediaries? Either it’s end-to-end (in which case, the omitted headers are effectively hidden from proxies, reverse proxies, CDNs, server-side frameworks, etc., unless they also implement this spec), or it’s hop-by-hop (in which case it’s harder to deploy, and tricky to get right; different in H1 vs H2). I went for the former. In your spec, this is probably just some advisory text.
I’d envisioned this as end-to-end, and really only looked at it from the perspective of the server and the browser. I suspect you have some opinions about what this would mean for intermediaries that need to understand things like the omitted headers?
I think you’re using different resources (e.g., /.well-known/origin-policy/policy-1) for versioning, not to allow multiple policies to be active for a site at the same time - correct?
Correct. One policy is set for the origin, and it’s just a resource like any other, with the same request semantics and caching rules as any other resource. That means that
ETag would certainly be one way of versioning the policy, and it might work really well for lots of users.
I’m not sure it would be the only mechanism that works, however, given the tight binding between the manifest’s effects and the application-layer logic that determines the headers sent by the origin. My understanding here might be outdated, but my understanding is that infinite-lifetime, unique URLs are best practice for a site’s resources (images, etc). This feels like a pretty good model to support with the manifest as well.
You use the same header field name (
Sec-Origin-Policy) both as a request and a response header, with different semantics and syntax. Doing that has been confusing for developers and admins in the past; please consider using two header field names.
Hrm. Ok. Inventing more headers seems more complicated, but I’m open to distinctions between the request and response if that’s helpful.
I’m not too fussed about venue, but because this touches HTTP so closely, it’d be good to at least coordinate with the HTTP WG.
Very happy to!
Thanks again for your feedback! I look forward to more conversation, especially about the origin-wide vs resource-specific distinction raised above.