One-app-per-origin

[Jonas Sicking]

Hi All,

Sorry, this is going to be a short message before heading out on
vacation. But I wanted to get a discussion started now rather than
waiting another couple of weeks.

Currently the OWA format is defined as one-app-per-origin for security
reasons. I.e. since we generally consider everything in one origin as
the same security context, we wanted to stick to that even with OWA.

However the more I think about it, there doesn't actually seem to be a
reason that we need to do this. Our current thinking is that security
sensitive APIs are granted to a specific App, not to an origin. For
example if you install a camera app from cameragram.com, and the user
grants that app permission to use the camera without any prompting
(how that happens is orthogonal to this thread), then we are only
going to grant cameragram.com that permission inside that app.

I.e. if after having done the above, the user browses to
cameragram.com using firefox, that doesn't mean that cameragram.com
will have that access. Similarly, if the user opens a different app,
which contains <iframe src="http://cameragram.com">, we won't
automatically let the document in that iframe have access to the
camera without prompting.

So there doesn't seem to be any reason the user couldn't install two
apps from cameragram.com which are granted different levels of
security.

I think relaxing the one-app-per-origin restriction would make it
easier to develop applications which integrate with websites since it
would allow for more same-origin communication which is always a lot
easier.

/ Jonas

[Jonas Sicking]

On Thu, Apr 12, 2012 at 12:55 AM, Scott Wilson
<scott.brad...@gmail.com> wrote:

> The case where this doesn't work quite so well is where an origin is a container for third-party apps - in that case same-origin communication isn't such a great idea. Hence both W3C and OpenSocial provide a virtual origin: for W3C Widgets there is the widget:// scheme, and for OpenSocial, Apache Shindig can be configured to generate virtual origins, e.g. http://13ae72ddf.myserver.com instead of http://myserver.com?ifr=some_widget

This seems like a separate problem from what I'm talking about in my
email. I.e. this seems unrelated to if we allow one or multiple apps
per origin.

Please start a separate thread about this.

/ Jonas

[Raymond Forbes]

> / Jonas
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
I am not sure I understand how the API understands the difference
between the two apps if they both point to the same domain.

Let's say that I have Camera Free and Camera Premium and they both point
to cameragram.com, what differentiates it?

-r

[Jonas Sicking]

What gets installed is always determined by the app-manifest. The
manifest is always located through a URL, not through a simple domain
name. That is already the case and I'm not proposing that is changed.

I'm just proposing that we allow installing several app manifests that
come from the same origin. Since they are different manifests they can
have different icons and point to different start HTML pages.

I'm not sure which API you are referring to when you say "how the API
understands the difference", so maybe I'm answering the wrong
question?

/ Jonas

[Benjamin Smedberg]

On 4/12/2012 5:18 AM, Jonas Sicking wrote:
> What gets installed is always determined by the app-manifest. The
> manifest is always located through a URL, not through a simple domain
> name. That is already the case and I'm not proposing that is changed.
>
> I'm just proposing that we allow installing several app manifests that
> come from the same origin. Since they are different manifests they can
> have different icons and point to different start HTML pages.
>
> I'm not sure which API you are referring to when you say "how the API
> understands the difference", so maybe I'm answering the wrong
> question?

The issue in the past has been that it's not clear what .getSelf is
supposed to return in this case. Because .getSelf is supposed to work in
the browser as a way to get receipts and detemine if "the app for this
domain" is installed, it (at least in theory) should not be specific to
an installed app instance.

FWIW, I agree that we shold allow multiple apps per domain. I think the
.getSelf API isn't ideal for a whole bunch of reasons (see prior
discussions about websites forcing installation on users). I think we
should separate out the two use cases of .getSelf:

RECEIPTS:

Receipts should be scoped to a domain, not an app. Websites should be
able to use the browser receipt mechanism entirely independently of the
app API. I haven't really gotten a lot of feedback about this thought,
but I'd be happy to try and turn it into a real API proposal.

SELF-AWARENESS:

If we decide that apps should be allowed to know whether they are
installed, for the purposes of showing or not-showing "install me"
buttons: provide an .isInstalled(url) API.

--BDS

[Mike Hanson]

On Apr 12, 2012, at 10:55 AM, Benjamin Smedberg wrote:

> SELF-AWARENESS:
>
> If we decide that apps should be allowed to know whether they are installed, for the purposes of showing or not-showing "install me" buttons: provide an .isInstalled(url) API.

The original impetus of one-app-per-origin was because the security team advised me that we have no robust security perimeter other than domain - and that, if we were going to grant access to an API, we should do it at the level where we could be sure of the security properties of the caller.

