SysApps Face to Face - Shenzhen -- 11 Nov 2013

<richt__> <meeting starting with a round of introductions>

Agenda Bashing

<tomoyuki> +Present Tomoyuki_Shimizu

<richt__> anssik: Switch ServiceWorker topics the other way around?

<richt__> wonsuk: Need to discuss this with Alex. Has a TAG meeting this morning.

<richt__> wonsuk: Anssi, you could introduce ServiceWorker before App Lifecycle and Events and we'll go from there.

<richt__> wonsuk: We need to discuss some issues with Alex but later on.

<richt__> wonsuk: Any comments on other agenda items?

<Zakim> manu, you wanted to ask if we can introduce a brief 5 minute discussion about coordination w/ Web Payments group.

<richt__> manu: Want to ensure there is a good amount of collaboration between Web Payments and this group. Can we add that to the agenda?

<anssik> +1 to add Manu's proposed topic to the agenda

<richt__> wonsuk: Yes. Let's add that before the SE discussion?

<wonsuk> ?

<Zakim> richt, you wanted to demonstrate the queue

ServiceWorker

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0036.html

<richt__> <anssik introduces ServiceWorker>

<anssik> https://gist.github.com/slightlyoff/7fae65a908ac318f69a3

<gmandyam> +q

<richt__> richt: Any idea where this ServiceWorkers work will take place in W3C?

<richt__> anssik: We don't know yet and we need to coordinate with Alex on that.

<richt__> anssik: There's not really a spec yet.

<richt__> anssik: Seems like a good fit for WebApps? HTML?

<richt__> anssik: Extensions could be specified elsewhere e.g. this group.

<richt__> wonsuk: It's in scope for the WebApps WG.

<richt__> gmandyam: Is ServiceWorkers applicable to device APIs as well?

<richt__> anssik: I think it's a good fit for many device-related events.

<richt__> anssik: Could be good for e.g. alarms.

<richt__> kenneth_: It's on a case-by-case basis.

<richt__> kenneth_: Should look in to what Google did for Apps.

<richt__> gmandyam: In terms of Device APIs what can ServiceWorker provide that WebWorkers cannot provide today?

<richt__> anssik: Key thing is that ServiceWorkers can stay alive even if associated window is closed.

<richt__> anssik: We should ask Alex for full details on that.

<richt__> gmandyam: So it's a persistent background worker?

<richt__> anssik: Yes. e.g. Gmail client. Close the tab. You can be notified and brought back to Gmail.

<richt__> anssik: Not the same but have additional capabilities

<richt__> kenneth_: Events can restart the worker.

<richt__> anssik: This is behind a feature flag in Chromium. Nothing production quality at this point but you can check it out.

<richt__> anssik: Also experimental implementation happening in FF.

<anssik> chrome://flags/#enable-service-worker

<richt__> anssik: Building on experimental foundations. Share richt's concern here.

<richt__> anssik: But there is also some momentum and relatively confident this will end up shipping in all major browsers.

<richt__> gmandyam: When we implemented Persistent Workers we ended up putting up a UI so the user could see what was active, close things down, etc...

<richt__> gmandyam: ...Are you seeing any special types of permissions needed relating to ServiceWorkers.

<anssik> re ServiceWorker impl status: http://code.google.com/p/chromium/issues/detail?id=285976

<richt__> anssik: Good questions gmandyam. That's something that needs to be fixed on the platform.

<richt__> anssik: Permissioning is broken on the web and now we are opening up more powerful capable APIs. In the context of SysApps this permissioning model is yet to be decided.

<richt__> mounir_: We should not try to define APIs on when and how the permission will be set. e.g. FFOS - no permission up-front. If you mandate that type of model then they cannot implement it.

<jungkees_> Hi SysApps, i'm in WebApps now doing agenda bashing and i mentioned SysApps invites Alex this afternoon to get introduction about ServerWorker

<kenneth_> One way to make installable apps is reusing the service worker infra. Like on a webpage you could click on an install link which would basically make the service worker cache the whole app. Now that could be done with upfront permission granding, that would reask when an update requires further permissions

<richt__> anssik: So you're saying we should be agnostic on how and when permissioning works?

<jungkees_> And WebApps is sort of interested in talking about ServiceWorker together if time permits

<richt__> mounir_: Yes. The details will need to be thought out a bit more. Dev feedback - devs want to know when permission prompting is going to happen.

<jungkees_> 15:00 - 15:30 seems to be the prospective time slot WebApps can use

<richt__> mounir_: Maybe the API should be generic. Agnostic to user permission model.

<richt__> anssik: there's been some pushback on e.g. the Web Notifications permission opt-in model.

<richt__> gmandyam: You have X number of processes taking up resources in the background. An up-front permission model or permissions API is probably not going to work for that.

<richt__> Anders: sometimes you would like to disable certain permissions when you 'install'. Is that in scope here.

<richt__> anssik: I think it's an important point. If something is not available it would be good if we could gracefully degrade.

<richt__> anssik: Would like to see that built in to the platform.

<richt__> mounir_: If all APIs do not have permission up-front or whether they are all approved up-front should be an implementation detail.

<richt__> mounir_: If you want to give an option for the user to revoke access at a later point then the API should be ready for that / designed to handle that e.g. revocation.

<richt__> anssik: I agree.

Application Lifecycle and Events

<anssik> http://www.w3.org/2012/sysapps/app-lifecycle/

<gmandyam> Clarification: If there are webpages (X1, X2, ...} with associated number of service workers {Y1, Y2, ...}, then the number of service workers running could be Y1 * Y2 * ... The user may need to actively manage (i.e. shut down specific workers) when running on an e.g. FF OS device.

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0014.html

<richt__> anssik: The major change is that we use ServiceWorker as the base.

<richt__> anssik: There's also hooks in to the Task Scheduler proposal.

<richt__> anssik: We would like a normative dependency to ServiceWorker. Need to talk to Alex about that.

<richt__> anssik: currently 4 open issues.

<richt__> anssik: 1. Remove features without strong use cases.

<richt__> Open issues on App Lifecycle and Events available in email link above

