Service like apps

[Antonio Manuel Amaya Calvo]

Hi there.

In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions.

The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services.

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

* They're loaded remotely (aka in another process).
* If the app/url referenced on the iframe is already loaded, don't load it again, just return a window object that points to the already loaded URL.
* They don't have opener (which wouldn't make sense anyway since they can be opened from several places at the same time)
* And the window object created by the iframe allows postMessage

With an example:

* On the client app HTML:

<iframe id="settingsService" mozservice src="app://settingsservice.gaiamobile.org" ></iframe>

(on the client app code)...
...
settingsService.postMessage(settingINeed, "app://settingsservice.gaiamobile.org");
...

* On the service app:
....

window.addEventListener("message", handleMessage, false);

....

// Called sometime after postMessage is called
function handleMessage(event)
{
  // We can check here the sender, the data, or any combination thereof
  // So for example, originA could only be allowed to read settingA while
  // originB could be allowed to read and write settingB, and read only settingC
  if (!allowedMessage(event)) {
    return;
  }
  // At this point we know the petition can be served, go ahead and serve it.
  getSetting(event.data).then(settingData => event.source.postMessage(settingData, event.origin));
}

As I said, it's easily told (and IMHO webby enough since we don't actually need any new API, just a new kind of frame which can be just ignored by everybody else) but harder to implement.

WDYT?


[1] http://hg.mozilla.org/mozilla-central/diff/2a8fd75b667f/dom/apps/src/PermissionsTable.jsm

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

[Vivien Nicolas]

On Thu, Feb 26, 2015 at 12:02 PM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

Hi there.

In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions.

That would be very cool imho.

 

The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services.

Part of the design of the new Gaia architecture is to be able to prototype such a thing. Some apps can be built as 'Services' and multiple apps may access those Services to do some stuff.

It is not yet implemented but this is on our 'things to explore' todo list.

 

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

What I have been told is that there is a proposal from Google called 'Tubes' to allow cross-origin communication. I may have misunderstood and the name may not be the right one, but sicking knows.

So maybe the cross-origin communication mechanism is still an option (but not IAC, nor DataStore).

In Gaia the prototype would look a bit like:

App:

var c = new Client('settings', /* version */ '1.0');

c.get('some.setting').then(function(value) {

  // do something

});

Remote Service:

var s = new Server('settings', /* version */ '1.0' {

  get: function(setting) {

    // do something

  }

});

Where Client and Server are client sides API based on Promises. The postMessage communication, is hidden into the lib in order to make it easier to use any new APIs that may comes one day. (fwiw this APIs is built primarily in order to have a clear communication API between views and workers).

Why I would prefer that over embedding a frame ?

 - The iframe trick seems to just be a workaround around the lack of APIs to do cross-origin communication.

  - With the frame you need to know the url of the Service, which is something that may change, and it would be cool if third-party developers can create their own Services to replace ours in the future.

  - The service does not need to have a window object to return. It simply returns data.One of the cool thing we could build around Services too is the ability for the client to subscribe to some events.

  For example:

  var c = new Client('contacts', '1.1');

  c.addEventListener('oncontactschanged', function(changes) {

    // do something

  });

 While if the iframe does not have an opener (as you describe), it could only react to postMessage. So the iframe needs a way to know who has opened it to push those kind of notifications.

Fwiw, this is just a different API design. I'm just exposing the way I would like to explore it with the new Gaia architecture.

The first focus should really be on: "is there a chance that those kind of services exists ?"

 

Thanks for launching this discussion.

Vivien.

[1] http://hg.mozilla.org/mozilla-central/diff/2a8fd75b667f/dom/apps/src/PermissionsTable.jsm

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Salvador de la Puente González]

Hi all

On 26/02/15 12:02, Antonio Manuel Amaya Calvo wrote:

Hi there.

In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions.

The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services.

It sounds like a great idea.

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

* They're loaded remotely (aka in another process).
* If the app/url referenced on the iframe is already loaded, don't load it again, just return a window object that points to the already loaded URL.
* They don't have opener (which wouldn't make sense anyway since they can be opened from several places at the same time)
* And the window object created by the iframe allows postMessage

All these characteristics suit very well with the concept shared workers, what we would need is some kind of system-wide shared worker.

With an example:

* On the client app HTML:

<iframe id="settingsService" mozservice src="app://settingsservice.gaiamobile.org" ></iframe>

Analogous:

var settingsService = new SharedWorker("app://settingsservice.gaiamobile.org", { service: true }); // second parameter is new
settingsService.port.start();
settingsService.port.postMessage(settingNeed);

(on the client app code)...
...
settingsService.postMessage(settingINeed, "app://settingsservice.gaiamobile.org");
...

* On the service app:
....

window.addEventListener("message", handleMessage, false);

....

// Called sometime after postMessage is called
function handleMessage(event)
{
  // We can check here the sender, the data, or any combination thereof
  // So for example, originA could only be allowed to read settingA while
  // originB could be allowed to read and write settingB, and read only settingC
  if (!allowedMessage(event)) {
    return;
  }
  // At this point we know the petition can be served, go ahead and serve it.
  getSetting(event.data).then(settingData => event.source.postMessage(settingData, event.origin));
}

As I said, it's easily told (and IMHO webby enough since we don't actually need any new API, just a new kind of frame which can be just ignored by everybody else) but harder to implement.

The implementation challenges here are mainly two (from my naive point of view):

1. Same origin policy concerning Shared Workers should be disabled for the service kind or we should enable CORS here.
2. These workers should run on their own origin. The `new` keyword is not creating actually a new worker but getting the existent instance.
   

WDYT?

I lke the iframe proposal mainly for two reasons: it is more natural from the point of view of "getting the same instance" and it's like embedding a component (which reminds me about the <object> tag).

[ANTONIO MANUEL AMAYA CALVO]

On 26 Feb 2015, at 14:31, Vivien Nicolas <vnic...@mozilla.com> wrote:

On Thu, Feb 26, 2015 at 12:02 PM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

Hi there.

In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions.

That would be very cool imho.

 

The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services.

Part of the design of the new Gaia architecture is to be able to prototype such a thing. Some apps can be built as 'Services' and multiple apps may access those Services to do some stuff.

It is not yet implemented but this is on our 'things to explore' todo list.

 

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

What I have been told is that there is a proposal from Google called 'Tubes' to allow cross-origin communication. I may have misunderstood and the name may not be the right one, but sicking knows.

So maybe the cross-origin communication mechanism is still an option (but not IAC, nor DataStore).

In Gaia the prototype would look a bit like:

App:

var c = new Client('settings', /* version */ '1.0');

c.get('some.setting').then(function(value) {

  // do something

});

Remote Service:

var s = new Server('settings', /* version */ '1.0' {

  get: function(setting) {

    // do something

  }

});

Where Client and Server are client sides API based on Promises. The postMessage communication, is hidden into the lib in order to make it easier to use any new APIs that may comes one day. (fwiw this APIs is built primarily in order to have a clear communication API between views and workers).

Why I would prefer that over embedding a frame ?

 - The iframe trick seems to just be a workaround around the lack of APIs to do cross-origin communication.

