Brand newer TAG Review Update

Couple of quick personal reactions here (not representative of any sort of TAG consensus, and admittedly a little biased), but I don't see any meaningful engagement with WebKit's Position on this matter in the "Community Feedback" section.

Hi @marcoscaceres, thanks for your comment. We've had quite a bit of ongoing discussions with the community and other browser vendors, and we recognize that WebKit has had a rather continuous position regarding site-initiated installation flows. I think it's very fair to say that @dmurph has expressed some particularly fair feedback that we believe was in line with our own perspectives. Google is of course organizationally distinct from Microsoft even if we both contribute to Blink; but perhaps that is fair.

Having said so, I also submit that your position "on this matter" is with respect to the capability of user-initiated application install (notably, you referenced the BeforeInstallPromptEvent when commenting on "this matter"), and that issue is currently Closed. @LiaHiscock specifically said:

In the interest of productivity, we'd like to explicitly request technical architecture feedback on this proposal.

Although we are sensitive to the desire to ensure that we have appropriate user intent signals and to afford balance for prompt fatigue, we have quite thorough feedback from independent web developers, alongside experiment data from the Chrome team, which signal positive direction and sentiment toward the capability. That said, we would prefer not to relitigate the question of the capability here, lest we go around in circles.

I believe @LiaHiscock has answered most of the concerns about the capability in the "Re. previous TAG concerns" section. We appreciate your review.

Right, but this is fundamentally about architecture: does this capability belong in web pages at all is the core question. There’s fundamental disagreement on that amongst implementers precisely because of what “installing” an app means and to whom; plus the implications that has on the capabilities afforded to the web application (e.g., longer lived storage, push notifications, badging, etc.).

Adding install capability shifts how developers funnel users into their apps, which changes how apps are designed.

My feeling is that we need a TAG finding to settle this matter, as we’ve gone around in circles on this for 13+ years.

Cc'ing @adactio too, as it would be great to get his input here too as we move things along.

@marcoscaceres wrote:

Right, but this is fundamentally about architecture: does this capability belong in web pages at all is the core question.

Do “Smart App Banners” belong in web pages at all? Almost certainly not.

But this capability? Most definitely!

Hey folks,

I was directed to this thread and have read through much of the conversation. Like @adactio, I'm perplexed.

The most salient points have been repeatedly explained with great care, often F2F, over several years. Moreover, we now have a long functional track record to consult regarding many of the whataboutist concerns raised in the WebKit position that was referenced, and the OT experience does not indicate increased validity for them. Instead, it largely goes to show that they are manageable when not entirely unfounded.

In the interest of clarity, I'll go through the major questions raised in a point-by-point way here so that we cannot be accused of ignoring the feedback should we feel a need to ship over threats of a Finding (!!!).

Permissions (Non-)Escalation

First, and most importantly, we need to dispel the idea that installation grants permissions. It does not.

In no implementation of PWAs today are permissions elevated by the mere act of installation.

Some UAs remove a storage Sword of Damocles for storage that is already permitted, but that's not the same thing as granting a permission that users would have otherwise been consulted about. Indeed, in every other area where new features light up, they are either prompted post-install, in-context, based on use or they become newly available only because they did not make sense without the standalone app modality to back them (e.g., Share Target and WCO). Those capabilities are only "new" in the sense that we could not reliably figure out how to make them available otherwise. They do not pierce the origin model, nor do they change the security situation. All capabilities that would have needed a permission prompt can still be permission-gated by any UA that chooses to do so in a post-installation world.

There are secure UI questions to be answered in PWA installation flows, and as we have reckoned with them over the past dozen+ years, they all share a similar flavour: can users understand which origin is associated with the icon on their home screen? This is a process that takes on meaning both from presentation but also experience and use. The correct answer to the questions arising from it are derived from UXR and our bug rates. Thankfully, both point in a positive direction.

In Chromium-based browsers, this connection is re-enforced on a regular basis through unforgeable title bar UI (desktop), low-priority notifications (mobile), and installation and settings UIs (both) that are fully controlled by the runtime, rather than the site. Room has been preserved for UAs to chart their own UIs and policies in same-origin PWA installation flows, and that strategic flexibility was not an accident. The deliberately asynchronous and UA-controlled nature of these capabilities has been demonstrated to consistently enable app/origin affiliations in the UAs that support these APIs (e.g., oBIP) and consistent effort has gone into ensuring that reputation checks of all sorts can continue to be built and enforced in unforgeable ways at installation, management, and update moments. The cross-origin case does not add a fundamentally new concern, and the asynchronous, flexible, host-mediated flow continues to enable arbitrary amounts of friction from UAs that want to offer it.