<richt__> anssik: Would be good to have some discussion now on Lifecycle Events.

<richt__> anssik: Do we have consensus on the lifecycle events we want to expose?

<richt__> mounir_: still believe we can get rid of anything non-essential here.

<richt__> anssik: So what do people want to see the lifecycle events look like?

<richt__> mounir_: Probably implementor specific. Probably good to see what people do and standardize from there.

<richt__> anssik: In ServiceWorker you have 'on install time' events.

<richt__> anssik: When it's upgraded other events are provided. So only after install and after upgrade events in ServiceWorkers.

<richt__> mounir_: Agree with that approach.

<richt__> kenneth_: Another idea, if you don't get the permission up-front then you could get it when it wakes up?

<richt__> anssik: Interesting. e.g. Web Notifications are not time-sensitive. We could allow some delay in that permission opt-in.

<richt__> anssik: So it could try again at a later time perhaps.

<richt__> anssik: Agree with mounir_. Let's see what gets implemented and then tighten up from there.

<richt__> anssik: Another issue, the ServiceWorker could be killed at any time. Should we let the app know that is happening?

<richt__> gmandyam: if termination is resulting from an end-user action then it may not be desirable to allow it to persist until permission is obtained to kill it.

<richt__> gmandyam: There are likely valid reasons for end users to kill e.g. ServiceWorkers.

<anssik> chrome://inspect/

<richt__> anssik: There are a number of tools available in e.g. Chromium.

<richt__> gmandyam: There's a difference between a browser and an app installed in an OS.

<richt__> anssik: There was some work around Web Activities/Intents but not sure what's happening there.

<mounir_> ack

<Zakim> mounir_, you wanted to ask for UC for terminate event

<richt__> mounir_: One of the main issues with App Lifecycle and Events would seem to be on cleaning up

<gmandyam> Summary: The current def.'n for App LifeCycle events seems to sandbox the Service Worker to only rcv. events related to the app that created it. I asked Anssi if the intention is that this model could be extended to listen to other app's lifecycle events. He said no - this would have to be handled through inter-app messaging.

<richt__> mounir_: Sometimes the app could die before the system tells it it is dead.

<richt__> mounir_: therefore it may not be a good idea to add such clean up events.

<richt__> anssik: I agree with mounir_.

<wonsuk1> +1 for Mounir

<mounir_> mounir_ sometimes apps will not have enough time to save things between the terminate event and the app being actually killed

<richt__> anssik: Let's simplify and have a single event called 'launch' or something.

<richt__> anssik: Next issue, looking for a mechanism to pass data from the application that launch it.

<richt__> anssik: WeB Intents/Activities was promising for this.

<richt__> mounir_: Web Intents stopped due to UI issues.

<richt__> mounir_: Web activities and web intents were for different devices. They were designed with different UIs in mind.

<richt__> mounir_: unclear whether e.g. Web Activities works well on Desktop.

<richt__> mounir_: Google closed Web Intents because the UI was not working well there (on Desktop).

<richt__> mounir_: assuming we have web intents/activities at some point. The hook would be on the launch event. Data can be passed on events.

<richt__> mounir_: this is probably not a big issue for the work we're doing here.

<mounir_> mounir_: the hook would be on the launch event or on a specific event but anyway, the data will very likely end up in the event object

<richt__> anssik: issue 4 in my email (linked above) will likely be resolved at the ServiceWorkers level.

<richt__> anssik: Let's summarize the open issues now.

<richt__> anssik: issue 1: drop terminate/cancelled events.

<richt__> anssik: issue 2: get rid of reasons.

<richt__> anssik: issue 3: let's create LaunchEvent and later we can pass data to that implicitly.

<richt__> anssik: let's close issue 3 down.

<richt__> anssik: issue 4: defer to ServiceWorker spec.

App Lifecycle and Events - Next steps

<richt__> mounir_: let's take a break?

<richt__> <break time. meeting resumes at 11:10>

<dsr> scribenick: dsr

Mounir: we will move as a group to Shenzhen Hall at 3pm for a short discussion with webapps on service workers.

Next steps for App Life Cycle

Next steps:

- Continue track ServiceWorker, align Application Events with the model

- Flesh out System Event delivery and registration (and/or defer to the ServiceWorker proper?)

<anssik> e.services = ["fetch"];

Anssi: may want to do registration in the manifest

- Permission control, need a consistent model that works for ServiceWorkers

Following discussion before the break, we may want to give implementations some freedom in his permission requests are handled (when apps are installed, or later at time of use)

Wonsuk: we tried to set a joint meeting with WebApps about manifest, but it was cancelled.
... some discussion via email, e.g. on use of meta tag, but no consensus as yet.

Anssi: we continue with the App Life Cycle, simplifying it and aligning it with the Service Worker spec as that evolves.

Kaz: interested in possible relationship to W3C work on multimodal interaction architecture model

<kaz> MMI Architecture

Kaz: I've invited Anssi to join the MMI meeting this week.

<kaz> mmi f2f schedule

Anssi: Kaz can you please introduce the MMI WG?

Kaz: MMI Architecture is actually quite simple and defines life cycle events for loosely coupled multimodal applications

Anssi: what are the main use cases for that?

Kaz presents the MMI architecture spec http://www.w3.org/TR/mmi-arch/

The MMI WG will hold an introductory session on the MMI Arch this Thursday morning and you are all welcome if you're interested.

Mounir: does anyone have questions on service workers and relation to SysApps at this time?

Anssi: asks Rich about Opera's interest in this topic

Rich: we've moved the opera browser over to Chromium, and want to add some opera specific APIs on top of Chrome.
... We've looked at extending the Chrome CRX extension APIs
... We looked at what is being done for Firefox as well as Chrome and think there is value in standards around the manifest format.
... There are lots of different views, but it is interesting to see what level of consensus can be reached around the manifest and SysApps APIs

Anssi: manifest and app packaging?

Rich: we're starting from Chrome CRX but want to move towards a standards based solution

Mounir: I was speaking with some Mozilla guys. Moving the manifest format spec to WebApps, but slow progress.