The thing is that postMessage *is* an API designed specifically to do cross origin communication. Or that's how I understood it anyway :). In fact if I wanted to do cross origin communication on the web right now j would have to do it using postMessage. The trick here is that mostly for performance and security reasons we want those iframes to be reusable (have only one actual instance). 

  - With the frame you need to know the url of the Service, which is something that may change, and it would be cool if third-party developers can create their own Services to replace ours in the future.

That's right, but again, URLs are the standard way to identify objects/elements/resources on the web. So the difference is if the client app wants to use any settings service versus this specific service identified by this URL. 

  - The service does not need to have a window object to return. It simply returns data.One of the cool thing we could build around Services too is the ability for the client to subscribe to some events.

  For example:

  var c = new Client('contacts', '1.1');

  c.addEventListener('oncontactschanged', function(changes) {

    // do something

  });

 While if the iframe does not have an opener (as you describe), it could only react to postMessage. So the iframe needs a way to know who has opened it to push those kind of notifications.

Hmm that is a fair point. As I had seen this would work on a request/response way only, not on a publisher/subscriber way. 

In any case, what I had tried to do with this proposal was to *not* introduce any new API (which then would have to be designed and standardized and what not) but to see if we could do with what we currently have. Note that if we remove the restriction to encapsulate other apps this could even work with what we have right now.

Best, 

Antonio

* They're loaded remotely (aka in another process).
* If the app/url referenced on the iframe is already loaded, don't load it again, just return a window object that points to the already loaded URL.
* They don't have opener (which wouldn't make sense anyway since they can be opened from several places at the same time)
* And the window object created by the iframe allows postMessage

With an example:

* On the client app HTML:

<iframe id="settingsService" mozservice src="app://settingsservice.gaiamobile.org" ></iframe>

(on the client app code)...
...
settingsService.postMessage(settingINeed, "app://settingsservice.gaiamobile.org");
...

* On the service app:
....

window.addEventListener("message", handleMessage, false);

....

// Called sometime after postMessage is called
function handleMessage(event)
{
  // We can check here the sender, the data, or any combination thereof
  // So for example, originA could only be allowed to read settingA while
  // originB could be allowed to read and write settingB, and read only settingC
  if (!allowedMessage(event)) {
    return;
  }
  // At this point we know the petition can be served, go ahead and serve it.
  getSetting(event.data).then(settingData => event.source.postMessage(settingData, event.origin));
}

As I said, it's easily told (and IMHO webby enough since we don't actually need any new API, just a new kind of frame which can be just ignored by everybody else) but harder to implement.

WDYT?

Fwiw, this is just a different API design. I'm just exposing the way I would like to explore it with the new Gaia architecture.

The first focus should really be on: "is there a chance that those kind of services exists ?"

 

Thanks for launching this discussion.

Vivien.

[1] http://hg.mozilla.org/mozilla-central/diff/2a8fd75b667f/dom/apps/src/PermissionsTable.jsm

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Fernando Jiménez Moreno]

Thanks for starting this thread Antonio.

On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia. On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service?

/ Fernando

[Fernando Jiménez Moreno]

On Feb 26, 2015, at 2:30 PM, Vivien Nicolas <vnic...@mozilla.com> wrote:

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

What I have been told is that there is a proposal from Google called 'Tubes' to allow cross-origin communication. I may have misunderstood and the name may not be the right one, but sicking knows.

I believe this is the proposal you are talking about https://github.com/mkruisselbrink/navigator-connect

[Fabrice Desré]

Yep, that's the key point for me. Exposing more apis is not hard,
vetting who can use them is. If I were playing the devil's advocate, I
would say that the current proposal is not different from just removing
permission checks.

(yes, I know there are other use cases beyond api access that justify
cross-origin messaging).

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Antonio Manuel Amaya Calvo]

On 26/02/2015 16:11, Fernando Jiménez Moreno wrote:

Thanks for starting this thread Antonio.

On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia.

Yes and not. I'm not proposing to move the permission check from Gecko to Gaia, Gecko will still have the same permission check it has now. What I'm proposing is implementing a (set) of proxy/ies of APIs. Some app(s) that will act as proxy/ies for other apps that cannot request the permission directly (because the API is certified or privileged for security reasons or because we don't want to open the API to the web). That way some apps that currently are certified (in Gaia) can be moved to privileged or even web.

On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service?

Ok, again there are two different issues here. On one hand, initially the services would be services for the OS apps (that is, the Gaia apps). Those services will allow moving apps from certified to privileged or even web, if the APIs that they use can be mediated by a "service app". As such, the service can decide to serve or not the request by a combination of the origin (origin URL) and the actual data passed. A hypothetical settings service could use a table like:

{
  "https://music.gaiamobile.org" : {
       read: ["volume.max", "volume.current", "silentmode"],
       write: ["volume.max"]
...
}

(I didn't check the actual settings that the music app uses).

Each service can, and should, have it's own set of rules it applies before serving a request. So we could have a XMLHttpRequest proxy that could serve petitions using SystemXHR from some apps to a concrete set of domains (or *), a disk access proxy that could allow access from some apps to some specific directories and so on. The nice part of this is that since it's all on the Gaia side we will not be introducing any design dependencies between Gecko and Gaia (Gecko doesn't need to know anything about Gaia!).

This is the initial step. I didn't talk anything about third party apps so far :)

If we want to open this to third party apps, then it'll have to be on a controlled way. We can still do it by origin (https only, obviously) and we can download the actual ruleset from a Mozilla/Operator/OEM server. That would allow dynamic configuration of what apps can access what services, allowing Mozilla, an operator or an OEM to add another app without having to change the core/certified apps. For example, if we decide to add a "3D photo camera" at a later point, that requires access to a mediated API, we can just update the ruleset for that service on the Mozilla server (or the operator server, or the OEM server, or even the personal server of the user if the phone has a homebrew build!) to add the rules for https://3dphonecamera.somedeveloper.com and presto, we have a new app that has access to protected resources on a controlled way.

Best,

Antonio

/ Fernando

[Antonio Manuel Amaya Calvo]

On 26/02/2015 16:23, Fabrice Desré wrote:

> On 02/26/2015 07:11 AM, Fernando Jiménez Moreno wrote:
>> Thanks for starting this thread Antonio.
>>
>> On the scenario that you propose, at least for the use case that you
>> provided (settings), it seems that we are moving the permission check

>> from Gecko to Gaia. On Gecko we currently have signed apps and a list of

>> permissions associated to them. On the content side we don't have any of
>> this information available. Could you elaborate a bit more about how
>> would the Service decide if a 3rd party app can access or not the
>> wrapped resource. In other words, how would third party apps request
>> permission to access the content controlled by the Service?

> Yep, that's the key point for me. Exposing more apis is not hard,
> vetting who can use them is. If I were playing the devil's advocate, I
> would say that the current proposal is not different from just removing
> permission checks.

I already answered this (I hope ;) ). What we're really doing this is
giving potentially much more granularity to the permissions, without
actually changing the APIs or permissions. Using a mediating app, we
can, for example:

* Give controlled access to some settings
* Allow the web to connect/disconnect selectively from bluetooth devices
(the webapp from Jabra can connect only to Bluetooth devices that
identify themselves as Jabra, for example).
* Even allow the web to use the dialing and SMS APIs on a controlled
form. For example, we could allow a messaging app to send SMS and
receive SMS to/from a concrete subset of numbers (and the SMS would
progress as if it was send with an app with the sms permission).

As I said, the actual rules that the API services/proxies use can either
be static (they're configured when the device ships and cannot be
changed without an OTA) on the most conservative case, be user defined
(on the most liberal case) or be controlled by a trusted party (be it
Mozilla, the OEM, the operator, any or all of them).

For the Gaia apps, a static ruleset should be enough. To allow adding
third party apps (don't even need to be apps, they can just be third
party websites!) .

BTW, exposing new APIs is not hard... agreeing to make them available to
everyone on the web is a loooong process though ;). This way we don't
really add anything new to the web, we just use what's currently
available on a device efficient way, and can be pegged as implementation
details. All the mumbojumbo about not having opener, reusing the
processes and such are just so all the apps using the service on a
resource-light device share the same instance, and they're really not
needed on a device without memory restrictions. A mozservice iframe on a
desktop, on other words, can be a plain iframe and what I'm proposing is
just the standard use case for postMessage.

>
> (yes, I know there are other use cases beyond api access that justify
> cross-origin messaging).
>
> Fabrice

[Anne van Kesteren]

On Thu, Feb 26, 2015 at 8:31 PM, Antonio Manuel Amaya Calvo
<antoniomanue...@telefonica.com> wrote:
> BTW, exposing new APIs is not hard... agreeing to make them available to
> everyone on the web is a loooong process though ;). This way we don't
> really add anything new to the web, we just use what's currently
> available on a device efficient way, and can be pegged as implementation
> details.

If only it were that easy :-)

