Executing installed System Applications in browser

[opoto]

Once a system application has been installed, the specification does not specify if this application can be executed in a usual browser, or if it needs a dedicated UA. This question has been raised on the mailing list (http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0019.html), and answers suggest that this is missing from/should be added to the spec.

The situation can occur for both hosted and packaged applications: what happens when a user, while navigating in her usual browser, clicks on a link that belongs to an installed sys app? Or is redirected to such link?
A new section could be introduced in the spec, eg “7. Execution Context” (after “Data isolation”), or alternatively it can be added to the existing “7. Navigation”.

It should be possible to continue the navigation in the same UA (the regular browser) in order to:

• Avoid multiplication of UA instances on the user device, which is both resource consuming and confusing for the user (multiple windows).
• Facilitate back and forth navigation (in particular through redirects) between web sites.
• Allow a sys app to run inside an iframe of a common web application.
  Even if not executed by a dedicated UA, the sys app would still get the benefit of the trust gained by the installation (and hence have the permissions granted at installation).

If this is the behavior we agree on, the following text can be used (amended and complemented as needed):
“When the user, while navigating with her regular UA browser, opens a page or iframe which URL belongs to an installed system application, the UA sets the execution context of this page or iframe so that the data isolation and trust model of this installed system application applies. In particular, the permissions associated to the installed application will be granted to this page or iframe.
As soon as the navigation closes or leaves a page or iframe of an installed application, the UA terminates the associated execution context, and sets a new context suiting the new navigation URL, if any.”

We could also add a recommendation or non normative text suggesting that UA visually notify that context has been switched to an installed sys app. This could be rendered similarly to the https/ssl indicator currently used in browsers.

[jmajnert]

A lot here depends on whether the Browser and the Runtime are the same application. In fact in Tizen these are two separate beasts, which makes it impossible to do what you wrote in the third bullet.
Please also remember that a user can install a third party browser that:

• may have no knowledge of which sysapps are installed
• may not support SysApps specs (APIs, execution model etc)

In this particular scenario (a browser is navigated to a webpage that is part of an installed sysapp) I would expect that the browser, if it has knowledge of the installed sysapps, renders the webpage normally and informs the user that they have this webpage installed as a sysapp. Additional trust gained from being installed should not be granted in the browser, IMHO.

[opoto]

The limitations you list here seem to be "state of the art" restrictions, related to existing products. Of course, the products you are referring to do not comply to the specification we are defining, because this specification does not exist yet! There will necessarily be an adaptation phase for existing products to comply to the spec once it is finalized.

More specifically:

1. The browser/runtime distinction in Tizen comes from an implementation decision of this platform (which I am not critizing BTW!), it could evolve with the standard.
2. If users can install 3rd party browsers, couldn't they install 3rd party "runtimes" too?
3. It would be up to the underlying OS to offer a "shared" repository of installed sys apps, that any browser/runtime could query to know if an app is installed, and feed when they install a new one. If this is not present, then each browser/runtime would have its own repository, meaning that an app installed in one browser will have to be reinstalled when using another browser. In practice, it means that when a user installs an app in a browser, he will always use that same browser to run the app. I think this is acceptable (and is actually what we have in the PC world)
4. About 3rd party browsers not supporting SysApps, well... you just won't be able to use SysApps there :)

Maybe I am missing some information. Is there any technical motivation for this runtime/browser separation? What would be the impact of merging the two?

[jmajnert]

1. If users can install 3rd party browsers, couldn't they install 3rd party "runtimes" too?

I think Tizen will not allow this.

1. It would be up to the underlying OS to offer a "shared" repository of installed sys apps, that any browser/runtime could query to know if an app is installed, and feed when they install a new one.

Such a mechanism is not defined anywhere and is not a part of the runtime specification, so we should not depend on having it.

If this is not present, then each browser/runtime would have its own repository, meaning that an app installed in one browser will have to be reinstalled when using another browser. In practice, it means that when a user installs an app in a browser, he will always use that same browser to run the app. I think this is acceptable (and is actually what we have in the PC world)

IMHO the aim is not to have apps "installed in browser", but rather installed in the OS in the same way that native apps are. That's why the runtime doesn't have any chrome, history etc. Having multiple instances of the same sysapp installed (for different runtimes) is not a desired UX.

1. About 3rd party browsers not supporting SysApps, well... you just won't be able to use SysApps there :)

True

Maybe I am missing some information. Is there any technical motivation for this runtime/browser separation? What would be the impact of merging the two?

Different use cases and user experience make these two separate products.