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

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

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. 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,](https://infrequently.org/2020/07/why-ui-isnt-specified/) 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](https://github.com/WebKit/standards-positions/issues/619#issuecomment-4448282291), 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. 

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

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

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