What defines the scope of an app?

[Ben Francis]

*For a given URL, how should we determine whether it belongs to an app or
should be opened in a browser window?*

This is a question that has come up recently in the Systems Front End team
as we work on the new system browser and Rocketbar in Firefox OS.

Chrome hosted apps define the scope of a hosted web app with a list of URLs
with wildcards, in doing so they appear to allow multiple apps per origin
and multiple origins per app [1].

Amazon web apps define the scope of an app by the location at which the app
manifest is hosted on the server (e.g. a domain, subdomain or a
subdirectory), this allows multiple apps per origin but only one origin per
app [2].

Am I right in thinking that in Firefox OS we currently only allow one app
per origin and one origin per app? If so, is origin a good enough indicator
as to which app a URL belongs to?

The Rocketbar allows you to search your browsing history. We would like
this to include browsing history from inside apps as well as browser
windows. But if you click on a history result, should you open it in an app
window or a browser window? What if the same URL has previously been
visited in both an app and a browser window? The current UX spec says to
always open it in a browser window, but Jason pointed out that this could
cause permission problems if the URL was originally loaded inside an app
window as it may not get all the same permissions in a browser window
without the mozapp attribute set.

One proposal was to identify which app a URL belongs to by its origin, but
this assumes one app per origin and Fabrice pointed out that we may want to
support multiple apps per origin in future. Do we have any concrete plans
for how that would work? Is using origin a good enough indicator until such
a point as we define something more granular in the future, if ever?

*Should we open all off-origin hyperlinks from an app in a new browser
window instead of the current app window?*

Currently in Firefox OS as I understand it you can load any URL in any app
window. If you follow a hyperlink inside an app which doesn't specify
target=_blank it will open in the current app window, not the browser app.
This could mean for example that if you follow a link to a news article on
a news web site from a social app it might open in the app window of the
social app rather than in the browser app.

Apparently this is a common source of review rejections in the Firefox
Marketplace because it provides a bad user experience, particularly if the
user can't go back. It would also currently mean that the news article
would be not be recorded in your browser history so you couldn't get back
to it later.

Should we just open all hyperlinks to another origin outside of the app
window?

Ben


1. https://developers.google.com/chrome/apps/docs/developers_guide
2.
https://developer.amazon.com/post/Tx1VQ8CDCS8T3O2/Creating-and-Updating-your-Web-App-Manifest.html

[Benjamin Smedberg]

On 2/12/2014 9:08 AM, Ben Francis wrote:
> *For a given URL, how should we determine whether it belongs to an app or
> should be opened in a browser window?*

The root of this problem is that on the "browser web" you just open a
new window using target="_blank" or window.open("_blank"). For apps this
could either mean "open another window of my app" or "open another
window in the default browser".

Are there other cases which are unclear? Do you mean for this to apply
to normal navigation using links which wouldn't open a new window in a
normal browser?

For the web inside of apps, I strongly feel we should do two things:

* it should be possible for the app either kind (a new app window or a
browser window) of window for any URL. So something like <a
rel="external" target="_blank"> would open a browser window while <a
rel="internal" target="_blank" would open a new app window. For
window.open we might be able to use the window features to achieve the
same thing

window.open(url, "_blank", "external")
window.open(url, "_blank", "internal");

This proposal obviously needs to be standardized.

The rest of the question comes down to what to do by default when there
is a target="_blank" with no internal/external marker. And perhaps what
to do when there is a normal hyperlink which links to an "external"
domain. I don't have much opinion there other than whatever seems to
work best with existing content.

--BDS

[Ben Francis]

On Wed, Feb 12, 2014 at 3:55 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> The root of this problem is that on the "browser web" you just open a new
> window using target="_blank" or window.open("_blank"). For apps this could
> either mean "open another window of my app" or "open another window in the
> default browser".
>

I think the current behaviour in Firefox OS is that target=_blank should
open a browser window, window.open should open up to one additional
overlayed app window (useful for authentication use cases for example).
When we implement the full "sheets" model after 1.4 we will probably allow
apps to have multiple windows.