Rich: meta headers ...

Mounir: the full requirements for apps is too large to standardize all at once

Rich: we're currently considering adding hosted apps to the device's home screen, and meta headers are effective for that

Anssi: it is likely that both meta headers and manifest will need to be supported to handle legacy and future

Mounir: meta headers are not that efficient and don't scale as requirements grow

<anssik> +1 on Mounir

Rich: I can agree with that sentiment, but let's focus on simple requirements as a starting point, i.e adding apps to home screen

Mounir: let's say you want to a link to facebook, but we need to worry about refresh

Wonsuk: manifest looks like a better long term solution

<mounir_> mounir_: in that case, you might want to have a property to define the bits of UI your website wants to use even if "bookmarked"

Anssi: Rich you seem to be describing an install API which includes a reference to the manifest.

Rich: install can pull data from the page or manifest ...
... does WebApps have manifest on their agenda this week?

Mounir: no

If you guys want to continue to discuss manifest here and now, we have time

Kenneth: there is no standard around how to use the meta tag content

Mounir: concerned that if we follow the meta tag route we risk a repeat of the problem's seen with app cache

Rich: even a simple meta tag to indicate that this is a web app is complicated as seen by the differences in current implementations

<mounir_> mounir_: (concerned because trying to specify a too simple solution because it is easy to implement and ship might prove itself limited later)

<kenneth_> kenneth_, the problem with meta tags is that the page has to be refeched with extensions disabled to make sure that extensions etc didn't modify the dom (ie. add extra permissions etc)

Rich: apps can update the meta tag up to the point that the user adds the app to the home screen
... we can take a snapshot at install time

<JonathanJ> web manifest - http://www.w3.org/2008/webapps/manifest/

Anssi describes risks around attacks that confuse user into installing a malicious app

Mounir: solution is to use CSP (content security policy) forbidding this

Rich: CSP gives us the control we need

Anssi: I would like to revisit app packaging formats.

Mounir: are developers willing to change their implementation around packaging? If not we are wasting our time discussing packaging.

Anssi: we are focusing on API interoperabiity, but not around packaging right now

Kenneth: but what about the future?

Anssi: can this working group resolve that we aren't working on interop around packaging?

Mounir: packaging is not out of scope, but also it is not a priority

Anssi: zipping is easy, but signing is hard

Anssi invites Anders as an expert on signing to state his view

Anders: best to adopt existing solution where possible

Rich: unfortunately, different vendors handle signing differently, so the ship has sailed on that

Mounir: if we use the same APIs that developers only have to deal with packaging for each app store

Anssi: on the list we raised whether the existing SysApps charter reflects the current reality? Should we revise the charter, or should we update the home page to clarify the group's priorities for people coming from the outside

<virginie> +1 on anssi proposal to clarify priority and deliverables scope

Mounir: we need to establish a consensus before any consideration of changing the charter

Giri: rechartering would help to set clear expectations on priorities

Rich: we need to foster APIs with strong implementation support

<richt> richt: how do we get people excited about the _idea_ of implementing standard APIs across runtimes?

Anssi: SysApps focuses on privileged APIs
... we need an environment to expose such APIs safely

Rich: executing the same code base in different environments should be our objective

Virginie: I would support work on clarifying this group's expectations. A Working Group Note would be valuable

<richt> re: 'executing the same code base in different environments'. That's why the web itself is so successful. Everyone is standardizing APIs because the same code base runs everywhere. That's not the case yet in SysApps.

Virginie: we would like to help, but need others to join in

Mounir: it seems like the consensus has shifted on privileged vs web APIs, e.g. focus on service worker. Interested in changing charter to allow us to work on web apis as well as privileged environments.

Rich: good that SysApps is working on privileged APIs

<Kenneth> Kenneth, we have raw sockets implemented in our new runtime (privileged)

Giri: there are some things like dialer that you want to avoid every tom, dick and harry re-implementing.

SysApps goals and rechartering

Dave: we have further time on this topic tomorrow afternoon. We need a short but clear statement of a consensus on the group's goals

<gmandyam> Summary of what I was trying to say: the current charter has lumped very different types of deliverables into Phase 1 which has bogged down the group. For instance, telephony has proven difficult and is probably not an API that should be exposed to arbitrary 3rd-party developers.

Rich: agreement on the execution environment is hard but a higher priority that say the contacts API

<mounir_> mounir_: to follow-up on Giri's comment, I would be happy to see Messaging, Telephony and maybe Contacts being de-prioritezed

<gmandyam> Summary (cont.): Raw Sockets would be required for 3rd-party developers to provide them equivalent capability to what they have in native programming environments.

Mounir: we should get a consensus on goals before discussing specific APIs

<gmandyam> Summary (cont.): Yet Raw Sockets and Telephony are both considered high-priority API's in the current charter.

Anssi: we may not need to recharter, but we certainly need a document setting out the priorities, perhaps just updating the home page and wiki

Mounir: we can continue this discussion tomorrow afternoon including the charter.
... We will now break for lunch at resume at 2pm, and then walk over to WebApps at 3pm.

<genelian> wonsuk, could you please put the link on the Agenda for DataStore API?

<mounir_> Scribe: mounir_

<scribe> ScribeNick: mounir_

<efullea> Hi, I am having troubles to dial in. It says the conference is restricted. I see you are not bein gable either

DataStore API overview

<wonsuk> DataStore API: https://wiki.mozilla.org/WebAPI/DataStore

genelian: I will give you an overview of the DataStore API but we did not write a full spec yet
... <points to DataStore API link>
... the goal of the API is to improve syncing and searching given the issues we had it Contacts and Messaging
... it was very hard to define a Messaging API that would fulfil all the requirements of a Messaging app, for example, having group of messages
... the solution was to have a very simple Messaging API (send/receive) and there would be a central DataStore that would be used sync'd with
... so the application could do its own filtering based on its own UI requirements

<efullea> * Hi Dave, the instructions in the wiki states you should type: zakim, call Wutong_West have you tried that? I am still not able to join...

<Yudong> JINGWANG-QI: hi

