WebAPIs for allowing exclusive access to a (hardware) resource to more than one app.

[Garner Lee]

Hi,

I work in a team adding NFC apis to FirefoxOS. In many cases, the W3C apis
tend to be desktop browser centric: The application needs to be running, in
order for the event handler to be set.

IPC Methods available:

1) Message broadcast (SystemInternalMessage: broadcastMessage)
2) message "single-cast" (SystemInternalMessage: sendMessage) with
manifestURL, and PageURL)
3) Activity fired (ActivityPicker, but data is pubilc).
4) EventHandlers (non-queued events to registered event callbacks).

One problem with WebActivity is of course, the intended public nature of
the API, anybody can send (or intercept) anything, asking if there's
ambiguity with a activity picker. This is less than ideal, if you are
dealing with NFC Wallet Payments, for example. That data could be a
security concern.

------------------------
A few questions:
------------------------
1) Is "window.navigator.mozSetMessageHandler" going to be a web standard,
or just intended to be a Mozilla WebApp feature only? This does start the
application, and deliver information.
-- How hard/sane is it to create a filter for system messages like it is
done for MozActivities?

2) Is it possible to modify the system messaging such that we can get a
targeted event to also start the application that should receive a message?
-- We have a solution for NFC, but it isn't pretty (lots of back and
forth messages to indicate when the callback is finally set in the
application to receive a event and do the event callback.)

3) Somewhat less important, can we ever deliver a DOM object, from gecko
parent process to another child process, with an active interface attached
(W3C has their NFC APIs do this), via a parameter list?

4) Is there any UX started for selecting a "default" one? I know
WebActivities has one, but one may be needed for "targeted system messages"
as well if implemented that way.

----------


In every case, we would want to start the user intended app first, rather
than blind fire events to every possible interested NFC, Couponing, or
Payment application. We're still working out some UX details.

For now, we want only to notify one application, though there's some talk
still of expanding it to allow more than one to be a target, but not all
apps.


--------------------------------------------------------------
Some further reading for a bit more background:
--------------------------------------------------------------

In the case of NFC (and Wallet Applications, for example), we want to send
payment "received" transaction messages to a designated application (Some
more information here: https://bugzilla.mozilla.org/show_bug.cgi?id=979767).

For a few reasons, SystemMessages aren't sufficient:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037380

Thanks for any input (and questions)!

-Garner

[Ehsan Akhgari]

On 2014-07-17, 8:18 PM, Garner Lee wrote:
> Hi,
>
> I work in a team adding NFC apis to FirefoxOS. In many cases, the W3C apis
> tend to be desktop browser centric: The application needs to be running, in
> order for the event handler to be set.
>
> IPC Methods available:
>
> 1) Message broadcast (SystemInternalMessage: broadcastMessage)
> 2) message "single-cast" (SystemInternalMessage: sendMessage) with
> manifestURL, and PageURL)
> 3) Activity fired (ActivityPicker, but data is pubilc).
> 4) EventHandlers (non-queued events to registered event callbacks).
>
> One problem with WebActivity is of course, the intended public nature of
> the API, anybody can send (or intercept) anything, asking if there's
> ambiguity with a activity picker. This is less than ideal, if you are
> dealing with NFC Wallet Payments, for example. That data could be a
> security concern.
>
> ------------------------
> A few questions:
> ------------------------
> 1) Is "window.navigator.mozSetMessageHandler" going to be a web standard,
> or just intended to be a Mozilla WebApp feature only? This does start the
> application, and deliver information.
> -- How hard/sane is it to create a filter for system messages like it is
> done for MozActivities?

I don't think our system messages are something that we can standardize
as an API exposed to web pages. The Web equivalent way of delivering
notifications to apps that may or may not be running is going to be
dispatching an event to the app's service worker.

> 2) Is it possible to modify the system messaging such that we can get a
> targeted event to also start the application that should receive a message?
> -- We have a solution for NFC, but it isn't pretty (lots of back and
> forth messages to indicate when the callback is finally set in the
> application to receive a event and do the event callback.)

I think so. Do you have any concerns about that?

> 3) Somewhat less important, can we ever deliver a DOM object, from gecko
> parent process to another child process, with an active interface attached
> (W3C has their NFC APIs do this), via a parameter list?

I'm not really sure if I understand what you want to do here. Can you
please elaborate? (Perhaps include an example?)

> 4) Is there any UX started for selecting a "default" one? I know
> WebActivities has one, but one may be needed for "targeted system messages"
> as well if implemented that way.

Targeted messages and a default handler are sort of mutually exclusive
as far as I can see. If the sender sends a message specifically to app
1, when is the user going to be prompted? AFAICT that is not necessary,
so there should be no UX issues here. Perhaps I'm missing something.

