Re: [w3ctag/design-reviews] Question: Review manifest-first Web Install API (Issue #1245)

slightlyoff left a comment (w3ctag/design-reviews#1245)

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:

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.

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.
 - Unlike Notifications, 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 or justified increase in security or even 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 as banners and through the omnibox -- as a way to head off the need for proposals such as this, that seems supportable by 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1245#issuecomment-5287201773
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1245/5287201773@github.com>