> Are there other cases which are unclear? Do you mean for this to apply to
> normal navigation using links which wouldn't open a new window in a normal
> browser?
>

Yes, I'm saying clicking on a normal hyperlink (without target=_blank
specified) inside an app with an href outside the origin of the app should
open outside of the app frame. If the scope of the app is defined by the
origin then it isn't part of the app. Additionally, I'm suggesting
navigating to a URL that corresponds to the origin of an installed app from
inside a browser window should open the URL in the app.

There's another use case of clicking history results in the Rocketbar (like
awesomebar results). URLs from installed app origins should open in apps,
all other URLs should open in system browser windows.

> For the web inside of apps, I strongly feel we should do two things:
>
> * it should be possible for the app either kind (a new app window or a
> browser window) of window for any URL. So something like <a rel="external"
> target="_blank"> would open a browser window while <a rel="internal"
> target="_blank" would open a new app window. For window.open we might be
> able to use the window features to achieve the same thing
>
> window.open(url, "_blank", "external")
> window.open(url, "_blank", "internal");
>

There have been discussions about something similar for "sheets" after 1.4
but I don't think this is necessary yet, if ever.

> The rest of the question comes down to what to do by default when there is
> a target="_blank" with no internal/external marker.

I suggest always open a browser window, as we do today.

> And perhaps what to do when there is a normal hyperlink which links to an
> "external" domain. I don't have much opinion there other than whatever
> seems to work best with existing content.
>

I suggest opening a browser window, unless the URL corresponds to the
origin of another app, in which case it should open in the app.

Ben

[Benjamin Smedberg]

On 2/12/2014 1:20 PM, Ben Francis wrote:
> On Wed, Feb 12, 2014 at 3:55 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
>
>> The root of this problem is that on the "browser web" you just open a new
>> window using target="_blank" or window.open("_blank"). For apps this could
>> either mean "open another window of my app" or "open another window in the
>> default browser".
>>
> I think the current behaviour in Firefox OS is that target=_blank should
> open a browser window, window.open should open up to one additional
> overlayed app window (useful for authentication use cases for example).
> When we implement the full "sheets" model after 1.4 we will probably allow
> apps to have multiple windows.

If nothing else, it should be part of some webapp spec exactly how this
ought to behave. Which spec is that?

I don't think it makes much sense for window.open and <a target> to have
such different default behavior. From basically every other perspective
they are the same call; one is declarative and one is scripted.

> Additionally, I'm suggesting
> navigating to a URL that corresponds to the origin of an installed app from
> inside a browser window should open the URL in the app.

I would strongly object to this in Firefox desktop at least. Installing
an app should not by itself alter the behavior of normal browsing
activities.

But I also wonder what "open the URL in the app" means. Does that happen
via intents, or by just forcing a new window into an existing app with
that URL?

>> For the web inside of apps, I strongly feel we should do two things:
>>
>> * it should be possible for the app either kind (a new app window or a
>> browser window) of window for any URL. So something like <a rel="external"
>> target="_blank"> would open a browser window while <a rel="internal"
>> target="_blank" would open a new app window. For window.open we might be
>> able to use the window features to achieve the same thing
>>
>> window.open(url, "_blank", "external")
>> window.open(url, "_blank", "internal");
>>
> There have been discussions about something similar for "sheets" after 1.4
> but I don't think this is necessary yet, if ever.

Currently you seem to be saying that in Firefox OS, there is no way for
an app to call window.open which will open a browser window (instead of
an overlayed window). This seems like a fundamental flaw. If you are
converting an existing website to behave as an app, it's likely that
code is going to open links in new browser tabs by calling
window.open(url, "_blank") and they need a way for this to continue working.

Have you considered how this will interoperate on Android? AIUI Android
apps can currently register themselves as handlers of certain URL
patterns. Since we're going to be focusing some significant effort in
getting webapps on Android, perhaps we should use that system as a
model. It does require apps to declare which URL patterns they want to
handle.

