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

Thanks for the comments, @mnot and @lknik! 

To the point about splitting the values across multiple headers, I looked into the data we're collecting from clients with Chrome's experimental web platform features flag enabled based on a total of ~155M requests to 200 Google services. 

In this data set, we have 81 permutations of the four main values `(destination, target, site, cause)`. The top 10 most common permutations (e.g. `site=same-site, destination=image, target=subresource`) are seen in 90% of requests, and for the top 20 permutations this rises to 98% (note that this doesn't take into account Fetch's `mode` value because Chrome's implementation doesn't send it yet). Also, this is global data -- my guess is that for a given connection the number of permutations would be lower because requests would tend to have the same `site` field. I'm not sure how this distribution affects the HTTP header compression discussion, but I'd expect most servers to see a top-heavy distribution of values even if they were included in the same header.

>From a developer ergonomics point of view my guess is that having the information in a single header would be slightly easier to reason about -- servers will generally need to look at several of the values to make a security decision, and developers may need to do the same when debugging any rejected requests. That said, it's not a hill I'd want to die on; if the performance benefits of the split header approach are substantial and request size is our main remaining concern, I think it would still be workable.



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