beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app

[rniwa]

Prompting the user to "install" a website (via beforeinstallprompt) makes it hard to tell whether the user actually wanted to save the website for later use, or the user just wanted to pass through the prompts encountered before using / while the web app.

If we're trying to gate any feature only to installed apps, then it goes directly against the goal of differentiating websites that the user trusts; by the virtue of eagerly asking the user to install an app, we've decreased the likelihood that the user intentionally did so.

[ecjs]

Wait, what? Am I the only one that’s having trouble following what is actually being said here?

[rniwa]

Let me try it again. The issue isn't that the user won't understand "installing" means saving to "home screen". The label or description doesn't matter much.

The issue is that if website is asking the user to save it on home screen, that is less of a signal to the web browser / operating system that the user had intentionally done so because some user may just tap through prompts from habit / muscle memory.

If the user were to manually add it to home screen via browser's UI, then that's more of a positive signal that the user wanted to do that.

[dominickng]

In Chrome, users are shown the same confirmation prompt regardless of whether beforeinstallprompt or browser UI is used to initiate an installation. I'm not quite sure why there would be a significant difference in intent between the user initiating the installation process from the web content area or from browser UI - can you elaborate more?

As another example, granting powerful permissions like location or camera/mic are all typically initiated from the web content area.

[rniwa]

As another example, granting powerful permissions like location or camera/mic are all typically initiated from the web content area.

Those permissions aren't used as a signal to allow other features, and there is a clear connection between what the user is trying to do (e.g. join a video conference) to what the permission is asking (e.g. access to camera).

In general, we don't think asking persistent permissions upfront in a manner disassociated with the relevant user actions is a good model for security or privacy sensitive features because there is a risk for users to tap through prompts without fully understanding the implications, the users may not remember what permissions they've previously granted to a given website, and it may not be clear for users to revoke such permissions later.

For pasting from system clipboard (a.k.a. pasteboard on Apple platforms) to work on iOS WebKit, for example, we show a callout bar with "Paste" as an item to match the behavior of user triggering selection, and only when the user taps "Paste", we grant one time read access to the clipboard. We don't allow generic persistent access permission to system clipboard.

[dominickng]

Those permissions aren't used as a signal to allow other features ... In general, we don't think asking persistent permissions upfront in a manner disassociated with the relevant user actions is a good model for security or privacy sensitive features because there is a risk for users to tap through prompts without fully understanding the implications, the users may not remember what permissions they've previously granted to a given website, and it may not be clear for users to revoke such permissions later.

Installation as a sole signal to allow other features is not considered good practice in Chromium either (see https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/permissions-for-powerful-web-platform-features.md), and we are trying to move towards a model where persistency of permissions is the key differentiator of installation (since installing is an explicit act of persistence by the user). Permissions in tabs would move towards being ephemeral only.

, and there is a clear connection between what the user is trying to do (e.g. join a video conference) to what the permission is asking (e.g. access to camera).

This would be entirely under the control of the web content right?

[rniwa]

Those permissions aren't used as a signal to allow other features ... In general, we don't think asking persistent permissions upfront in a manner disassociated with the relevant user actions is a good model for security or privacy sensitive features because there is a risk for users to tap through prompts without fully understanding the implications, the users may not remember what permissions they've previously granted to a given website, and it may not be clear for users to revoke such permissions later.

Installation as a sole signal to allow other features is not considered good practice in Chromium either (see https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/permissions-for-powerful-web-platform-features.md), and we are trying to move towards a model where persistency of permissions is the key differentiator of installation (since installing is an explicit act of persistence by the user). Permissions in tabs would move towards being ephemeral only.

I'm not sure how or why this commentary of what Chromium does or intend to do in the future is relevant to my earlier comment but okay.

, and there is a clear connection between what the user is trying to do (e.g. join a video conference) to what the permission is asking (e.g. access to camera).

This would be entirely under the control of the web content right?

And that is precisely why we want to limit & reduce the number of such permission prompts as much as possible. Any new prompt that depend on web content requires a substantial burden of proof to be added. Accessing a camera, for example, is inherently tied to what the website offers (e.g. video conference) and the current state of what the website is trying to do (e.g. are you in a chat room vs. shoping page). Saving a website to home screen doesn't come off as something that's required to be initiated within the website due to its dependency on a specific functionality or a state of a given website. Having a dedicated UI in the browser to do that (as Chrome & Safari both already offer) would be a better fit.

