[Web Install] Feature adoption

[diekus]

I wanted to circle back and get ideas on install_sources, by default the Web Install API is set to not allow any installation unless there's an install_sources or an allow_all_install_sources in the target PWA's manifest-- this serves as a 2-way mechanism that helps stop possible installation spam. I am ok with this. Just because an origin has an install permission it shouldn't be able to start installing any PWA. The challenge is that this can diminish adoption of the API once it is out. The scope of the feature is only to install web apps, but thinking about it's current form, how can we make sure we promote a healthy adoption pace closer to launch.

I don't think reverting the current default behaviour of install_sources to "allowing any PWA be installable from any cross-origin site" would be sensible, and I recon there's a lot of education and dev-rel and support in tools to make this take off. Want to get your ideas around this.

cc @mwbender @dmurph @amandabaker @HowardWolosky

[HowardWolosky]

I've never been quite sold on the utility of install_sources (or at least the deny-by-default approach). An argument that I've heard in favor of it is that it helps to protect users from allowing nefarious sites the ability to install trusted sites. I'm still not sure what that gains. The only benefit that a nefarious site can get from this is to know that the web app is installed.

The user already needs to permit the nefarious site to be able to install apps. If the concern is that a nefarious site may say that it's installing "Foo" but instead it installs "Bar", that isn't solved by this. That can still happen anyway. My contention is that it should be up to the UA to ensure that the user is appropriately and adequately informed regarding what web app is about to be installed before they complete their user gesture and permit installation of the app.

If the concern is that a nefarious site may spam multiple installations, once again, that issue isn't solved by this. They could still do that once the user grants install permission, just limited to (likely other nefarious) sites that they already have a relationship with. We might suggest in the spec that UA's limit the number of installs that an origin can request over a given period of time.

From a web app perspective, it's not clear what benefit would be derived from limiting user acquisition of their app. I would wager that the majority of web apps don't care how/why a user installed them, provided that the user is using them.

As far as I can tell, the only thing that this deny-by-default approach accomplishes is preventing unknown sites from knowing if the app is installed, but only if that unknown site was the one that installed it. I don't think that web app developers will care about this. And for users, as long as it's deny-by-default, there won't be much benefit from the API if there isn't sufficient adoption by web app developers.

With deny-by-default, we effectively create a walled garden that will make it far harder for a new install source to come up later once the API has already launched. If we update tooling so that it just sets allow_all_install_sources = true by default in order to help with adoption, and we're assuming that a majority of manifests are created by that tooling, then we're effectively acknowledging that there is a problem with the design.

I would recommend we still support manifest configuration, but enable-by-default. Instead of allow_all_install_sources, we could have deny_all_install_sources. We could then decide if we want to keep install_sources as an opt-in list for when deny_all_install_sources is true, or turn it into deny_install_sources where it's an opt-out list. At the moment, I'd recommend the former.

[mwjacksonmsft]

Drive by comment, so apologies if I'm misinterpreting your feedback @HowardWolosky .

If keeping install_sources prevents "The only benefit that a nefarious site can get from this is to know that the web app is installed.", that feels like a significant privacy win. If it causes it - then it seems like we should have further discussion.

Delayed Clipboard Rendering had a similar concern - and it was mitigated by only allowing built-in formats to be delay rendered. You can read up about it here: w3c/editing#439

[HowardWolosky]

If keeping install_sources prevents "The only benefit that a nefarious site can get from this is to know that the web app is installed.", that feels like a significant privacy win. If it causes it - then it seems like we should have further discussion.

@mwjacksonmsft - install_sources wouldn't mitigate this. The current design only allows the install source that installed the app to be able to see if it's currently installed. install_sources currently just limits which sites are able to attempt an install with a user gesture. So, install_sources isn't providing any privacy win here as you're describing.

[amandabaker]

Installation will already be gated behind a permission, the following would have to happen for a malicious site to know if a user installed an app:

1. The user navigates to a malicious site
2. The malicious site requests permission to install other apps
3. The user clicks somewhere on the page and the UA shows an installation prompt
4. The user accepts the installation prompt
   Result: navigator.install() resolves successfully indicating to the malicious site that the app has been installed.

Given how many steps the user has to take to allow the site to know the user installed the app, I don't think this is a reasonable concern.

However, #778 updates the default installation behavior to be up to the UA. This allows privacy minded browsers to block by default while still permitting other browsers to allow by default

[diekus]

is this resolved by putting this in the hands of the implementer?