Hadley: no security & privacy review... There's a security considerations section of the explainer... They do mention the scenario I was worried about - giving the site the ability to replace the title bar you could spoof the titlebar. To mitigate this threat they've only made it available for "isolated webapps"

Dan: so there's a dependency on isolated webapps... Which is also in our review queue.

Sangwhan: this is less complicated than isolated webapps - but some intesting risks. URL bar spoofing, phishing, etc... some gates to prevent that. Not likely that it would happen.

Hadley: I think it would be good that we'd like it to stay in that explicit context. It says in the explainer "at least for now" only in isolated webapps..

Sangwhan: overall... PWAs give more customizability... whether that's the correct choice given that the user has chosen to install the application...

Dan: can we clarify what exactly this is doing because to my understanding PWAs can already come up "full screen"...

Sangwhan: not zero risk but less risky than letting regular PWAs to do it..

Yves: relationship between Isolated webapps and miniapp...

Sangwhan: philisophical difference between IWAs and miniapp..

Hadley: Restricted to (dependent on) Isolated Web Apps, which is Chrome only. No signals from Firefox or Safari.

Dan: so there is a dependency on isolated web apps..

Yves: and there should be coordination between them and miniapps...

Max: they need to provide more use cases from the user's perspective.

Dan: let's bump this to the plenary...

Hadley: we discussed this, since it had a strong dependency on isolated web apps, we were going to join them up with miniapps.

Sangwhan: miniapps is primarily about mobile. If they want to go to desktop, they'll have this problem. you want the user to have control over application sizing.

...Sounds like IE6

Hadley: also sounds like kiosk mode, but without the restrictions from getting into the operating system

Lea: what's the use case?

Hadley: It's for IWAs, which want to look like they're not in the web. Like native apps.

Lea: what happens if the app doesn't iclude a close button? Most users don't know the keyboard shortcuts.

Sanghwan: I'm against using the webkit prefix style. There are efforts to remove this, but given the speed of how things work, i'm not convinced it's a good way of doing this.

Lea: I have concerns. A big use case is adding controls to the existing title bar, see their example of Excel. They've added controls but still need the regular controls... However, here the common case is not easy and there is a cliff: the moment you need to add anything to the title bar, you have to recreate the whole thing, including the regular windowing controls. I can easily see lazy implementations that look like OSX or Windows in every platform, rather than preserving the platform conventions.

Sangwhan: is there an enforcement of draggable? No. Guarantees of draggability is probably required. What is the accessibility story for this?

Hadley and Lea: +1

Sangwhan: the semantics of close are very important. There is no discussion of that.

Hadley: we should ask them to talk to the Second Screen WG, re Fullscreen popup windows.

We discussed this during our vF2F. While we see potential use cases which could benefit from this functionality, we'd like to discuss a couple things that are points of concern.

First of all, this depends on a feature that no other implementation has provided any signal on - which somewhat jeapordizes its future path on the web platform. We'd probably want to hear some level of feedback from other implementors on the dependency proposal (IWA) as it is a architecturally complex topic which we should carefully approach.

Even if this is gated behind a protected context of some form (IWAs?) - draggability should be a key consideration, especially the guarantees of having the user to be able to do so. The proposal as it stands does not seem to have mitigations from applications (be it malicious or not) breaking usability by making undraggable windows - and we believe that is not a positive pattern. Similar situation with the window controls. Reading the IWA explainer, we had a hard time understanding how that as a mechanism can prevent bad patterns coming from user-experience degrading applications.

We are also concerned that the feature introduces a [sharp cliff](https://www.w3.org/TR/design-principles/#high-level-low-level) in terms of usability: While many use cases are as simple as adding a control to the title bar, there is no way to do this without recreating the entire title bar, windowing controls and all. It would be better to introduce a layered solution, that makes [simple cases easy and complex cases possible](https://www.w3.org/TR/design-principles/#simplicity:~:text=As%20Alan%20Kay%20said%2C%20%22simple%20things%20should%20be%20simple%2C%20complex%20things%20should%20be%20possible.%22.

The drag feature being coupled to a webkit-prefix style is definitely not a recommended pattern, and unless this is a prototype/trial, having yet another feature depend on a webkit prefixed feature is a pattern we should avoid.

And we would recommend you have a conversation with the Second Screen working group, who are working on [Fullscreen Popup Windows](https://github.com/w3ctag/design-reviews/issues/840). Their use case is slightly different, but it would be good if you could align your approaches and attributes. @bradtriebwasser, @michaelwasserman, @inexorabletash, and @anssiko are your main contacts for that.

Finally, we see there is no discussion about the accessibility risks associated with removing the window controls from the user interface. This can have detrimental effects on the usability in the context of AT needs.

Sangwhan: can I get back to you in a week? I misunderstood what this is.

bumps

Sangwhan: I met with the developers - they have heard our concerns but unlikely to be addressed. Concerns were mainly about user agent controls being completely removed when the permission has been granted. Dragability and resizeability goes away... No way for user to claw that back - except by going into browser settings and revoking the permission... That's not great - one particular thing - unmovable modal dialogs - accessibility issues. How they plan to use this - have the virtualized desktop environments - a super fancy remote desktop. Idea is that all the windows from your remote desktop brought over to your local desktoip as separate windows... Like parallels or vmware - remote applications casted to your local OS as if they are local applications... Dragability is determined by the OS on the other side... e.g. Photoshop on remote desktop - it will say "you cannot drag that window" and native dragability should not be able to usurp.

Dan: comparable to.. in the powerful apis breakout.. where yes there's a native capability but does it make sense for that native capability to be translated directly to the web. I kind of agree but I feel like the argument that comes back to us from people who are promoting the web as a competitor to native is that well native has it so we have to have it. This is a very good example of something that disproves that.

Sangwhan: ultimately I think this is an implementer decision. I don't see this proposal having any feature being standardised becuase there are so many unknowns when it comes to normative text. On top of that, the questions you have to ask about.. the reason for this powerful capability being a thing is because it's in a trusted environment - which is not a well defined paradigm. The application is from a vetted vendor, a managed browser.. none of these concepts exist on the web platform today

Dan: therefore it's chrome only, like the mangaged device api, or capture all the screens, not okay to standardise

Sangwhan: I suggested there's likely no future for this on the web platform unless a lot of boilerplate work is done to do with formalising the "trusted" browser or application concept

Yves: is it related to web apps can provide the fact you trust them?

Sangwhan: yes, hard dependency on that. How do they define what is a trusted application? It's a business decision, up in the air. What's on the table today, we can't support it. Consider this as a non web platform feature, or a proprietary api. Probably wouldn't cause serious harm from one implementer with the surface it has today, it's very specifically carved out. We wouldn't support, but not harmful.

Yves: "ambivalent" - we see the use cases, but they need to iron out details. Not something that should not be implemented, but needs more work. We don't want to see it on the web right now, but it's useful in the case of installable web apps

Sanwhan: depends on isolated web apps. Without that context it doesn't work. Also introduces new accessibility issues.

<blockquote> Hi @sonkkeli we discussed today in our TAG breakout. We don't think this should be standardized in it's current form on the web platform. We understand the use case. However there is a dependency on the idea of "trusted" applications - and this is an area that is in development - e.g. [isolated webapps](https://github.com/w3ctag/design-reviews/issues/842) which we're also concerned with and is currently not stable enough for other things to be built on top of it. In any case, we are concerned with the lack of agency of the user - e.g. with dragability and accessibility issues. We're going to close this review for now. </blockquote>

*closed as ambivalent