Punted

Rossen: I want to spend more time with this one.. move to B?

Rossen: tiny little proposal.

Hadley: functional but it doesn't have a user need.

Rossen: the user - the platform's developers...

Hadley: presume it's supposed to be more secure for users but they don't spell this out

Tess: this isn't the only new iframe like proposals - do we need a Cambrian explosition of new iframey things?

Hadley: at least they should be talking to each other

Rossen: i agree - they should all be talking to each other. Attempting to extend iframes into a useful mechanism for sharing data without breaking CORS - creating a bunch of policies the document can opt into or opt out. From a PoV of extending existing tech and making it more fitting into that example it's decent. Good enough complexity that requires a careful review IMO. because they are changing the cross-origin policies essentially - they have to go in and add a bunch of things - e.g. credentials - this to me is a path forward to other changes that would be necessary to land it functional and complete.

Dan: there is a data sharing aspect... feels like these things are being developed in isolation from each other. the potential for developer confusion is high.

... Also, want to support what hadley was saying re user needs. We can ask for that. They need to be very clear.

Peter: should we recommend a task force about iframes? Get all these diffeent efforts to coordinate?

Tess: I think they are talking - but only maybe in places that are opaque - e.g. blink dev - not collaborating with other engines...

Peter: ... or broader W3C community.

Hadley: that's important.

Hi @camillelamy! Thanks for this review request.

1. What end user needs are you trying to support? When would this feature be useful to a user, and why is it worth adding to the web? It would be great if you could add this to the explainer.

2. We are seeing a number of iframe related proposals, all of which would benefit from input from the rest of the W3C community. To help bring that together, we will be recommending the W3C create a task force on iFrames, and we would very much welcome your participation.

3. Could you elaborate on the answers in the Security and Privacy questionnaire? For example, where you've just said "No", can you give more detail?

Rossen: - security & privacy questionnaire answers - enable origins to downgrade default security protections? they answer "no" - they should have more to that answer about why they believe that this will not allow downgrades - if I have credentials set to emit - and I go and change something that gets me into a cross-origin state... then ... would an iframe without credentials propogate up into a parent browsing context and change its siblings credential states. if so, lowering their state, or increasing the credential sharing? This would introduce new threat vectors.

Hadley: .. a nonce only available to that page .. clears when pages not avaulable...

Rossen: 2 iframes - one iframe an ad and another my bank - i don't want the ad to be able to increase the capabiities of my banking iframe....

Hadley: no different keys - [ref diagram in explainer]

Rossen: i saw the diagram and I couldn't convince myself it was impossible... We should just ask them if they can provide additional detail on the s&p questionnaire responses.

Rossen: last time we talked I felt like we went through the document fairly extensively, there was a bunch of us, Hadley and I had three meta questions around usre needs, security and privacy and the overall scoping of that into the set of other documents and other proposals. I see that Camille has put another document which I haven't had a chance to look through. Sounds like they are trying to list here a number of challenges rather than user secnarios.. around popups and subresources and third party iframes and how that solution is going to address those. I haven't had a chance to digest this. From actual end user point of view scenarios it's still doesn't feel this addresses what Hadley was asking for. THeyr'e saying they've identified some problems.. but are these problems that people are fine with? They coudl be problems and nobody cares. Identifying them doesn't make them good use cases. They're using these pivots to fit what they're proposing, not necessarily the conversation around scenarios or uses cases that sucks today and they're going to make it better. Like "we're going to get rid of popups." That would be something I'd be excited about... or "we're going to solve auth and single sign on forever"... That is my take on this through reading quickly the first few paragraphs. They go on to say how their solution is solving this becuase they explain how their solution fits these problems.... I'll ping Hadley and work out another response. I don't see how the user needs are expressed, even if the users are web developers.

Peter: it seems like a mechanism for creating an iframe without having to do all the CO* headers and still get some of that behaviour. Am I reading that correctly?

Rossen: generally yes.. Is there a task force on iframes?

Tess: not that I know of

Rossen: that's what Hadley said.. to help bring that together we will be recommending a task force on iframes..

Tess: first I've heard of it. What WG would the task force be under?

Dan: we closed #649 which is related. One issue is just as with 649 it jumps right into talking about sites that want to continue using sharedarraybuffer must opt in to cross origin isolatuion, it doesn't talk about use cases

Ken: they have a section called 'what are anonymous iframes', 'documents can create..' - is this a new thing? Sounds like something you can already do

Dan: that's the proposal. Later on it says something about autofill.. is that one of the main uses?

Ken: difficult to dissect this. Sounds like they want this by default in anonymous iframes so for some reason that makes it safe?

Sangwhan: what's the final end user use case?

Ken: I'm wondering what is the use case where you don't have any credentials but you have anonymous iframe and want to use sharedarraybuffer. Getviewportmedia I assume is for camera acess?

Dan: [drafts feedback]

Hi @camillelamy I have similar feedback as i did for #649 which is that the explainer jumps right in to talking about how "sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation" without first talking about the end-user use cases (the user need).  What user need is being served by the use of SharedArrayBuffer in this context that this set of mitigations is aimed at securing?  You talk about password managers later on in the doc - is that one of the primary use cases? Can you please amend the explainer to start with a few user needs to help us set the context? 

Sangwhan: I understand the S&P needs but not when this would be useful. What applications does this have?

Ken: me neither but they mention getviewportmedia..

Sangwhan: screen sharing

Ken: i want my anonymous iframe to get my screen?

Sangwhan: camera and screen

Ken: definitely want opt in for iframes to get my screen and camera. I don't want embedded iframes to get access whether they're anonymous or not

Sangwhan: Feedback is - who is the consumer of this thing?

Dan: Hadley did already ask about the user need and Camille did respond, but it's still not reflected in the explainer

Dan: leaves amended comment

Tess: I don't like the name of the DOM attribute or attribute value, because it's not credentials that are being omitted, it's storage, and it's not so much that it's omitted, it's that you get a new, one-off partition. I think the open issue 20 captures this concern.

Commented.

Dan: last thing I remember is this needs to be consolidated with all the other iframe proposals.. but not reflected in the issue.. we need to make some progress. I think Arthur's response to my question is compelling.

Hadley: did that end up in the explainer as well as responding to your question?

Dan: [writes response]. Are there other issues here? Is this linked to the other COEP / COOP thing where there was going to be a chrome trial period and we wanted to wait for the output of that? We had a discussin with mike west about it.

Tess: I commented with an issue that's still open, I don't think it's changed. On one hadn it makes sense to bucket it with the COOP and COEP stuff that we're waiting on. On the other hand this feels like a feature that is primarily a faster stop gap, peolpe can't adopt COOP and COEP yet because it's hard, maybe we're doing them a disservice by delaying.

Dan: we should close it on the basis of thanks for that information? Looks good as a stop gap

Tess: and please make progress on the open issues.. The name is terrible and actively misleading.

Dan: other question is where does this go?

Tess: I'd expect HTML. It's an iframe attribute

Thanks @ArthurSonzogni  that's very helpful. Can this info be brought into the explainer to make that document more clear (including the linked user needs)?  This looks good to us on the basis of it being a stopgap. Can you please progress the open issues including the one [Tess pointed to](https://github.com/camillelamy/explainers/issues/20). Spec-wise where is this going? Is this headed to HTML?

Dan: proposed close, for plenary

Dan: waiting for response to questions

Amy: explainer has an update

Dan: close at plenary?