Window Controls Overlay for Installed Desktop Web Apps

[amandabaker]

Hello TAG!

I'm requesting a TAG review of Window Controls Overlay for Installed Desktop Web Apps. (Originally: "Title Bar Customization for PWAs")

The title bar feature extends the app's client area to cover the entire window, including the title bar area. The web app developer is then able to draw and handle input for the entire window except the window buttons (close, maximize/restore, minimize), which are overlaid on top of the app's canvas.

• Explainer: https://github.com/WICG/window-controls-overlay/blob/master/explainer.md
• Security and Privacy self-review: [Title Bar Customization] TAG Security and Privacy Questionnaire  MicrosoftEdge/MSEdgeExplainers#218
• GitHub repo: WICG/window-controls-overlay
• Primary contacts:
  • Amanda Baker (@amandabaker), Microsoft
  • Jason McConnell (@Maggers), Microsoft
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature: Chrome Status

Further details:

• I have reviewed the TAG's API Design Principles
• The group where standardization of this work is intended to be done: CSS Working Group, Web Platform Working Group
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • [css-env] Add environment variable for left/right bounds of notch w3c/csswg-drafts#4721
  • Add option to replace title bar with a display a smaller caption control overlay  w3c/manifest#847
  • https://discourse.wicg.io/t/proposal-title-bar-customization-for-web-apps/4278
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Microsoft

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @amandabaker

[dbaron]

