Web Install API
Breakout session - TPAC 2024 - September 25 2024
Participants
- Lu Huang (Microsoft Edge)
- Etienne Noël (Google)
- Natasha Gaitonde (Microsoft Edge)
- Dan Murphy (Google Chrome)
- Thomas Steiner (Google)
- Addison Phillips (Invited Expert - I18N / Retired)
- Alex Kyereboah (Microsoft Edge)
- Christian Liebel (Thinktecture)
- Kristin Lee (Microsoft Edge)
Chair
- Diego Gonzalez (Microsoft Edge)
- Amanda Baker (Microsoft Edge)
Scribes
Relevant Links
Slides: https://drive.google.com/file/d/1-pO4Ar5EpznGuNX-0AWp25ctIlsOCMcH/view?usp=sharing
Explainer: https://aka.ms/webinstall
Feedback for Web Install API: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues?q=is%3Aissue+is%3Aopen+label%3A%22Web+Install+API%22
Feedback for Acquisition Info API: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues?q=is%3Aissue+is%3Aopen+label%3A%22Acquisition+Info%22
Minutes
- Description of the API
- Brief summary of challenges & pitfalls of webapps
- update of API - how it integrates with acquisition info API
- How an application will integrate with OS. Edge or Chrome on window, Mac, linux. Safari on MacOS
- Application can get added to launcher, OS UI, firefox mobile does it this way. Add an application to the doc. The act of installing - app will get icon on homescreen of device.
- Different ways cross-browser to do install.
- User Agent can do prompting - like in Chromium
- Proposal here - imperative way for developer to prompt install.
- API to democratize & decentralize web application acquisition (and app install).
- aka.ms/WebInstall
- web sites installing their web apps.
- Creation of online application catalogs
- store.com, list applications, can be used on other platforms
- or installing from a search engine.
- Competition between stores.
- promise-based method
- resolves if application isinstalled, or when installed.
- parameters include a manifest id, install url, and optional object
- object - information to track campaign id, things like that
- 'manifest id' is "What to install". Install url is "where to find it"
- Url that is meant for instaling an application.
- Any url that is in scope of the manifest file, links to the manifest. Cannot redirect.
- Ideally only contains things necessary - manifest link, serviceworker, icons, etc.
- same-origin version of install
- website can provide some ui to be able to install.
- mysite.com, install button in site.
- click on that, and you can go through install flow. application on homescreen.doc
- navigator.install(id)
- navigator.install(id, install_url)
- last month
- satisfactory resolution with TAG
- cross-origin version of install
- Struggles and gotchas of web app installs
- Difficult to do automated testing
- Pitfalls of apps not having ids
- Irreversible bad install -: no way to fix a bad install
- Malformed manifest files
- Network errors
- Async manifests
- Swapping of different manifests
- Setting an ID means that gotchas are recoverable
- Diego: cross-origin install API
- Amanda: Scenario -someone has built an app store
- These apps are listed with a bunch of install buttons
- Install button installs an app outside of the scope / origin of the current site
- Shape of API is the same as same-origin - but the install_url is required (as you need to point to something outside of your current origin)
- Diego - Recent changes based on recent feedback from TAG
- Manifest would have list of sources in the manifest file
- "I want to be installed for a specific set of things"
- or "I want to be installed from anywhere"
- Concerns about centralization from TAG
- Please let us know in discussion about concerns
- Downside: less control for developers, but open to this change if this is an issue.
- Focusing on value of the feature and what the feature brings to the web. Any friction on install click introduced dropoff
- End goal of API is not to create application stores, end goal is give user control of discovery & acquisition
- Intention is to respect the same-origin policy for cross-origin install
- installation is gated behind user activation
- permissions API integration - switching gears. We are debating whether or not to gate cross-origin installation behind a permission. We do hae an associated an other part of the API - getInstalledApps - to be behind permission
- Diego - we have 'cross-origin install' - once permission has been granted, you get app install prompt
- having integration with permissions API will allow developers to query if granted or denied If denied, they can swap to a different UX to link to content they want to install.
- Or provide an alternative way to do the button
- this is an upside of permission api integration
- Additional bit of UIs that the user agent can build (not in spec necessarily) - post-install UX
- Diego - think about where you go to an application, and expect to install X, and instead you install a casino. So we think it would be valuable for user agents to check in after install, to remove application if user wants to
- Diego - navigator.acquisitionInfoProvider - knowing where the application installation came from.
- aka.ms/WebInstallAcquisition
- supplements the web install api to let the dev know how the app was installed - install source and attribution id.
- track a campaign id
- can be an optional parameter of the navigator.install
- similar to campaign id concept for apple store, msft store.
- optional data
- time installed
- region
- referrer
- kenneth: you wanted to clarify which part(s) same-origin installs don't require
- Does it require user initiation?
- I don't want this to be become yet-another-thing
- Diego - same origin does require user activation
- Marcos: That's not enough - for forced situation on Reddit - "install the app"
- Web that's full of naggy stuff.
- I'm worried that we risk putting more annoyance in front of users.
- It goes back in github 10 years, we are scared of the web becoming a place where you have to install things in order to use things
- We have to have a good story for that.
- Amanda: the user agent can implement its own restrictions. The user agent has the freedom.
- Dan: The reason this happens is because you make more money on ads with android native apps. Devs aren't making more money too
- Natasha: Diego is also looking for feedback
- What if the prompt said "yes, no, don't ask me again" Does that help for this concern.
- The website that's presenting the UI.....
- Marcos - in the world today - with smart banners on Safari - it's a link relationship
- Dan - isn't that the same situation - so the site can present UX, and the banner doesn't show up in safari because the user closed it - same situation if the browser stops showing the install prompt.
- So I'm store.com. I'm listing the apps.
- From the developers point of foo, you're still saying install foo.com.
- At some point you passed the install_url
- does the app store even communciate with the site it's going to install.
- Dan - it loads the install_url.
- Marcos - what if you need to be logged in. You're still having the app store site communciate with the site. So... you're already sending the refer. The install time. There's already collaboration between the store site and the site that's being installed
- So the acquisition stuff - doesn't need to be held by the browser, as the site that installed can point the app store
- Dan - are there standardized ways to provide acquisition info in the http request? as headers?
- Marcos - yes, but not standardized.
- Marcos - example - https://app.l9.com.au/
- so they want to gate install on login
- Marcos - so SW might depend on login state.
- Marcos - not seeing a need for the acquisition API - as the parties that are involved, already in collaborating over http.
- Site can ping back the store.
- Dig in a bit more here.
- Solution that this is trying to install is to allow a specific client instance to know how it was installed
- Idea with the headers is great from a server side, to understand from a server perspective, how many installations am I getting from source 1 vs source 2. But for the specific client instance, advertisers want to know - "this client got installed from source 1", so I might want to continue to give them addition promotions inside this instance that are tied to the fact it was installed from source 1 instead of source 2. Not clear to me how headers allow that type of experience.
- Marcos
- In theory, this data..... region gets weird. That seems like a privacy violation right there. The install version is weird as well - that's in the manifest?
- (No versions in manifest)
- Can you pass this all through https
- Web install is not the only way apps can be acquired. Another way - apps installed through the MSFT store. or play store.
- Marcos - right, this is making a bit more sense.
- But if you have a relationship with that site... you can acquire it that way.
- No relationship
- Privacy violation - if there is no relationship....
- user might not want the app to know where it was installed from
- The API seems too developer focused, and not focused on what users would feel
- Acquisition info - I love the optional values such as region or install time. Not required values and we can work on that
- Important to know the acquisition info .... take the existing attribution apis like apple ads, trying to be a standardized way to bring it all together
- practice for campaigns that exist - if a user installs an app, it would be tracked by the campaign. Lots of privacy things to think about
- Supplementing the api, not existing for the case of the web install api.
- Marcos - We're codifying this stuff in a way. IDK if this will pass muster. May raise some eyebrows.
- Diego - any opinions about using or removing the install sources?
- Marcos - why would my bank want this? Does this API make sense to be universal? Do we want every website on the web to be an app store?
- Diego - that's not the focus or scope of the API.
- If a website wants to have an install button, we enable that.
- Cross-origin - Does every website need to have this capability?
- Dan - is democratization of app stores bad?
- Marcos - no that sounds great
- Marcos - does it.... does this have to be on the web platform?
- Diego - geolocation exists, not all websites use it.
- Marcos - yes - we should prompt
- Diego - This makes sense as to where the web platform is going and hugely towards what developers want and need to bring their app experience to the web platform.
- We're not thinking about the app store use-case - thinking about a developer providing their own acquisition and discovery of apps, without having to rely on app store.
- Marcos - same-origin api, as a user, you would go to that site and use it from there.
- SQL - web browser on mobile phone
- I generally have 2 browsers on the phone. If I install the same app from both, there are two icons there. How do we resolve this?
- Amanda - right now, there isn't a good way to differentiate between installs with one browser is installed
- we can add that using the getinstalledrealated apps api in the future, with participation with other user agents
- Web app store vs native app store.
- Apple app store -
- you cannot build a centralized app store besides the apple app store. So - when we do this, are we building a new web app store.
- Amanda - the idea is you could do that with this. Native apps and everything... anything that is not a web app
- Dan - you can link to native apps from your manifest, so you could install those from a third party app store enabled by this.
- Diego - ... [missed][
- Diego - final concerns or comments?
- Marcos - I'm understanding the perspective a bit more.
- On the webkit side, there has never been a web app store thing. Usually you navigate to the thing and install it
- Maybe it's not a good idea? The webkit side - the perspective has always been you navigate and install.
- Acquisition info provider
- Marcos - if you installed a thing, and gave it those super powers, permission to do those things.
- So install + permission - cross-origin install seems reasonable.
- Diego - in the explainer, the web install capability could be per-user-agent requirements.
- Favorite search engine .com. no one will install their search engine.
- But perfectly valid to have it available in some case and not another. but the functionality would be the same
- Marcos - yes - we would need something in the manifest to enable the entitlement to receive the app store permission.
- Diego - so you're thinking that for cross-origin web install, if we had something in the manifest to declare I want to install, that would ensure for webkit folks?
- Marcos - yes - then every website isn't a store.
- Thanks! please leave issues on github!