Can COWL be useful for ths use case?

[deian]

Nice! Out of curiosity, have you considered using a more general mechanism like COWL for some of this? For example the opaque iframes can be implemented pretty easily using labeled iframes. I think some of the examples we describe can be retrofitted for this use case (while providing a more general mechanism beyond ads for web developers).

[michaelkleber]

Thanks for the pointer! TURTLEDOVE is one of several recent proposals that would need some sort of more-restricted way of embedding content. We'll need to clearly spell out the restrictions demanded by the various use cases, and it would be great if existing work can meet all or some of them.

That said, the COWL threat model is quite clear that

COWL is intended to be used as a defense-in-depth mechanism that can restrict how untrusted—buggy but not malicious—code handles sensitive data. Given the complexities of browser implementations and the presence of covert channels, malicious code may be able to exfiltrate data.

The threat model here must explicitly target the malicious sharing case: the very same ad network may be running script in the top-level page (which knows the first-party user identity) and inside the ad (which knows the interest group), and that ad network might very much want to join up those pieces of information.

[deian]

The restricted thread model is from a while back, before browser folks were willing to put iframes into separate processes. And we have formal proofs showing that you can actually provide confidentiality in the presence of malicious code if you're willing to use a separate thread.

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Fenced Frames proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.