genelian: <describing how DataStore have a common name to be able to merge DataStores>
... <describing how the sync() call synchronize the DataStore>
... the change event will be fired when the datastore is updated
... we are hoping to replace the our existing Messaging API and Contacts API to use this DataStore API
... we will put our design and ideas in a git repository so anyone can contribute to that

<efullea> * ok dsr, I will wait until you solve the issue. thanks

genelian: before switching the Messaging API to use DataStore, we might need to fix a few pending issues
... Zoltan and Marcos seem to be interested to have a separated interface that would be specialized for the searching and filtering
... that way, the DataStore API will not only help synchronize data but also help the app adds some semantic by having some indexes for example
... like the phone number of a message or the delivery time
... that is pretty much it

ack

mounir_: I was wondering if you have any feedback regarding performances

genelian: we have this implementation but we do not use it yet
... the next step is to use it to maintain the conversations for our messaging application
... but you are right that performances are going to be a very big issue

<efullea> Hi mounir I am interested in the overall discussion but I have no feedback on performance

genelian: the app will get an event every time there is a change which might require the app to change its index and make it slower than the current system

<efullea> * very low

Contacts API

efullea: there is no major issues open
... so, unless there are new issues opened, we should go to LC

wonsuk: what about DataStore in Contacts API?

efullea: we are doing some experimentations but it is too early to say

<gmandyam> Summary of my comment: Data Store API is a two-step op for synchronization: (1) Invoke DataChangeEvent handler, and (2) Call sync(). The developer gets the benefit of a more flexible data model w/Data Store for Contacts/Messaging, but at the expense of managing synchronization with the local store.

mounir_: so, to summarize, there no outstanding issues except DataStore to go to LC?
... I propose that efullea takes an action which is check whether DataStore API is okay for the Contacts API and we should also make sure there is still some group interest in this API given that there was no activity in the past month
... after that, we could see whether the specification should go to LC as is

<efullea> o

<efullea> ok

<scribe> ACTION: Eduardo will check whether DataStore matches Contacts API needs [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action01]

<scribe> ACTION: Mounir will check whether there is still group interest for the Contacts API [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action02]

Messaging API

efullea: the problem with messaging is similar to Contacts API with regard to DataStore
... I don't know of any implementation of Messaging using DataStore, maybe someone in the room is experimenting that?
...
... <reading the issues listed in the email he sent to the group, listing the changes since the last F2F>
... so, unless we move to DataStore, we can go to LC very shortly

<Zakim> mounir_, you wanted to ask if Mozilla is experimenting that in FxOS

mounir_: I was wondering if Mozilla is experimenting Messaging with DataStore

genelian: we do not for the moment, it is complex and it will take a couple of months so it might unlikely happen before the next F2F
... all we are discussing now is actually mostly theoretical

mounir_: do you want to go to LC without DataStore?

efullea: yes

mounir_: I feel that going to LC without DataStore might be counter-productive if we do use DataStore

anssik: can we push out LC1 and then push out LC2 after some major changes?

mounir_: I propose to have as a resolution to not move Messaging API before we have as stronger opinion regarding the DataStore API

anssik: I agree, this specification do not look stable to me

efullea: it sounds like blocking the specification for a few months, I do not know if we should do that but I am fine either way

anssik: going to last call is an expensive step because we ask to other groups to review your work and people might end up using their time reviewing this API knowing that we might go to a totally different path in a few months

mounir_: I propose to put an action on efullea to lead the discussion regarding whether the DataStore API should be used for messaging

<efullea> ok

<scribe> ACTION: Eduardo will lead the discussion to see whether the DataStore API should be used for Messaging [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action03]

RESOLUTION: Messaging API will not go to LC until the DataStore situation is stable

mounir_: we have a few minutes to wrap up and go to the other room for the joint meeting with WebApps
... we will be back there after the Service Worker discussion, I do not know when

<dsr> We are about to resume after a coffee break following the joint session on service workers with WebApps.

<scribe> Scribe: mounir_

<scribe> ScribeNick: mounir_

Telephony API

<zolkis> https://rawgithub.com/sysapps/telephony/gh-pages/index2.html

zolkis: the current spec is here: https://rawgithub.com/sysapps/telephony/gh-pages/index2.html
... there have been a few changes, that is why it is index2.html so people can compare to the previous document
... <summarizing the list of changes from the email to the list>

<zolkis> short summary on the Telephony spec

<zolkis> TelephonyManager now implements a series of interfaces:

<zolkis> services related, call management, tone management, emergency numbers, command parser

<zolkis> ServiceManager can also implement CallManager and EmergencyManager

<zolkis> in this spec navigator.telephony implements them and it is the main entry point

<zolkis> the service + command parsing support was added because issues raised asking for support

<zolkis> also, client side call merge is supported

<zolkis> which made the API very suitable also for supporting VoIP calls

<zolkis> this is the summary

<zolkis> questions?

dsr: how many of the companies here want to implement this?

<zolkis> Intel will do it for 2 telephony backends and 2 platforms

<zolkis> Mozilla implementation is close to the spec, but would require some work, to support the current split of functionality in interfaces

<zolkis> on Android and Crosswalk

hsinyi: this is close to what Mozilla does but the structure is different so it is not clear whether we have the ressources

mounir_: Google is not going to implement that anytime soon as far as I know

<zolkis> can't hear, I rely only on the chat transcript

gmandyam: it would be interesting to know if the spec is stable enough so I could get feedback internally

mounir_: it would be interesting to get some feedback from Qualcom indeed

<zolkis> yes, it is now - I will add support for constructing the events where it is missing

<zolkis> but I will do it today, and it is a small change

<wonsuk> How many outstanding issues are there in Telephony API spec?

<gmandyam> OK - will get a review from our internal telephony team.

<zolkis> I will close them one by one as this current proposal gets reviewed: most of the issues should be solved by now

