HowardWolosky
commented
7 months ago 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
amandabaker
diekus
I wanted to circle back and get ideas on
install_sources, by default theWeb Install APIis set to not allow any installation unless there's aninstall_sourcesor anallow_all_install_sourcesin 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_sourcesto "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