Re: [w3ctag/design-reviews] `sec-metadata` (#280)

Hey @dbaron, thanks for the feedback!

I'd actually appreciate y'all spending a little more time on this in the somewhat near future, as it's something that turned out to be trivial to implement, and that doesn't seem controversial from the (few) conversations I've had with other vendors. It's feasible that we could ship it in the somewhat near future, and your feedback would be really helpful in ensuring that we do that in the right way.

I'll also note that I started sketching out a more detailed spec at https://mikewest.github.io/sec-metadata/, which might relieve some of your interop concerns below. :)

To the line-by-line:

> mitigating CSRF is a worthwhile problem to work on

I agree! Google's security folks are enthusiastic about this mechanism, and I'd like to let them loose on it in the wild.

> it seems like the underlying problem here is use of ambient authority in unexpected ways.

I think that's accurate. The goal here is to give developers on the server enough context to make more informed decisions before doing all the work of putting together a response and delivering it to the client. Rather than relying on client-side rules (e.g. MIME type checks a la CORB), we can perform checks on the server that enable _a priori_ decision-making, therefore avoiding things like timing attacks which are otherwise pervasive.

> It seems like there could be alternatives that would reduce the scope of the ambient authority

`SameSite` cookies are good at reducing ambient authority. They're also somewhat difficult to deploy effectively. I happen to think it's worth the effort for things like CSRF tokens, but developers have yet to practically agree with me by doing the work. :)

This proposal has some deployability advantages insofar as it doesn't require rearchitecture, renaming, or etc. All the server needs to do is read a header and make decisions. In many cases, those decisions can even be abstracted out of the application code itself, and into frontend servers which might be maintained and hardened by an entirely different team. I think that's very much worth exploring.

I'd also note that things like `SameSite` cookies address only the `same-site`/`cross-site` portion of the proposal's [`site`](https://mikewest.github.io/sec-metadata/#site-member) member. It doesn't allow `same-origin` distinction, which is helpful in many cases, and doesn't address [`destination`](https://mikewest.github.io/sec-metadata/#destination-member), which is just as (more?) important (and without existing analog).

> the header isn't tiny, and seems like it will be sent on every request

I agree that the size is a possible concern. That said, if it's something we ship, I'm pretty sure we can minimize the impact by tweaking the H/2 compression dictionary. We're just uploading ~4 enums, after all. The values remain static over time, and should be quite compressable.

> it seems like it might be quite a bit of work to get browsers to produce interoperable statements

We're actually already exposing the most complext bit of information via Service Workers (see `Request.destination` for example), so I expect that the interop work there will be minimal.

The `user-activated` vs `forced` distinction will be tougher to get interoperably working in the various edge-cases, but since that reflects a deeper set of disagreements between browsers' determinations of what constitutes a "gesture", it's not clear to me that exposing those differences to servers is doing any harm (and might lead to more interop work in the future).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/280#issuecomment-394577738