<zolkis> they are not recorded to be solved, but I will make a swee[p

<zolkis> right now there are 31 open issues

<scribe> ACTION: gmandyam will send the specification internally to get some feedback from Qualcom telephony team [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action04]

<zolkis> thanks gmandyam! that would be helpful

mounir_: what's the next step for the specification?

<zolkis> clean up the open issues, get feedback from Qualcomm

<gmandyam> Zoltan, is CellularService going to be spec'ed or not? - Giri

<zolkis> right now that is a note that it could be spec'd - but should it be done in this document, or in a separate one?

mounir_: we will need Mozilla implementation (or another one) before going to LC

annsik: but it is not required until CR, right?

mounir_: indeed but it is a good practice to get two implementations to go to LC

gmandyam: given that this is quite linked to the modem, having two multiple implementations is even more important than usual

<zolkis> gmandyam, specifying all cellular interfaces is a huge work; it can be done, but we need to justify the effort; right now what we know is how to do it when it comes to it

<zolkis> the modems are abstracted by TelephonyService

<zolkis> mounir_: is having two implementations from the same company good enough?

<wonsuk> It would be great if Mozilla also review and give feedbacks about current Telephony spec.

zolkis: the implementatios have to be independent I believe

<zolkis> yes, but they are done by different teams

<gmandyam> To clarify:Is the "Two Implementation" rule of thumb that normally is used in W3C really applicable to telephony API? Should it be two implementations involving different modems? Or is two web runtime implementations using the same modem sufficient?

<zolkis> if you define independent by company, then we need someone else, too

<zolkis> yes, still questions

<gmandyam> Zoltan, Is Tizen implementation going to be verified with Intel modem?

<zolkis> I think we should support at least 2 different modems

<zolkis> and also, 2 different telephony middleware + os

dsr: I think that the w3c director is looking for entirely independent implementations so in this case, we might want different modems

mounir_: zolkis, anything else?

<zolkis> I agree

<zolkis> let's continue by emails and by discussing issues

<zolkis> https://github.com/sysapps/telephony/issues?state=open

mounir_: sounds good, let's move to the next topic, if we can reach Marcos

<MichaelH> Q: CamelCase for oncalladded, callremoved, activechanged?

<zolkis> not for events

<anssik> +1 to move app URI to LC

<gmandyam> See http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0042.html. RichT had asked about whether app:URI can be more broadly applied.

<gmandyam> My comment: I think it could be used for broader purposes without affecting its current functionality by relaxing the requirements in Sec. 6.4

<richt> Here's a follow up use cases for adding additional app:// URI dereferencing models without affecting 'package' dereferencing currently defined: http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0053.html

<scribe> ACTION: Mounir will reach out internally at Google to get some feedback regarding the specification [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action05]

MichaelH: I had a question about app lifecycle regarding the cancel event, I am not sure what is that for

anssik: it was actually dropped

<dsr> we close for the day

<Github> [13telephony] 15zolkis opened pull request #211: added constructors to events for testability (06gh-pages...06gh-pages) 02http://git.io/ku7dCQ

<Github> [13telephony] 15zolkis closed pull request #211: added constructors to events for testability (06gh-pages...06gh-pages) 02http://git.io/ku7dCQ

<Github> 01[13telephony01] 15zolkis pushed 2 new commits to 06gh-pages: 02http://git.io/UEuRuw

<Github> 13telephony/06gh-pages 14b7f5453 15Zoltan Kis: added constructors to events for testability

<Github> 13telephony/06gh-pages 1490fc613 15Zoltan Kis: Merge pull request #211 from zolkis/gh-pages...

<cdumez> Hi, I am on the line

<dsr> agenda: http://www.w3.org/wiki/System_Applications:_3rd_F2F_Meeting_Agenda_TPAC

<dsr> chair: Mounir

<dsr> scribe: Mounir

mounir_: <greetings>
... we will start with the Task Scheduler API and because Christophe is on the phone, we will mostly use IRC
... so please, make sure to join the sysapps channel

Task Scheduler

mounir_: we are going to start with a status update from Christophe

<cdumez> This is me on the phone but I barely hear anything

<cdumez> so I can use IRC if this is OK

<jungkees> Yes!!

<cdumez> Task Scheduler API draft URL: http://www.w3.org/2012/sysapps/web-alarms/

cdumez: since the last F2F, I made three changes to the specification
... the first one is removing the timezone support from the API, it simplifies the API quite a bit

<cdumez> * http://www.w3.org/2012/sysapps/web-alarms/#taskscheduler

cdumez: especially the add() method

<cdumez> * http://www.w3.org/TR/WebIDL/#common-DOMTimeStamp

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0012.html

cdumez: the API is no longer using Date but DOM timestamp, defined in WebIDL

<cdumez> Date.now() + DELAY_IN_MS

cdumez: the second change is that we no longer throw an exception if the schedule is in the past
... instead, the new behaviour is to fire the task as soon as possible asynchronously
... otherwise, there have been some discussions recently on the mailing list, mostly about adding support for priority about scheduling an alarm
... whether the time has to be exact or can be delayed
... I propose something in the mailing list and I am waiting for feedback on this one
... This is is regarding the status of the API

mounir_: any question or comment?

dsr: the usual question: who is implementing the specification?

<anssik> +q

kenneth: because of the unknown relationship with the service worker, we can't implement that spec yet

anssik: +1

mounir_: I was going to ask Christophe about that actually

annsik: functionaly-wise I feel that it could happen in service worker

anssik: cdumez, any comment?

<cdumez> I am not familiar with service workers yet, sorry

<cdumez> Right now the API relies on system messages from Runtime specification

<anssik> https://gist.github.com/slightlyoff/7fae65a908ac318f69a3

<cdumez> But last I heard, system messages would get replaces by sometimes else more chrome-extension like

mounir_: regarding implementation status, there might be some interest at Google to implement that but if that happen, it would be on top of Service Worker I believe

anssik: I pasted a link that has a draft about using alarms on top of service worker
... I would like to know if chris wants to keep that has standalone or want to build it on top of service worker?

mounir_: while waiting for Chris to reply, what about Mozilla implementation status?

genelian: we have an implementation but we use System Messages for the moment

thinker: my concern is the removal of timezone,
... there are issues with device time and local time
... <explaining issues with not having timezone parameter>

mounir_: will you switch to Service Worker if we happen to change the spec?

genelian: it should be realisable

<Zakim> anssik, you wanted to ask if the Moz impl is still moz-prefixed

anssik: is the implementation prefixed?

<Zakim> mounir_, you wanted to ask about the relation with the spec and Service Worker

<anssik> navigator.mozAlarms

anssik: if the implementation is still prefixed, it should not be a problem to switch?

mounir_: I believe it is prefixed

genelian: yes, it is prefixed

<scribe> ACTION: cdumez will write a new Task Scheduler specification based on Service Worker [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action06]

<cdumez> Oh was that agreed? :)

