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
________________________________
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