This is the same trade-off as we have seen in many other areas implementing the TAG's guidance to enable asynchronous permission APIs. Mozilla was able, e.g., to use that flexibility to implement Web MIDI and now Web Serial using a higher-than-Chromium amount of UI friction. That's not a bug, it's an outcome we (including past TAGs) explicitly designed to enable, and represents the system working as intended. Perhaps in the distant future all browsers will align on some set of patterns for what to do in all of these cases, but I suspect not. As I've written elsewhere, we don't put browser UI into specs because we are going to change our UIs if it turns out we're wrong. Under these conditions, the best we can hope for is what is being proposed here: API surfaces that are explicitly designed to put the UA in the driver's seat, allowing arbitrary (and perhaps escalating) amounts of friction based on future concerns that are not fully understood today.

Mischaracterizing the permissions and security situation is particularly problematic given that most of the folks pushing this line work for browsers that have supported PWA installation in some form over the years. That experience has undoubtedly taught the same lessons, and instead of whatabouting here, I'd expect to see a reliance on evidence instead. Folks offering it are no doubt aware that installation doesn't grant push notification permissions, e.g., in any runtime I'm aware of. Even in the most restrictive, least-capable UAs, it only lights up the ability to ask for that permission. Conflating those cases is beneath the TAG.

Developer Feedback

Having read through the 30+ responses to the linked WebKit position thread considering same-origin installation affordances, the overwhelming feedback from non-implementer developers leans in support of both same-origin and cross-origin installation affordances. To characterize it differently would be to do violence to the arguments made there, and from my perspective that's natural. Unlike native apps, web applications represent the safer, more privacy and user-respecting alternative for accessing digital services.

This is surely a non-controversial viewpoint within the TAG so I won't belabour it here except to say that any issue (or Finding (!!!)) suggesting otherwise would be gravely in error if it did not first begin with a list of capabilities and features the TAG believes should be removed from all native applications in order to bring them into alignment with the more restrictive, less invasive policies implemented by all modern browser engines today. Given the length of such a preamble, it might be helpful for the TAG to publish it as a separate document.

Given all of that as background, it seems entirely reasonable to ask how this API should behave, not if it should exist. And that's the question before the TAG here. What specific, technical changes could improve the design? The team has taken some feedback from OT and decided that manifest URLs are a better design; does the TAG agree? Are there other open API shape questions that can be meaningfully worked through?

The TAG's Role in Blink Intents

The reason that @LiaHiscock, @robpaveza, and the rest of the team have continued to engage with arguments that veer from the circular to the amnesiac is, roughly, that I make them.

Well, not just me, but as part of the Blink API OWNERS group, I continue to back a policy within Chromium that tries to elicit TAG guidance to shape APIs in ways that will integrate well into the web platform because we have a (legitimate) fear of groupthink and "go fever". One way we try to tamp down on those potential overenthusiasms is first put developer feedback at the head of the line when it comes to assessing optional areas of a design. The Edge privacy and security teams will make a considered judgement independent of any other view, and have the power to block this work; we don't come to the TAG to manage those aspects of the design, nor do Google or Opera or Vivaldi. Instead, we look to the TAG to help ensure that designs fit well with the platform, that they use common idioms and patterns, and that where possible they create generatively more positive outcomes through composition and layering.

I.e., we ask the TAG to help keep the quality of APIs high, not to pass judgement on if they're needed in the first place, or secure in the final instance.

Which brings me to the content of this thread. As @adactio points out, nearly all browsers support installation of less-secure, less privacy-preserving native applications. For my part, I wish this was less true in general, and less necessary at the limit. One way we can make that possible is to expand the reach of web developers and the secure, private envelope that good browsers provide by enabling installation of web applications more widely.

I'd ask that TAG members weighing in here keep in mind that they are elected (or appointed) to represent their own best personal judgement in challenging technical matters, and that they are not being asked either to bless or absolve any particular business model. If there are concerns about the quality of the API's shape, we'd love to hear about them. If, instead, the team will be asked to respond to inchoate rehashes of points previously addressed by long experience or first-pass inspection...well, I don't reckon that makes for a process I'd ask the next lot to consult with.