We can't add some magic unexplained <iframe> variant to the web, claim
victory, and hope nobody notices.

See also the emails here that discuss a very similar idea:

https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg352
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg379

I think we'll have to embrace that there are no shortcuts and start
figuring out what needs to become a service and what needs to become
something the browser needs to expose as an API.


--
https://annevankesteren.nl/

[Antonio Manuel Amaya Calvo]

On 27/02/2015 9:14, Anne van Kesteren wrote:

On Thu, Feb 26, 2015 at 8:31 PM, Antonio Manuel Amaya Calvo
<antoniomanue...@telefonica.com> wrote:

BTW, exposing new APIs is not hard... agreeing to make them available to
everyone on the web is a loooong process though ;). This way we don't
really add anything new to the web, we just use what's currently
available on a device efficient way, and can be pegged as implementation
details.

If only it were that easy :-)

We can't add some magic unexplained <iframe> variant to the web, claim
victory, and hope nobody notices.

Well, we only need to add a magic explained (I did explain it after all, I think :P) <iframe> variant to the web because FirefoxOS already has some other magic more or less explained <iframes> (mozapp, and mozbrowser). The only reason a new iframe is needed is because on FirefoxOS (and I believe that's specific for FirefoxOS) we have process separation for apps, and:

• The parent process enforces a strict permission list on the childs so when it forks a new child it knows what permission it has, and if a child requests a permission it doesn't have at fork time, it's killed. Because of this we do need the iframe hosting the service app to be remote, because otherwise it cannot have more permissions than the hosting iframe.
• Since our devices tend to be very limited on memory, and we're forking new processes per app, it's desirable that the new remote iframe reuses any process already alive for that app/service, to save on memory.

That two things don't change the semantic at all, and as I said they're implementation details, for FirefoxOS only. If FirefoxOS process model were different (and/or if our devices had metric tons of memory ;)) then we wouldn't even need to hint the browser that "this iframe is special, please see if you can treat it with care".

For the rest, the proposal is not different from having an external https://webreakcorsforyou.com server that allows itself to be embedded on an iframe and responds to postMessages with an URL with the content of that URL (which the server, not the client, downloads). And that's something we can *already* do on the web, without needing new browser APIs.

Best,

Antonio

See also the emails here that discuss a very similar idea:

  https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg352
  https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/thread.html#msg379

I think we'll have to embrace that there are no shortcuts and start
figuring out what needs to become a service and what needs to become
something the browser needs to expose as an API.

[Salvador de la Puente González]

The <iframe> approach is quite semantic and it makes explicit the dependency between your app and the service. Moreover, the URL is actually the name for anything in the WWW, I think it's better than a simple name (more verbose, that's right), and as Antonio already stated .postMessage() is the way of making cross-domain messaging.

If you need a new API, does not anyone want to buy the special Shared Worker I proposed some posts ago? If not a Shared Worker, I think we could reuse the effort put on them as they seem very similar in characteristics. Although, after a thoughtful reflection I think the embedded iframe is more webby.

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Anne van Kesteren]

