Yves: interesting discussion on mozilla position repo

Dan: sympathetic to Anne's point about being wary of adding functionality to popups

Ken; I don't think this is adding new feature.. popups as a communicatin channel are disabled if using sharedarraybuffer. This is about with an opt in renabling that communication channel so people can continue working and still use shared arraybuffer because additional protection was put in place

Dan: not clear on user need

Ken: sites working today with payment via the window object, former popup, that's how a lot of payments work in Denmark.. that works toyda. These sites might be using that feature ands hared array buffer and want to use shared array buffer but at some point that's going to stop working because to use shared array buffer they need changes which will disable the features.. There's going to be a solution to this which is changes to web payments and Web ID..

Dan: webid is not about payment it's about id flows.. red herring.. I see people saying webid fixes this but that's not to do with payments

Ken: argument is it'll be fixed in the future, but it's way in the in future so we need something now. I'd like a security expert to be able to evaluate whether it's secure, I'm not sure. Ongoing discussion, how much we should get involved? Except who has looked at this for security.

Yves: would be good to have apple's input

Dan: need user needs.. why do these sites need sharedarraybuffer? In service of what? Need clear statement of user needs in the explainer. [writes comment] .. looks like a patch

Amy: scope of problem is confusing because it's tied up with all of these other secs, credentiallless, anonymous iframes

Dan: discussion in Mozilla thread about how webid addresses this, but webid is a set of ideas, which don't seem to address the payment case.. a lot left unsaid..

Hadley: seeing this in the context of developer needs (rather than user needs)

Dan: the developer need as articulated by artur is .. restrictions are onerous for developers in complex apps, eg. cross origin sign on.

Hadley: maybe it should be onerous.. breaking same origin policy right?

Dan: statement about "this proposal makes it easier for developers to enable COOP+COEP without reducing the security guarantees provided by cross-origin isolation" is the key thing that needs to be demonstrated

Hadley: did we review cross-origin isolation? COOP thing? Seems recent from search results (apr 2021) eg. blog post

Dan: origin isolation 464 from jan 2020... Mozilla still views it as 'worth prototyping'. Safari is neutral. What's the implementation status on this? If we're now building stuff on top of origin isolation and it's not fully implemented across other browsers..

Yves: development requires consensus among implementations?

Dan: for building stuff on top of it, for a key architectural plank, it needs to be stable

Yves: needs to be implemented by everyone or sites won't work in some browsers

Hadley: I see Chrome and WHATWG..

Hadley: WindowOrWorkerGlobalScope.crossOriginIsolated is a specific property of this concept? If so MDN has a breakdown of implementations which includes firefox and opera but not safari and IE on desktop, and only incudes chrome android and samsung internet on mobile, if this is accurate

Dan: includes firefox is less concerning, but safari is a worry

Hadley: struggling with what they're trying to solve

Yves: also ask about discussion in webappsec?

Hi @arturjanc. Just reviewing in this morning's [TAG breakout](https://github.com/w3ctag/meetings/blob/gh-pages/2021/telcons/07-12-agenda.md). I think the phrase "...without reducing the security guarantees provided by cross-origin isolation" is really the key and this requires some additional elaboration.  The security considerations and privacy considerations sections of the explainer need to spell out some of the abuse scenarios - not from a security-jargon perspective but from a user-needs perspective.  "e.g. bad actors will try to do xxx to use this to steal users' infos". Likewise the user needs at the root of the problem need to be better spelled out - again in terms of what user problem this helps to solve. If it doeesn't solve a user problem but only makes it somewhat easier for developers, and it achieves this by weakening security & privacy guarantees and opening up potential for abuse then maybe it's not a good idea? On the other hand, if it's intended to encourage developers to adopt better security practices then overall it can be a good trade-off.  I think that's what you're getting at but can you try to spell it out a bit more from an end-user perspective?

