beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app #835
Comments
|
Wait, what? Am I the only one that’s having trouble following what is actually being said here? |
|
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. |
|
In Chrome, users are shown the same confirmation prompt regardless of whether 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. |
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.
This would be entirely under the control of the web content right? |
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 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. |
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. |
|
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. |
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.
Thanks for your kind words :) |
|
@elylucas that was actually how 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 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. :) |
|
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. |
Indeed, that's the core of what I'm trying to say here.
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. |
|
@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:
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 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?! |
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. |
|
@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...
I find it hard to believe that this is the actual reason Apple is deciding not to implement some sort of solution for this. |
|
Just chiming in on the Mozilla side that we share Apple's concerns about |
@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 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.
|
|
@marcoscaceres you were right about everything here:
|
“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”™️. |
|
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 |
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!). |
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. |
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.
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.
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. |
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. |
|
https://www.w3.org/TR/appmanifest/#install-prompts 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. |
Agree. We've had |
|
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 Thanks! |
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. |
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. I feel like I’ve done my due diligence in expressing my concern here. |
Right, and I'm saying that leave it to the browser to provide such an UI.
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. |
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. |
|
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. 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 Having said that, I will continue discussing the removal on #836 based on the assumption that neither Mozilla nor Apple is going to implement. |
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. |
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 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
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). |
"Good" sites are kind of irrelevant here.
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.
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. |
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.
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. |
|
I agree with what Marcos said. Firefox Preview will have a similar install flow to current Firefox for Android so nothing is changing there. |
|
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. |
|
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. |
|
@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
This is very different from Safari's stance of never encouraging web users to add websites to their home screens. |
|
@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, |
|
I like this part from @mgiuca's comment:
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". |
|
@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 as @marcoscaceres stated:
|
|
@NekR The Firefox prompt starts as just the house icon in:
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. |
|
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. |
|
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.... |
This seems like a classic case of false dilemma.
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.
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. |
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 |
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.
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.
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. |
|
I believe all "good site" developers care about is the BeforeInstallPromptEvent.prompt()
@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. |
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. |
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.
The text was updated successfully, but these errors were encountered: