Peter: already a ?? cross origin embedder policy

Peter: maybe instead of ... put them all in the window object - makes sense to me.

... if they create a policy object would you expect to see all the other policies there?

Rossen: in their S&P... there is a costly and polyfillable thing and this is an API to let you do it

Dan: jumps right into talking about solution and assumes a whole ton of knowledge without bringing up to speed on the problem and the space.

Peter: There's a PR against the HTML spec... the motivation here is for ads... to know if they will be effected by this policy...

Hadley: this isn't even in WICG... Opening comment - "this is a simple PR" on HTML...

@ArthurSonzogni, 

We will be able to review this if you can provide [an explainer](https://github.com/w3ctag/tag.w3.org/blob/main/explainers/index.md) that puts this in a bit more context.  Please remember that although we are often reviewing security-related proposals, we do not share all the back story of this proposal and how it fits together with other technologies.  What is the user need that is being serviced here?  What kinds of threats does this protect the user from?  How can the developer employ this technique?  Etc... 

Lacking use cases we can follow and review, we encourage use of our explainer template in order to capture all the other important bits in a single place - other considerations, code examples, privacy, security and a11y considerations etc. Can you please write one?

Also: in your response to question 2 of the s&p questionnaire it's a little confusing: do you expose or do you not expose the info specified?

Rossen: leaves feedack

Dan: response from Mike West.

Peter: we're concerned about the primary use case. I can leave a comment.

peter leaving additional comment

Peter: ads to detect they are in a less restrictive env.

Tess: It's not much of a stretch - we know there are actors out there who will get away with whatever they can get away with.

Peter: making it easier to do the bad behaviour - is the jist.

Dan: Peter left a message.. can we close?

Peter: they haven't really responded, we got a reply from someone else. We pushed back saying doesn't this just help advertisers keep abusing users. They have not answered that.

Dan: their response

Peter: response seems to support my point.. keep doing what they're doing with accses to extra cookies and data for as long as possible

Amy: they want to avoid anonymous iframe so they can keep doing bad 3p cookies stuff? we reviewed that positively. How does this relate to fenced frames

Peter: not sure difference between fenced frames and iframes. Their response says we don't want to switch to anonymous iframe as that will have consequences for our ad performance. But they need a different solution than just not doing the privacy-enhancing stuff.

Dan: Mike wrote a bunch of stuff and asked for clarification.. Peter wrote clarification and Mike didn't respond, someone else did. We need to signal to them we're not happy with this?

Peter: It looks like there are other uses related to sharedarraybuffers, maybe. Clearly the obvious use case is ads and they're making that very explicit.

Dan: we can ack the other use cases, but there's no way to only use it for the not-bad stuff.

Amy: one comment says that the alternative to going through with this is to just use anonymous iframe undconditionally. Best case from our perspective is doing this, right?

Peter: that's what I'd like us to say

Amy: there's a commit message that says there was positive signals from webkit and mozilla, and that anonymous iframe depends on coep reflection.. but anon iframe now decoupled

Dan: anonymous iframe removing dependency on coep is a good sign, anon iframe will exist regardless

Amy: mozilla, webkit .. responses are minimal

Peter: initially I had the same reaction - it's information you can already get so why not expose it. But if you think about it more and abuse cases, you start to get concerned

<blockquote> Hello folks. As things stand we're not convinced this is sufficiently in users' interest / addresses user needs. It looks to us like this circumvents privacy controls that are being introduced in the platform to the benefit of advertisers. There may be additional use cases as described by Mike above, but it's unclear how these could be enabled only for those non-ad use cases. Chromestatus still says no signals from Safari or Firefox. However we've seen some info from [Mozilla indicating support](https://github.com/mozilla/standards-positions/issues/645). However, it's not clear that they've considered the abuse cases as described above. So at this point we're leaning towards closing this issue with "unsatisfied" – unless there's some further info forthcoming. </blockquote>