> In every case, we would want to start the user intended app first, rather
> than blind fire events to every possible interested NFC, Couponing, or
> Payment application. We're still working out some UX details.
>
> For now, we want only to notify one application, though there's some talk
> still of expanding it to allow more than one to be a target, but not all
> apps.
>
>
> --------------------------------------------------------------
> Some further reading for a bit more background:
> --------------------------------------------------------------
>
> In the case of NFC (and Wallet Applications, for example), we want to send
> payment "received" transaction messages to a designated application (Some
> more information here: https://bugzilla.mozilla.org/show_bug.cgi?id=979767).
>
> For a few reasons, SystemMessages aren't sufficient:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037380

It would be really great if you could summarize the information here
instead of just pointing to the bugs.

Thanks!
Ehsan

[Garner Lee]

On Fri, Jul 18, 2014 at 2:45 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

If I'm not mistaken, web pages can't send system messages, but they can
sure receive them (mozSetMessageHandler('activity', func);)

App's service worker? Can you explain, point to a resource?

>
>
>

> 2) Is it possible to modify the system messaging such that we can get a
>> targeted event to also start the application that should receive a
>> message?
>> -- We have a solution for NFC, but it isn't pretty (lots of back and
>> forth messages to indicate when the callback is finally set in the
>> application to receive a event and do the event callback.)
>>
>
> I think so. Do you have any concerns about that?
>

> Yes, the concern is it's specific to NFC only, and not to say, any other
API that wants to route a single sourced hardware message to a subset of
apps.

>
> 3) Somewhat less important, can we ever deliver a DOM object, from gecko
>> parent process to another child process, with an active interface attached
>> (W3C has their NFC APIs do this), via a parameter list?
>>
>
> I'm not really sure if I understand what you want to do here. Can you
> please elaborate? (Perhaps include an example?)

I guess it's a secondary concern for now until we finalize the "V2" NFC
design.

Actually, I think DOM objects are fine in events, and W3C does expect them
in the argument list (their example):
http://www.w3.org/2012/nfc/web-api/#widl-NFCManager-ontagfound

It's Activites that don't accept them (we currently use a
"getNFCPeer(sessionToken)" as a workaround .. objects with interfaces are
sent as empty objects the last I checked).
Ex of current implementation in FirefoxOS:
https://wiki.mozilla.org/WebAPI/WebNFC#NDEF_P2P_Send_Example

>
>
> 4) Is there any UX started for selecting a "default" one? I know
>> WebActivities has one, but one may be needed for "targeted system
>> messages"
>> as well if implemented that way.
>>
>
> Targeted messages and a default handler are sort of mutually exclusive as
> far as I can see. If the sender sends a message specifically to app 1,
> when is the user going to be prompted? AFAICT that is not necessary, so
> there should be no UX issues here. Perhaps I'm missing something.
>

> For example, one might choose a default browser, email app, contacts app,
and a default payment app.

Perhaps a few apps might be interested in couponing, which have equal
weight after applying filtering. And imagine 2 marketplace apps handle can
them. The system would then need to ask the user, and a perhaps default for
future uses. This UI planned for WebActivities, but not system messages at
the moment (messages have no filters). I can't find the bug right now, but
I can update.

>
> In every case, we would want to start the user intended app first, rather
>> than blind fire events to every possible interested NFC, Couponing, or
>> Payment application. We're still working out some UX details.
>>
>> For now, we want only to notify one application, though there's some talk
>> still of expanding it to allow more than one to be a target, but not all
>> apps.
>>
>>
>> --------------------------------------------------------------
>> Some further reading for a bit more background:
>> --------------------------------------------------------------
>>
>> In the case of NFC (and Wallet Applications, for example), we want to send
>> payment "received" transaction messages to a designated application (Some
>> more information here: https://bugzilla.mozilla.org/
>> show_bug.cgi?id=979767).
>>
>> For a few reasons, SystemMessages aren't sufficient:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1037380
>>
>
> It would be really great if you could summarize the information here
> instead of just pointing to the bugs.
>
>

Very good point. A very high level summary:

A new api for Payments are in
https://bugzilla.mozilla.org/show_bug.cgi?id=979767. The payment
"HCI_EVENT_TRANSACTION" message itself is simple: "you have submitted
payment for that thing!" with some transaction data specific to that app,
like, the vendor and amount pending/transacted. The applet on the
SIM/embedded secure element does all the actual work for now.

We're still in discussion on whether it's a 1-1 pairing between the
application (running on the host processor, ie, the CPU running FirefoxOS),
and the secure element running Java cardlets on the baseband processor
(i.e., the mobile radio), and if it expands to more than one web
application application, how we're going to securely route those
transaction messages.

