Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

> On 24 Nov. 2016, at 3:14 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 24 November 2016 at 13:28, Mark Nottingham <mnot@mnot.net> wrote:
>> Biggest change in this revision is restricting site-wide headers to a
>> whitelist + a prefix ("site-"). Feedback appreciated.
> 
> So the intent is to signal to the client that the header field is
> valid for inclusion in the site-wide headers?  Doesn't that make it
> odd when you have a header field (like CSP) that is perfectly valid on
> a per-resource basis?  Isn't a blacklist easier to work with?  I
> realize that doesn't give any potential HTTP overlords the ability to
> control what appears, but nonsensical responses will be created with
> or without blessing from upon high.

No, but interesting guess. 

I sketched in a whitelist because site-wide headers are the exception, not the rule, and the designer of the header should really opt into it. Requiring a known prefix and whitelisting existing headers gives you that.

Happy to talk about other approaches, of course, but hopefully with better motivation than you've described.


> You don't describe the consequences if someone puts a Date header
> field in a site-wide resource.  You only say not to.

Where do I say not to?


> The example of CSP is particularly enlightening: it has very strict
> combining rules:
> https://w3c.github.io/webappsec-csp/2/#enforcing-multiple-policies
> These rules mean that a site-wide CSP can be deployed, but it would
> have to be permissive enough to permit the union of all valid policies
> for every resource on the origin.  That's certainly possible, but
> potentially inconvenient.  Deploying CSP is already a nightmare.

Yes. I've never liked that aspect of CSP, but apparently it's necessary for security. IIRC Mike has been working on a default / base CSP policy spec, but I couldn't find it in a quick search of the usual places; Mike? If that gets traction, maybe it should be here instead of CSP.


> Text describing how site-wide and local header fields are combined
> might help point in the right direction.

It says append. I suppose I could monkey-patch Fetch, if there's interest. Although in many ways, this kind of happens at a layer "below" Fetch.

> You say that site-wide headers are appended, but the natural thing to
> do when you hit HS is to insert.

Mmm, dunno. I think it depends a lot on your implementation. I'm not against that approach, but append seems more... stable (and thus easier to debug?).


> P3P lives!

Unfortunately. <https://www.w3.org/TR/P3P/#Appendix_Working>. You're welcome. 


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 24 November 2016 05:40:50 UTC