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

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

Hi @christianliebel, thanks for the feedback and the resolution. We wanted to leave a few comments on the record here, since we'd actually given consideration to some of the comments you gave us.

Regarding organizational cross-origin installs: This is an interesting potential use-case. However, to the best of my knowledge, the only web technology that really tackled that sort of cross-origin declaration was Related Website Sets, aka First Party Sets; and this is [on track for deprecation in Chromium](https://chromestatus.com/feature/5194473869017088) presently. I think there is interesting novelty there, and I wish we'd discussed something there which had been productive sooner, although it isn't entirely clear to me that the claim of "it's considerably safer" is true. (What is "safe" on the web is entirely outlined by what the user agent affords the web to do, but I understand the impetus behind the claim.)

The latter question about the manifest and/or manifest ID: we opted to go this direction to **impose as small a requirement as possible on implementation** while addressing critical security, privacy, and performance issues. Notably, this change required a significant change to the way in which we installed applications within Chromium. Prior to the manifest-URL requirement, we actually installed an application by opening the application in an invisible tab and otherwise going through the same process that would have been invoked by the UI. Importantly, *the original mechanism would have inhibited the ability to operate on resource-constrained devices*, which led us to conclude it was not the ideal design.

Regarding the claiming of `navigator.install` or `<install>`, we have purposely chosen API shapes - accepting a dictionary and/or a list of optional element attributes - which can afford for change and growth in the future. If and when the TAG chooses to advocate for installation of an arbitrary web application without a manifest or other ID, the API shapes afford for that possibility in growth, based on implementors' desire for change. We gave diligent consideration to the questions of *what works for us right now?* and *how can we afford for what we can't predict right now?*. It very specifically is designed to afford adaptation in the future.

Thanks again,
Rob


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

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