On Fri, Feb 27, 2015 at 12:04 PM, Antonio Manuel Amaya Calvo
<antoniomanue...@telefonica.com> wrote:
> Well, we only need to add a magic explained (I did explain it after all, I
> think :P) <iframe> variant to the web because FirefoxOS already has some
> other magic more or less explained <iframes> (mozapp, and mozbrowser). The
> only reason a new iframe is needed is because on FirefoxOS (and I believe

> that's specific for FirefoxOS) we have process separation for apps, ...

I mean I understand why you want to introduce something like this and
why it looks "webby", but that does not mean it is. The test for that
is whether it would work in Safari without special code paths, were
Safari to implement the same standardized features as us.

Everything else is proprietary and we can pack proprietary bits in
whatever way we want, but claiming they're the web is disingenuous and
counter to our mission.

We do need proprietary features to figure things out and we do need to
ship within reasonable timeframes, but we should also remain true to
ourselves.


--
https://annevankesteren.nl/

[ANTONIO MANUEL AMAYA CALVO]

> On 27 Feb 2015, at 16:22, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> On Fri, Feb 27, 2015 at 12:04 PM, Antonio Manuel Amaya Calvo
> <antoniomanue...@telefonica.com> wrote:
>> Well, we only need to add a magic explained (I did explain it after all, I
>> think :P) <iframe> variant to the web because FirefoxOS already has some
>> other magic more or less explained <iframes> (mozapp, and mozbrowser). The
>> only reason a new iframe is needed is because on FirefoxOS (and I believe
>> that's specific for FirefoxOS) we have process separation for apps, ...
>
> I mean I understand why you want to introduce something like this and
> why it looks "webby", but that does not mean it is. The test for that
> is whether it would work in Safari without special code paths, were
> Safari to implement the same standardized features as us.

Funnily enough I used this same argument with a colleague this morning. Well, I did use Chrome instead of Safari as an example. With this proposal, I could implement a CORS proxy service, host it on https://corsproxy.gaiamobile.org, set that as a trusted hosted origin in FirefoxOS and write it so if systemXHR is available it uses it and if not it uses the server to do the actual requests.

Then I could use:
<iframe mozservice src="https://corsproxy.gaiamobile.org" id="corsProxy">

corsProxy.postMessage({URL: "http://a.web.com/whatever"});

And it would work on both FirefoxOS and Chrome. Chrome would just ignore the mozservice part since it doesn't mean anything for it.

Now, of course, the actual service implementation would differ. And we cannot offer things like dialing or SMS on Chrome. But the semantics and syntax of the communication mechanism is basically the standard way of using postMessage.

Best,

Antonio

>
> Everything else is proprietary and we can pack proprietary bits in
> whatever way we want, but claiming they're the web is disingenuous and
> counter to our mission.
>
> We do need proprietary features to figure things out and we do need to
> ship within reasonable timeframes, but we should also remain true to
> ourselves.
>
>
> --
> https://annevankesteren.nl/

[Vivien Nicolas]

On Thu, Feb 26, 2015 at 2:50 PM, ANTONIO MANUEL AMAYA CALVO <antoniomanue...@telefonica.com> wrote:

On 26 Feb 2015, at 14:31, Vivien Nicolas <vnic...@mozilla.com> wrote:

On Thu, Feb 26, 2015 at 12:02 PM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

Hi there.

In the frame of the recent arguments about the permission model and making the apps more webby and as a result more easily updatable (or the other way around), we've been playing with the idea (and trying to prototype) of having certified service-like apps that would encapsulate some permissions.

That would be very cool imho.

 

The rationale behind this is that there are some certified permissions (like settings) that are used by a bunch of apps that only need a small subset of the things the permission actually allow. So we could split the permission (as setting has actually done, in a way that requires Gecko to be aware of the specific settings that Gaia uses, see [1]!) or we could add a Gaia component that has access to the whole setting functionality and mediates on requests to fulfill them or not. Enter the services.

Part of the design of the new Gaia architecture is to be able to prototype such a thing. Some apps can be built as 'Services' and multiple apps may access those Services to do some stuff.

It is not yet implemented but this is on our 'things to explore' todo list.

 

One way to implement the services would be (and that's what we're actually toying with) to use IAC or Datastores to communicate with them). But as we were reminded recently, there's little to no chance of those APIs being actually opened to the web. So... I thought another proposal, that seems webby enough. The idea is to define a new kind of frame, "mozservices". Those frames can be embedded on an app and when they are embedded:

What I have been told is that there is a proposal from Google called 'Tubes' to allow cross-origin communication. I may have misunderstood and the name may not be the right one, but sicking knows.

So maybe the cross-origin communication mechanism is still an option (but not IAC, nor DataStore).

In Gaia the prototype would look a bit like:

App:

var c = new Client('settings', /* version */ '1.0');

c.get('some.setting').then(function(value) {

  // do something

});

Remote Service:

var s = new Server('settings', /* version */ '1.0' {

  get: function(setting) {

    // do something

  }

});

Where Client and Server are client sides API based on Promises. The postMessage communication, is hidden into the lib in order to make it easier to use any new APIs that may comes one day. (fwiw this APIs is built primarily in order to have a clear communication API between views and workers).

Why I would prefer that over embedding a frame ?

 - The iframe trick seems to just be a workaround around the lack of APIs to do cross-origin communication.

The thing is that postMessage *is* an API designed specifically to do cross origin communication. Or that's how I understood it anyway :). In fact if I wanted to do cross origin communication on the web right now j would have to do it using postMessage. The trick here is that mostly for performance and security reasons we want those iframes to be reusable (have only one actual instance). 

Note that Client/Server are pure app logic as I mentioned and they use postMessage in the background.

 

  - With the frame you need to know the url of the Service, which is something that may change, and it would be cool if third-party developers can create their own Services to replace ours in the future.

That's right, but again, URLs are the standard way to identify objects/elements/resources on the web. So the difference is if the client app wants to use any settings service versus this specific service identified by this URL. 

Well. I assume that different phones from different manufacters may ship similar Services but their inner app may used different urls.

 

  - The service does not need to have a window object to return. It simply returns data.One of the cool thing we could build around Services too is the ability for the client to subscribe to some events.

  For example:

  var c = new Client('contacts', '1.1');

  c.addEventListener('oncontactschanged', function(changes) {

    // do something

  });

 While if the iframe does not have an opener (as you describe), it could only react to postMessage. So the iframe needs a way to know who has opened it to push those kind of notifications.

Hmm that is a fair point. As I had seen this would work on a request/response way only, not on a publisher/subscriber way. 

In any case, what I had tried to do with this proposal was to *not* introduce any new API (which then would have to be designed and standardized and what not) but to see if we could do with what we currently have. Note that if we remove the restriction to encapsulate other apps this could even work with what we have right now.

A new kind of <iframe> is a kind of new API :)

 

Best, 

Antonio

[1] http://hg.mozilla.org/mozilla-central/diff/2a8fd75b667f/dom/apps/src/PermissionsTable.jsm

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Jim Porter]

On 02/26/2015 05:02 AM, Antonio Manuel Amaya Calvo wrote:
> Hi there.
>
> In the frame of the recent arguments about the permission model and
> making the apps more webby and as a result more easily updatable (or the
> other way around), we've been playing with the idea (and trying to
> prototype) of having certified service-like apps that would encapsulate
> some permissions.

We've actually talked a lot about this on the media team in the context of a "headless" music player, to keep the OOM killer from stopping music playback. As you mention, the main job is to figure out how to communicate between processes. It might be worth creating some services/daemons in Gaia (like the aforementioned music app) to see what exactly we need for inter-process communication. That would make it a lot easier to design an API, I think.

- Jim

[Paul Theriault]

I can't comment on webby-ness, but I do have thoughts about security here.

(OK, just one comment: this sounds like a variation on the existing inter app communications service - its there practically any differences, other than a forward declaration in the app manifest?Just a thought).

In general I think the next step here is to flesh out what some of these services might do?  I'm struggling to think of actual services that would support gaia use cases in a safe way but its probably worth exploring, if only to better understand the APIs we need for gaia.

On Fri, Feb 27, 2015 at 2:42 AM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

On 26/02/2015 16:11, Fernando Jiménez Moreno wrote:

Thanks for starting this thread Antonio.

On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia.