The second bug https://bugzilla.mozilla.org/show_bug.cgi?id=1037380 arose
from the first bug: Can we filter the system messages like we do
WebActivities (basically, add similar syntax to the manifest.webapp file,
and internally, filter, route, and preset a UI/UX as necessary for
ambiguities). In a few discussions, there's some mild resistance to that
idea, since system messages was intended to be simple.



> Thanks!
> Ehsan
>
>

[Andrew Overholt]

On 18/07/14 08:52 PM, Garner Lee wrote:
> On Fri, Jul 18, 2014 at 2:45 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
>
>> On 2014-07-17, 8:18 PM, Garner Lee wrote:
>>>
>>> 1) Is "window.navigator.mozSetMessageHandler" going to be a web standard,
>>> or just intended to be a Mozilla WebApp feature only? This does start the
>>> application, and deliver information.
>>> -- How hard/sane is it to create a filter for system messages like it
>>> is
>>> done for MozActivities?
>>>
>>
>> I don't think our system messages are something that we can standardize as
>> an API exposed to web pages. The Web equivalent way of delivering
>> notifications to apps that may or may not be running is going to be
>> dispatching an event to the app's service worker.
>>
>>
>>
> If I'm not mistaken, web pages can't send system messages, but they can
> sure receive them (mozSetMessageHandler('activity', func);)
>
> App's service worker? Can you explain, point to a resource?

Ehsan is referring to the nascent Service Worker:

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

Both blink and gecko implementations are currently underway.

HTH,

Andrew

[Ehsan Akhgari]

On 2014-07-18, 8:52 PM, Garner Lee wrote:
>
> On Fri, Jul 18, 2014 at 2:45 PM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2014-07-17, 8:18 PM, Garner Lee wrote:
>

> Hi,
>
> I work in a team adding NFC apis to FirefoxOS. In many cases,
> the W3C apis
> tend to be desktop browser centric: The application needs to be
> running, in
> order for the event handler to be set.
>
> IPC Methods available:
>
> 1) Message broadcast (SystemInternalMessage: broadcastMessage)
> 2) message "single-cast" (SystemInternalMessage: sendMessage) with
> manifestURL, and PageURL)
> 3) Activity fired (ActivityPicker, but data is pubilc).
> 4) EventHandlers (non-queued events to registered event callbacks).
>
> One problem with WebActivity is of course, the intended public
> nature of
> the API, anybody can send (or intercept) anything, asking if there's
> ambiguity with a activity picker. This is less than ideal, if
> you are
> dealing with NFC Wallet Payments, for example. That data could be a
> security concern.
>
> ------------------------
> A few questions:
> ------------------------

> 1) Is "window.navigator.__mozSetMessageHandler" going to be a

> web standard,
> or just intended to be a Mozilla WebApp feature only? This does
> start the
> application, and deliver information.
> -- How hard/sane is it to create a filter for system
> messages like it is
> done for MozActivities?
>
>
> I don't think our system messages are something that we can
> standardize as an API exposed to web pages. The Web equivalent way
> of delivering notifications to apps that may or may not be running
> is going to be dispatching an event to the app's service worker.
>
>
>
> If I'm not mistaken, web pages can't send system messages, but they can
> sure receive them (mozSetMessageHandler('activity', func);)

Yes, that is why these are called "system" messages. :-)

> App's service worker? Can you explain, point to a resource?

What Andrew said. Service workers basically provide the UA with a
Worker that can 1) be run without there being any page opened from that
origin in the browser, and 2) be started in order to respond to UA
initiated events.

If you are looking for a way to initiate one of these messages from a
page, you want one of the messaging APIs (postMessage etc) depending on
what information you have from the code on the other side which is
responsible for handling the message. Honestly I don't really
understand the problem you're trying to solve here so I can't provide
better info. :-)

> 2) Is it possible to modify the system messaging such that we
> can get a
> targeted event to also start the application that should receive
> a message?
> -- We have a solution for NFC, but it isn't pretty (lots of
> back and
> forth messages to indicate when the callback is finally set in the
> application to receive a event and do the event callback.)
>
>
> I think so. Do you have any concerns about that?
>
> Yes, the concern is it's specific to NFC only, and not to say, any other
> API that wants to route a single sourced hardware message to a subset of
> apps.

I'm not sure I follow. Why can't you use system messages for NFC *and*
these other use cases you're mentioning?