Many good reasons for why developers would want multiple-apps-per-origin have been proposed - but I haven't seen a robust analysis of what the security implications would be.

If we are launching a gecko-instance-per-app, it feels easy. We know the provenance of the app, we configure our Gecko appropriately, and we're left with the (relatively small) problem of deciding which origins are allowed to invoke the API. Maybe just the one that served the manifest, maybe extra ones listed in the manifest.

If we are running a single gecko, with multiple apps in it, we have to handle a bunch of tricky cases. We could have content from https://app.com/lowpriv which embeds an iframe, or a worker, from https://app.com/highpriv, and posts messages to it. Or which does something automatically and communicates back to lowpriv somehow. Does the user know whether they are running as lowpriv or highpriv (and how do confirmation prompts look)? Or, lowpriv could have an XSS fault, which allows an attacker to generate content that reaches the highpriv domain.

Maybe we lock down access to high-privilege APIs to be in top-level frames only, and we make sure the user always knows which app they are "in" - but we don't have an SSL root-of-truth, just a bunch of string matching on the path. So anything that conceals or obscures the path could become an attack vector - directory traversals, homonym attacks, all that good stuff.

Now, you could try to move the problem around, by saying high-privilege APIs can't be on shared domains - but in a self-publishing world, how do we enforce that? The user agent would have to check it, and it would be a bizarre error message for an end user to see ("you can't install AppA because AppB already has access to your microphone?")