There seems to be some confusion between browsers as products and browser engines. WebKit, an engine and open source project, is not Safari: a web browser product that makes use of the webkit engine. Smart Banners are a product decision.

Product decisions are outside the scope of the discussion.

Do “Smart App Banners” belong in web pages at all? Almost certainly not.

I don't think Apple ever proposed to standardize Smart Banner, AFAIK. That's a fundamental difference. No one is advocating for a Smart Banners web standard.

@slightlyoff, you've, again, completely missed the point of the WebKit feedback or are willfully choosing not to engage with the main point. Let me ask it in simple terms: do users want install buttons on their pages at all? Chrome's own data seems to suggest that users do not want this stuff in their web pages, even if developers think it's a fabulous idea - just like users probably wouldn't want a <button>bookmark this page</button>. That's why WebKit's position is: users who want to install an app can just use the browser's UI.

Could browsers do better improving the install/add to home screen UX? Sure.

Are developers going to do better than browsers? that's literally the question. And, given this affordance, is there a risk that the feature could be misused to nag users to install precisely because it grants the app more capabilities? Even if well-intentioned, it fundamentally changes the incentives of developers.

I'm not sure anyone in the thread is confused about the difference between WebKit and Safari. You may be aware that we (Edge) maintain a WebKit-based iOS browser today, though we would vastly prefer to use a different engine there.

Putting iOS's forced engine monoculture and concomitant suppression of alternatives to Safari to the side for a moment, we can clearly say that may sites on the internet do prompt users to install applications, and that as partisans for the web (rather than proprietary native app platforms) we (Edge) would prefer it if those prompts directed users to install their web applications instead.

As we have patiently re-explained, the counterfactual you've returned to is not reality, and when folks bring Smart Banners into frame, it isn't because they are confused about what's engine and what's browser -- instead, they're trying to get you to acknowledge what everyone else can see. Failing to reckon with that web-wide reality would be disingenuous, and indulging debates about a fully theoretical status-quo would neither help users or developers. If WebKit wants to add code to prevent all links from leaving the browser, including links to app stores, that would be a welcome declaration of intent. Barring it, I'm not sure what we're discussing.

As for browser UIs that can offer these affordances, that's immaterial to the question being asked: are there changes that could make this capability fit better into the platform, given that there are browsers that will ship something along these lines?

The problem with the question is that it’s built on a bunch of presuppositions. That’s really the ask of the finding: to neutrally document what those are from multiple perspectives so we, as a collective (including you and everyone here), can make an informed decision as to a path forward.

The presuppositions are simply reflecting reality. We have data from the ecosystem that allows us to understand the relative prevalence of prompting today, although they don't create direct comparators thanks to various limitations.

Regarding oBIP(), ~13% of page loads in Chrome qualify to display a prompt or to trigger UA-supported install UI. Less than a quarter of those page (3%) attempt to offer their own UI rather than browser-provided affordances and, despite this capability being available for a decade, only 0.019% of pages display a prompt. Put another way, 0.63% of pages that qualify to show their own prompts do:

https://chromestatus.com/metrics/feature/timeline/popularity/1436 https://chromestatus.com/metrics/feature/timeline/popularity/1436 https://chromestatus.com/metrics/feature/timeline/popularity/1439

If the argument is that 0.019% is a user abuse catastrophe, I'd welcome data on the counterfactual. What it suggests to me is that when UA affordances are voluble and effective (as they are in many Chromium-based browsers, but demonstrably are not in, e.g., Safari), the need for customized prompts falls away.

Not for nothing, but as this debate has dragged on, I'm increasingly confused as to the data-light content of the catastrophizing. You could have asked for other vendors that provide prompting surfaces to share what they have learned through their telemetry to make the argument, including the rates at which sites link users out to native app acquisition channels. This is very likely to be significantly above 0.019% (again, an absolute rate of 0.00019 out of 1) of page loads given the dark patterns deployed pervasively today to trick users into installing/invoking native apps, e.g. on Facebook, Instagram, TikTok, etc. It doesn't take many top-10 sites to drive up the score and fundamentally transform user's experiences. Indeed, it appears that 20% of the top-1k sites attempt to trigger Safari installation banners for native apps, and 16% of the top-10K do as well:

https://trends.builtwith.com/link/Apple-App-Link

Because web use is head-heavy, those numbers are a floor on total native app prompt rates, at least for iOS. For Android, as discussed above, we observe many links from content directly to stores (a terrible dark pattern), as well as ~2% of page views prompting users to install their native app from browser-provided UI:

