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

> Splitting document seems potentially breaking, but I wouldn't mind trying to use nested-document for frames.

Breaking insofar as folks might be looking at the `destination` value in a Service Worker?

> I'd prefer destination=fetch, with no string values. <link rel=preload as> takes a potential destination, as defined by HTML.

Turns out, @mnot removed bare identifiers as valid dictionary values in https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-05#appendix-A.1 (https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-05#section-4.4). It's strings or nothing.

> The way it relates to #76 is that #76 is about the fetcher having to know how to fetch the resource. This seems to make that worse as this allows the resource to make that much more granular (e.g., only providing a response when destination is font).

The goal is indeed to allow the server to make more granular decisions about when to service a request. I'm claiming that as a substantial advantage. :)

> Given that according to https://www.arturjanc.com/cross-origin-infoleaks.pdf SameSite cookies provide the same level of defense, it's unclear that it's worth the tradeoff.

`SameSite` does not offer the same defenses (perhaps the table we put in that doc wasn't quite detailed enough :) ). It allows folks to distinguish cross-site vs same-site requests (which is valuable!). It does not allow folks to distinguish between request types for endpoints which expect cross-site usage. `SameSite` also seems quite a bit more difficult to deploy in a robust manner.

-- 
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-394600115