Sandboxing

[annevk]

I discussed with @clelland the idea that perhaps we should tell sites they're being sandboxed (or restricted in some manner).

This should probably be separate from destination/mode, but I was reminded of it when filing #17 and it seemed useful to bring up as it might inspire other solutions.

(At least in my mind these mechanisms are all somewhat related.)

[arturjanc]

It seems useful to give this information to the server, presumably only for mode=navigate requests (or would we want to attach it to resources loaded from a sandboxed document as well?).

@mikewest I wonder if there's a better general model for revealing boolean flags such as this one, Sec-Fetch-User, and potentially the popup bit from https://github.com/mikewest/sec-metadata/issues/17. My main concern is that separate request headers are quite verbose and a large majority of requests will have them set to false. It's probably manageable if we'll only ever have one or two such bits, but I expect there will be other assertions that the browser could make to help servers with security decisions.

I can think of two approaches:

1. Only send the header if its value is true, e.g. Sec-Fetch-Sandbox: ?T or no header at all.
2. Concatenate all such metadata into a single header, e.g. Sec-Fetch-Flags: sandbox, user-activation.

I kind of like (1) -- it seems cleaner than what we currently have. The main difference is that it would switch from making a negative assertion ("there was no user activation for this navigation") to an absence of a positive one (no header set). However, the server could still infer this based on the presence of other Sec-Fetch headers especially as the booleans will very frequently need to be used in conjunction with other data, e.g. Sec-Fetch-Site.

One other benefit this would have is that servers will almost always need the other Sec-Fetch values (e.g. site, mode, and destination) to make their isolation decisions, and the boolean ones will likely be used in a much more narrow set of scenarios. So sending the boolean values only conditionally may strike a better balance between utility and the number of bytes on the wire.

[mikewest]

Sandbox might be a little more complicated than a boolean, if we want to give the site detail about the various flags enforced for a given document's policy. If we extend this to the rest of feature policy's flags, it would be even more unwieldy to pack it into a series of boolean headers. It's probably worth trying to figure out what problem we're trying to solve by sending the data around in the first place to see if it ends up being worthwhile to do so on each request.

As @arturjanc suggests above, limiting some headers to navigation requests might be reasonable. I'm not sure if there's much value in informing sites that a given XHR or fetch() was called from a user-activated context (though, now that I think about it, I guess I could imagine some use cases for "The user clicked on this button that records this important data." as a potential CSRF mitigation).

I can also see value in dropping ?F headers rather than sending the positive assertion of falseness. I wonder how @mnot feels about that for structured headers generally? I also wonder whether he's thought about potentially lengthy sets of flags... I worry at some point that we'll just end up replicating serialized protobufs in a less-efficient manner. ;)

[annevk]

(For sandboxing I only care about the request for the resource upon which the policy will be applied. The user-activated bit though I've indeed seen others ask about as well, though I wonder effective that is as it's rather easy to obtain once you have a compromise of sorts.)

[mnot]

@mikewest probably not for all SH; it tells you how to serialise a data structure, but doesn't get into things like defaults.