https://chromestatus.com/metrics/feature/timeline/popularity/5345

All of this shows that the counterfactual is not a world without prompts; it's a choice to ignore the problem, to try to solve the problem, or to turn off all prompts for app-like experiences from browsers to discourage prompts -- e.g., by introducing code that removes the ability to link to app stores and native apps entirely and sunsetting features like Smart Banners.

To avoid confusion, I must also repeat some baseline facts about all of these APIs, both proposed and launched:

• All banner/prompt creating APIs are designed to give the UA the power to suppress the ability for a site to prompt on any specific site, opening up wide policy latitude for UAs, similar to the latitude we have enjoyed when suppressing Notification prompts across a wide swath of the web in recent years.
• These APIs have been designed with anti-spam surfaces in mind from the start. The design of oBIP(), in particular, is anti-spam friendly.
• Cross-origin install will remain firmly within the purview of every browser to expose as it sees fit. There is no blanket policy being requested or proposed here, and many of the choices made in the design and validated in the Origin Trials focus specifically on ensuring that the UA can guard the user's interests, while still making a market for responsible parties to offer Web Applications.
• Contrast this with the state of play regarding native apps, where the dominant mobile UAs gleefully allow any/every site to bounce users into app stores that are antithetical to the web's interests, and some even allow link capturing to disrupt user's browsing, inserting native apps instead (e.g. App Clips).

It's head-spinning to see this reality, along with the care taken in all of these designs to tamp down on exactly the concerns raised here, downplayed by a TAG who has invested so much time in the issue.

As for a Finding, it would be shocking to see the TAG use its moral authority (which is what Findings represent) to attempt to browbeat browsers into not offering features the web's competitors provide, and which would harm the web's competitive position despite providing no identifiable decrease in security or probable net increase in user annoyance. Attempts to bring the conversation to a point of reference that has no relationship to the contemporary web (on any platform) seem, at best, non sequitur.

If the TAG wants to write a finding about how important is for browsers to offer compelling and high-profile installation surfaces for PWAs using available site metadata -- e.g., the analogue of both Safari's Smart Banners and Edge/Chrome/etc.'s various install surfaces such as banners and omnibox icons -- as a way to head off such proposals, that seems marginally supportable by the evidence. That said, it doesn't seem as though it would be persuasive to the parties that have seemed entirely resistant to meeting web developer needs to date, so the investment of time and reputation seems hard to justify.

Thank you to everyone who's weighed in on this so far.

I'm one of the independent developers whose feedback was cited earlier in this thread.

I'd like to push back (again) at the conclusion that low installation rates signify low interest in PWA installation. My contention is that engagement with web apps is low, in part, due to low public awareness of what web apps even are, due in large part to the fact that today's installation flows are severely lacking. The option to install is often so buried that users simply haven't been exposed to the concept.

In browsers like WebKit-based Safari, the installation process is so obscure that, out of all the users who may be interested in installing a web app, only a tiny percentage will ever realize that option is available to them. Further, only a tiny percentage of those who have made up their mind to install a web app will make it through the complicated, often-changing interactions required to do so.

As @marcoscaceres stated:

WebKit's position is: users who want to install an app can just use the browser's UI.

This stance might make sense if the browser UI in question did not require more interactions to install a web app than any other browser available today. At the time I created this PWA-installation guide, 6 steps were required to install a web app on iOS. That number now appears to be 5. While a decrease in friction is appreciated, this illustrates the fact that developer-created installation guides will never keep up with changing browser and OS-level UIs, leading to poor outcomes for those users who do want to install and use web apps.

In informal user testing, I've sat right next to users whose explicit goal was to install our web app to their homescreen. Even with a link to the required installation steps, most users struggled immensely. Overprotecting users who may not want to install web apps directly harms the users who do.

A clear, standardized way to install web apps without relying on varied browser interfaces is critical to the adoption and success of web apps as a concept.

To quote @marcoscaceres again:

Adding install capability shifts how developers funnel users into their apps, which changes how apps are designed.

Yes, adding install capability would change how apps are designed... in a good way! More developers would be encouraged to spend time developing web apps if their users had a viable installation path. Public awareness of web apps would grow, usage of web apps would increase, and users would have increased choice and freedom in how they receive and use software.

Now how could anyone object to that..? :-)

Hi all. We are planning to discuss this at our upcoming W3C TAG face-to-face in early September. So let's come back to this discussion after that.