Yes and not. I'm not proposing to move the permission check from Gecko to Gaia, Gecko will still have the same permission check it has now. What I'm proposing is implementing a (set) of proxy/ies of APIs. Some app(s) that will act as proxy/ies for other apps that cannot request the permission directly (because the API is certified or privileged for security reasons or because we don't want to open the API to the web). That way some apps that currently are certified (in Gaia) can be moved to privileged or even web.

From a security perspective, you _are_ just implementing more APIs, except in Gaia instead of gecko. The security of these services depends on the security checks they implement. Not saying this is a bad thing (maybe the flexibiity of an update app is useful?) but there's no escaping that the security of device relies on the security checks implemented in these services.

What's more is that these services actually have less information to make a security decision on. They basically only have access to the origin of the page making the request. 

On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service?

Ok, again there are two different issues here. On one hand, initially the services would be services for the OS apps (that is, the Gaia apps). Those services will allow moving apps from certified to privileged or even web, if the APIs that they use can be mediated by a "service app". As such, the service can decide to serve or not the request by a combination of the origin (origin URL) and the actual data passed. A hypothetical settings service could use a table like:

{
  "https://music.gaiamobile.org" : {
       read: ["volume.max", "volume.current", "silentmode"],
       write: ["volume.max"]
...
}

(I didn't check the actual settings that the music app uses).

I know this is contrived example but this seems backwards to me. Shouldn't the settings that the music wants to access be defined in the music app itself?

That aside, lets consider the compromise scenario (which is the main challenge hosted apps). In this case, the music app has been compromised and the attacker has access to the same settings as the music app. The service has no way of of knowing that the app is compromised, so the only settings that the service can safely expose to the music app are things that don't matter to much if the music app is compromised. 

In general I guess the benefit here is that ability to add new, more finely grained APIs without changing the underlying gecko API. I like the concept, but I'm struggling to think of actual services that we could implement that would bring meaningful powers hosted versions of gaia apps.

Each service can, and should, have it's own set of rules it applies before serving a request. So we could have a XMLHttpRequest proxy that could serve petitions using SystemXHR from some apps to a concrete set of domains (or *), a disk access proxy that could allow access from some apps to some specific directories and so on. The nice part of this is that since it's all on the Gaia side we will not be introducing any design dependencies between Gecko and Gaia (Gecko doesn't need to know anything about Gaia!).

This is the initial step. I didn't talk anything about third party apps so far :)

If we want to open this to third party apps, then it'll have to be on a controlled way. We can still do it by origin (https only, obviously) and we can download the actual ruleset from a Mozilla/Operator/OEM server. That would allow dynamic configuration of what apps can access what services, allowing Mozilla, an operator or an OEM to add another app without having to change the core/certified apps. For example, if we decide to add a "3D photo camera" at a later point, that requires access to a mediated API, we can just update the ruleset for that service on the Mozilla server (or the operator server, or the OEM server, or even the personal server of the user if the phone has a homebrew build!) to add the rules for https://3dphonecamera.somedeveloper.com and presto, we have a new app that has access to protected resources on a controlled way.

So Mozilla just granted access to my photo library to some random third-party that they decided to trust? :) As a user, do I get a say in this?

To me this use case feels more like extensions than apps - maybe we should be considering building extensions (that have full gecko access, and can use that to make security decisions and can provide security UI, like prompts/notifications etc) rather than trying to implement everything as an app?

Just a thought.

/ Paul

 

Best,

Antonio

/ Fernando

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

[Antonio Manuel Amaya Calvo]

On 07/03/2015 10:20, Paul Theriault wrote:

I can't comment on webby-ness, but I do have thoughts about security here.

(OK, just one comment: this sounds like a variation on the existing inter app communications service - its there practically any differences, other than a forward declaration in the app manifest?Just a thought).

Well, yes, it doesn't need us to introduce a new navigator API (going to start differentiating between those and any other kind of APIs ;)) that has to be standardized. More on this later.

In general I think the next step here is to flesh out what some of these services might do?  I'm struggling to think of actual services that would support gaia use cases in a safe way but its probably worth exploring, if only to better understand the APIs we need for gaia.

Things I can think of:

• Mediated systemXHR: allow systemXHR on a per origin and per destination basis, so the contacts app can access Facebook and Gmail, and only some specific URLs on those servers, for example. Or allow any random X app to access only the servers we deem it's safe for it to access to.
• Mediated settings access: Allow the apps only to access the settings they actually need without adding new permissions to Gecko for each specific Gaia setting that needs more access.
• Mediated dial and SMS access: allow some apps to dial and/or send and/or receive SMS including the text, but only from some specific numbers.
  

On Fri, Feb 27, 2015 at 2:42 AM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

On 26/02/2015 16:11, Fernando Jiménez Moreno wrote:

Thanks for starting this thread Antonio.

On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia.

Yes and not. I'm not proposing to move the permission check from Gecko to Gaia, Gecko will still have the same permission check it has now. What I'm proposing is implementing a (set) of proxy/ies of APIs. Some app(s) that will act as proxy/ies for other apps that cannot request the permission directly (because the API is certified or privileged for security reasons or because we don't want to open the API to the web). That way some apps that currently are certified (in Gaia) can be moved to privileged or even web.

From a security perspective, you _are_ just implementing more APIs, except in Gaia instead of gecko. The security of these services depends on the security checks they implement. Not saying this is a bad thing (maybe the flexibiity of an update app is useful?) but there's no escaping that the security of device relies on the security checks implemented in these services.

Correct, we're implementing more APIs but those APIs that don't change the APIs exposed by the navigator, and so they're conceptually not much different of me creating a server that exposed a set of REST APIs... which extend the things I can do on the web/using a browser, but I don't have to standardize ;).

And yeah, the security of the device depends on the security checks implemented on the services.

What's more is that these services actually have less information to make a security decision on. They basically only have access to the origin of the page making the request. 

They have access to that, and to what each origin is allowed to do. So if https://someserver.wetrust.com has access to:

• Read and send SMS from +123456789
• Have socket access to someserver.com:12345

then even if https://someserver.wetrust.com is thoroughly compromised, it *still* would only be able to access to that same services. This is actually better and worse than what we currently do for privileged and certified apps:

• It's worse because we don't actually check the code of someserver.wetrust.com and it's easier (I hope :P) to compromise a remote server than a locally installed app.
• It's better because even if/when it's compromised, it will still have access exactly the same subset of the device APIs it previously had. Currently, if a privileged app that has access to SystemXHR is compromised, the attacker will get access to *any* server using SystemXHR (ditto if it has access to contacts, or whatever).

I don't envision services as giving uncontrolled access to any of the underlying APIs, but of them giving access, to each origin, to the specific subset of the API than when the origin was submitted/we wrote the app we deemed for it safe to access. So basically the same that reviewers currently do with privileged apps, only even when the app changes it will still have access to the same subset of the underlying API.

On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service?

Ok, again there are two different issues here. On one hand, initially the services would be services for the OS apps (that is, the Gaia apps). Those services will allow moving apps from certified to privileged or even web, if the APIs that they use can be mediated by a "service app". As such, the service can decide to serve or not the request by a combination of the origin (origin URL) and the actual data passed. A hypothetical settings service could use a table like:

{
  "https://music.gaiamobile.org" : {
       read: ["volume.max", "volume.current", "silentmode"],
       write: ["volume.max"]
...
}

(I didn't check the actual settings that the music app uses).

I know this is contrived example but this seems backwards to me. Shouldn't the settings that the music wants to access be defined in the music app itself?

Yes and no. The music app will define the settings it want to access in two ways:

1. Using them ;
2. And telling the service ruleset: Hey, I'm the music app and I will need access to these settings.

Now, for Gaia apps, the second part can be automated. That is, the settings app can define in it's manifest, on in some new file read at build time only, the services it need to access, and what subset of those services it need, and the build process can create the initial/static ruleset for those apps. For third party apps, though, they will have to submit their apps/needs to the ruleset server, the same way they currently submit the privileged apps, if they want to access restricted elements on the phone.

That aside, lets consider the compromise scenario (which is the main challenge hosted apps). In this case, the music app has been compromised and the attacker has access to the same settings as the music app. The service has no way of of knowing that the app is compromised, so the only settings that the service can safely expose to the music app are things that don't matter to much if the music app is compromised. 

Correct. If the hosted app is compromised, the only things it can do on the phone is the same things it could do *before* it was compromised (so the security depends on how strict the ruleset is when giving access to something, and how narrow that access is).

In general I guess the benefit here is that ability to add new, more finely grained APIs without changing the underlying gecko API. I like the concept, but I'm struggling to think of actual services that we could implement that would bring meaningful powers hosted versions of gaia apps.

Each service can, and should, have it's own set of rules it applies before serving a request. So we could have a XMLHttpRequest proxy that could serve petitions using SystemXHR from some apps to a concrete set of domains (or *), a disk access proxy that could allow access from some apps to some specific directories and so on. The nice part of this is that since it's all on the Gaia side we will not be introducing any design dependencies between Gecko and Gaia (Gecko doesn't need to know anything about Gaia!).

This is the initial step. I didn't talk anything about third party apps so far :)

If we want to open this to third party apps, then it'll have to be on a controlled way. We can still do it by origin (https only, obviously) and we can download the actual ruleset from a Mozilla/Operator/OEM server. That would allow dynamic configuration of what apps can access what services, allowing Mozilla, an operator or an OEM to add another app without having to change the core/certified apps. For example, if we decide to add a "3D photo camera" at a later point, that requires access to a mediated API, we can just update the ruleset for that service on the Mozilla server (or the operator server, or the OEM server, or even the personal server of the user if the phone has a homebrew build!) to add the rules for https://3dphonecamera.somedeveloper.com and presto, we have a new app that has access to protected resources on a controlled way.

So Mozilla just granted access to my photo library to some random third-party that they decided to trust? :) As a user, do I get a say in this?

Unless we can think on some way to make my mother understands what she would be granting access to, then no :P.

Seriously, though, it would be easy to allow the user to remove specific sites from the ruleset and (easy but dunno how safe unless it's a developer setting) to add new rules himself using the settings API.

To me this use case feels more like extensions than apps - maybe we should be considering building extensions (that have full gecko access, and can use that to make security decisions and can provide security UI, like prompts/notifications etc) rather than trying to implement everything as an app?

Well, from some point of view, everything we've written as certified apps feel like extensions already :). The security UI is a different problem, though, and one that doesn't seem to have any good solution that doesn't involve losing screen real-state.

Best,

Antonio

[Paul Theriault]

On Sat, Mar 7, 2015 at 9:26 PM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

On 07/03/2015 10:20, Paul Theriault wrote:

I can't comment on webby-ness, but I do have thoughts about security here.

(OK, just one comment: this sounds like a variation on the existing inter app communications service - its there practically any differences, other than a forward declaration in the app manifest?Just a thought).

Well, yes, it doesn't need us to introduce a new navigator API (going to start differentiating between those and any other kind of APIs ;)) that has to be standardized. More on this later.

In general I think the next step here is to flesh out what some of these services might do?  I'm struggling to think of actual services that would support gaia use cases in a safe way but its probably worth exploring, if only to better understand the APIs we need for gaia.

Things I can think of:

• Mediated systemXHR: allow systemXHR on a per origin and per destination basis, so the contacts app can access Facebook and Gmail, and only some specific URLs on those servers, for example. Or allow any random X app to access only the servers we deem it's safe for it to access to.

Maybe, but seems far simpler to change the SystemXHR permission just to also accept a whitelist of origins that the app will connect with.

(PS contacts app is a bad example I think, since if it was hosted, the contacts app doesn't need to talk to gmail/facebook oauth services, right? I get your point though)

 

• Mediated settings access: Allow the apps only to access the settings they actually need without adding new permissions to Gecko for each specific Gaia setting that needs more access.

I guess same argument, and there is the risk of exposing dangerous settings to hosted app.

• Mediated dial and SMS access: allow some apps to dial and/or send and/or receive SMS including the text, but only from some specific numbers.
  

Lots of risks to mitigiate here. An attacker which compromises a hosted gaia app can send 1000 sms messages and cost the user large amounts of money. (I guess you could rate limit). But this is exactly the sort of thing that I would want to surface to the user for them to decide, rather than making the choice for them. It gets very complicated to explain very quickly though.

 

On Fri, Feb 27, 2015 at 2:42 AM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

On 26/02/2015 16:11, Fernando Jiménez Moreno wrote:

Thanks for starting this thread Antonio.

On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia.

Yes and not. I'm not proposing to move the permission check from Gecko to Gaia, Gecko will still have the same permission check it has now. What I'm proposing is implementing a (set) of proxy/ies of APIs. Some app(s) that will act as proxy/ies for other apps that cannot request the permission directly (because the API is certified or privileged for security reasons or because we don't want to open the API to the web). That way some apps that currently are certified (in Gaia) can be moved to privileged or even web.

From a security perspective, you _are_ just implementing more APIs, except in Gaia instead of gecko. The security of these services depends on the security checks they implement. Not saying this is a bad thing (maybe the flexibiity of an update app is useful?) but there's no escaping that the security of device relies on the security checks implemented in these services.

Correct, we'red implementing more APIs but those APIs that don't change the APIs exposed by the navigator, and so they're conceptually not much different of me creating a server that exposed a set of REST APIs... which extend the things I can do on the web/using a browser, but I on't have to standardize ;).

And yeah, the security of the device depends on the security checks implemented on the services.

What's more is that these services actually have less information to make a security decision on. They basically only have access to the origin of the page making the request. 

They have access to that, and to what each origin is allowed to do. So if https://someserver.wetrust.com has access to:

• Read and send SMS from +123456789
• Have socket access to someserver.com:12345

then even if https://someserver.wetrust.com is thoroughly compromised, it *still* would only be able to access to that same services. This is actually better and worse than what we currently do for privileged and certified apps:

• It's worse because we don't actually check the code of someserver.wetrust.com and it's easier (I hope :P) to compromise a remote server than a locally installed app.
• It's better because even if/when it's compromised, it will still have access exactly the same subset of the device APIs it previously had. Currently, if a privileged app that has access to SystemXHR is compromised, the attacker will get access to *any* server using SystemXHR (ditto if it has access to contacts, or whatever).

The crucial difference you overlooking is likelihood of compromise. Currently, there is no server for an attacker compromise, that will own _all_ FxOS phones. A compromise of marketplace would be bad, but it wouldn't allow pushing malicious code to user's devices. Furthermore, I'd also argue that combination of static HTML apps and CSP is a fairly strong mitigation to cross-site scripting which is by far the most prevalent web app vulnerability (and the biggest concern if you are talking about expose privileges to a web apps).

But from my investigation so far, I don't see any solution other than introduction some kind of integrity mechanism to hosted Gaia apps (i.e. making them static and signed, with CSP etc). And if we have that then a service might be a nice defense in depth layer.

I don't envision services as giving uncontrolled access to any of the underlying APIs, but of them giving access, to each origin, to the specific subset of the API than when the origin was submitted/we wrote the app we deemed for it safe to access. So basically the same that reviewers currently do with privileged apps, only even when the app changes it will still have access to the same subset of the underlying API.

On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service?

Ok, again there are two different issues here. On one hand, initially the services would be services for the OS apps (that is, the Gaia apps). Those services will allow moving apps from certified to privileged or even web, if the APIs that they use can be mediated by a "service app". As such, the service can decide to serve or not the request by a combination of the origin (origin URL) and the actual data passed. A hypothetical settings service could use a table like:

{
  "https://music.gaiamobile.org" : {
       read: ["volume.max", "volume.current", "silentmode"],
       write: ["volume.max"]
...
}

(I didn't check the actual settings that the music app uses).

I know this is contrived example but this seems backwards to me. Shouldn't the settings that the music wants to access be defined in the music app itself?

Yes and no. The music app will define the settings it want to access in two ways:

1. Using them ;
2. And telling the service ruleset: Hey, I'm the music app and I will need access to these settings.

Now, for Gaia apps, the second part can be automated. That is, the settings app can define in it's manifest, on in some new file read at build time only, the services it need to access, and what subset of those services it need, and the build process can create the initial/static ruleset for those apps. For third party apps, though, they will have to submit their apps/needs to the ruleset server, the same way they currently submit the privileged apps, if they want to access restricted elements on the phone.

How would a ruleset server decide whether or not to grant access to a particular hosted app (noting that it can't review the code of a hosted app) ?

 

That aside, lets consider the compromise scenario (which is the main challenge hosted apps). In this case, the music app has been compromised and the attacker has access to the same settings as the music app. The service has no way of of knowing that the app is compromised, so the only settings that the service can safely expose to the music app are things that don't matter to much if the music app is compromised. 

Correct. If the hosted app is compromised, the only things it can do on the phone is the same things it could do *before* it was compromised (so the security depends on how strict the ruleset is when giving access to something, and how narrow that access is).

That's basically what I am getting at - so far when looking a the most common permissions used by Gaia apps, making the API narrow enough so that is safe enough, breaks the gaia use cases.

[ANTONIO MANUEL AMAYA CALVO]

On 07 Mar 2015, at 23:31, Paul Theriault <pther...@mozilla.com> wrote:

On Sat, Mar 7, 2015 at 9:26 PM, Antonio Manuel Amaya Calvo <antoniomanue...@telefonica.com> wrote:

On 07/03/2015 10:20, Paul Theriault wrote:

I can't comment on webby-ness, but I do have thoughts about security here.

(OK, just one comment: this sounds like a variation on the existing inter app communications service - its there practically any differences, other than a forward declaration in the app manifest?Just a thought).

Well, yes, it doesn't need us to introduce a new navigator API (going to start differentiating between those and any other kind of APIs ;)) that has to be standardized. More on this later.

In general I think the next step here is to flesh out what some of these services might do?  I'm struggling to think of actual services that would support gaia use cases in a safe way but its probably worth exploring, if only to better understand the APIs we need for gaia.

Things I can think of:

• Mediated systemXHR: allow systemXHR on a per origin and per destination basis, so the contacts app can access Facebook and Gmail, and only some specific URLs on those servers, for example. Or allow any random X app to access only the servers we deem it's safe for it to access to.

Maybe, but seems far simpler to change the SystemXHR permission just to also accept a whitelist of origins that the app will connect with.

That is another option, to give every special navigator API much more granularity. Writing it on gaia makes it more flexible and easier to update, IMHO, though. 

(PS contacts app is a bad example I think, since if it was hosted, the contacts app doesn't need to talk to gmail/facebook oauth services, right? I get your point though)

 

It really depends on if we wish the contacts app to have some server component (other than being hosted or not). Even if the actual app code was hosted, I would prefer all the code to run locally (without any code that run server side) since that way the user's data only go from Gmail or Facebook to the phone, without any intermediate. 

• Mediated settings access: Allow the apps only to access the settings they actually need without adding new permissions to Gecko for each specific Gaia setting that needs more access.

I guess same argument, and there is the risk of exposing dangerous settings to hosted app.

If the setting is dangerous then it probably should not be exposed to the hosted content, no matter how. We're requiring the permission and thus making some apps certified for innocuous settings (at least they're innocuous to read and in some case even to set).

• Mediated dial and SMS access: allow some apps to dial and/or send and/or receive SMS including the text, but only from some specific numbers.
  

Lots of risks to mitigiate here. An attacker which compromises a hosted gaia app can send 1000 sms messages and cost the user large amounts of money. (I guess you could rate limit). But this is exactly the sort of thing that I would want to surface to the user for them to decide, rather than making the choice for them. It gets very complicated to explain very quickly though.

Well, when I was thinking of giving restricted dial/send sms to some apps I was thinking more on the line of toll free numbers controlled by the app maker. Everything that costs money to the user should require an explicit approval by the user, every time. Otherwise we're just asking for problems. 

Best, 

Antonio

[Jonas Sicking]

On Sun, Mar 8, 2015 at 1:01 PM, ANTONIO MANUEL AMAYA CALVO
<antoniomanue...@telefonica.com> wrote:
>>
>> Mediated systemXHR: allow systemXHR on a per origin and per
>> destination basis, so the contacts app can access Facebook and Gmail,
>> and only some specific URLs on those servers, for example. Or allow
>> any random X app to access only the servers we deem it's safe for it to
>> access to.
>
> Maybe, but seems far simpler to change the SystemXHR permission just
> to also accept a whitelist of origins that the app will connect with.
>
> That is another option, to give every special navigator API much more
> granularity. Writing it on gaia makes it more flexible and easier to update,
> IMHO, though.

I think this gets to the core of what this proposal accomplishes.

That by implementing these APIs in Gaia rather then in Gecko, it makes
it both easier to implement the API (writing gaia code is "easier"
than writing gecko code), and, if we host Gaia on a webserver, we can
update it without getting the OEM to compile a new FirefoxOS
distribution.

I agree that this proposal accomplishes that, and that there are good
sides to this.

I don't, however, think that this proposal is any more "webby", would
be any easier to standardize or would be any less FirefoxOS specific,
than adding APIs the way that we currently do.

But I don't think that's a big deal since I don't think any of the
ways that we expose these "sensitive APIs" stand a particularly good
chance of getting standardized no matter what solution we use.


The main downside that I see is that this solution would mean that
we'd hand out access to particular APIs, not through signatures, but
rather though hardcoded (but updatable) lists of websites that can
access a given API.

This would mean that we can't enforce things like signatures and CSP
policies. Which are two nice security features of our current system.

Using signatures actually removes some of the need to update as often.
You don't have to update the API implementation every time you want to
expose the API to a new website. The decision to expose an API to a
new website is done purely server-side.


If all we're trying to accomplish is to enable Gaia to implement APIs,
then we should simply expose IAC to 3rd party content. This is
effectively what the <iframe> proposal does anyway. I.e. it creates a
postMessage-based channel between 3rd party content and Gaia.

We could even add the ability to let the gaia side of IAC to inspect
what permissions the content on the other end has been signed for,
which would enable us to still enforce things like signatures and CSP
where we want to.


The only caution I would give is that just because we're implementing
APIs in Gaia doesn't remove a lot of the work that we need to do to
design APIs. I.e. a lot of what makes APIs hard to expose is that once
exposed, you have to maintain them essentially forever.

Looking at the other place where we've enabled Gaia to implement APIs
exposed to 3rd party apps, we don't have a good track record in well
designed APIs.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities#Firefox_OS_activities

/ Jonas

[Benjamin Francis]

See also https://groups.google.com/forum/#!topic/mozilla.dev.gaia/0CkXpQ25Wdc

I think we're trying to solve similar problems in a slightly different way.

It's possible navigator.connect with cross-origin onfetch events for Service Workers could achieve some of this, and already has another browser vendor interested in implementing it.

Particularly for APIs which are privileged because they give access to private user data rather than device features, it could provide a much more webby solution that what we have today.

[Dave Huseby]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/07/2015 01:20 AM, Paul Theriault wrote:
> In general I think the next step here is to flesh out what some of
> these services might do? I'm struggling to think of actual
> services that would support gaia use cases in a safe way but its
> probably worth exploring, if only to better understand the APIs we
> need for gaia.

Paul and I were discussing this in the context of the proposed
crypto-ish hardware framework. I'm replying here to get some more
eyes on what we discussed.

Using apps to provide services via IAC of some form is a good approach
to adding support for crypto-ish hardware (e.g. secure elements,
yubikeys, hardware bitcoin wallets, hardware entropy sources, etc).

What I'd like to see is crypto-ish hardware manufacturers creating
signed apps that we can grant access to restricted APIs for talking to
their hardware (i.e. Yubico writes a signed Yubikey app that gets
access to their hardware and can respond to IAC requests from other apps
).

This avoids having to figure out how to give 3rd party apps direct
access to the hardware. It puts the responsibility of supporting a
piece of hardware into the hands of the manufacturer. It allows for
supporting a multiplicity of crypto-ish hardware without having a
specific API for each one.

I'm currently attempting to build a prototype certified app that will
access a Secure Element and respond to IAC requests from other
certified apps.

Some of the prototype use cases we've thought of are:

1. Storing an encryption key on the Secure Element and using it to
encrypt/decrypt email credentials so that we no longer store them in
the clear.

2. Creating a generic key store Secure Element applet and allowing
other apps to generate and store the keys on the Secure Element
instead of on the flash.

3. Implementing a shared secret + time one-time-password applet for
the Secure Element and using that for two-factor auth.

Ultimately, I want 3rd-party apps to be able to talk to the service
apps, but for now I'm just trying to prove that this is viable for
certified apps.

WDYT?

- --dave
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJVEKxNAAoJEJ7v31qiCP4gYuwP/RAaP5Kmxvdfv2+7v/oQmuuB
zfuE5aP3y2iC1l2/cNoI8HYFJMu5rRVmpo01kkjI8lWMM6Dm1NM4FQ83R6LzT/bi
KnglxQd4roPpx2xUUOMJiqAjjz7kSbM+D1stisuQkzABWI4zgDl9wth8zzS3+57Z
/FPY7euO+d22ieEAPBX8HhWMmbdDcNebbBtm1QbZbO6O2FrG49fIh2zENKg9Udvq
M09J+iaOSVE7fwqBj6IBPo0Uxk3RvSLR1ADsQmw8KhfVq0aOkHTXoPfgrf/F+xK1
+iSqZWZL0mcMM9wLEW35LBndPDtgg6Z0OPW82CWTYBu6KJSkjSgnBmX7URQFqXTe
hYYH5IpcV4B02/fsrF6HAQEk6B+P5lksGjI1jbsd4J3JrgyfjrqPoPpy3dgYbp/l
bjyFNqdV1P3RnqBzgSXeffi/Yqaoc66YEr9BFYrWIU2PhhJWMDQRo4cs2eAT6agd
zQj/cpc5XIr7ETITxKgRQEHyE21xTnMEVxbwtu9p64Y9W8EWwX+LyXT6EAfQT3sq
H0cOeu9EWRKOBMi+fOeb7VCdM6h6KZpkoLa5D4IIfBw1YjEyXsbt/mTKkM55Z4jO
gffqWtIKjxZhAPEU7+nkeWdWv6taGNyWgqAgpfWxDQaKzFfw64qOAgCrTnWcane/
mZ1Rv3YaG26T6RPtUfl6
=PNHk
-----END PGP SIGNATURE-----

[Anders Rundgren]

This sound very interesting. Would these services be available in the "Open Web"? Would they be useful for other platforms as well?

[Yoshi Huang]

Hi Dave

This might not related to the original subject

but just provide some comments on your previous post.

On Tue, Mar 24, 2015 at 8:14 AM, Dave Huseby <dhu...@mozilla.com> wrote:

Some of the prototype use cases we've thought of are:

1. Storing an encryption key on the Secure Element and using it to
encrypt/decrypt email credentials so that we no longer store them in
the clear.

2. Creating a generic key store Secure Element applet and allowing
other apps to generate and store the keys on the Secure Element
instead of on the flash.

3. Implementing a shared secret + time one-time-password applet for
the Secure Element and using that for two-factor auth.

For the Secure Element, you need either UICC Secure Element or embedded Secure Element

which will need help from SIM provider or OEM, since only they own the keys to provision the SEs.

And please check Bug 884594 if you're using an UICC SE.

But if you are talking about Yubikey Neo, it is a NFC Forum Type 4 tag,

you need NFC API to communicate with those YubiOath/PIV/OpenPGP/... applets.

Also for your information NFC API already became privileged since v2.2

And SE API is also expected to become privileged in next release.

Thanks

[Soledad Penadés]

On 07/03/2015 10:26, Antonio Manuel Amaya Calvo wrote:
> Unless we can think on some way to make my mother understands what she
> would be granting access to, then no :P.

This is tangentially offtopic to this thread, but I would appreciate if
everybody please avoided using "mothers" as examples of less qualified
technical users.

A better non sexist and non patronising alternative is "an average user"
or "a non technical user" or "non tech savvy user" if you want to
highlight the fact that they are just users and not developers.

It's not like the Gaia / Firefox OS project is filled to the brim with
women, so this kind of language is totally unwelcoming to us.

Thanks :-)

--
http://soledadpenades.com

[Naoki Hirata]

Soledad makes a good point. And besides, do you really want to insult your mother to the public? :)
[ light hearted joke ]

Regards,
Naoki

[Ben Kelly]

FYI, we discussed cross-origin service workers last week at the face-to-face meeting:

  https://blog.wanderview.com/blog/2015/07/28/service-worker-meeting-highlights/#foreign-fetch

It seems we're all in agreement that we should provide something here.  We just need to de-conflict our two proposed specs.  Implementation will take longer of course.

Anyway, if you have feedback on the two proposals, please let us know in the issue:

  https://github.com/slightlyoff/ServiceWorker/issues/684

Thanks.

Ben

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Benjamin Francis]

On 30 July 2015 at 16:52, Ben Kelly <bke...@mozilla.com> wrote:

FYI, we discussed cross-origin service workers last week at the face-to-face meeting:

  https://blog.wanderview.com/blog/2015/07/28/service-worker-meeting-highlights/#foreign-fetch

From the post: 

The idea is to permit a service worker to intercept fetch events to its own origin.

...

1. Its more “webby” using HTTP requests instead of RPC-like messags.
2. As a consequence its easy to provide offline support for REST APIs build on top of HTTP verbs like GET and POST.
3. Its progressive. If a browser does not support this new system, then the requests simply go to the server as they used to.

This is awesome :)