--BDS

[Ben Francis]

By way of follow up...

On Wed, Feb 12, 2014 at 2:08 PM, Ben Francis <bfra...@mozilla.com> wrote:

> *For a given URL, how should we determine whether it belongs to an app or
> should be opened in a browser window?*
>

It seems that we have gradually been removing assumptions in the system in
Firefox OS in preparation for allowing multiple apps per origin, so there
is currently no reliable way to determine what app a URL belongs to given
only the URL. Therefore the conclusion we reached was to treat a URL
visited from an app window as a different "place" in the places database to
the same URL visited in a browser window. Clicking a history result for a
URL visited in an app window will open in a new or existing app window with
the same manifest URL, clicking a history result for the same URL visited
in a browser window will open in a browser window.

> *Should we open all off-origin hyperlinks from an app in a new browser
> window instead of the current app window?*
>

A problem with the above is that it can result in duplicate history entries
of the same URL visited inside and outside an app window. In order to not
link unrelated web browsing to an app's history and to reduce the number of
duplicate places with the same URL but separate frecency scores, we are
going to experiment with opening all hyperlinks to off-origin URLs from
apps outside of the app window in Firefox OS, tracked by bug 972320.

As a side note, as I understand it it is currently not possible to create a
hyperlink from one privileged app to another privileged app and make use of
any permissions granted to that app. This is because permissions are only
granted if the correct manifest URL is set in the mozapp attribute of the
iframe and this attribute only gets set when launching a new app. Although
Web Activities go some way to addressing these types of use cases, this
does seem to break the fundamental linkability of the web and seems like
something we should fix.

Ben

[Ben Francis]

On Sun, Mar 9, 2014 at 10:33 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> A. Make it easy for developers to avoid the problem where clicking an
> ad in an app which doesn't have back/forward UI takes them to some
> other website, but with no way to get back.
>

OK, so by default the scope of an app could be defined by the origin of the
manifest, following an off-origin link from within the app should open
outside the app window.

The app developer can reduce the scope of the app further or carve up the
origin into multiple apps with the use of a manifest property as you
suggest. I would suggest a property called "scope" which is a list of
strings (paths with wildcards or something more complex like regex, but
relative to the origin of the manifest, like the launch_path).

{
"name": "Google Calendar",
...
"scope": ["/calendar*", "/some_other_parts_of_the_app/*"]
}

Navigating a top level browsing context to a URL outside of the scope of
the app will load the URL outside of the app.

Note that if the scope extended outside the origin of the manifest, we may
want app authors to prove they own a particular domain before allowing them
to handle URLs for that domain. This is what Chrome hosted app authors have
to do and the process of doing so is centralised, relatively painful and
requires manifests to be hosted by the app store. (Amazon has an
alternative self-hosting approach that works quite well which I mentioned
in my original email).


> B. When the user receives a link to a facebook post in their email,
> clicking that link should open the post in the facebook app, if the
> user has the facebook app installed. Same thing if finding a link to a
> facebook post on some other website.
>

