Dan: Lets try to not creep the term PWA into specs, especially since some vendors do not like the term and because it is more a pattern than a formal term.

Ken: this is about the app getting control to draw the title bar - with trusted controls to mitigate against e.g. it mimicking your bank or some other trusted site...

Alice: I am no CSS expert, but I don't think adding classes is the right approach, why not a media query.

Dan: Adding my comment about the term PWA.

Alice: OK the class example, was in user code, sorry

Dan: I might move this to... not sure why I put this here. I think Alice and I should discuss in Breakout C

Ken: Haven't heard anything back on our questions.

... Thought Rossen was going to talk to the team?

Ken: not just about where not to draw... about how to drag the window around... New display modifier in the webapp manifest for how it would look, new api for bounding rects and states... Environment variables.. system drag region... So lots of stuff. Should we look at each of these in separation?

Dan: so each of these becomes a separate proposal?

Ken: yes, like something related to CSS needs to go to the CSS working group... Also there should be some restrictions on drag regions.. CSS environment variables could be fine ... also used for dual screen API... Right names, right properties... using left and right – does that work for accessibility? Maybe start and end might make more sense

Ken: good to see change

Dan: agreed

Ken: they are experimenting with it in chrome right now

Dan: I asked Amanda if there is a mitigation against the issue Rossen raised. Hope we can get a reply before the plenary. I don't think there additional issues

Alice: I unassigned myself, since I've never commented.

Ken: No update since we asked for updates.

Sangwhan: Not sure how this would work on non-Windows OSes.

Ken: Definitely for desktop OSes.

Dan: Could work for DeX, windowing system for Android. Lets you use your phone like a desktop.

Sangwhan: I seem to recall this is wonky on macOS. Most apps fake the Mac window bar.

Dan: Should we bump this to the plenary to get some feedback from Rossen and Tess, respectively?

Dan: requested access to the s&p document...

Rossen: I explained some of the concerns - Amanda did say that the spec and proposal are being worked on. They are definitely addressing the privacy & security concerns. As a result the doc has info... I'll ping.

[bumped to next week

[bumped]

Skipped.

Ken: this is also moving along ... article from google ...

Dan: At this point I don't see why we shouldn't close the issue given we have answers to the spoofing concerns.

Rossen: Sure, let's close it.

Spoofing from article by Google
Giving sites partial control of the title bar leaves room for developers to spoof content in what was previously a trusted, browser-controlled region. Currently, in Chromium browsers, standalone mode includes a title bar which on initial launch displays the title of the webpage on the left, and the origin of the page on the right (followed by the "settings and more" button and the window controls). After a few seconds, the origin text disappears. If the browser is set to a right-to-left (RTL) language, this layout is flipped such that the origin text is on the left. This opens the window controls overlay to spoof the origin if there is insufficient padding between the origin and the right edge of the overlay. For example, the origin "evil.ltd" could be appended with a trusted site "google.com", leading users to believe that the source is trustworthy. The plan is to keep this origin text so that users know what the origin of the app is and can ensure that it matches their expectations. For RTL configured browsers, there must be enough padding to the right of the origin text to prevent a malicious website from appending the unsafe origin with a trusted origin.