[dominickng]

I'm not sure how or why this commentary of what Chromium does or intend to do in the future is relevant to my earlier comment but okay. ... Saving a website to home screen doesn't come off as something that's required to be initiated within the website due to its dependency on a specific functionality or a state of a given website.

The commentary precisely ties into this: installation should not be a guard for other permissions, and in and upon itself it should not give sites more than the persistency of a home screen shortcut and the ability to run in a standalone fashion. That is, we already avoid purely gating features only to installed apps, and avoid treating installation as a "trust" point for other permissions.

[rniwa]

I'm not sure how or why this commentary of what Chromium does or intend to do in the future is relevant to my earlier comment but okay. ... Saving a website to home screen doesn't come off as something that's required to be initiated within the website due to its dependency on a specific functionality or a state of a given website.

The commentary precisely ties into this: installation should not be a guard for other permissions, and in and upon itself it should not give sites more than the persistency of a home screen shortcut and the ability to run in a standalone fashion. That is, we already avoid purely gating features only to installed apps, and avoid treating installation as a "trust" point for other permissions.

I understand that Chromium or Google may hold such a position but Apple's WebKit team may not necessarily agree with such a position.

[elylucas]

How about when an app is a proper PWA (SW, Manifest, Secured), a more prominent "Install App"/"Add to HomeScreen" is displayed somewhere more findable in the browser UI.

This would get rid of the cumbersome procedure of having to hunt through the share picker and find "add to home screen", which we find is a seldom used feature by normal users.

Also, thanks for all that you do here. I know it has to be a difficult job of providing a great user experience and providing developers with the tools/apis we need to build great apps.

[rniwa]

How about when an app is a proper PWA (SW, Manifest, Secured), a more prominent "Install App"/"Add to HomeScreen" is displayed somewhere more findable in the browser UI.

This would get rid of the cumbersome procedure of having to hunt through the share picker and find "add to home screen", which we find is a seldom used feature by normal users.

This is somewhat outside the scope of this issue because W3C doesn't dictate or recommend how browser may present such an UI but we're aware that many people feel the current UI on iOS is too obscure for ordinary users to find it.

Also, thanks for all that you do here. I know it has to be a difficult job of providing a great user experience and providing developers with the tools/apis we need to build great apps.

Thanks for your kind words :)

[dominickng]

@elylucas that was actually how beforeinstallprompt event used to work - it was purely advisory for developers than a prominent, browser UI installation prompt was about to be automatically shown, and the event was a way to prevent the prompt from being shown until a more opportune moment.

We received feedback from developers that an API where they could actually trigger installation themselves (subject to constraints like requiring a user gesture, passing installability requirements, and having sufficient engagement) was more ergonomic. We reworked beforeinstallprompt to satisfy that, whilst keeping the event semantics to ensure that the browser would only allow site-triggered installation under the mentioned constraints.

And to echo @rniwa, thanks for your kind words. It's challenging to get to agreement here, but the benefits for developers and users are huge. :)

[aeallord]

Maybe my thought is off the wall on this thread, but my concern with the "Add to Home Screen" prompt it will eventually become annoying to users of mobile websites. This is the case with sending push notifications currently. A majority of sites will immediately prompt you to send push notifications, users for the most part simply deny out of habit. In time it will completely defeat push notifications.

I think that is what @miwa is pointing out. A means to request the user to make a conscious choice to add it to the home screen becomes more meaningful to developers and companies as the user then intended to have the PWA on the home screen. Permissions to me are a whole other nightmare.

I do appreciate what you do for the web and can only imagine the massive challenge faced from so many developers and browser companies.

[rniwa]

I think that is what @miwa is pointing out. A means to request the user to make a conscious choice to add it to the home screen becomes more meaningful to developers and companies as the user then intended to have the PWA on the home screen. Permissions to me are a whole other nightmare.

Indeed, that's the core of what I'm trying to say here.

I do appreciate what you do for the web and can only imagine the massive challenge faced from so many developers and browser companies.

