A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Adding an execution context while starting Web-Apps


Currently web-apps started for the first time have no idea why they have been started by the browser. The “why” starts to matter when web-apps should not be executed in all cases:

  • URL entered by the user
  • URL reloaded by the browser
  • URL intent from hybrid app XY
  • URL intent from native app XY
  • URL intent from operating system feature Beacons
  • URL intent from operating system feature NFC

Maybe authors could use the webapp manifest for defining valid entry points for their app.


In the URL intent scenarios, is the web app loaded in the browser, or in a webview inside a native app or the OS?


In case of an valid URL-record type written on an NFC tag the OS loads the web app directly in the browser (without any third party app). I haven’t tested beacons yet and I am not sure if they are able to procude an URL intent without having to install a third party app.

I know that the security of the web app itself is not getting improved by limiting an app to a certain kind of URL intent. But I think that it is a way to improve UX and to prevent misuse of the web app (i.e. when the web app is limited to NFC intents, the user is not able to load the app by entering its URL into the browser manually. Instead he is forced to scan a tag and “wait” for the OS to load the app) This approach might lead to potentially better secured web apps.


A web app that is running inside the webview of an hybrid app is able to know that it is actually running inside a webview because the native app is able to inject javascript variables and functions into the web app. So that is the only context information available for web apps I currently know about.