Whenever we navigate to a new URL we check it against the list of installed
origins. If there's a match we check against the app scopes defined in the
corresponding app manifest(s). If there's a match we open the URL in that
app (not sure if it should open in an existing browsing context for that
app if one is open but that's probably more the sheets discussion). If
there is no match, the URL is loaded inside the current window if it's a
browser window, or in a new browser window if the current window isn't a
browser window or a different target was specified.



> C. Enable an AwesomeGame app to use google login and other 3rd party
> services without causing that to leave the AwesomeGame app.
>

Rather than add an additional manifest property for this purpose, one
option would be to get the app to use window.open() with the "dialog"
feature so that they get a temporary window which overlays the current one
rather than opens a new browser window, and has to be dismissed before
returning back to the app. This way the default behaviour is to open
off-origin URLs outside the app, but the app author can opt-in to
overlaying external web content over their app for certain exceptional use
cases. I think this is similar to the approach Alive was taking with his
sheets experiments.


> D. Don't recreate the issue that the android browser has where every
> so often during navigation it asks which browser you want to open the
> clicked link in.
>

We would have to enforce that multiple apps on the same origin can not have
overlapping scopes.


> E. Support multiple apps per origin.
>

Carve up the origin into multiple app scopes in app manifests, as you
suggest.


> F. If the user has used an app, they should be able to use the
> rocketbar to get back to content inside that app.
>

It's possible to map a given URL onto a particular app by its origin or app
scope as defined in app manifests.


> What I'd further like to accomplish, but that is much more complex is
>
> G. Preserve the current security feature that app data is protected
> using OS-level process boundaries. I.e. if a webpage that the user
> visits manages to hack gecko child process, it still can't access any
> cookies or other data from an installed facebook app or bank app.
>

Can we start be listing what *wouldn't* work here, to define the problem?

A tricky aspect here is that a lot of websites use a separate origin
> for their mobile sites. So for example facebook uses m.facebook.com
> for their mobile website. I'm not really sure how to reconcile that.
> Possibly this isn't as big of a deal since they might not link
> directly to the m-site from things like emails? Ideas here very
> welcome.
>

That is annoying, and bad practice IMHO. But a common practice is to use UA
sniffing and redirect a desktop URL to a mobile equivalent and vice versa
where necessary. This could actually work fine.


>
> With regards to F. I think we'll have to, for each browsed URL,
> remember not just which URL the user visited, but also as part of what
> app.


Actually the only case I can think of where this is necessary is the
"dialog" use case I described above, where web content from outside the
app's origin can be overlayed over the app. But I would argue that we could
just not store browser history in these cases. We could still store
manifest URLs alongside places in the browser history to use as hints, but
it's not strictly necessary when we can map any URL to an app, and might
actually cause problems in the case where an app is un-installed.

What I like about this solution is that the "browser" is like a catch-all
app for browsing the whole world wild web, and bookmarking/installing an
app to the homescreen is like slicing off a particular part of the web I
want to go to often and giving its own little bucket with a label and an
icon to recognise it by.

It also potentially allows us to lock down permissions further by not
requiring that granting permissions to google.com/calendar also grants
permissions to google.com search as it does currently.

What have I missed?

Ben

[Ben Francis]

See also: Related discussion around the W3C Manifest specification.
Interestingly this highlights the issue of how this "app scope" may
interact with the scope of ServiceWorkers.

https://github.com/w3c/manifest/issues/114

[Bill Walker]

On Mar 10, 2014, at 7:53 AM, Paul Theriault <pther...@mozilla.com> wrote:

> = Long Version =
>
> How about we do away with the separation between web and hosted web apps entirely (unless the apps explicitly requests to be sandboxed) AFAIK, there is little difference in the risk profiles of web pages vs hosted apps, so perhaps they should all be in the same sandbox. Also if we allow an app to not represent the entire origin, I have a proposal for supporting multiple apps for origin which I think solves some of the “which app am I in” questions. Allow me to ruminate in terms of your goals:

Paul,

At the risk of being slightly off topic -- I'll ruminate on two differences I see between web and hosted web apps:

1. User intent and expectation -- users don't know it's a hosted web app when they install it from Firefox Marketplace (nor should they, IMHO). They've expressed an intent that they want it to be available on their device, so we prefetch all its appcache assets, I think we give it a bigger allowance for indexedDB and similar API's. They expect that when they launch said app, it will operate without reliance on browser chrome. Whereas with ordinary web content they don't mind relying on the browser back button.

2. mozActivities -- even hosted web apps can register for mozActivities, which allows them to interact much more richly with other apps on the device than most web content could.

-Bill

[Ben Francis]

On Mon, Mar 10, 2014 at 2:53 PM, Paul Theriault <pther...@mozilla.com>wrote:

> How about we do away with the separation between web and hosted web apps
> entirely

This is the direction I would like to see us go in too, and the system
browser in Firefox OS will go a long way towards this from a UI point of
view.

>From an architectural point of view the main difference between an "app"
and other web content is that the app content has to be loaded inside an
iframe with a manifest set in its mozapp attribute in order to get some
permissions. When loading a URL we need to know which app it belongs to in
order to know which manifest URL to set in the app window, as you describe
below.

> (unless the apps explicitly requests to be sandboxed) AFAIK, there is
> little difference in the risk profiles of web pages vs hosted apps, so
> perhaps they should all be in the same sandbox.

If by sandbox you mean they all use the same data jar, I'm not sure if
that's necessary. But I hope we can define this problem a bit better.

A. Always show browser chrome, unless you are on the origin of an installed
> app (see B though about reducing app-scope). If you are in an app, and you
> navigate to a page which is not contained within the app's scope, show
> browser chrome (unless of course you are linking to a page which is contain
> within the scope of another app).
>

Whether or not we show browser chrome is orthogonal to whether the current
URL is part of an app. Apps can request browser chrome in their manifest.
Rather than "show browser chrome" I would say "open in a browser window",
by which I mean a frame without a mozapp attribute which doesn't belong to
any other app. The browser is like a catch all for URLs which don't have
another home.


>
> B. Allow web developers to carve up their origins into web content and app
> content (potentially multiple apps), but make sure that for any given URL,
> it is either web content, or belonging to a specific app - never both, or
> multiple apps. To do this, we allow to reduce the scope of its origin in
> the manifest by supplying a URL pattern (or maybe regex even) relative to
> the origin of the manifest:
> {
> "name": "GreatApp",
> ...
> "app-scope": "/app/*"
> }
>

Yep, sounds good.


>
> We automatically fail any install if an app specifies a scope that is
> already claimed by an existing app (or ask the user if they want to
> uninstall the existing app, and replace it with the new app?)
>

That is the simplest solution.

>
> This approach also assumes one developer controls all apps on a given web
> origin. Apps on shared hosting may conflict with each other. Do we need to
> support this as a use case? Can we somehow try synthesize an app-scope
> parameter here? e.g app installed at /foo/manifest.webapp and trying to
> install /bar/manifest.webapp - we add a /foo and /bar app-scope parameter
> to each app respectively and just fail if one subsumes the other on a
> subfolder basis? (e.g if /foo/manifest.webapp, fail for attempts to install
> /foo/bar/manifest.webapp) I'm not exactly sure of the correct logic here,
> but I feel like if we are careful we can come up with a deterministic
> algorithm.
>

Alternatively we could try to use some kind of longest prefix matching and
last-registration wins like the scope of ServiceWorkers [1] I'm not sure
how well that would work.

>
> C. Hmm, maybe my approach falls down here, but if we are navigating to
> enter my google login, don't I really want to be taken out of the app, and
> into the browser view at this point? I actually hate this about other app
> platforms where you end up browsing the web inside an app.


I suggest using the "dialog" feature of window.open() for the special case
when you don't want to taken out of the app, but we should take the user
out of the app by default.


> Note that for web apps, since web apps and web content is in the same
> sandbox, we are already logged into google, just as it is on the web.
>

Yeah that is a downside of separating apps into separate data jars... you
wouldn't get that.

Allowing web apps to elect to be sandboxed:
> We should provide a option in the manifest to let sensitive apps that
> don't want to be a part of the web sandbox, hive themselves off, e.g:
> {
> "name": "GreatApp",
> ...
> "sandbox": true
> }
>

I guess that could work. Not sure whether it's necessary to be opt-in.

I haven't dealt at all with how to link to packaged apps, but that seems
> orthogonal, maybe (or at least I don't have a good answer...)
>

We can link to packaged apps, but we can't really expose those URLs to
users because they aren't real URLs. We should either give packaged apps
real URLs on the Internet, or not have packaged apps :)

Ben

1.
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md#longest-prefix-matching