> 3) Somewhat less important, can we ever deliver a DOM object,
> from gecko
> parent process to another child process, with an active
> interface attached
> (W3C has their NFC APIs do this), via a parameter list?
>
>
> I'm not really sure if I understand what you want to do here. Can
> you please elaborate? (Perhaps include an example?)
>
>
> I guess it's a secondary concern for now until we finalize the "V2" NFC
> design.
>
> Actually, I think DOM objects are fine in events, and W3C does expect
> them in the argument list (their example):
> http://www.w3.org/2012/nfc/web-api/#widl-NFCManager-ontagfound

Now I'm really puzzled! ontagfound doesn't have an argument list...

> It's Activites that don't accept them (we currently use a
> "getNFCPeer(sessionToken)" as a workaround .. objects with interfaces
> are sent as empty objects the last I checked).
> Ex of current implementation in FirefoxOS:
> https://wiki.mozilla.org/WebAPI/WebNFC#NDEF_P2P_Send_Example

So you want to pass a DOM object to an activity? Yes, that's not really
supported. The way we "send" DOM objects around in other parts of the
platform (for example postMessage) is by doing a structured clone on the
DOM object in order to serialize its content alongside with all of the
information required to reconstruct it from scratch later on, send the
serialized representation to the other side, and create a completely new
object from that serialized info which looks and acts like the original
object. So in a sense, sending the same DOM object to somewhere else
may not mean exactly what you are thinking.

> 4) Is there any UX started for selecting a "default" one? I know
> WebActivities has one, but one may be needed for "targeted
> system messages"
> as well if implemented that way.
>
>
> Targeted messages and a default handler are sort of mutually
> exclusive as far as I can see. If the sender sends a message
> specifically to app 1, when is the user going to be prompted?
> AFAICT that is not necessary, so there should be no UX issues
> here. Perhaps I'm missing something.
>
> For example, one might choose a default browser, email app, contacts
> app, and a default payment app.
>
> Perhaps a few apps might be interested in couponing, which have equal
> weight after applying filtering. And imagine 2 marketplace apps handle
> can them. The system would then need to ask the user, and a perhaps
> default for future uses. This UI planned for WebActivities, but not
> system messages at the moment (messages have no filters). I can't find
> the bug right now, but I can update.

Yeah, AFAIK we currently let any app which is interested in handling a
system message handle it, without involving the user in the decision.
That is mostly because system messages are not really designed for the
use case you are targeting.

So, back to the idea of using activities for this for a second, what is
the nature of the data passed to the activity, and how can a potentially
malicious app which handles that activity cause harm for the user? I'm
trying to understand the thread model involved here to see if we can
make activities work for this case somehow.

Cheers,
Ehsan

> In every case, we would want to start the user intended app
> first, rather
> than blind fire events to every possible interested NFC,
> Couponing, or
> Payment application. We're still working out some UX details.
>
> For now, we want only to notify one application, though there's
> some talk
> still of expanding it to allow more than one to be a target, but
> not all
> apps.
>
>

> ------------------------------__------------------------------__--

> Some further reading for a bit more background:

> ------------------------------__------------------------------__--

>
> In the case of NFC (and Wallet Applications, for example), we
> want to send
> payment "received" transaction messages to a designated
> application (Some
> more information here:

> https://bugzilla.mozilla.org/__show_bug.cgi?id=979767

> <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>).
>
> For a few reasons, SystemMessages aren't sufficient:

> https://bugzilla.mozilla.org/__show_bug.cgi?id=1037380

[Garner Lee]

On Mon, Jul 21, 2014 at 11:54 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> Sorry, it's at:

http://www.w3.org/2012/nfc/web-api/#introduction
Example 1:
ontagfound(e) {
...e.tag ...
tag.writeNDEF...

}


>
> It's Activites that don't accept them (we currently use a
>> "getNFCPeer(sessionToken)" as a workaround .. objects with interfaces
>> are sent as empty objects the last I checked).
>> Ex of current implementation in FirefoxOS:
>> https://wiki.mozilla.org/WebAPI/WebNFC#NDEF_P2P_Send_Example
>>
>
> So you want to pass a DOM object to an activity? Yes, that's not really
> supported. The way we "send" DOM objects around in other parts of the
> platform (for example postMessage) is by doing a structured clone on the
> DOM object in order to serialize its content alongside with all of the
> information required to reconstruct it from scratch later on, send the
> serialized representation to the other side, and create a completely new
> object from that serialized info which looks and acts like the original
> object. So in a sense, sending the same DOM object to somewhere else may
> not mean exactly what you are thinking.
>

> Passing a DOM object might be important later in an activity.

Whether it's the same object or not is less important than being able to
get an object, and call APIs on it immediately without a
"getNFCTag(sessionToken) call.

It is actually not hard to do that extra step, but it is an extra step. The
object is intended to be part of an object hierarchy eventually in the case
of NFC.