Did you intend that those two links to w3c/csswg-drafts issues point to different issues? (They're the same.)

[kenchris]

Hi there,

We are wondering what are the intended venues for these features, like dragable might be intended for CSS WG and the manifest changes for Web Apps WG but where will the JS additions land? Also as part of Web App Manifest?

[torgo]

In general we are a bit concerned about specs that explicitly refer to the term PWA, as there is no formal definition. I am a big proponent of the PWA pattern, but specs should probably instead of saying "PWA title bar", it should say "installed windowed web app title bar" or something more related to the underlying technologies such as the manifest file...?

[kenchris]

Related (with my comments): MicrosoftEdge/MSEdgeExplainers#229 regarding security/phishing

[kenchris]

@atanassov you pointed out that this same technology would work for other use-cases than explained in the explainer. Are you following up?

[kenchris]

Regarding unsafe-area-top-inset-left and unsafe-area-top-inset-right: These should work in both RTL and LTR and in other specs we are moving to use start and end (think flexbox) instead of left and right @plinss

[amandabaker]

We have iterated on the title per some of the feedback here and elsewhere, so I changed it above from "Title Bar Customization for PWAs" to "Window Controls Overlay for Installed Desktop Web Apps".

---

Did you intend that those two links to w3c/csswg-drafts issues point to different issues? (They're the same.)

@dbaron Not intentional, but I've updated it to include the web app manifest issue

Hi there,

We are wondering what are the intended venues for these features, like dragable might be intended for CSS WG and the manifest changes for Web Apps WG but where will the JS additions land? Also as part of Web App Manifest?

@kenchris JS changes are targeted for WICG. Currently the discussion has started here. I also added to the discussion links section above.

In general we are a bit concerned about specs that explicitly refer to the term PWA, as there is no formal definition. I am a big proponent of the PWA pattern, but specs should probably instead of saying "PWA title bar", it should say "installed windowed web app title bar" or something more related to the underlying technologies such as the manifest file...?

@torgo "Installed windowed web app" is what we were intending, so I've updated the title to use that terminology. Thanks for the suggestion!

[atanassov]

Since this feature enables PWA's to paint in areas where the window title bar would have been, we identified a concern of impersonating a browser. Most modern browsers today have their tabs UI in the window title bar area, something that's hard to spoof by windowed PWAs and presence of a title bar. In other words, a user could install a PWA that after launch looks like Chrome for example thus spoofing the user to enter privacy-sensitive data.

[tomayac]

s/lunch/launch/
Fun typo in tough times… A little chuckle at the beginning of my work day…

[torgo]

Thanks @amandabaker! Looks good. Is there a mitigation against the issue @atanassov raised above?

[amandabaker]

@atanassov @torgo We're working on writing up some of the mitigation options that we've come up with so far, so I'll share that out shortly

[kenchris]

@amandabaker any update?

Also there is now this related proposal from Google (at least touching the display values):

https://github.com/dmurph/display-mode/blob/master/explainer.md

[torgo]

Due to holiday schedules we've had to bump discussion on this to the week after next. Sorry for the delay on our side @amandabaker. If there are any updates in the mean time please feel free to let us know here.

[amandabaker]

Just as a heads up, we moved the explainer into it's own WICG repo here: https://github.com/WICG/window-controls-overlay/blob/master/explainer.md

I also updated the original post to reflect the new location of the explainer

[kenchris]

Web App Manifest is close to integrate display_override (w3c/manifest#932) but the explainer is not using that yet.

[torgo]

Hi @amandabaker - we're just discussing in the TAG "f2f" today and it seems to me that some potential privacy issues are not being taken into account. Specifically:

The point of PWAs is to have app-like experiences that have the same safety guarantees as the rest of the web - so if we're allowing developers to write arbitrary stuff into trusted UI then this can be a problem. It does not seem like there are sufficient mitigations. For example, a PWA could write confusing or misleading UI elements into the title bar in order to trick the user into disclosing private information (e.g. a phishing attack making it looks like their bank and taking their username and password).

Yes, we're talking about web apps that are installed but I'm also concerned that the web app could be installed under false pretences - where the user's trust is gamed by a web site or malicious advert for example, or via a URL they receive by text message or otherwise out of band...

It feels to me like this needs to be in the Privacy section and some mitigations need to be discussed here?

[amandabaker]

Hi @torgo, we have heard a lot of concerns about security and spoofing and have been discussing implementing a way to toggle between a normal standalone titlebar and the window controls overlay. When an app is installed that supports window controls overlay, by default it opens in standalone mode. Then from a button in the titlebar, the user can choose to toggle into this unsafe state. We are still discussing how best to notify the user of exactly what area can be trusted (e.g. highlighting bounds of UA-controlled region when toggling between modes).

Would this help to resolve the privacy issues? If so, I can update the explainer to include this mitigation. Also, we have a doc with other mitigation options if this approach is still insufficient: https://docs.google.com/document/d/1l7z7Y88lhL9r_0y5S-pcYGaFJqUkaPKSDcgRRTIyj6c/edit?usp=sharing

[kenchris]

I think it solves it partially and I even suggested this idea to @torgo in our breakout today.

I also think that if we can detect that the titlebar UI changed radically (maybe look at fuzzy comparing average color etc) then we would toggle back to standalone mode or so

[amandabaker]

@kenchris I worry that detecting differences in the UI would be harmful to both the user and the developer:

1. For "good" apps, it limits the amount of change that is permissible in the title bar, making them less customizable and likely a worse experience for users.
2. For malicious apps, it just forces the developer to work harder to spoof, but it doesn't prevent spoofing.
3. For any app, the dev needs to experiment to figure out how much can change before toggling the standalone title bar. This is bad for "good" devs, but still won't stop the bad ones.
4. Due to minor style/font differences across OSes, devs would have to validate their changes on all platforms to ensure that the title bar did not toggle back to standalone.

Also, I think it would be difficult to agree upon an acceptable amount of change.

[kenchris]

It should be per platform, by saving info from rendering. Chrome already has pixel rendering tests that does something similar.

All that would happen if it detects a large change is expand back to regular titlebar, and the user can easily collapse it to the custom toolbar again.

[kenchris]

Anyway you don't have to implement this, but I think it is worth listing or exploring as a mitigation strategy.

It is good to have potential mitigation strategies listed in case we start seeing abuse cases

[kenchris]

With regard to 1. I was mostly considering the state of the toolbar after a reload or restart of the app, but I see that it might be dynamic while the app is running (ie. entering data in search bar)

I mostly think the phishing attempts will be pretending to be another app after relaunch, but I might be wrong.

In which case it could be extended to visibility change as apps probably shouldn't change the toolbar while invisible - or it would be interesting to hear use cases for doing that

[kenchris]

What is this current status of this?

I see that "display_override" is shipping in next Chrome version (M89) on desktop. https://chromestatus.com/features/5728570678706176 - I assume this is blocking on that?

Is there anything in particular that you would like our help with?

[kenchris]

Since last, we see that "display_override" has shipped in Edge and Chrome.

Google also made an article about it here: https://web.dev/window-controls-overlay/

[kenchris]

From the article:

Spoofing #
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.

[atanassov]

During our May 2021 vf2f @torgo, @kenchris and myself took another look at this issue. Overall we are still concerned about the lack of multistakeholder interest. At the same time there has been sufficient efforts made to ensure our concerns about spoofing have been addressed, thus we are happy to close the issue. Good luck and thank you for working with TAG.