CORS integration

[annevk]

I think we'd have to be extremely careful if we didn't require CORS (and given that most new things require CORS anyway it's not clear it's worth the hassle). And if we require CORS we need to consider whether the user agent can poke through the lack of Access-Control-Expose-Headers for these new response headers or not.

[mikewest]

I don't think anything in this proposal changes the CORS requirement; that really does seem mandatory for signatures and hashes alike.

I don't think it's necessary that we expose those headers, but I can see an argument that unless the headers are exposed, there's some information leakage based on the key used for signing (e.g. the contents of Signature-Input)? Is that what you're concerned about here, or have I missed your point?

[annevk]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

As for exposing headers, I think ideally user agents would be able to use https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name deep in the networking subsystem to identify which headers to share with their caller. If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Not sure if there's an actual leak or not. Perhaps if the server was not expecting the browser to make use of headers that are not part of the safelist, which kinda is the desirable model.

[mikewest]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Assuming we run with #16, would you suggest adding Signature, Signature-Input, and *-Digest to the safelist? That doesn't initially seem unreasonable to me, and could clarify the ways in which delivering those headers might impact response handling.

[annevk]

Either we add them to the safelist or we require them to be specified by ...-Expose-Headers.

[mikewest]

Ok, thanks!

I'll add a monkey-patch to the doc once we work out what which headers we're planning to rely upon and evaluate their content. I know I'm not familiar enough yet with Signature and Signature-Input to judge risk. Assuming no surprises, I'd prefer adding them to the safelist, but we can evaluate that together later.

[ddworken]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

So I think the idea here was that it might not be necessary since signature-based SRI wouldn't provide any visibility into the contents of the response (unlike hash-based SRI, which allows probing against specific hash values). Though I do tend to agree that it is better to just keep the CORS requirement to avoid the complexity/risk here.

[estark37]

For posterity, I understood the argument against CORS requirement to be that the developer would have to add a header to the resource to serve the signature, and adding that header could be interpreted as opt-in for some information about the resource to be obtainable cross-origin. But I agree that it's not worth the complexity.