Events apparently can pass a working API object, but events don't start
applications.

> thread --> threat?

To quote a recent discussion (Paul Theriault, Hi!):

-------
Do we need support a user choosing from a list of qualified applications
(e.g. like web activities, but from a list of web apps which satisfy
certain security properties).
-------

As we know, activities are quite public. System messages (and perhaps the
event that gets triggered somehow), is supposed to be relatively "trusted"
as it is supposedly originated from the system. The is that the nature of
the data can be private, can be intercepted or mistakenly sent to the wrong
application by the user, or worse, a somehow malicious app asking a high
value app, like the wallet, for example, to do something unexpected for it.

Bug 979767 <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>
(HCI_EVENT_TRANSACTION message) references a security mechanism that is an
over the air managed white list to help secure the target end: which webapp
is allowed to handle things at the target level, as determined by say,
Mastercard.

The "Access Control Enforcer" on the gecko side will check web application
certificates against a whitelist, but it doesn't actually cover the source
of the message if it were from a WebActivity (which is available to all
apps to send --> untrusted data).

A system message (with filters), will potentially allow the system can do
some security checks first before delivering the message (or event with
sensitive data attached if that's decided) to the application.
<https://bugzilla.mozilla.org/show_bug.cgi?id=979767>

I'm looking at service worker. Can it be described as an application
service model? Application, Mime-type, Filtering/Routing, and "message data
origin" type security issues is of interest.

-Garner

[Ehsan Akhgari]

On 2014-07-21, 7:55 PM, Garner Lee wrote:
>
>
>
> On Mon, Jul 21, 2014 at 11:54 AM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2014-07-18, 8:52 PM, Garner Lee wrote:
>
>
> On Fri, Jul 18, 2014 at 2:45 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>

> <mailto:ehsan.akhgari@gmail.__com

> 1) Is "window.navigator.____mozSetMessageHandler" going

> to be a
>
> web standard,
> or just intended to be a Mozilla WebApp feature only?
> This does
> start the
> application, and deliver information.
> -- How hard/sane is it to create a filter for system
> messages like it is
> done for MozActivities?
>
>
> I don't think our system messages are something that we can
> standardize as an API exposed to web pages. The Web
> equivalent way
> of delivering notifications to apps that may or may not be
> running
> is going to be dispatching an event to the app's service
> worker.
>
>
>
> If I'm not mistaken, web pages can't send system messages, but
> they can

> sure receive them (mozSetMessageHandler('__activity', func);)

> http://www.w3.org/2012/nfc/__web-api/#widl-NFCManager-__ontagfound

> <http://www.w3.org/2012/nfc/web-api/#widl-NFCManager-ontagfound>
>
>
> Now I'm really puzzled! ontagfound doesn't have an argument list...
>
> Sorry, it's at:
>
> http://www.w3.org/2012/nfc/web-api/#introduction
> Example 1:
> ontagfound(e) {
> ...e.tag ...
> tag.writeNDEF...
> }

tag is a property of the event object, which is a "platform object"
(meaning that it is a JS reflection of an object provided by the UA).
This is a very normal concept across all Web APIs. I'm not sure what
the issue with this is exactly.

> It's Activites that don't accept them (we currently use a
> "getNFCPeer(sessionToken)" as a workaround .. objects with
> interfaces
> are sent as empty objects the last I checked).
> Ex of current implementation in FirefoxOS:

> https://wiki.mozilla.org/__WebAPI/WebNFC#NDEF_P2P_Send___Example

> <https://wiki.mozilla.org/WebAPI/WebNFC#NDEF_P2P_Send_Example>
>
>
> So you want to pass a DOM object to an activity? Yes, that's not
> really supported. The way we "send" DOM objects around in other
> parts of the platform (for example postMessage) is by doing a
> structured clone on the DOM object in order to serialize its content
> alongside with all of the information required to reconstruct it
> from scratch later on, send the serialized representation to the
> other side, and create a completely new object from that serialized
> info which looks and acts like the original object. So in a sense,
> sending the same DOM object to somewhere else may not mean exactly
> what you are thinking.
>
> Passing a DOM object might be important later in an activity.
>
> Whether it's the same object or not is less important than being able to
> get an object, and call APIs on it immediately without a
> "getNFCTag(sessionToken) call.
>
> It is actually not hard to do that extra step, but it is an extra step.
> The object is intended to be part of an object hierarchy eventually in
> the case of NFC.
>
> Events apparently can pass a working API object, but events don't start
> applications.

If you are asking for a generic event dispatch mechanism that can wake
up an application and transmit arbitrary information to it in form of
platform objects, then neither web activities or system messages are
what you want. I'm not aware of any existing mechanism to do that.