<cdumez> Was service worker merged into the runtime specification?

<cdumez> I mean that the task scheduler API is using what is defined in the runtime specification currently.

no, we will build the app lifecycle on top of it

the runtime specification is going to be shelved

with some definition of shelved

<cdumez> Ok, well, if the group agrees, fine by me

<anssik> re http://www.w3.org/2012/sysapps/runtime/ status: "The System Applications Working Group is currently not progressing the approach outlined in this draft. Please treat this document with caution and do not reference it or use it as the basis for implementation. The domain covered by this document is still within the scope of the Working Group as defined in

<anssik> its Charter."

<renoirb> Hi everybody!

Web Payments

manu: the work that we are doing in the Web Payments group is build payments in the core architecture of the Web
... if you go to a website, you should easily be able to build a product that you want using APIs
... As you can expect, when you are talking about Payments, identity and security is important
... that is why the work of SysApps is important to us
... for example, being able to access a Secure Element is important regarding security
... My goal here is to give a heads up to let every one know that we have a Web Payment group
... How many people here believe that the web payments work is being to affect there organization?
... would you be interested to join the Web Payments group given your organization progress in web payments?
... We have a breakout session on Wednesday
... the second question is how to integrate the Web Payments work with SysApps?

anssik: so you guys don't have any concrete proposal at this time?

manu: actually, we have a set of specs (8)
... we don't need sysapps work for the moment but we might need secure element at some point

anssik: could you briefly summarize the implementations?

manu: we have nothing implementing in major browsers
... because we don't want to get blocked
... it is mostly working around de-centralized approach like Mozilla Persona
... we are also working with the IETF
... (like HTTP Signature spec)
... <explain some use cases>
... we have Mozilla, Bloomberg, small security companies
... financial institutes are also interested
... because Web Payment would allow touching the 2.5 billions people that do not have a bank account

ack

<Zakim> mounir_, you wanted to ask more details about the implementations status (who is expected to implement? and who implements? basically, is it interoperable?)

manu: Mozilla Persona is not a requirement but we are looking for a nice identity solution and Persona is a nice one, that is why we use that
... the idea is not to take what Mozilla has currently and stamp it as a standard and go one
... we had a lot of discussions with Mozilla teams on this
... what I am saying is that it would be ideal if Mozilla Persona continues in the trajectory it is on
... if Persona work fails, they are going to need an identity solution and we have a backup spec if that becomes necessary
... so that is kind of where we are with Mozilla on this
... as far as who is required to implement this, there are a couple of answers for that
... one set of implementers would be the banks
... we have been speaking with banks standard body (SWIFT)
... they want something that is Paypal/Google Wallet that is open so any bank can use it
... the other group that is interested in this work are the large technology companies that could compete with the banks if they implement the solutions
... cellphone providers and operators are in a third basket
... if you have a mobile phone, it is very easy to associate it with a credit card or a bank account of some kind
... and the fourth group of implementers,
... are implementers of the identity solutions like governments so banks can digitally verify identity of their customers

<Zakim> anssik, you wanted to ask if NFC is in scope

manu: NFC is optional, there are many things that we could add to this work
... we would love to use NFC but it is not a requirement yet
... no one is really screaming NFC yet in the group

Fan: two questions: does web payments have other solutions if Secure Element do not take off?
... <not understood>
... are you considering the security issues regarding running JS code?

manu: the secure element seems to be our best best right now
... an alternative might be to use the Web Crypto API
... both those solutions would be related to client base digitil signature
... all those stuff would happen in the cloud
... we do not require those mechanisms for the moment but we would like to make this happen
... regarding running JS alongside the API we are running
... yes, we looked into it but we do not think it was good enough
... and we would have to do many security passes
... right now, there is no client side code
... any of the standard security issues we have (click jacking, ...) exist for Web Payments
... for the moment there is no API running on the client so there is no attack surface yet
... hopefully that answers your second question
... I will drop two links on IRC: a Mozilla Hacks blog post and a link to join the group

<anssik> manu: now a CG, planning to create a WG, to have a workshop in ~March 2014

mounir_: we will do Secure Element and then finish the morning sessions early

<Anders> manu: https://payswarm.com/intro <--- introduction to PaySwarm

Secure Element

<Anders> manu: https://payswarm.com/join <-- instructions on joining Web Payments group

dsuwirya: <greetings>

<Anders> manu: if you want to contact me directly - msporny at digitalbazaar.com

dsuwirya: <presenting the specification>
... the intention this morning is to judge the interest of the group for the Secure Element

<MichaelH> Secure Element API:http://opoto.github.io/secure-element/

<wonsuk> Secure Element API: http://opoto.github.io/secure-element/

dsuwirya: the secure element is a micro controller with RAM, ROM, etc.
... it offers hardware and software protections against the attacks
... it usually have a JVM running so we can run different applications
... the purpose of the interface is to provide an interface for web applications to talk to the applications running in the SE
... the SE is complying to ISO7816-4
... there are many form factors
... most commonly on a credit size card
... <showing his card>
... this one can be contact or contact-less
... the second form factor is the one we have on Mobile, we call it ICC
... it is mostly called a SIM
... but it is actually the application responsible for the network access but it is only on part of the SE
... finally, some SD cards have a SE inside, even some have NFC supports
... it could also be a USB tocken or a passport
... when we are talking about applications for the SE, we are talking about two parts:
... on card applications and off card applications, they run respectively inside and outside the SE

<virginie> s/ICC UUICC

