[many

Yves: I was a bit concerned that there is already a CSP reporting - so many instead of creating a new header, reuse it?

Peter: there are other reporting APIs as well. we gave them feedback - as long as it's separate, I'm OK with it being a new header. HPKP has the same thing.

Yves: that's just at the HTTP level, not a JS API

Peter: true. The point of this header isn't to generate a report...

Yves: It's reporting what will be blocked but don't block anything. Apart from the point I made about CSP - seems OK to have that kind of thing. Good section on how not to leak private information or leak info to 3rd parties.

Peter: they went through a lot of work to figure out what can and should be reported...

Dan: Why is this whatwg and not webappsec?

Yves: cross origin opener policy is defined in Fetch...

Tess: what is the relationship between this reporting API and the reporting API defined by the web performance working group?

Yves: that also uses structured headers... so could be a good match.

Peter: it's not just the fact you want to report but you want to get a report as if the cross-origin policy is on. You need to have a report-only mode. You could put is a switch in the one header and not have 2 headers... Useful to have reports one way or the other...

Yves: related to secure context as well...

David: [summarizing] opting into a stricter model so browsers can have better guarantees about site isolation - because of SPECTRE

Peter: primary feedback was yet another header...

[bumped to B