Also quick question: Referencing our previous review of origin isolation https://github.com/w3ctag/design-reviews/issues/464 and looking back at the implementation status, it looks like there is not good support across engines for this underlying tech (COEP/COOP) yet. Is it premature to start building stuff on top of it?  Are there additional implementer signals for this specifically? Chrome status still shows "no information". 

Also if developer feedback is the thing driving this then maybe this should be linked to in Chrome Status or in this review?

Finally, has there been any relevant discussions in WebAppSec that we should know about?

Dan: [posted](https://github.com/w3ctag/design-reviews/issues/649#issuecomment-878903613

Dan: we were reviewing this, looking at user needs and trying to understand how this could weaken the current security guarantees of the overall browser. That lead us to this discussion

Tess: a lot of relevant conversation in the WHATWG

Mike: it seems like cross origin isolation is an important primitive that security teams in different browsers are trying to push on. The conversation in this review as well as others seemed like there were some questions popping up about what it is that's going on more generally. Less about specifics, but the world in which this proposal lives. I wanted to give you a two minute overview of what I think about this stuff. I'd love for Anne to jump in. Then maybe we can dive into specifics of one or more proposals. Sketching out the broad story would be interesting. A couple of different docs to get started:

• https://w3c.github.io/webappsec-post-spectre-webdev/ - tries to summarise a couple of documents
• https://arturjanc.com/coi-threat-model.pdf - does a fantastic job of going into detail about what this is and why
• https://resourcepolicy.fyi/

Mike: we want to align the origin model on the web with the process model in hardware. Computers are broken. Cross origin isolation is a set of compromises that allows developers to opt into a subset of the status quo web that enables us to isolate origins from each other more deeper than we can normally. We have a number of ways origins can reach into each other from a site. *.example.com can become same origin with other *.example.com pages through eg. document.domain. We have to keep the process isolation at the site level not the origin level. It's important to keep thing sprocess isolated because everything that comes in can be read by an attacker. We had a variety of mechanisms that allowed the browser to enforce explicit legibility of resources. If I can get the result into my process with spectre attacks I can read those bits.

...With that in mind, we know the process boundary is the only one that counts for this set of attacks. Given that, the cross origin isolation proposals are really wrapped up in not solving the problem of legibility, not possible, but ensuring data only enters your process if it has chasen to do so. You can make requests to cross origins ites, eg img or iframe, those responses will only be allowed to enter your process if they opt into do so with the cross origin resource policy header, or more with iframes.

...The work that is shipping today in firefox and chrome is wrapped up in two primitives. Cross origin opener policy and cross origin embedder policy. Today they are quite strict in what they allow. In order to be considered cross origin isolationed and get access to eg. shared array buffer you must opt into the same origin cross origin openeer policy. This breaks the opener relationship with any window that navigates to a cross origin page.

Dan: opt in how?

Mike: you opt in by sending a cross origin opener policy header with your document. As the attacker in order to get access.. cross origin isolation wer'e using as a gate for things we know make attacks more effective. sharedarraybuffer can increase the bandwidth of spectre attacks. It's possible to execute spectre attacks without it, but its a lot slower. By limiting your access to high resolution timers we meaningfully affect the ability of the attacker to get data. The attacker wants to be cross origin isolated for a good attack surface. They have to opt into an opener policy of same origin, which breaks oopener relationships, which allows us to process isolate the window. Some browsers can do it by default some need the heuristic that cross origin windows can live in a separate process. that has the impact of any cross origin navigation is going to break the relationship. Has impact with oauth flows and popups, payment providers, and other things that folks have found when doing things.

...The other thing you have to opt into is the embedder policy - require-corp. This has the effect of ensuring that you can only load resources that epxplicitly opt into being loaded by you or something that looks like you. If attacker.com makes a no cors request to bank.com using a script or image tag, the request goes out and if it doesn't come back explicitly labelled with a cor policy of cross origin you don't get access to that thing, it's blocked. The server is opting in to allowing their resources to be loaded in cross origin contexts. The only things loaded in cross origin contexts are the set of resources the server has chosen to make available to third parties.

... The combination of these two we think is robust. Gives us the ability to provide devs with powerful tools without being able to attack the rest of the web. At the same time - a number of constraints. Feedback from devs is they're having problems deploying apps in a cross origin isolationed mode. It's unfortunate .We want apps to be cross origin isolationed. Opting into cross origin isolation model allows us to move from site based to origin based isolation. Domains with lots of applications at different subdomains. Google is an example.

...It would be excellent if they could remain separated at the process level so a bug in one doens't turn into a bug in the other. With site isolation it's a single site based process. So we need to shift to cross origin isolated. Difficult for apps because of restrictions - popups are a problem for a number of work flows. Subresources and subframes are a problem. Apps like google earth that have user generated content from millions of years of internet history and its infeasible to imagine that they'll go back trhough and ensure third party servers referenced are going to be updated. Quite unlikely.

...Two proposals for today are about ways in which we think we can change the reqs in a way that don't weaken security but increase developers ability to deploy these. The first is the opener policy mentioned at the beginning. The second is the credentiallless cross origin embedder policy. One other thing in the future is a proposal for anonymous iframes.

...Taken together we hope thse mechanisms will give us the ability to more broadly deploy cross origin isolation in order to put users into a world where they have better guarantees about the ways their data might be accessed. Today it's difficult for devs to do that work.

Rossen: about having a difficult time moving some legacy.. what is the solution going forward?

Mike: the solutions right now are ways in which we can create isolation without requiring an opt in. On one hand the opener policy today is the opened window doesn't need to opt into being spoken to. We'd be able to open it and the behavioural changes in that proposal make it possible to maintain process isolation while doing so. The embedder policy change makes it so i fyou don't send credentials with the request the resulting data is somtehing the attacker could have got anyway so it's not necessary to explicitly require an opt in. Anon iframes is similar - it aims to break the credentialled relationship between the frame and the origin to which it lives by separating it out and not sending credentials with the initial request.

Hadley: you are talking about as a user when I am doing something on a page that is going to open another page, you want to restrict both ends of that journey into the same process, to be treated as one isolated security unit?

Mike: the opposite of that. I want to ensure that the application and its cross origin dependencies can remain in distinct processes. If I"m on twitter.com and twitter wants to run a SSO flow with some other entity, that those distinct entities need to live in separate processes, it's critical that they're protected by a process boundary

Hadley: and then same concept separating two entities by process bounddary for resources embedded in the page, to keep the iframe separate?

MIke: i would distinguish iframes and other subresources. irames create their own environment that is a separate origin from its embedding page. We do want that to be in a distinct process, we can't always guarantee it. Chrome on android for instance, often the case that we don't have more processes to give. In those cases today we want to ensure the frame is explicitly opting in to live in that kind of environment. Today we do it with a cross origin resource policy and embedder policy. The anon iframes proposal is another path to getting there, but that's distinct from subresources. Today subresources need to opt into being loaded. If I grab an image from a server I"m goign to process that in the rendererer, and I might found out it's not an image, it's data. Reading it gives the attacker access. I need to block before I can read it. Looking for an a priori assertion about the resource before we parse it. Look at headers, if its opted in it can be loaded.

... example.com is loading an image from cdn.net. cdn.net needs to say my resources are loadable by third parties, that's my reason for existance, I expect them to be loaded by someone other than me. We're asking them to explicitly assert that by sending a header that says that.

... If i am an attacker and I want access to very high resolution timers i have to opt into a mode that only allows me to load resources that have done that opt in. cdn.com is fine, it's going to assert this for all of its resources. but bank.com isn't going to make that - they don't know, or they don't want their resources to be loaded by others.

Dan: root assumption that is driving this is it's about minimisation. It's minimising the surface area of attack by minimising the number of times that access to the sharedarraybuffer can happen?

Mike: I suppose minimisation is a reasonable frame. We want to provide certain capabilities only in a framework that allows us to provide them as safely as possible. W eset up a number of restrictions that we think made this thing safe and ask the developer to opt in to those restrictions before we give it to them.

Anne: same origin policy has a number of holes that make spectre attacks feasible. img doesnt enforce the same origin policy, you can load images from anywhere. You oculd point the image element to a bank statement and it would fetch it into your process, end up in the incorrect process and it oculd be spectre read. Cross origin isolation idea is that we have a set of headers that patch these known problems in thes ame origin policy by requiring everyone to consent to being in that process. If everyone consents to being in that process it no longer has the flaws of the same origin policy so we can give it certain capabilities.

Dan: you're not consenting for a specific other origin? Just I consent to be cross loaded?

Hadley: we're assuming that the bank statement exmaple, the bank is never going to want to serve my bank statement in another origin?

Anne: yes

Hadley: do we feel comfortable about that?

Rossen: goes back to questions around banks that are not moving as fast. Or the google earth user content, you can't move it to adopt the new embedder policy

Mike: my claim is twofold. First, the resources of that slow moving bank are protected by default. As soon as the attacker opts into a set of restrictions they can now no longer load things from that bank, because they haven't opted in

Anne: what if the bank wants to have cross origin isolation and also wants to embed resources from a cdn? we haven't really encountered that thus far. But they could load the resources via CORS. The cross origin embedder policy only applies to non-cors resources. cors are already consent. it's about no cors loads. You can do cors loads for images with crossorigin attribute. If a bank wants to do that they can use cors.

Dan: what happens when an ads/marketing/analytics agency says to the banks or whoever: in order ot make our analytics work please add this header to this http configuration. Maybe that wouldn't make sense for banks because they generally hav ea robust security department that looks at that, but thinking about this in the context of where we've been talking about advertising mechanisms and trackers and how there's a lot of pattenrns emerging of ad networks that compel third parties to make config changes or add cnames.. whereas that might not be something that's really understood to the party, but they're compelled to do it becuase they want to participate in this other thing

Anne: already hard to avoid.. these providers often say just include a script tag.. by that point they have all yoru data and your storage

Rossen: would weakening of that policy open it to tohers besides the analytics company. In the example hadley was pointing out, if that page includes that policy to be read by a third party, does that mean that now you're also weakening it for other third parties and not just yourself?

Mike: I don't feel like I understand what data is being leaked. If I'm an advertiser, with complete power over you and tell you to do a thing. I think the thing yo'ure suggesting is I'd tell you to cross origin isolate your site and send an opener policy and an embedder policy? that sounds good. Higher restriction. Opener policy and embedder policy are restrictive by nature

Anne: the host has a trusted third party and an untrusted third party, and the trusted one forces these headers and the host doesn't realise the implications of doing that

Rossen/Dan/Hadley: yes

Mike: if you include script from someone who is going to do bad things on your page you're going to have a bad day, regardless of cross origin isolation. If someone has script execution on your page they are you

Anne: they might be in a sandboxed iframe but because of resource limitations the host, trusted party and untrusted party all end up in the same process with access to sharedarraybuffer. I don't think it's in firefox yet ubt we did add permissions policy restrictions on shared array buffer access. The third parties wouldn't necessarily have accesso to higher resolution timers, mitigates to this to some extent

Mike: the cross origin isolated needs to be expicitly delegated to iframes via the allow attirbute. Shipping in chrome. Attacker would be able to without hosts permission take action would be if they had script access at the top level. In that case they don't need the allow attribute.

Dan: User needs - it always comes back to payment flows or oauth type flows. Is the use of sharedarraybuffer with these types of flows so compelling? Why is it not possible to do these flows without something as powerful as sharedarraybuffer?

Mike: sharedarraybuffer might or might not be necessary for the thin in the popup. Seperable from the application. One thing is that the paplication is what the user actually cares about. I go to a webpage because it does cool/useful things. I want them to work. If that application has a third party dependency of some sort, a sign in flow that gates my access, whether it's a payment flow, that's part of the applications flow regardless of whether that piece needs sharedarraybuffer or not. You could imagine applications that shunt useres off to a seprate page that is deprivileged. They take you out of the application, put you on a special page that didn't opt into to cross origin isolations, kick off sign in flow, then take you back. That could work but is disruptive for the application. Need to take the user out of what they're doing and no longer have a sign in form on every page or a donate button on every page. That' sthe kind of friction that we're talking about. It's user facing insofar as th euser expects the application to work and do the kinds of things the application wants ot do in a low friction way.

Dan: that really captures what I was looking for for user needs. Makes sense.

Hadley: helps. I'd love to broaden it. In the use cases, what's on the list that isn't payment or login?

Mike: those are the easiest. The others are stuff that pops up in enterprise. Salesforce applications talking to other parts of their infrastructure. A weird thing broke iwth a printer that has a service in a popup. Salesforce integration with this printer, sends information, bidirectional communication, printer is not going to be updated any time soon. Long tail, but is going to be the case that the general assumptino on the web to now if I pop open a window I can talk to that window and that window can talk to me. people build flows around that. Payments and identity are the flows most people will come into contact with most often. I think there is more out there that we discover as we get people to roll this stuff out.

Hadley: helpful, thanks. I can imagine other longtail stuff with other hardware.

Mike: one thing about printers is they usually live on local networks. Credentiallless - private network access is one of the plaes where that is not good enough. Todya it's the case that you can make requests from the internet to the intranet and to localhost and we want to change that. There is a proposal for private network acces,s used to be cors-rfc1918. When you're thinking about credentiallless I"d ask you also thinks about risks associated witih private networks. If we remove necessity of server to opt in, the attacker can continue to access things that live on local networks until such time as we can get private network access rolled out which does create an affirmative opt in requeriment using a cors like framework for all pages all the time.

Hadley; helpful, makes sense

Tess: lots of discussion in whatwg issue 6364. Anne, do you think we've surfaced enough of that? COuld you help us understand the remaining disagreement?

Anne: out of privacycg wokr we know that popups are bad for privacy. Most browser that have various privacy protections, popups end up being an escape hatch. I'm not sure happy with continuing catering to the popups use case, since I don't think we want to have popups around in the long term. I can undersatnd the argument for doing it, but wonder if we should hold off.

Tess: a common use case for popups today is oauth flows and authn stuff. I suppose there's also the webid work that's happening to maybe deprecate that kind of thing and replace it with a browser mediated thing. Is that how we might make popups go away?

Anne: login or oauth type flows are the primary use case. The federated auth ..

Dan: brings the question of how much work should the web do to accommodate this case, if we think popups in general we want to see go away in the medium to long term?

Tess: adding features to the web is .. the web is additive, it's very hard to undo, to stop shipping things. Do we want to permanently add this level of complexity for a class of feature we want to go away in the long run?

Mike: this version of cross origin opener policy is likely we'd be able to deploy by default. The current mechanism for opting in, we have two cross origin opene rpolicies - same-origin and same-origin-allow-popup. The forme rallows cross origin isolation and is iimpossible to deploy by defautl today - breaks flows that exist. We are past the point of developrs depending on popups exisitng. Correct to remove things from the web is hard. If we want to get rid of popups my bold assertion is that this is not going to be the straw that breaks the camesl back.. camel is already in a bad state. To get rid of popups, webid and web payments are good to push on, but take a while to get close to the long tail of sites. We want mechanisms we can roll out quickly to get security benefits for a set of websites that are unable to shift off their current worflows. We can all agree how bad popups are, but sites depend on them for things today. If we give them a choice between origin isolation or their users signing in, they're not going to pick origin isolation. and lose the thing that makes them valuable in the first place.

Dan: mentioned privacy network access, our issue 572. And crednetialless embedder policy. Any topics in those issues we can bring to the table?

Rossen: any of the two documents you posted earlier a good framing that stitches all of the different proposals in flight that we could see as a timeline and dependencies? And what is necessary and critical and what are things at risk?

Mike: artur's threat model doc is a good read and give syou the conceptual framework within which we've been working. I don't think there's a doc with a timeline and dependenceis. My view is there are in both firefox and chrome coop and coep are shipping today. Firefox is gating sharedarraybuffer behind cross origin isolation. Chrome will probably be shipping that tomorrow. That creates a status quo with multi browserimplementation with the core of cross origin silation, agreement to limit known timers behind that.. sharedarraybuffer is only available in origin isolated environments. performance.now is .. 100mil and 5ms depending on if you're in cross origin isolation or not. Large differenc in granulaity. APIs we want locked behind cross origin isolation - memory measurement api and others. We epxect it to be a primitive used mor erather than less going forward. Question in my mind is how we get more people to shift into this world that llows us to isolate origns itno processes. Turns into a deployment question. Feedback has been around these popups on one hand, and subresources on the other. Proposals on y'all's plates are response to developers wanting to deploy these things in the wild.

Rossen: thanks

Dan: Feedback you'v ehad from developers and developer research in general. Is there developer research which you can surface as part of the public information? x developers are using this api in this way or we saw this much potential fraud which could be mitigated if this were in place

Mike: wrt to data I can point you to mitigation.supply/#isolation .. not super useful for specifics, but give you a wide story. Some big sites have started using it, so the useage numbers are starting to go up. Also the anecdotes that have popped up on variosu review threads. This one or the threat against html (?) - examples from google earth, twitter, zoom, docs - an addon mechanism for companies all using third party stuff has been a problem.

Dan: the other thing to mention is complexity.. something we often find ourselves talking about. Is it worth it to add xyz feature when it is increasing complexity. And anonymouse iframes have been discussed - a lot of proposals about variation son iframe - feels like a layering issue, need to get people to talk to each other and think how they can be built in a more layered way.

MIke: agree, the things we're proposing turn out to be complicated. THe model is mor ethan i want most people to think about most of the time. It is complicated, there's a lot of interaction between pages and resources. We've talked in various forums about the things we should be aiming for and the kind of direction we might be able to push in that could simplify things. Presentation I gave around what it would take to shift toward a model of isolation by default.

...The proposals are the building blocks I think we might start being able to turn on by default, such tha twe don't ask devs to think about them unless they need the weird stuff. If they need the weird stuff we can ask them to deal with complexity. Problem today is introducing it to a status quo we don't like and creating changes to the status quo. My hope is we can work toward inverting that picture so the complicated things are the status quo, and the complication come swhen you want to opt into something different than that status quo. I hope.

Yves: question about service worker - using credential mode could be used as a cache key? To mimic the fact there are differences between what's cacheable at public and private level. Anonymous or using the authn information. If it's part of the cache key then you might have a way to solve th eissue for service worker as well

Mike: yes I think it would be reasonable for us ot use the crednetialled state of a request as part of it's cache key. Probalby necessary. Service workers ar ea problem for privacy related proposals. We need to find ways to partian service workers. Similar to safari maybe or other options. Seems likely we'll need to do something.

Hadley: this was really helpful, thank you. I'd like time to read through the docs you sent and wrap my head around the specifics.

Amy: +1

Dan: worth us tying the three issues together

Rossen: how much is shipping?

Mike: core of coop and coep are shipping today in firefox and chrome. Credentialless is going to origin trial in chrome 93, a couple of weeks, through 96, and look at developer feedback which we can share. Anon iframes as well as cross origin opener policy proposal we hope to implement in Q3. Expect implementations behind a flag at the end of a quarter. Origin trial then would be nice.

Rossen: stacking up most to be ready by Q4?

Mike: these are blocking some sites from using cross origin islation. My teams are doing implementation to make sure they're solving the problem. Love feedback into whether this fits in the way the platform works. Not shipping tomorrow, working on it now, expect we'll have it behind a flag in two or three months

Anne: timeline for changing defaults? that's the most interesting aspect

Mike: agree. Not where we've been putting our time. We're getting back tot he resource I started at the end of lats year around document.domain. A few sites using it widely. Hope to start reaching out sometime soon. But haven't yet. Deprecations and behavioural changes are the important thing. Looking at opt ins first then opt outs, and path from one to the other. But we need opt ins done in order to have something to opt out of.

Dan: checking minutes from meeting with Mike on the 19th.. questions are still around when they would activate it by default... I think we should close this with thanks for the explanation, we understand you're going to be trialling this in q3 so we'd appreciate hearing what the feedback has been on the trial. Our concerns about complexity remain and we'd like to understand more about any developer research you have which supports this approach, is one of the things I asked... I think we've provided what feedback we can.

Yves: multipe issues - we did send some feedback...

Hadley: not in the issue itself.. did we cover it off elsewhere?

Yves: popup thing is for dialogs for payments

Hadley: and third party login

[recap of earlier conversations about this]

Hadley: we also had conscerns about the use cases...

Rossen: do we have use cases?

Hadley: particular question i had was in the bank statement example are we assuming my bank will not serve my statement in another origin... the response was yes as far as I remember..

Hadley: my inclination is to condense some of this feedback into the issue so we can remember where we were on the issue... I will do this.

Amy: i recall after the meeting with mike west we agreed we shouldn't get in the way ...

Rossen: concerns about strategies about rollouts, schedules, timelines...

Strategy for acquiring new customers coming on board with htis functionality, but also need to figure out how to change the defaults for existing content. How is that strategy going to play out?

Dan: I don't think there's a reason to leave it open. We've left feedback, they've heard it, asked some questions, want ot hear about the rollout schedule, but other than that no reason to keep this open

Hi all, 

We've discussed this in our W3C TAG meeting today. We want to thank you for a thorough and helpful meeting on this and COOP/COEP.

We want to summarise our thoughts here, so that we have the notes in one place, and then we'll close this issue. 

Our thoughts:

* We are concerned about anything that adds complexity to the web, confusing developers and making it harder for developers and site owners to produce websites. This proposal is substantially complex, though it does offer big benefits especially to users. 
* We are still interested to hear how use cases develop. In our meeting, we asked if there was an assumption that, for example, a bank will never want to surface a PDF of a customers' bank statement on another origin. It sounded like you might discover that that use case does — or doesn't — actually occur in the wild. It will be interesting to hear how the various groups impacted by this respond.
* We started a discussion with you all about how to shift the defaults on existing content to benefit from this proposal. On the one hand, that could be a very substantial shift for the web, which is always challenging. On the other hand, we are still behind our [Evergreen Web](https://www.w3.org/2001/tag/doc/evergreen-web/) finding and recognise that everything needs to upgrade. So we are interested to hear, in due course, how you want to explore this.

Thanks again, and we'll be keen to see how this develops. Please do come back to us as you learn more from your work.

Amy: didn't we agree to close this? It's proposed close

Dan: Hadley drafted feedback but it was never posted in minutes

Hi all, 

We've discussed this in our W3C TAG meeting today. We want to thank you for a thorough and helpful meeting on this and COOP/COEP.

We want to summarise our thoughts here, so that we have the notes in one place, and then we'll close this issue. 

Our thoughts:

* We are concerned about anything that adds complexity to the web, confusing developers and making it harder for developers and site owners to produce websites. This proposal is substantially complex, though it does offer big benefits especially to users. 
* We are still interested to hear how use cases develop. In our meeting, we asked if there was an assumption that, for example, a bank will never want to surface a PDF of a customers' bank statement on another origin. It sounded like you might discover that that use case does — or doesn't — actually occur in the wild. It will be interesting to hear how the various groups impacted by this respond.
* We started a discussion with you all about how to shift the defaults on existing content to benefit from this proposal. On the one hand, that could be a very substantial shift for the web, which is always challenging. On the other hand, we are still behind our [Evergreen Web](https://www.w3.org/2001/tag/doc/evergreen-web/) finding and recognise that everything needs to upgrade. So we are interested to hear, in due course, how you want to explore this.

Thanks again, and we'll be keen to see how this develops. Please do come back to us as you learn more from your work.

[CLOSED]