Thanks for kinds words :) I like that everyone here is very civil & kind here. We need more of that in our industry instead of treating people with different opinions with animosity.

[tomayac]

@rniwa As the initial requester of this feature on the WebKit bugtracker, first of all, thanks for openly engaging on this.

I think people on this Issue thread mix a couple of not necessarily related (yet admittedly close) things:

1. Gating permissions on the installed state.
2. The way a prompt or ambient install badge would be shown.
3. The terms used to ask the user ("install" vs. "add to home screen" vs. "…").

For 1., this can happen at the UA's discretion, but certainly doesn't have to happen. The spec, as far as I can tell, makes no assumptions in this direction.

For 2., this can be an annoying overlay like the notifications prompt on many UAs, but it can also be a subtle (+) in the URL bar or anything else the UA in question comes up with.

For 3., this is completely up to the UA to decide, experiment, and optimize.

The way I understand beforeinstallprompt is that it allows the developer to time the prompting right (e.g., don't ask immediately after loading, but maybe wait until a meaningful page action has happened, which could be "an item was purchased", "an article was read",…). This gives back control to the developer.

Apple has pioneered the concept of Web Clips way back in 2008, maybe there is a chance for Apple to evolve it in 2020, and incorporating some of the learnings from Smart App Banners?!

[othermaciej]

The commentary precisely ties into this: installation should not be a guard for other permissions, and in and upon itself it should not give sites more than the persistency of a home screen shortcut and the ability to run in a standalone fashion. That is, we already avoid purely gating features only to installed apps, and avoid treating installation as a "trust" point for other permissions. I understand that Chromium or Google may hold such a position but Apple's WebKit team may not necessarily agree with such a position.

Chromium doesn't seem to be fully following this policy fully either. For example Periodic Background Sync is being added as a feature with implicit permission based on installed. It's nice as an aspiration but it's not clear that this is where treatment of installed web apps is going.

[ecjs]

@othermaciej Apple can decide not to gate features to installed apps though right? I think the argument thats being made in this issue is that prompting users is a bad idea...

because some user may just tap through prompts from habit

I find it hard to believe that this is the actual reason Apple is deciding not to implement some sort of solution for this.

[marcoscaceres]

Just chiming in on the Mozilla side that we share Apple's concerns about beforeinstallprompt, which is also why we've decided not to ship it (despite implementing it). Mozilla's conclusion was that we don't think it's needed. We will continue to endeavor to provide a nice installation ceremony for users and do our best to surface that a web application is installable to users via the browser UI.

[ecjs]

we don't think it's needed

@marcoscaceres Care to elaborate on this?

...I want you all to imagine that you are a developer or running a product. Next I want you to imagine that you've built a beautiful web app, PWA, ..."web thingy that installs"

Then I want you to imagine, that a user asks..."How can I install your web app?"

How would you answer that question? You would have to give them a different set of directions for every browser, because every single one of these browsers is going to do something different with their elegant badging/ceremonies. Not to mention they all call web apps something entirely different.

...Now imagine a brand/app specific UI that directs them to install the app with an API that functions similar to beforeinstallprompt, that works/behaves consistently no matter the browser. I've attached an example...ignore the placeholder..it doesn't matter. The user clicks install, it opens a browser specific confirmation/prompt/whatever.

The only real reason I can imagine browser teams avoiding implementing this is because they are worried about bad actors/abuse/whatever...they've got post push notification permission request disorder...and listen, I get it. Nobody likes being prompted every two seconds as they peruse the web. I'm sure there are things we all learned from that implementation.

[ecjs]

@marcoscaceres you were right about everything here:

So, unless all browsers have a standardized mechanism, the web suffers.

https://github.com/mozilla/standards-positions/issues/84#issuecomment-384507840

[marcoscaceres]

How would you answer that question?

“Bookmarking” was a weird concept not long ago - but nowadays most users know what it is to “bookmark” something.

So I’d imagine “installing” will be similar: just a normal thing that a browser provides and a normal thing that users come to expect as they gain browsers literacy in over time.

Browser makers help users learn about “installing” by teaching them about these UI affordances in various ways: onboarding screens... marketing steps in... all the way to TV/Movie advertising. Over time, installing becomes part off the normal browsers lexicon: Open a tab, “googling“, bookmarks, install, add to homescreen, etc.

Just a browser thing.... “you don’t need to bookmark it - Just install it”™️.

[ecjs]

You're kind of making my point. You need to deeply educate users on how to install an app on every specific browser, otherwise they'll never know they can. Firefox, Chrome, Safari all have to deeply educate their users on how to install on their specific browser.

Instead of each respective browser team working together to come up with an API that works for everyone. One thats hard to abuse by the bad actors y'all are worried about.

What is it exactly that everyone is worried about in implementing an API that requires user interaction to display a browser-specific install prompt? And where do you draw the line with other abusable things...oh l don't know...like an <img>.

[marcoscaceres]

Firefox, Chrome, Safari all have to deeply educate their users on how to install on their specific browser.

That’s the challenge, yes. But browser vendors are up to the challenge. Even if we shipped the API, we still have to educate users for those sites that don’t use the API but are still installable (i.e., potentially any/all websites are installable, installability signals be damned!).

[tomayac]

[P]otentially any/all websites are installable

Nota bene that there’s a difference between desktop-style “create a shortcut and open in a dedicated window” and mobile-style bookmarking on the home screen vs. more integrated “install” with so-called WebAPKs, which are, to recall, not limited to just the Google Play Store, but also other stores, for example, Samsung’s Galaxy Store, and the Windows Store. This allows for OS integration like uninstalling the default OS way.

Update: this is not about inclusion in stores, purely about the fact that installation through mechanisms like WebAPKs or similar exist.

[rniwa]

Then I want you to imagine, that a user asks..."How can I install your web app?"

I have no doubt you'd get such questions but please also understand that the frequent complaints we get as a browser vendor is that websites are harassing users with prompts & asking for random permissions.

How would you answer that question? You would have to give them a different set of directions for every browser, because every single one of these browsers is going to do something different with their elegant badging/ceremonies. Not to mention they all call web apps something entirely different.

This seems like a necessary evil in that the concept of application is different across different operating systems and platforms. What each platform or operating system may allow web / native app to do is quite a bit different.

...Now imagine a brand/app specific UI that directs them to install the app with an API that functions similar to beforeinstallprompt, that works/behaves consistently no matter the browser. I've attached an example...ignore the placeholder..it doesn't matter. The user clicks install, it opens a browser specific confirmation/prompt/whatever.

Great. Now imagine that when a user visits dozens of websites they routinely do, each one asks the user to save it to home screen. Maybe every once in a while, the user would accidentally tap on it and save it to home screen.

Compare that to the workflow of going to iOS App Store. It might be opened via another app or website, but the user has to click on "Install" explicitly to install any app. This is a deliberate action of the user, not someone trying to get through prompts to use their device. Also contrast to the current workflow of user having to open the share sheet in Safari and tap on "Save to home screen". Again, there is very little chance that this happens accidentally.

I get that there is an appeal for this feature because you can provide a nice UI in your own website across the board, and I understand that many feel that Safari's UI to save a website / app to home screen isn't very obvious to the users right now but I don't think adding this event / capability to the Web is the right solution.

[electrify12]

I get that there is an appeal for this feature because you can provide a nice UI in your own website across the board, and I understand that many feel that Safari's UI to save a website / app to home screen isn't very obvious to the users right now but I don't think adding this event / capability to the Web is the right solution.

Unfortunately this is what I hear far too often from the webkit team, that the proposed solution is inadequate. While there is nothing wrong with having different opinions or disagreeing, what I don't often hear are potential alternative solutions. This is a highly requested feature from developers and it would be great to hear vendors thoughts as to what the best solution might be.

[rniwa]

Unfortunately this is what I hear far too often from the webkit team, that the proposed solution is inadequate. While there is nothing wrong with having different opinions or disagreeing, what I don't often hear are potential alternative solutions. This is a highly requested feature from developers and it would be great to hear vendors thoughts as to what the best solution might be.

As far as I can tell, the best solution is to keep it a part of the browser / operating system concern, not of a Web API.

[alancutter]

https://www.w3.org/TR/appmanifest/#install-prompts beforeinstallprompt only comes into play once the user agent has decided to prompt the user to install a site. User agents may trigger a prompt at their own discretion (which may be never).

Given the inherent flexibility granted to user agents on this contentious UI I'm not sure anything needs to change in the spec. User agents are free to follow their own values.

[rniwa]

Given the inherent flexibility granted to user agents on this contentious UI I'm not sure anything needs to change in the spec. User agents are free to follow their own values.

The last I checked, having multiple independent implementations of a given feature was an important exit criteria of W3C and this working group. Given the feedback that Gecko and WebKit will likely not implement this feature, the most appropriate action for the working group is to remove the event / feature from the specification.

[marcoscaceres]

The last I checked, having multiple independent implementations of a given feature was an important exit criteria of W3C and this working group. Given the feedback that Gecko and WebKit will likely not implement this feature, the most appropriate action for the working group is to remove the event / feature from the specification.

Agree. We've had beforeinstallprompt event in the spec for multiple years - it is time to concede that it should be removed due to lack of implementer interest (and the reasons above).

[jyasskin]

https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html also seems like a feature that reduces the signal of whether the user really wanted to install an app, vs just wanted to get rid of a prompt. @rniwa, could you elaborate on any differences you see between that "please install me" prompt and the one controlled by the beforeinstallprompt event, which make the first acceptable to WebKit and the second not?

Thanks!

[rniwa]

https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html also seems like a feature that reduces the signal of whether the user really wanted to install an app, vs just wanted to get rid of a prompt. @rniwa, could you elaborate on any differences you see between that "please install me" prompt and the one controlled by the beforeinstallprompt event, which make the first acceptable to WebKit and the second not?

Those banners don't ask or prompt users to install any app; it simply indicates that there is an app available if they wanted to use, and links to the relevant content in App Store where the user then has an option of installing it. There is no mechanism to directly install an app straight out of app banners.

In the case of a web app, users are already using the app so there is no reason to remind them of its existence (since they're already using it), and the way people promote that there are other apps available on the web is to have hyperlinks to them.

[dominickng]

Those manners don't ask or promot users to install any app; it simply indicates that there is an app available if they wanted to use, and links to the relevant content in App Store where the user then has an option of installing it. There is no mechanism to directly install an app straight out of an app banners.

Under this definition, beforeinstallprompt also does not provide a mechanism to directly install an app, and seems analogous to what you have described Apple's native app banners as doing: showing the user native UI containing the app metadata, and give them an install button should they wish to install.

Do you mind clarifying the distinction you see here? I'm having a hard time drawing a distinction. :)

In the case of a web app, users are already using the app so there is no reason to remind them of its existence (since they're already using it), and the way people promote that there are other apps available on the web is to have hyperlinks to them.

Semantically, I suspect users think of hyperlinks as not really representing links to apps, but links to web pages, which is why developers have made it clear that the ability to promote their web apps in this way is important.

[rniwa]

Those manners don't ask or promot users to install any app; it simply indicates that there is an app available if they wanted to use, and links to the relevant content in App Store where the user then has an option of installing it. There is no mechanism to directly install an app straight out of an app banners.

Under this definition, beforeinstallprompt also does not provide a mechanism to directly install an app

I don’t follow. beforeinstallprompt is literally about showing UI to install a web app. Not about indicating the existence of some other app.

and seems analogous to what you have described Apple's native app banners as doing: showing the user native UI containing the app metadata, and give them an install button should they wish to install.

Not at all. The fact there is an install button is almost incidental. The primary purpose is to have a way of discovering the app associated with a website.

Here, we’re talking about the feature which asks the user to install an app. That’s an entirely different feature.

Anyhow, I don’t think spending anymore time discussing whether these things are analogous in your view or our view would be productive. It’s true that different people and companies may have different perspective on things and that’s okay. We don’t have to agree on every perspective; that’s sort of the point of diversity & having multiple implementors.

In the case of a web app, users are already using the app so there is no reason to remind them of its existence (since they're already using it), and the way people promote that there are other apps available on the web is to have hyperlinks to them.

Semantically, I suspect users think of hyperlinks as not really representing links to apps, but links to web pages, which is why developers have made it clear that the ability to promote their web apps in this way is important.

I don’t see how that’s relevant? Besides, if they’re interested in making their hyperlinks looking different, they can. There is nothing preventing them to do that.

Also, if this topic was somehow relevant, beforeinstallprompt isn’t about discovering other web apps at all. This is about asking the user to install the very website / app they’re currently using.

[tomayac]

I don’t follow. beforeinstallprompt is literally about showing UI to install a web app. Not about indicating the existence of some other app.

@rniwa, I think there's something important missing from your statement above, which is:

"beforeinstallprompt is literally about showing UI to install a web app <ins>at exactly the moment the app developer deems the right moment</ins>".

Having this event allows for enabling experiences like Microsoft showed with their <pwa-install> custom element that now has to take a special code path for dealing with iOS. The event, by the way, also allows developers to prevent the browser prompt and app-level install buttons from showing at all, whereas Smart App Banners always show (either with the "View" or the "Open" label). As an iOS user myself, this gets tiring really quickly, especially since it causes a content jump.

A prompt can also be non-intrusive, as Samsung Internet has shown (the down arrow in the URL bar):

In my understanding, the onbeforeinstallevent was introduced to avoid bad experiences with annoying prompts to give developers control, allowing for different install patterns, with automatic browser promotion being the poorest.

Concluding, if Safari showed a subtle badge like Samsung Internet that then entered the regular share sheet "Add to Home Screen" flow at the "Cancel"/"Add" state shown in the screenshot below and that respected the icons from the Web App Manifest (my related WebKit bug), this would put the user in full control and not annoy them.

[madmoizo]

The initial issue was:

The issue is that if website is asking the user to save it on home screen, that is less of a signal to the web browser / operating system that the user had intentionally done so because some user may just tap through prompts from habit / muscle memory.

But as @tomayac said

beforeinstallprompt is literally about showing UI to install a web app at exactly the moment the app developer deems the right moment

That means User will have to click an "install" element in the webapp UI which will trigger the browser confirmation UI. I don't think the user will "autoclick from habit" in this process.

The real issue is the automatic "mini info bar" which shouldn't be automatic (or shouldn't exist at all) but let the developer decide when he can inform the user that the application is installable (and allow him to install it with the same experience despite browsers differences) is a must have.

[rniwa]

Having this event allows for enabling experiences like Microsoft showed with their <pwa-install> custom element that now has to take a special code path for dealing with iOS.

That's exactly the kind of a thing we don't want to allow. We don't want websites to have its own UI to initiate some kind of browser UI to save / install a web app to home screen.

Concluding, if Safari showed a subtle badge like Samsung Internet that then entered the regular share sheet "Add to Home Screen" flow at the "Cancel"/"Add" state shown in the screenshot below and that respected the icons from the Web App Manifest (my related WebKit bug), this would put the user in full control and not annoy them.

Indeed but in that scenario, there is no need for this event because such an UI is by definition non-intrusive. I feel like I keep repeating myself but the issue here is that we don't want to give web apps / site control as to when or how the ability to save a web app / website to home screen is presented to the user.

The real issue is the automatic "mini info bar" which shouldn't be automatic (or shouldn't exist at all) but let the developer decide when he can inform the user that the application is installable (and allow him to install it with the same experience despite browsers differences) is a must have.

I understand you and some other developers feel that way, but this is precisely what we're objecting. We don't want to give away that control to web apps / sites.

[rniwa]

Note that there is currently no restriction as to which web site / app can be saved to home screen in iOS so the idea that the UI to save it to home screen shouldn't be always presented doesn't appeal to us. For example, we don't want to get to the world where a bunch of websites would simply prevent themselves from being saved to home screen just so that they can encourage more users to install native apps either.

[tomayac]

Note that there is currently no restriction as to which web site / app can be saved to home screen in iOS

And likewise not on Android or any other platform that I am aware of. Manual install via the browser menu is always possible, just the prompted install (that on Android is connected with what we call a WebAPK) is gated by the site’s “PWA-ness”.

[rniwa]

Note that there is currently no restriction as to which web site / app can be saved to home screen in iOS

And likewise not on Android or any other platform that I am aware of. Manual install via the browser menu is always possible, just the prompted install (that on Android is connected with what we call a WebAPK) is gated by the site’s “PWA-ness”.

I feel like we're going in circles now. We don't want to prompt anyone to install / save-to-home-screen any website or web app. That's the primary issue that I pointed out in OP. Since we're not going to do such a prompting, this feature is either irrelevant or would prevent users from saving a web site / app to home screen.

[jyasskin]

We do seem to be talking past each other a bit. @tomayac, you pointed out that the "please install me" prompt doesn't have to be intrusive, and so maybe with this UI improvement in browsers, developers no longer need the beforeinstallprompt event. @marcoscaceres, I think you're saying that's Mozilla's position.

I'd thought @rniwa was also making that argument, but the latest comment explicitly distinguishes between websites for which "We don't want to prompt anyone to install / save-to-home-screen" (because an installed web app may be able to do things the browser-based app can't) vs native iOS apps, for which Smart App Banners do prompt users to install the app, which can do things the browser-based app can't. These banners are described as a "method of promoting apps on the App Store from a website", not as just a "link[] to the relevant content in App Store", which could be expressed with the itms-apps: scheme.

[marcoscaceres]

... and so maybe with this UI improvement in browsers, developers no longer need the beforeinstallprompt event. @marcoscaceres, I think you're saying that's Mozilla's position.

Correct. That’s our position.

[madmoizo]

We don't want to give away that control to web apps / sites.

Specs cannot give recommandation about the UI, so each browser can have it's how way to implement an install/a2hs UI and the burden of education will be on the developer. And even if browsers share a similar experience, it won't be natural for the user to install an app (especially during the education period), so as a developer you'll have to promote it with UA sniff and this kind of intrusives things https://github.com/mozilla/standards-positions/issues/84#issuecomment-384507840

With beforeinstallprompt, developer can provide a better & consistent UX to install/a2hs (and it's just a shortcut which triggers the browser install process, not the install process itself). It's maybe not perfect, it could be reworked but remove it won't help (me - as a dev - and my users).

[rniwa]

I feel like I’ve done my due diligence in expressing our concerns here.

As a working group participant, I stand with my earlier comment that the best course of action for the working group is to proceed with the removal of this event and anything that depends on it given there will be no multiple independent implementations of this feature anytime soon.

[rniwa]

[E]ven if browsers share a similar experience, it won't be natural for the user to install an app (especially during the education period), so as a developer you'll have to promote it with UA sniff and this kind of intrusives things

This seems like a completely orthogonal issue. On one hand if the browser’s UI is completely non-intrusive, then the user may not notice and web sites / apps may continue to have such a UI. On the other hand, if browser’s UI is intrusive, then that’s not something we want to let a website / app to trigger it.

[madmoizo]

This seems like a completely orthogonal issue

Because UI is not spec-ed, it's a moving thing, a browser can change its UI as much as it wants, it can chose to make it visible (an icon in the address bar) or very hidden (a non-obvious label at the end of the three dot menu), but as a developer, I shouldn't be concerned about the browser UI, I don't want to educate my users to access a web plateform feature on a specific browser. It should be the browser's charge. beforeinstallprompt event offers a consistent way to manually trigger a web plateform feature despite browser UI & its potential changes over time and that's all I need.

I feel like I’ve done my due diligence in expressing my concern here.

[rniwa]

Because UI is not spec-ed, it's a moving thing, a browser can change its UI as much as it wants, it can chose to make it visible (an icon in the address bar) or very hidden (a non-obvious label at the end of the three dot menu), but as a developer, I shouldn't be concerned about the browser UI, I don't want to educate my users to access a web plateform feature on a specific browser. It should be the browser's charge.

Right, and I'm saying that leave it to the browser to provide such an UI.

beforeinstallprompt event offers a consistent way to manually trigger a web [platform] feature despite browser UI & its potential changes over time and that's all I need.

Since this is a browser UI issue as you've just stated, I see no reason why there needs to be a Web API which triggers it. FWIW, there might be nothing to be triggered because some browsers would rely fully on users to trigger it like Safari on iOS currently does.

[marcoscaceres]

FWIW, there might be nothing to be triggered because some browsers would rely fully on users to trigger it like Safari on iOS currently does.

Agree - or the UI that signals that a site is installable is surfaced in a non-intrusive manner (e.g., ambient badging). I think that leads to the conclusion that the API is not needed, or that the API trying to deal with a limitation in the browser’s UI.

I think this thread has run its course. I’ll prepare a PR.

[mgiuca]

I'd like to chime in (since I was absent during this discussion).

This thread is conflating two separate issues: firstly, the subject line ("prompting user makes it hard to discern whether user truly wanted to install"), and secondly, whether this should be in the spec given the lack of interest from Mozilla and Apple. Let's keep this thread relevant to its subject line (the first issue), and continue discussing standards policy (the second issue) on #836.

Marcos, you've been clear from a process perspective that you want to remove this due to lack of interest. But I don't think you've commented on the first issue. In fact, I can't find any clear Mozilla position on this at all, recent or historical. You diligently wrote the spec for this years ago but as far as I can tell, this was never implemented in Firefox possibly just because nobody got around to it. mozilla/standards-positions#84 never really reached a conclusion, ending with "We will work this out in the spec itself. Don't require a position." So I'd like a clear answer from you (possibly consulting others at Mozilla): is Mozilla actually opposed to this API on the grounds that @rniwa is elaborating here, or another reason, or have you just never implemented it for lack of time?

I must say I do not understand @rniwa 's argument here. We have permission prompts for all sorts of scary things like cam/mic and geolocation which can be requested by the site at any time, and if the user is accepting them just to dismiss a prompt, they're going to have a bad time. beforeinstallprompt is at worst the same as any other permission prompt, and because of the way it was carefully designed, can be much more respectful of the user by only allowing itself to be called after a certain amount of engagement, or any other signal the UA wants to apply as a precondition. It doesn't make sense to veto this API when there are other APIs that give developers much more direct control over the prompting, with much more serious consequences if the user clicks through.

The argument that "the browser already has passive UI for the user to click, so why do we need an API for this" is also analogous to other permission prompts. Why do we allow sites to prompt for camera permission? We could just have all websites instruct users to click on their browser's "site settings" panel and manually activate camera permission. But that would create unnecessary friction and require sites to tailor their tutorial to each user agent. So we have an API to ask for camera permission. Exact same argument applies to app installation.

Also, it is entirely up to the developer what "prompting" means. If you don't want to show a modal dialogue, you could consider responding to a call to the prompt() method by simply flashing or wiggling the install button in your browser UI. You can do anything you want with your browser UI.

Having said that, I will continue discussing the removal on #836 based on the assumption that neither Mozilla nor Apple is going to implement.

[rniwa]

We have permission prompts for all sorts of scary things like cam/mic and geolocation which can be requested by the site at any time, and if the user is accepting them just to dismiss a prompt, they're going to have a bad time.

And that’s bad. Permission prompts should be avoided whenever possible. But those permissions are directly associated with the action user is attempting to take (e.g. join a video conference), and the permission granted won’t persist once the browser exits. The problem with saving to home screen / installing is that it’s not obvious to the user as to why one may want to do that and the consequence is persistent. If browsers were to give more leniencies to websites saved on home screen / installed (e.g. not showing URL), this becomes a persistent attack surface for social engineering / phishing.

[mgiuca]

But those permissions are directly associated with the action user is attempting to take (e.g. join a video conference)

That depends on the site. A "good" site will have a "join video conference" button which asks for cam permission and thus it's obvious to the user from context why it's asking for permission. Just as a "good" site will have an "install me" button which calls BIPE.prompt()* and thus it's obvious to the user from context why the UA is prompting to install.

Of course, there can be a "bad" site that asks for cam permission with no apparent context, at which point a savvy user might say no, or a naive user who just wants to click through everything might say yes. Similarly, a "bad" site could ask for install with no apparent context, at which point the same user might say no or yes. Basically the same argument being applied here applies to all of the other APIs that ask for permission.

*only if pre-allowed by the user agent; again, BIP leaves much more control in the hands of the user agent than permission prompt APIs

and the permission granted won’t persist once the browser exits

Ah I see. I didn't realise Safari revoked all permissions at shutdown. That is an important difference. But since installation shouldn't be granting any permissions, it shouldn't matter (see Controlling Access to Powerful Web Platform Features).