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 < [email protected]> 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"; <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 > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
