Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rniwa opened this issue Dec 9, 2019 · 68 comments · May be fixed by #836 or #843

Comments

@rniwa
Copy link

@rniwa rniwa commented Dec 9, 2019

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

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 9, 2019

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

@rniwa

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Collaborator

@dominickng dominickng commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Collaborator

@dominickng dominickng commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Collaborator

@dominickng dominickng commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link

@elylucas elylucas commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Collaborator

@dominickng dominickng commented Dec 10, 2019

@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

This comment has been minimized.

Copy link

@aeallord aeallord commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 10, 2019

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

This comment has been minimized.

Copy link
Contributor

@tomayac tomayac commented Dec 10, 2019

@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

This comment has been minimized.

Copy link
Member

@othermaciej othermaciej commented Dec 10, 2019

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

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 10, 2019

@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

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 11, 2019

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

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 11, 2019

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.

Screen Shot 2019-12-11 at 8 35 32 AM

@ecjs

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 11, 2019

@marcoscaceres you were right about everything here:

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

mozilla/standards-positions#84 (comment)

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 11, 2019

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

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 11, 2019

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

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@tomayac tomayac commented Dec 11, 2019

[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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 11, 2019

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

This comment has been minimized.

Copy link

@electrify12 electrify12 commented Dec 11, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 11, 2019

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

This comment has been minimized.

Copy link

@alancutter alancutter commented Dec 11, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 11, 2019

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

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 12, 2019

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

This comment has been minimized.

Copy link
Member

@jyasskin jyasskin commented Dec 12, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 12, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 12, 2019

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

@frlinw

This comment has been minimized.

Copy link

@frlinw frlinw commented Dec 12, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 13, 2019

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

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 13, 2019

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.

@marcoscaceres marcoscaceres linked a pull request that will close this issue Dec 13, 2019
3 of 10 tasks complete
@mgiuca

This comment has been minimized.

Copy link
Collaborator

@mgiuca mgiuca commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Collaborator

@mgiuca mgiuca commented Dec 16, 2019

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

@rniwa

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 16, 2019

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.

"Good" sites are kind of irrelevant here.

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.

An important thing here is that it's more apparent to the user that the website may need camera access if one is joining a video conference. It's unclear why a website needs to be saved to home screen. Again, permission prompts are bad and should be avoided whenever possible.

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

Again, we (Apple's WebKit team) don't necessarily agree with this particular Blink / Chromium policy / strategy / approach.

On a somewhat orthogonal point, I find it rather concerning that multiple Google representatives keep referring to some kind of Blink / Chromium policy or implementation details as supporting details when making a point in this issue. Since the whole point of having multiple independent implementations is that they're independent, I respectively ask everyone involved in this and future discussions from refraining from using any kind of Blink or Chromium specific policy or strategy as a way to mitigate whatever Web API concerns we raise.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 16, 2019

is Mozilla actually opposed to this API on the grounds that @rniwa is elaborating here,

Yes, for exactly the reasons @rniwa outlined. I've discussed this with Firefox team/product owners on multiple occasion over many years and they've always opposed it and come to the same conclusion. Mozilla folks identified this problem in 2015 (my comment is a reflection of internal discussions).

However, I was personally optimistic Firefox would do something similar to Chrome from a install-UI perspective - but that never materialized.

or another reason, or have you just never implemented it for lack of time?

I indeed did implement BIP in Firefox, but we never shipped it - as again, Firefox UX folks don't believe it's a necessary API for the reasons above: The way Chrome does the install prompt is UA specific - hence there won't be any install prompt for Firefox. If that changes in the future, then BIP should become part of the standard again.

@kenchris

This comment has been minimized.

Copy link
Collaborator

@kenchris kenchris commented Dec 16, 2019

@NotWoods

This comment has been minimized.

Copy link
Member

@NotWoods NotWoods commented Dec 16, 2019

I agree with what Marcos said. Firefox Preview will have a similar install flow to current Firefox for Android so nothing is changing there.

@vincentmorneau

This comment has been minimized.

Copy link

@vincentmorneau vincentmorneau commented Dec 16, 2019

As a web developer who is currently building PWAs, I find this discussion appalling.

My users are struggling in Firefox, but Safari even worst. I understand the concerns about BIP but you are offering no alternatives. At the end of the day, this results in a bad experience for users. Plain and simple.

And where does that leave us web developers? It looks to me that Firefox and Safari would prefer we build native apps instead.

@ecjs

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 16, 2019

I agree with @vincentmorneau here. It's just baffling. I mean I get it from the higher-ups at Apple...PWAs taking off hurts App Store profits...but its strange to have developers in here giving these half-baked reasons that really don't add up at all. It's even more strange to have Mozilla supporting this kind of rhetoric. It's anti-web. We are creating more walls/barriers than necessary. Having some badging that indicates install-ability is great and welcomed, but PWA adoption, which is something the web needs...for reasons like Electron....will be severely throttled by these positions being taken by Apple/Mozilla.

You either want web apps to be installable or you don't. If you want it, then commit to it. If you want them installable, you want it to be as frictionless as possible. Otherwise, it's easier to get a user to just download a .dmg or .exe file. Do we really want that?

And whats funny, Apple says it doesn't really want web apps in the App Store. You have developers afraid to use frameworks like React Native because of some of these new policies. Personally, I think there are other things going on here that are unrelated to some of the points being brought up by @rniwa...and those things are related to App Store profits. PWAs taking off would potentially hurt those profits. I am just surprised to see Mozilla taking the same position.

Electron is not what we want. But it will be what we deserve if we don't do this the right way. I say we because we are all one large developer community trying to make the web a better existence. Installable PWAs are not just bookmarks.

@jyasskin

This comment has been minimized.

Copy link
Member

@jyasskin jyasskin commented Dec 16, 2019

@vincentmorneau @ecjs FWIW, I read Mozilla's position as saying they intend to show the app-install prompt, just in a way that's unobtrusive enough to not need a way for developers to turn it off with the beforeinstallprompt event. Their prompt looks pretty reasonable from that perspective:

Firefox Add to Home Screen prompt, after clicking the house icon

This is very different from Safari's stance of never encouraging web users to add websites to their home screens.

@NekR

This comment has been minimized.

Copy link

@NekR NekR commented Dec 16, 2019

@jyasskin that prompt is uncontrollable and intrusive, just as random popups on websites. It shows immediately when you open a website, even if you're not logging in. The only way to prevent Firefox to show that on-load, is to not serve Web Manifest until user is logged in, which is weird.

That said, beforeinstallprompt would allow to not show that popup on page load, but rather show it when user logged in or at another "happy moment".

@NekR

This comment has been minimized.

Copy link

@NekR NekR commented Dec 16, 2019

I like this part from @mgiuca's comment:

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.

The UI doesn't have to be "prompting". It may just "highlight" the ambient badge button. Or show a tooltip which says "You can install this web app by tapping this button". Tapping on tooltip itself would do nothing.

Possibilities are not limited here, but the problem is -- the thing itself is not wanted. I'm starting to think there is more to this issue than simply "we don't want to be intrusive to users".

@ecjs

This comment has been minimized.

Copy link

@ecjs ecjs commented Dec 16, 2019

@NekR that is my understanding as well. Seems odd that they would be against having some sort of API for installing web apps..that requires some sort of user-initiated action, like a <button> click. I'm curious why Mozilla thinks its "not needed", when in fact, developer support seems to be quite high.

as @marcoscaceres stated:

I think that leads to the conclusion that the API is not needed

@jyasskin

This comment has been minimized.

Copy link
Member

@jyasskin jyasskin commented Dec 16, 2019

@NekR The Firefox prompt starts as just the house icon in:

Firefox Add to Homescreen ambient badge before click

which I think isn't intrusive, although it does show even when you're not logged in. (Perhaps a use case for setLoggedIn...) I'm not saying you're wrong to want this, just that Firefox's and Safari's positions are pretty different.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 17, 2019

I understand folks are frustrated, but I remind everyone of our code of conduct. Please keep discussion civil and refrain from speculating on why companies have chosen to implement their UX in certain ways. If the discussion becomes accusatory I will have no option but to lock this issue.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 17, 2019

Just noting that Firefox Preview is - as the name suggests - "a preview" of what we are working on... and we will be experimenting a lot with how we do install prompts (if we do them at all!) over the next year or two as we gain experience in the area. However, don't take what is there today as any indication of what will be there tomorrow or completely gone the day after....

@rniwa

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 17, 2019

You either want web apps to be installable or you don't.

This seems like a classic case of false dilemma.

If you want it, then commit to it. If you want them installable, you want it to be as frictionless as possible. Otherwise, it's easier to get a user to just download a .dmg or .exe file. Do we really want that?

That doesn't logically follow. I find it much easier to visit a website in my browser than having to go to App Store or Play Store & download hundreds of megabytes of binary. The biggest strength of the Web, compared to native platform, is the reach in my view because of how easy it is to go to any website.

On the other hand, I would find it annoying if each one of those websites kept asking me to allow notifications or save it to home screen & will probably use web browser less if I had to constantly deal with that.

This is very different from Safari's stance of never encouraging web users to add websites to their home screens.

I don't think either Apple's WebKit team or Safari team ever said that; at least I'm not aware of any stance or policy to discourage users to save websites on home screen. Had that been the case, we probably would have gotten rid of the feature entirely.

On a related note, I find it reprehensive that some people feel comfortable making baseless accusations of companies or people. I get that you might be frustrated with the way current UI works in Safari on iOS but that's not a reason to make up & spread conspiracy theories about others. Let's not do that.

@Splaktar

This comment has been minimized.

Copy link

@Splaktar Splaktar commented Dec 17, 2019

"Good" sites are kind of irrelevant here.

As a developer, I find this worrying. As far as I understand it, "good sites" are the ones who are pushing for this feature to be implemented. While I understand that the title of this issue is focused on "bad sites", abuse, and confusion; calling "good site" developers and their product team requirements "irrelevant" seems a bit heartless and rude.

I'm happy to hear that Mozilla plans to try out some ambient badging strategies for surfacing a non-intrusive install action.

I continue to be unhappy with WebKit's "perspective" and vision of PWAs, especially the current implementation of the Add to Home Screen browser UI. I would like to see more proposals (solutions) and activity in the PWA space from WebKit.

I'm grateful for the Chromium team to be pushing forward and adjusting proposals and implementations in the PWA area. I'm happy that they are willing to share their references, policies, and insight while being open to feedback and input.

It will be unfortunate if beforeinstallprompt is removed from the spec, but all I am really concerned with is giving developers the tools to implement high quality UX PWA installation flows. If this comes in the form of another proposal, I'm fine with that. I don't want more unsolicited pop up prompts in the web content area (I don't see anyone advocating for that), but I do feel that giving developers the ability to have some control over the timing of the installation process is critical.

@rniwa

This comment has been minimized.

Copy link
Author

@rniwa rniwa commented Dec 17, 2019

"Good" sites are kind of irrelevant here.

As a developer, I find this worrying. As far as I understand it, "good sites" are the ones who are pushing for this feature to be implemented. While I understand that the title of this issue is focused on "bad sites", abuse, and confusion; calling "good site" developers and their product team requirements "irrelevant" seems a bit heartless and rude.

Let's recall the context here. We were discussing potential ways this prompt / UI can be abused.

Suppose someone proposed raw memory access API for the Web, which allows random physical address space access in user's machine. If someone were to reply to an issue raised by another saying that "a good website can display a carefully worded warning to users so that they won't accidentally enable it", I'd dismiss that as irrelevant because when we're talking about the threat models and abuses, we're not concerned with well behaving parties.

I continue to be unhappy with WebKit's "perspective" and vision of PWAs

Could you point me to what perspective and vision we shared about PWAs? Also, that topic is best discussed in the WebKit community (e.g. webkit-dev) instead of W3C, which is a venue for standardizing Web APIs.

If this comes in the form of another proposal, I'm fine with that. I don't want more unsolicited pop up prompts in the web content area (I don't see anyone advocating for that), but I do feel that giving developers the ability to have some control over the timing of the installation process is critical.

Unfortunately, this is a part of the concern we have about this API. It's increasingly common for websites to lock out Safari on iOS and force users to download native apps instead. Adding the ability to control when a web site / app can be saved on home screen can proliferate that further. If it's just a hint to UA that could be ignored, then I don't think it's useful anyway.

@vincentmorneau

This comment has been minimized.

Copy link

@vincentmorneau vincentmorneau commented Dec 17, 2019

I believe all "good site" developers care about is the BeforeInstallPromptEvent.prompt()
method. If the beforeinstallprompt event goes away from the specs, so be it. I agree it feels awkward to have to preventDefault() to offer a "good site" UX. But please w3c, keep a spec to manually prompt the install.

Could you point me to what perspective and vision we shared about PWAs?

@rniwa In Safari, "Add to home screen" is hidden at the secondary level of the share tray. I think that says it all about Webkit's vision on PWAs. But I'd love to be proven otherwise and I'm sorry if this is not the right channel to discuss it.

@marcoscaceres

This comment has been minimized.

Copy link
Member

@marcoscaceres marcoscaceres commented Dec 17, 2019

But I'd love to be proven otherwise and I'm sorry if this is not the right channel to discuss it.

This is not the right place to have this discussion.

I'm locking this issue as I feel we have enough information to make a decision.

@w3c w3c locked as resolved and limited conversation to collaborators Dec 17, 2019
mgiuca added a commit to mgiuca/manifest that referenced this issue Jan 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.