dsuwirya: about UC
... the first common UC is about strong authentification
... for email signature, encryption, etc.
... a second common UC is digital signature
... the strong point of the SE is that the key and the signature computation will happen inside the card
... which prevents extracting the key and ensure the integrity of the process
... the third UC is about payment
... for card present transactions
... the last UC is credential provisionning
... to top up credit remotely on your card for example
... that is for the most common UCs
... the next section about the relationship with the other W3C APIs
... to underline that there is no overlap
... regarding security and privacy, the problem is similar to the rest of API we are going to discuss with SysApps
... there are the same problems as in bluetooth api
... in order to insure integrity and security, we can use the trusted execution environment
... or we can also use an already existing secure messaging
... protocol
... We can also use the trusted environment here to help secure the interface
... in a desktop environment, we can use hardware feedback - to enter the PIN
... Usually, we are limiting the access to the secure element to only trusted applications
... The secure element will have a list of trusted applications that the OS will provide before the SE talks to an application
... The last point is traceablitiy
... the last point is describing the relationship between actors around the Secure Element
... to use SE, we need a reader, there can be one or more reader per device
... for example, NFC, sim slot, sd card slot are all readers
... The next entities is the container of applications that can run multiple apps at the same time
... if you look at the flow of the diagram there, the idea is to first get the SecureElementManager
... then, the manager will provide the methods to enumerate the readers
... from there, we can establish a session with the SE and a channel with the application you want to talk to
... This is the interface that we wrote to represent those entities
... <describes the interface>
... <showing a snippet of code from the specification>
... any question before we go to the demos?

thinker: with this API, we send low levels commands to the SE
... with this API we do not know which features are available in the SE
... which means that if you give access to the SE element to an application, it will have access to everything

dsuwirya: the level you are talking about is at the service level
... defining interfaces at the service level is not sufficient

thinker: my question is that wants we get a certificate, we want the application to use that certificate to do something specific but we can't control what the application is doing
... with this API, we can not do this kind of control

MichaelH: I think that the issue here is a protocol communication channel
... you would have to implement that yourself in a client/server architecture

Mohammed: when you get the authorisation to access a feature for your application, it is only available for this session

thinker: you mean that you use different channels for different features?

Mohammed: you have to reopen a new signature for new application

thinker: <repeating the question>

Fan: would the secure element be in televisions?
... <scribe did not understood the second question>

Mohammed: we have that already

Fan: is it using micro-sd?

Mohammed: no, chipset cards, to get content from service providers

Fan: maybe not all tv will have a slot

MichaelH: the form factor is not really involved in the specification

Fan: <scribe still not understood>

dsuwirya: TEE is out of scope of this API

rsleevi: I am concerned with this on a security and performance side
... this API is the scariest I have ever seen
... <concers about the sync aspect of the APIs>
... and this api gives access to everything or nothing
... I disagree that the PIN is enough to solve this problem
... I think the performances implication of insertion and removal events is scary
... this is not future-compatible
... I would like to see a way to restrict the API to specific applications

Mohammed: we never had performance issues so far
... and we have malware checks for security
... and did had any issues with that

<Zakim> dsr, you wanted to ask about installing new applications on the card, e.g. when installing a new payment solution provider

<m4nu> +1 to what rsleevi just said - very concerning.

Mohammed: today, there is no standard on this

<m4nu> Manu: +1 to what Ryan Sleevi said, the API needs some work wrt Promises and has some security concerns that the Web Payments group will have more input on in the future.

dsr: [...] that was the first question, the second question was about the PIN, did you consider alternatives?

MichaelH: it does not really matter what is being used, it just needs to be some bytes that matches what the card knows
... it could be one digit, two, a thounsand

dsuwirya: <doing demo>

<dsr> I was asking about alternative means to support user presence authentication such as finger print scanners, and the implications for SysApps.

<dsr> Some kind of trusted computing environment is needed to secure the user presence info.

Mohammed: <showing a video>

dsuwirya: to add a little bit about payments, there is a nation-wide payment system that will be available this year in the US to pay by tapping (card present payment authorisation)

RESOLUTION: there are some concerns about security and performance regarding Secure Element - this should be worked on, such as the implementation intent

<Claes> Yes, the passcode is not accepted

<dsr> zakim is there room for 6 at 06:10Z for 240

<Claes> Yes, sorry. Unfortunately I don't have Skype installed on my job computer now. I can fix that now but it will take some minutes or so I assume.

<Claes> Yes, move on. I'll come back

Discussion on App Model for the Open Web in SysApps WG aspect

anssik: let see what I wrote

http://lists.w3.org/Archives/Public/public-sysapps/2013Oct/0010.html

anssik: the first assertion is this thread was that it might be hard to find consensus with sign apps
... and even if we do, it wight not be interoperable
... so, what are we doing with un-signed app then?
... we want to bring more clarity about the deliverables from this group?

richt: how is this different from what we discussed yesterday?

anssik: it's quite the same

richt: I agree that the ship is sailed
... and that the packaging format is different
... as I said yesterday, the focus of the group should be running the same code base
... that's what I would like the objective to be

anssik: I would like to wake Jonas
... what do you think?

sicking: it appears to be that we are not in a position where we actually can get implementations to change
... I think that neither Chrome OS or Firefox OS will implement Widgets
... we should focus on hosted apps via the manifest specification
... I got very positive signals from various browser vendors
... It won't be a complete runtime but a start
... and hopefully we could evolve that to a real runtime overtime
... We might have issues with APIs that require trusted code
... Marcos thinks that we can just leave the security aside but I am not sure
... it might work for TCP Sockets though
... probably not for Telephony

mounir_: I quite agree with Marcos that we can ignore how the permission is granted to an API as long as APIs are able to handle the different cases (as we discussed yesterday)
... even for telephony I am not sure why this is needed

sicking: for telephony, I am not that optimistic because depending on your service provider, you might have different security levels

<Claes> I have installed skype now. Can you give me a skype adress to call.

<Claes> Ok, I'll call you

<Claes> I got about 10 hits on that address. Could you try to call me. claes.nilsson90

<Claes> Is someone writing MoM