Oops, my bad.

> To quote a recent discussion (Paul Theriault, Hi!):
>
> -------
> Do we need support a user choosing from a list of qualified applications
> (e.g. like web activities, but from a list of web apps which satisfy
> certain security properties).
> -------
>
> As we know, activities are quite public.

Yes, they can be triggered and handled by arbitrary apps.

> System messages (and perhaps
> the event that gets triggered somehow), is supposed to be relatively
> "trusted" as it is supposedly originated from the system.

Yes, they are initiated by the system.

> The is that
> the nature of the data can be private, can be intercepted or mistakenly
> sent to the wrong application by the user, or worse, a somehow malicious
> app asking a high value app, like the wallet, for example, to do
> something unexpected for it.

I'm not sure if I understand this part...

> Bug 979767 <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>
> (HCI_EVENT_TRANSACTION message) references a security mechanism that is
> an over the air managed white list to help secure the target end: which
> webapp is allowed to handle things at the target level, as determined by
> say, Mastercard.
>
> The "Access Control Enforcer" on the gecko side will check web
> application certificates against a whitelist, but it doesn't actually
> cover the source of the message if it were from a WebActivity (which is
> available to all apps to send --> untrusted data).

Yes, it seems that web activities are not the right tool for this job.

> A system message (with filters), will potentially allow the system can
> do some security checks first before delivering the message (or event
> with sensitive data attached if that's decided) to the application.
> <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>

I did read that bug. I think you're referring to comment 8 there.
Unfortunately I'm not as familiar with these concepts as you are, and I
didn't manage to understand the problem better from that bug. So far
all I know is that you have some data that you want to generate from
code inside Gecko and you want to launch an app and pass it that data
somehow. I don't understand how the app selection works, and what needs
to be protected, and how, etc. I'm going on with my extremely limited
understanding of this issue.

> I'm looking at service worker. Can it be described as an application
> service model? Application, Mime-type, Filtering/Routing, and "message
> data origin" type security issues is of interest.

Service workers provide us with the ability to launch a worker
associated with a web application and dispatch an event to it. The User
Agent will remain in control of when to dispatch the event and to which
service workers to dispatch it to. As I said before, I don't really
know anything about the specific requirements you're mentioning so I
can't provide any comment on whether they are the right tool for this job.

But please note that the spec and implementation of Service Workers is
still work in progress, and they are also currently being designed for
Web apps, so we may need to do some additional work to make it possible
to make them work in Firefox OS app.

Cheers,
Ehsan

> In every case, we would want to start the user intended app
> first, rather
> than blind fire events to every possible interested NFC,
> Couponing, or
> Payment application. We're still working out some UX
> details.
>
> For now, we want only to notify one application, though
> there's
> some talk
> still of expanding it to allow more than one to be a
> target, but
> not all
> apps.
>
>
>

> ------------------------------____----------------------------__--__--

>
> Some further reading for a bit more background:
>

> ------------------------------____----------------------------__--__--

>
>
> In the case of NFC (and Wallet Applications, for
> example), we
> want to send
> payment "received" transaction messages to a designated
> application (Some
> more information here:

> https://bugzilla.mozilla.org/____show_bug.cgi?id=979767
> <https://bugzilla.mozilla.org/__show_bug.cgi?id=979767>

> <https://bugzilla.mozilla.org/__show_bug.cgi?id=979767
> <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>>).
>
>
> For a few reasons, SystemMessages aren't sufficient:

> https://bugzilla.mozilla.org/____show_bug.cgi?id=1037380
> <https://bugzilla.mozilla.org/__show_bug.cgi?id=1037380>

>
> <https://bugzilla.mozilla.org/__show_bug.cgi?id=1037380
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1037380>>
>
>
> It would be really great if you could summarize the
> information here
> instead of just pointing to the bugs.
>
>
> Very good point. A very high level summary:
>
> A new api for Payments are in

> https://bugzilla.mozilla.org/__show_bug.cgi?id=979767
> <https://bugzilla.mozilla.org/show_bug.cgi?id=979767>. The payment

> "HCI_EVENT_TRANSACTION" message itself is simple: "you have
> submitted
> payment for that thing!" with some transaction data specific to that
> app, like, the vendor and amount pending/transacted. The applet
> on the
> SIM/embedded secure element does all the actual work for now.
>
> We're still in discussion on whether it's a 1-1 pairing between the
> application (running on the host processor, ie, the CPU running
> FirefoxOS), and the secure element running Java cardlets on the
> baseband
> processor (i.e., the mobile radio), and if it expands to more
> than one
> web application application, how we're going to securely route those
> transaction messages.
>
> The second bug

> https://bugzilla.mozilla.org/__show_bug.cgi?id=1037380

[Fabrice Desré]

On 07/22/2014 03:55 PM, Ehsan Akhgari wrote:
>
> If you are asking for a generic event dispatch mechanism that can wake
> up an application and transmit arbitrary information to it in form of
> platform objects, then neither web activities or system messages are
> what you want. I'm not aware of any existing mechanism to do that.

Activities are delivered by a system message and are dom objects. You
need to impleme

Activities are delivered by a system message and are dom objects. You
need to provide a xpcom wrapper for the system message for that to work.
See [1] and [2] for the only implementation we have currently.

Fabrice

[1]
https://mxr.mozilla.org/mozilla-central/source/dom/activities/src/ActivityWrapper.js
[2]
https://mxr.mozilla.org/mozilla-central/source/dom/activities/src/Activities.manifest#5
--
Fabrice Desr�
b2g team
Mozilla Corporation

[Kamil Leszczuk]

Hi Ehsan, Fabrice,

we have prepared a short document describing the EVT_TRANSACTION, it's use cases and requirements we have collected. It's purpose is to bring everyone on the same page, so we can have more efficient discussion from now on.

I think it'd be best if you could take a look and comment/ask questions if something is unclear.

Also, document contains overview of the proposed implementation - it'd be great to discuss it, if it makes sense.

Document:
https://docs.google.com/document/d/1tguuqvVUZHTLDfOtiwot5g3VrEsxfQoW0Twb-qUsaGo/edit?usp=sharing

Hope that clarifies the whole thing a bit :)
Kamil

