WebKit
App Manifest "screenshots" member
Request for position on supporting "screenshots" member in app manifest
(Please delete inapplicable rows.)
- WebKittens who can provide input:
Information about the spec
- Spec Title: Web App Manifest - Application Information
- Spec URL: https://www.w3.org/TR/manifest-app-info/#screenshots-member
- GitHub repository: https://github.com/w3c/manifest-app-info
- Issue Tracker (if not the repository's issue tracker): https://github.com/w3c/manifest-app-info/issues
- Explainer (if not README.md in the repository): https://github.com/w3c/manifest-app-info/blob/main/explainer.md
Design reviews and vendor positions
- TAG Design Review: https://github.com/w3ctag/design-reviews/issues/30 (
screenshotswas included in the original app manifest tag review) - Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/492
Bugs tracking this feature
- WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=222356
- Radar:
Anything else we need to know
Most browsers have facilities to enable users to add a website to their homescreen. Several browsers provide the ability to install PWAs. Currently the context that’s available to convey is the website’s origin, as well as the name and icons made available through the Web App Manifest. This is different from other store mechanisms, on all platforms, that also share developer-provided information such as a description and screenshots.
Microsoft’s Aaron Gustafson has proposed a Web App Manifest Application Information draft (see spec above), through which we can obtain that information.
Chrome implemented a new, richer user interface on mobile that displays this information (description and screenshots) when the developer has provided it (See help article). Chrome has started experimenting this on Desktop. We’ve carefully designed this interface to continue to highlight known information such as the origin, and are working with the permissions and privacy teams to make sure we can evolve it responsibly going forward.
Although we understand the appeal of showing screenshots of web applications as part of an application’s installation/“Add to Home Screen” UI, we have the following concerns:
- Presentation of untrusted web content in a trusted UI: installation UIs are privileged and trusted system UI and presenting arbitrary images in that context may lead users to believe that these web applications are more trusted by the browser or the operating system than they actually are.
- Misrepresentation: there is no way to verify that the screenshots or functionality being presented in the screenshots are representative of the web application itself once installed (or even anything related to the web application at all - it could show ads or other content to try to confuse the user). We trust that most developers will not deliberately set out to misrepresent the functionality of their web application; but by virtue that this is metadata it can quickly become stale.
We instead feel that web applications themselves serve as the screenshots: unlike “app stores”, users generally use web applications before they install them (i.e., they already have a good sense of what they look like and how they work, which is hopefully motivating users to install the application in the first place). Or, in case where installation is required to enable the features that would be represented in screenshots, the web site itself can present the screenshots in a web page.
With respect to misrepresentation: the risk of emulating trusted system UI in the screenshot could be mitigated with appropriate presentation of the screenshot. Thus, it would be good for the spec to mention that as a security consideration in the spec.
Perhaps the use case for this is not saving from the web but rather installing from a standalone separate store app that contains web apps packaged with a Web App Manifest?
That's definitely a use case (and was the primary driver for it). However, Chrome on Android shows the screenshots (and description) when installing directly from the Web. You can see it here:
https://youtu.be/tj0_4pcrj7s?t=301
Screenshot below:
Although I understand @marcoscaceres concerns, I do think all issues have to take into account a wider view of mobile ecosystems, specifically:
- The less desirable Web Apps are for developers, the more likely developers are going to shift from a free and open ecosystem (Web Apps) to vendor specific proprietary ecosystems (Native Apps).
- This leads to less investment in the web both in indirect investment (expertise, developer knowledge/experience) and direct investment (standards / APIs etc).
- If businesses have to develop multiple Native Apps instead of a single cross platform Web App due to lack of desirable functionality then those businesses have to incur far greater costs which ultimately get passed on to consumers.
- Native Apps are far more heavily taxed, and those costs must be passed onto consumers.
- Apple is a primary gatekeeper of Web App functionality which affects both iOS and Android (so need to be held to higher standard of evidence when denying functionality while not offering an alternative)
When considering functionality it's really important to consider a careful balance, with consumer needs taking a priority:
- Health / Viability of Web App Ecosystem
- Security
- Privacy
- Cost to the Consumer (i.e. Development / AppStore Fees)
It's not clear that potential security issues outweigh the health/viability and cost to the consumer issues and regardless of Safari's implementation alternative browsers should be free to provide this functionality and decide what's best for themselves.
Completely agreed with @mtom55's position. iOS & WebKits support for PWA, especially from an installation perspective lags far behind Android & Chrome.
If Webkit continues to treat them as second class we are unlikely to see mass adoption.
I also find two of @marcoscaceres points contradictory.
Misrepresentation: there is no way to verify that the screenshots or functionality being presented in the screenshots are representative of the web application itself
We instead feel that web applications themselves serve as the screenshots: unlike “app stores”, users generally use web applications before they install them
Screenshots of apps in app stores and otherwise are rarely directly representative of exactly the application, they provide context to what the user will do with the application- its material to convince the user that the application is worth installing!
The twitter example posted earlier is a good example of this. https://github.com/WebKit/standards-positions/issues/49#issuecomment-1259057111
Lastly, in response to this position:
Presentation of untrusted web content in a trusted UI
I find this a low-concern to non-concern, assuming that invoking installation is done from the Safari web add to home-screen menu. The user has already started the installation flow at this point and has seen the application. From a security perspective, screenshot display is going to make any current not-possible impersonation attacks possible. Safari on mobile is already displaying the icon and name of the application.
Safeties should be added in other layers around app installation- not by restricting PWA capabilities. Present the domain of the website and highlight cases where the domain is using common impersonation techniques (unicode character hacks etc). Safeties of this nature add to defence against phishing/impersonation attacks.