<Claes> ?

<dsr> scribenick: dsr

Jonas discusses signed apps as basis for access to trusted APIs

Rich: apps without access to the Internet could be granted permission to access trusted APIs with minimal risk of problems

<richt> http://richt.me/2013/05/exposing-privileged-apis-to-web-content/

Jonas: I don't know how I would create APIs that work in all 3 contexts (browser, disconnected and signed/trusted)

Anssi: asks Rich if developers are happy with the very restricted model proposed by Rich

Rich: anything written in the privileged state can only be read in the privileged state

Anssi: how will we sell this to developers?

Rich: let's focus on manifest for hosted apps, and installing apps on the home screen

Anssi: an installed app would sit between privileged and the drive by web

Rich: elevating an app's privileges is hard and is not how the web works.

Jonas: for each API we're designing, we need to pick the security model it runs in
... we should stick to the known security models: the regular web, and the signed/trusted
... we don't need to pick "one" security model, but for each API we need to be clear which security model applies

Anssi: can we open the SysApps home page please (on the projector)
... task scheduler is okay the for the Web
... contacts, messaging, telephony, raw sockets are all for the signed context

For phase 2, bluetooth signed?

Jonas: Mozilla doesn't even expose bluetooth to signed apps as yet, but will do so eventually

Mounir: our ideas on security models will evolve over time, and this will mean revisiting API design

<mounir_> scribenick: mounir_

Raw Sockets API

<wonsuk> Slide from Claes: https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=53293ca563&view=att&th=14247edd8d03c71d&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P_9ZyqSId_uZvO2K-Bes8iX&sadet=1384236110159&sads=PJAmCpe6b_QcGc9CubXtjoytRgE&sadssc=1

Claes: first, the name of the API might change
... a summary of what we have been doing since the last F2F
... <many things that the scribe did not catch>
... there are two outstanding issues
... one was raised by Marcos
... the node community said that the specification should be based on the Stream API
... and I have made a presentation on this proposal
... slide 2, the proposal is that it should be based on the Streams API but this would be a significant re-design of the Raw Sockets API
... why doing that?
... we would be using a general standardize solution
... for things like buffering and backpressure
... there is also in the work with streams, a solution for piping a source stream with a destination stream
... which is a common UC for a socket api
... slide 4, there are two activities for the Streams API
... one is a W3C Streams API and a WHATWG specification
... there is a GitHub link that I will patch in the IRC channel

<Claes> https://github.com/whatwg/streams

Claes: If you look at those proposals, you will see that they are very different
... hopefully, they will align
... slide 5, the Streams API deals with similar issues than the Raw Sockets API
... it is trying to keep a simple API for developers that do not lose data or overflow buffers
... slide 6, we talked about stream producers
... slide 7, stream consumers, that read and act on a stream object
... example or that is Web Audio
... next slide is the push based data sources requirements for a stream api
... now, requirements for write
... it includes buffering
... <reading slides>

sicking: we also need to deal with the fact that TCP Socket can be upgraded to SSL
... and the interaction that has with Stream

< Claes' Skype got disconnected >

sicking: <repeats the question>

Claes: we do not have a solution, it is good that you pointed that problem so we can try to find a solution
... so... slide 10, piping
... slides 11, 12, 13 - they show extremely preliminary interfaces
... questions?

anssik: I am looking at the status of the Streams proposal
... there is a GitHub readme file but what is the other one?

<Claes> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

anssik: is the W3C spec at LC now?

Claes: the proposal gots many comments
... so I think they will postpone the LC

anssik: do you know what's the implementation status of those proposals?

Claes: I do not know

sicking: stream is going to take a long time

anssik: I guess the question is whether we want to base our work on top of W3C experimental work?

Claes: I agree with Jonas, Streams will take a long time
... but it seems to have a strong potential
... I do not know if we have made a strong decision whether we would be using the Stream API but we should investigate
... they are working on the same problems

anssik: I think we (Intel) have an implementation
... there were issues but there were already addressed by the Mozilla Network folks
... I think since then you addressed them

Claes: it is very nice to hear that you have an implementation
... I would like to see that

anssik: I will talk to you more in the following weeks

<dsr> jonas: streams might take a year to stabilize

<dsr> Anssi

<dsr> Anssi: for Tizen we may need something sooner, but we are probably happy to follow the streams approach

<dsr> ... we should keep a stable snapshot on the current approach as a precaution.

<dsr> Jonas: streams are complicated and it will take a long time for people to reach a consensus.

<dsr> Anssi: I propose we progress both approaches.

<spoussa_> +1

RESOLUTION: the group will continue investigating using Stream for the Raw Sockets API
... the current state of the API (without Stream) should be published as another WD

<scribe> ACTION: Claes will publish another WD for the Raw Sockets API that is not based on Streams [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action07]

<Claes> Could you call me again on Skype claes.nilsson90

<Claes> Dave, Could you call me again on Skype claes.nilsson90

<Claes> Ok

<Claes> Dave is no longer in the SysApps meeting. Could anyone else call me on Skype, claes.nilsson90?

<scribe> scribenick: mounir_

Next F2F

mounir_: I propose that we do not schedule a F2F for the moment
... we have work to do before having a new F2F so lets do that work and decide when we meet when it is on its way

anssik: I agree, unless some people prefer 3 months notice, something like 1-2 months should be enough
... what about doing a F2F with another group? like WebApps?

<zolkis> what are the next steps? any tentative deadlines on actions?

<zolkis> anssik: +1

wonsuk: we could see if we could meet with WebApps, it could be good for us as well
... I could check that with the chair of WebApps

<scribe> ACTION: wonsuk will ask the chairs of WebApps regarding their next F2F [recorded in http://www.w3.org/2013/11/11-sysapps-minutes.html#action08]

mounir_: regarding the actions, I will send an email with a summary and open bugs
... but I do not think it is useful to have deadlines, people miss deadlines anyway

rssagent, generate minutes

mounir_: F2F closed, thank you everyone

- DRAFT -

SysApps Face to Face - Shenzhen

11 Nov 2013

Attendees

Contents