[Kamil Leszczuk]

Hi All,
Henry has some idea (system message filters) which seem to fit our use case. It's described here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1037380#c24

What do you think?

Best,
Kamil

[Jonas Sicking]

Hi Garner,

I'll jump in at the beginning of this thread since I think it might be
easer to make progress if we start by talking about use cases and
requitrements , rather than specific technical solutions.

I do think that it would be beneficial if we could get at least an
initial UX draft before heading down too far down the path of nailing
down a technical solution. We have seen many times in the past that

>From what I understand, you'd like to build a system where if the user
taps an NFC tag with the device, we want to make sure to start "the
appropriate" application, and deliver information to that application
about the tapped tag.

The crux is selecting "the appropriate" application.

It sounds like this is a function of what data is found on the NFC tag
and what data the users installed applications has indicated that they
can handle. But if the user has several applications installed which
all can handle the tag, we should let the user choose which
application to use, as well as possibly remember that application as a
default for "similar" tags (for some definition of "similar").

Additionally you want to deliver the information about the tag though
custom DOM objects. I.e. not just through plain structured clones
which only support things like JS objects and Blobs.

To make matters worse we have some security requirements. It sounds
like you don't want just anybody to be able to claim to be able to
handle certain tags. And you don't want it to be possible for other
apps to "fake" a message and make it look like the user tapped
something he/she didn't.

Is this correct so far?

If so, it seems like there are two desired things that you want to accomplish:

1) Bring up an application picker which has similar UI to the current
WebActivities picker, but which has a different set of requirements
about which applications to list.

S) Ability to send a system message to the selected application but
where the selected application receives a DOM object.

I would suggest that we solve 1) using NFC specific code. The set of
requirements that you have around security and how to determine which
applications are candidates to receive a message seems quite NFC
specific. So rather than trying really hard to extract some form of
reusable mechanisms which may or may not fit the NFC needs exactly,
lets just build this stuff into the NFC handling code.

The NFC code can simply call into the existing APIs that we have for
enumerating applications and inspecting their manifests to see which
applications match its requirements.

Possibly the system app could have a generic feature for "display an
application picker containing a specified list of applications". This
could then be called both by the NFC code and the WebActivities code.
However you should talk to Alive about if this would make sense.

Solving 2 sounds like it is already possible by using the mechanisms
that Fabrice pointed to.

/ Jonas

On Jul 17, 2014 5:18 PM, "Garner Lee" <dgarn...@gmail.com> wrote:
>
> Hi,
>
> I work in a team adding NFC apis to FirefoxOS. In many cases, the W3C apis
> tend to be desktop browser centric: The application needs to be running, in
> order for the event handler to be set.
>
> IPC Methods available:
>
> 1) Message broadcast (SystemInternalMessage: broadcastMessage)
> 2) message "single-cast" (SystemInternalMessage: sendMessage) with
> manifestURL, and PageURL)
> 3) Activity fired (ActivityPicker, but data is pubilc).
> 4) EventHandlers (non-queued events to registered event callbacks).
>
> One problem with WebActivity is of course, the intended public nature of
> the API, anybody can send (or intercept) anything, asking if there's
> ambiguity with a activity picker. This is less than ideal, if you are
> dealing with NFC Wallet Payments, for example. That data could be a
> security concern.
>
> ------------------------
> A few questions:
> ------------------------