So, again, one-app-per-origin is a security restriction - which can be released if we have a robust solution for how to secure access to high-risk APIs. (and which is definitely part of the WebAPI security discussion that's happening right now in other threads!)

m

[Ben Francis]

On Thu, Apr 12, 2012 at 11:18 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> What gets installed is always determined by the app-manifest. The
> manifest is always located through a URL, not through a simple domain
> name. That is already the case and I'm not proposing that is changed.
>
> I'm just proposing that we allow installing several app manifests that
> come from the same origin. Since they are different manifests they can
> have different icons and point to different start HTML pages.
>

Permissions aren't just required for one HTML page though so there needs to
be another way to define the scope of the app than origin.

Chrome hosted apps use a list of URLs (which can include wildcards)
https://developers.google.com/chrome/apps/docs/developers_guide#manifest

For apps installed from the Chrome Web Store, these URLs can also span
multiple origins. As well as multiple apps per origin, multiple origins per
app has also been suggested as a common requirement.


--
Ben Francis
http://tola.me.uk

[Ben Francis]

On Thu, Apr 12, 2012 at 9:36 PM, Mike Hanson <mha...@mozilla.com> wrote:

> Maybe we lock down access to high-privilege APIs to be in top-level frames
> only,
>

I think that would be problematic for B2G given that all apps run inside
iframes and apps run inside other apps (i.e. all other apps run inside the
homescreen app).

[Benjamin Smedberg]

On 4/13/2012 5:50 AM, Ben Francis wrote:
> On Thu, Apr 12, 2012 at 11:18 AM, Jonas Sicking<jo...@sicking.cc> wrote:
>
>> What gets installed is always determined by the app-manifest. The
>> manifest is always located through a URL, not through a simple domain
>> name. That is already the case and I'm not proposing that is changed.
>>
>> I'm just proposing that we allow installing several app manifests that
>> come from the same origin. Since they are different manifests they can
>> have different icons and point to different start HTML pages.
>>
> Permissions aren't just required for one HTML page though so there needs to
> be another way to define the scope of the app than origin.

Why? Having multiple apps per domain doesn't change the scope of the
permissions, which would still be the origin (standard web security model).

--BDS

[Jim Straus]

Is this going to remain once we go to multi-process? I'm thinking not, but I haven't seen the design for making B2G multi-process yet.

[Ben Francis]

On Fri, Apr 13, 2012 at 5:34 PM, Jim Straus <jst...@mozilla.com> wrote:

> Is this going to remain once we go to multi-process? I'm thinking not,
> but I haven't seen the design for making B2G multi-process yet.
>

Yes, it will remain. But the iframes we use will be special in some way,
they will either have a special attribute or even a new HTML tag name which
we will look to standardise. Currently this is <iframe mozbrowser> and in
future there may be something like <iframe mozapp> too, but <iframe
mozbrowser> looks like it will be renamed to <browser>.

[Ian Bicking]

On Thu, Apr 12, 2012 at 2:36 PM, Mike Hanson <mha...@mozilla.com> wrote:

> On Apr 12, 2012, at 10:55 AM, Benjamin Smedberg wrote:
>
> > SELF-AWARENESS:
> >
> > If we decide that apps should be allowed to know whether they are
> installed, for the purposes of showing or not-showing "install me" buttons:
> provide an .isInstalled(url) API.
>
> The original impetus of one-app-per-origin was because the security team
> advised me that we have no robust security perimeter other than domain -
> and that, if we were going to grant access to an API, we should do it at
> the level where we could be sure of the security properties of the caller.
>

We have few perimeters or defined spaces at all except for domain, and I
think that has more implications than just security. We have yet to define
any way to handle organic navigation, for instance – but it wouldn't be too
hard to figure out if we can unambiguously map any URL to an app. Organic
navigation is a great feature of the web that I don't think we should give
up on, and to look at the competition Android specifically supports that.
I can get an email from, say, Google+, open it, and the Google+ app opens
up. Android is not unambiguous about mapping URLs to apps, so I actually
get a query about how I want to open the link – this wouldn't really be
sensible in our world, as we aren't choosing a app to render a page, but
something like it would be reasonable. If we create siloed apps (with
respect to linking) I think we'll see a lot of chaos with well-hyperlinked
apps – a functional copy of an app in a tab, the app running standalone on
the side, outgoing links from that app in their own window or otherwise
disconnected from the original app.

The expectation I'm seeing in this thread is that appiness is connected to
the invocation of app.launch() – that is, if you call app.launch() you get
a website, but that site is in its own visual container, with extra
permissions, etc. And if each app instance is really a pointer to a
manifest, not an origin, then this view that an app is defined by how it
was launched rather than its URL means that you can easily get multiple
apps on an origin. But... that just seems really disappointing to me,
making app.launch() different than navigating to a link means breaking
hyperlinks and deep linking across the web. Once you do that, it's not
that big a deal if the app is all served from chrome: URLs or http: URLs,
and from there going to Chrome-style packaged apps isn't a big change or
loss.

[Ben Francis]

On Tue, Apr 17, 2012 at 5:21 PM, Robert Kaiser <ka...@kairo.at> wrote:

> Benjamin Smedberg schrieb:

>
> Why? Having multiple apps per domain doesn't change the scope of the
>> permissions, which would still be the origin (standard web security
>> model).
>>
>

> Whoa, so let's says Google Maps would get full access to my contacts and
> my camera just because I gave one of those permissions to Google+ and one
> to Google Talk and all of them share a google.com/ origin? I wouldn't
> expect that, to be honest.
>

Exactly.

Ben

[Benjamin Smedberg]

On 4/17/2012 12:21 PM, Robert Kaiser wrote:
> Benjamin Smedberg schrieb:

>> Why? Having multiple apps per domain doesn't change the scope of the
>> permissions, which would still be the origin (standard web security
>> model).
>

> Whoa, so let's says Google Maps would get full access to my contacts
> and my camera just because I gave one of those permissions to Google+
> and one to Google Talk and all of them share a google.com/ origin? I
> wouldn't expect that, to be honest.

I understand that this feels unnatural. But this content is all at
google domains... if you grant a permission to one of the apps, there is
nothing preventing them from using that permission (within that app) in
other contexts. For example, they could cross-host google maps content
on plusapp.google.com or vice-versa, so there is no *actual* difference
in terms of what that domain could do...

--BDS

[Mounir Lamouri]

On 04/17/2012 08:06 PM, Benjamin Smedberg wrote:
> On 4/17/2012 12:21 PM, Robert Kaiser wrote:
>> Benjamin Smedberg schrieb:

>>> Why? Having multiple apps per domain doesn't change the scope of the
>>> permissions, which would still be the origin (standard web security
>>> model).
>>

>> Whoa, so let's says Google Maps would get full access to my contacts
>> and my camera just because I gave one of those permissions to Google+
>> and one to Google Talk and all of them share a google.com/ origin? I
>> wouldn't expect that, to be honest.
> I understand that this feels unnatural. But this content is all at
> google domains... if you grant a permission to one of the apps, there is
> nothing preventing them from using that permission (within that app) in
> other contexts. For example, they could cross-host google maps content
> on plusapp.google.com or vice-versa, so there is no *actual* difference
> in terms of what that domain could do...

FTR, the origin includes the sub-domains so plusapp.google.com and
mail.google.com are not the same origin.

Anyway, I don't think we should give permissions to an origin but to an
app. Indeed, Google could have all it's apps to the same origin and
indeed, there is no reason in practice to deny a permission to one
Google app but allow it to another. However, some apps might be in a
more generic origin (like people.mozilla.org/ or
people.some-university-company-or-lab.tld/) and in that case, you really
want to give a permission to the app and the origin doesn't mean anything.

--
Mounir

[Jonas Sicking]

On Fri, Apr 13, 2012 at 2:53 AM, Ben Francis <b...@krellian.com> wrote:
> On Thu, Apr 12, 2012 at 9:36 PM, Mike Hanson <mha...@mozilla.com> wrote:
>
>> Maybe we lock down access to high-privilege APIs to be in top-level frames
>> only,
>>
>
> I think that would be problematic for B2G given that all apps run inside
> iframes and apps run inside other apps (i.e. all other apps run inside the
> homescreen app).

It won't be a problem on B2G since they are special <iframe>s. I.e.
they are <iframe mozbrowser>s. For basically all intents and purposes
gecko should treat a <iframe mozbrowser> as the top of the iframe
hierarchy. We might not be doing that yet, but that needs to be fixed.

/ Jonas

[Jonas Sicking]

On Thu, Apr 12, 2012 at 12:36 PM, Mike Hanson <mha...@mozilla.com> wrote:
> On Apr 12, 2012, at 10:55 AM, Benjamin Smedberg wrote:
>
>> SELF-AWARENESS:
>>
>> If we decide that apps should be allowed to know whether they are installed, for the purposes of showing or not-showing "install me" buttons: provide an .isInstalled(url) API.
>
> The original impetus of one-app-per-origin was because the security team advised me that we have no robust security perimeter other than domain - and that, if we were going to grant access to an API, we should do it at the level where we could be sure of the security properties of the caller.

I think that was a good initial design.

However I think at this point we're pretty sure that we need to
restrict access to sensitive APIs such that we don't grant permissions
to an origin no matter where it runs. Instead we grant permissions to
an origin only when it runs in a tab where we're running that specific
app. I.e. if a user has installed a facebook app which has elevated
privilege to access your calendar, we only grant access to pages of
the "https://www.facebook.com" origin when it's running in the
"facebook app" tab, and only if it isn't contained by a cross origin
frame.

So in that scenario the "https://www.facebook.com" origin doesn't have
any elevated privileges if you just browse to that domain. And it
wouldn't have elevated privileges even if the facebook app contains an
iframe which points to www.othersite.com which in turn contains an
iframe to www.facebook.com.

We need to do this anyway as to prevent granting access to an origin,
and then have that origin clickjacked. For example, I would be very
worried that my dialer app could get clickjacked if we didn't have
this policy.

> Maybe we lock down access to high-privilege APIs to be in top-level frames only, and we make sure the user always knows which app they are "in"

Yes. That's essentially it.

> but we don't have an SSL root-of-truth, just a bunch of string matching on the path.  So anything that conceals or obscures the path could become an attack vector - directory traversals, homonym attacks, all that good stuff.

I'm not sure I follow this. Could you elaborate.

> Now, you could try to move the problem around, by saying high-privilege APIs can't be on shared domains - but in a self-publishing world, how do we enforce that?  The user agent would have to check it, and it would be a bizarre error message for an end user to see ("you can't install AppA because AppB already has access to your microphone?")

For *really* high privilege APIs we will probably only enable the
privilege to pages that are listed in the app's appcache manifest.
This is because we'll require signatures for all resources to ensure
that the webserver hasn't been hacked. So for those APIs this won't be
a problem.

For other APIs it might be ok that a given page has access to for
example the camera API when loaded through one facebook app, but
doesn't have access to camera when loaded through another facebook
app. I can't think of a scenario where that would actually be a
problem.

> So, again, one-app-per-origin is a security restriction - which can be released if we have a robust solution for how to secure access to high-risk APIs.  (and which is definitely part of the WebAPI security discussion that's happening right now in other threads!)

I think we do have such solutions.

/ Jonas

[Jonas Sicking]

On Tue, Apr 17, 2012 at 9:21 AM, Robert Kaiser <ka...@kairo.at> wrote:
> Benjamin Smedberg schrieb:
>

>> Why? Having multiple apps per domain doesn't change the scope of the
>> permissions, which would still be the origin (standard web security
>> model).
>

> Whoa, so let's says Google Maps would get full access to my contacts and my
> camera just because I gave one of those permissions to Google+ and one to
> Google Talk and all of them share a google.com/ origin? I wouldn't expect
> that, to be honest.

No. The google maps app wouldn't need to get access to your camera
just because you granted google+ that access.

However, practically speaking, when you grant access to an app for
something, you are generally actually granting the developers of that
app that access. I.e. if you install angry birds and grant it access
to your camera, you are actually granting Rovio (the angry birds
developers) access to your camera.

And so in the example above, while the google maps app wouldn't have
camera access, the google+ app could likely use any of the scripts or
other resources from google maps. And so if you don't trust google
with camera access, you likely shouldn't grant it to google+.

/ Jonas