> 1) Is "window.navigator.mozSetMessageHandler" going to be a web standard,

> or just intended to be a Mozilla WebApp feature only? This does start the
> application, and deliver information.
> -- How hard/sane is it to create a filter for system messages like it is
> done for MozActivities?
>

> 2) Is it possible to modify the system messaging such that we can get a
> targeted event to also start the application that should receive a message?
> -- We have a solution for NFC, but it isn't pretty (lots of back and
> forth messages to indicate when the callback is finally set in the
> application to receive a event and do the event callback.)
>

> 3) Somewhat less important, can we ever deliver a DOM object, from gecko
> parent process to another child process, with an active interface attached
> (W3C has their NFC APIs do this), via a parameter list?
>

> 4) Is there any UX started for selecting a "default" one? I know
> WebActivities has one, but one may be needed for "targeted system messages"
> as well if implemented that way.
>

> ----------

>
>
> In every case, we would want to start the user intended app first, rather
> than blind fire events to every possible interested NFC, Couponing, or
> Payment application. We're still working out some UX details.
>
> For now, we want only to notify one application, though there's some talk
> still of expanding it to allow more than one to be a target, but not all
> apps.
>
>

> --------------------------------------------------------------

> Some further reading for a bit more background:

> --------------------------------------------------------------

>
> In the case of NFC (and Wallet Applications, for example), we want to send
> payment "received" transaction messages to a designated application (Some

> more information here: https://bugzilla.mozilla.org/show_bug.cgi?id=979767).

>
> For a few reasons, SystemMessages aren't sufficient:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1037380
>
> Thanks for any input (and questions)!
>
> -Garner

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Henry Chang]

Hi Jonas,

Regarding the first requirements you generalized:

1) Bring up an application picker which has similar UI to the current
WebActivities picker, but which has a different set of requirements
about which applications to list.

>From what I know, a picker is not permitted for their requirement.
(Need Garner to confirm) Besides, an activity seems to require to
originate from DOM (with a window) whereas the NFC root event is triggered
from gonk.

If we go for 'writing NFC specific code', we need to write NFC specific code
in Webapps.jsm to store manifest.webapp information just like what system
message does [1]. This is no good.

Bug 1037380 extends system message with a broadcast filter
which adds the capability of creating filters for specific messages.
NFC could simply fully customize the behavior in the filter,
including fetching package/manifest info, verifying the app, etc.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#680

[Garner Lee]

On Tue, Aug 5, 2014 at 3:30 AM, Henry Chang <hch...@mozilla.com> wrote:

> Hi Jonas,
>
> Regarding the first requirements you generalized:
>
> 1) Bring up an application picker which has similar UI to the current
> WebActivities picker, but which has a different set of requirements
> about which applications to list.
>
> From what I know, a picker is not permitted for their requirement.
> (Need Garner to confirm) Besides, an activity seems to require to
> originate from DOM (with a window) whereas the NFC root event is triggered
> from gonk.
>

1) That's correct for now. For NFC/SE Transaction notifications (Like
payments) specifically, current plans for Firefox OS v2.2 is not have a
visible picker so much as an approved/configured white list on the SIM
Card: (Cardlet Application ID) + (Webapp security certificate) routing
table.

As Jonas mentioned, a generic system level configuration UI might be work
if it is determined it makes sense: "secure" application picker along side
the web activity version. If not a system level picker, then we'd need to
add an app to the white list to configure itself/other apps.

UX wise, we probably need let the user distinguish between them somehow,
either visually, or by context. A user configures more secure apps
specifically, and only web activities can pop up a picker uninitiated
maybe?

Gonk:
I thought stuff on system/gonk was supposed to be able to send activities
as well once the event arrives, given a target window? I haven't tried to
confirm yet.

> If we go for 'writing NFC specific code', we need to write NFC specific
> code
> in Webapps.jsm to store manifest.webapp information just like what system
> message does [1]. This is no good.
>
> Bug 1037380 extends system message with a broadcast filter
> which adds the capability of creating filters for specific messages.
> NFC could simply fully customize the behavior in the filter,
> including fetching package/manifest info, verifying the app, etc.
>
> [1]
> http://dxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#680
>

> Eagerly waiting for it :)

Yes, I plan on looking at adding the new wrap interface soon-ish
(MozNFCTag, MozNFCPeer objects) to see how to pass the DOM object directly
without the current workarounds. Thanks Fabrice!