02:30:21 <tantek> tantek has joined #sysapps
05:02:51 <thinker> thinker has joined #sysapps
05:42:08 <tantek> tantek has joined #sysapps
07:36:33 <Zakim> Zakim has left #sysapps
08:25:58 <zolkis> zolkis has joined #sysapps
08:50:04 <zolkis> zolkis has joined #sysapps
16:02:52 <RRSAgent> RRSAgent has joined #sysapps
16:02:52 <RRSAgent> logging to http://www.w3.org/2014/04/09-sysapps-irc
16:03:44 <anssik> zakim, what conferences are active?
16:03:45 <Zakim> I see T&S_Track(dnt)12:00PM, SEC_WASWG()11:00AM, WAI_PF()12:00PM, Team_(sysapps)16:00Z active
16:03:47 <Zakim> also scheduled at this time are VB_VBWG(SCXML)12:00PM, XML_XMLCore()11:30AM, SW_RDFWG()11:00AM, WAI_Team(WAIT)10:45AM, Style_CSS FP()12:00PM, I18N_MLWWG()11:30AM
16:04:31 <jinsong> jinsong has joined #sysapps
16:08:08 <Axel> Axel has joined #sysapps
16:08:32 <zolkis> sooo.... whaaat's hap-p-ening? dialed in, but no reaction. This side of the bridge is connected, but what about the other side?  Is that phone plugged in now? :)
16:09:16 <zolkis> zolkis has joined #sysapps
16:09:27 <genelian_> genelian_ has joined #sysapps
16:09:36 <anssik> zakim, who is here?
16:09:36 <Zakim> sorry, anssik, I don't know what conference this is
16:09:37 <Zakim> On IRC I see genelian_, zolkis, Axel, jinsong, RRSAgent, Zakim, gmandyam, dsr, tantek, anssik, terri, thinker, slightlyoff_, tobie__, cdumez, amorgaut___, zkis, Josh_Soref_,
16:09:38 <Zakim> ... timeless_, scheib_, genelian, schuki, mounir
16:10:05 <anssik> zakim, this is sysapps
16:10:05 <Zakim> ok, anssik; that matches Team_(sysapps)16:00Z
16:10:10 <anssik> zakim, who is here?
16:10:10 <Zakim> On the phone I see ??P14, ??P22
16:10:11 <Zakim> On IRC I see genelian_, zolkis, Axel, jinsong, RRSAgent, Zakim, gmandyam, dsr, tantek, anssik, terri, thinker, slightlyoff_, tobie__, cdumez, amorgaut___, zkis, Josh_Soref_,
16:10:11 <Zakim> ... timeless_, scheib_, genelian, schuki, mounir
16:10:41 <genelian_> present+ Gene_Lian
16:10:43 <Zakim> -??P14
16:10:58 <Zakim> +[Paypal]
16:10:59 <Zakim> -??P22
16:11:14 <Zakim> +??P22
16:11:19 <Zakim> +??P35
16:11:21 <dsr> meeting: Systeam Applications WG face to face 9 April
16:11:27 <anssik> zakim, ??P35 is me
16:11:28 <lgombos> lgombos has joined #sysapps
16:11:29 <Zakim> +anssik; got it
16:11:51 <dsr> Present+ Dave_Raggett
16:11:52 <anssik> zolkis: try redialing, should work now
16:12:27 <zolkis> zakim, ??P22 is me
16:12:27 <Zakim> +zolkis; got it
16:12:28 <Zakim> -zolkis
16:12:31 <dsr> agenda: https://www.w3.org/wiki/System_Applications:_4th_F2F_Meeting_Agenda#2nd_day_.289th_Wednesday.29
16:12:52 <dsr> rrsagent, set logs public
16:13:01 <Zakim> +??P22
16:13:29 <zolkis> zakim, ??P22 is me
16:13:29 <Zakim> +zolkis; got it
16:13:29 <mcaceres> mcaceres has joined #sysapps
16:13:55 <zolkis> Present Zoltan_Kis
16:14:20 <wonsuk> wonsuk has joined #sysapps
16:14:37 <wonsuk> Present+ Wonsuk_Lee
16:14:57 <jmajnert> jmajnert has joined #sysapps
16:15:05 <jungkees> jungkees has joined #sysapps
16:15:10 <anssik> Present+ Anssi_Kostiainen
16:15:24 <genelian_> Data Store API spec: http://airpingu.github.io/data-store-api/index.html
16:15:25 <jungkees> Present+ Jungkee_Song
16:15:28 <zolkis> Present+ Zoltan_Kis
16:15:29 <mounir> Topic: Data Store API
16:15:34 <mounir> Present+ Mounir_Lamouri
16:15:37 <lgombos> Present+ Laszlo_Gombos
16:15:40 <genelian_> Data Store API slides: https://www.w3.org/wiki/images/e/e1/DataStoreAPI.pdf
16:15:59 <anssik> zakim, who is on the call?
16:15:59 <Zakim> On the phone I see [Paypal], anssik, zolkis
16:18:00 <mounir> Topic: agenda bashing
16:18:02 <zolkis> anssi: +1
16:18:44 <mounir> anssik: lets move the charter discussion earlier
16:18:47 <mounir> ... before lunch
16:20:11 <mounir> mounir: I moved the charter discussion to the morning
16:20:21 <mounir> ... and the afterneen session is starting at 13.30 instead of 13.00
16:20:29 <anssik> excellent, thank you
16:20:41 <mounir> mounir: done, next topic is Data Store
16:20:41 <opoto> opoto has joined #sysapps
16:20:45 <mounir> Topic: DataStore
16:20:47 <mounir> scribe: mounir
16:20:50 <mounir> scribenick: mounir
16:21:00 <dsr> Chair: Wonsuk, Mounir
16:21:15 <dsr> rrsagent, make minutes
16:21:15 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/09-sysapps-minutes.html dsr
16:22:03 <opoto> present+ Olivier_Potonniee
16:22:15 <mounir> genelian_: we discussed this specification in the past
16:22:22 <mounir> ... with some other editors too
16:22:30 <mounir> genelian_: so, what does DataStore API do?
16:22:59 <mounir> genelian_: in the past, SMSManager, MMSManager and other
16:23:07 <mounir> ... specification had a filtering mechanism described
16:23:21 <mounir> ... but it couldn't fulfil all applications needs
16:23:33 <mounir> ... this kind of API doesn't work well for third party apps
16:23:48 <mounir> ... we had to design a DataStore API for those
16:24:06 <mounir> genelian_: you can see the different methods [on the screen]
16:24:35 <mounir> genelian_: you can add, remove, update and finally sync data
16:24:49 <mounir> ... sync allow you to sync between the DataStore and your
16:24:51 <mounir> ... local storage
16:25:47 <mounir> genelian_ describes a figure on the screen
16:26:49 <zqzhang_> zqzhang_ has joined #sysapps
16:28:14 <mounir> gmandyam: how do you handle when two apps want to hown the same datastore?
16:28:20 <mounir> genelian_: there will be only one app
16:28:27 <Zakim> -zolkis
16:28:33 <Bin_Hu> Bin_Hu has joined #sysapps
16:29:08 <Zakim> +??P22
16:29:16 <zolkis> zakim, ??P22 is me
16:29:16 <Zakim> +zolkis; got it
16:29:53 <zolkis> genelian_, raise an issue about concurrent access
16:30:40 <mounir> gmandyam: so the app would not be installed if you try to own the same store?
16:30:45 <mounir> genelian_: yes...
16:30:57 <mounir> mounir: we should not prevent an app to get installed for
16:30:59 <mounir> ... something in the manifest
16:31:03 <mounir> s/hown /own /
16:31:21 <zolkis> I would separate whether the app is installed (which is a policy) from handling concurrency
16:31:49 <mounir> marcos: the readonly access thing scares me
16:32:48 <mounir> cdumez: but facebook might not want to share readwrite
16:32:58 <mounir> marcos: but it's a user decision, not a developer decision
16:33:09 <mounir> cdumez: no, apps might not allow other apps to write their data
16:33:54 <zolkis> manifest and permissions is subject to more work, see also https://github.com/airpingu/data-store-api/issues/18
16:34:53 <tantek> tantek has joined #sysapps
16:36:39 <dsr> q?
16:37:37 <anssik> q+
16:38:16 <mounir> genelian_ continues reading the slides
16:39:20 <Zakim> -zolkis
16:39:44 <Zakim> +??P5
16:39:54 <zolkis> zakim, ??P5 is me
16:39:54 <Zakim> +zolkis; got it
16:40:10 <Zakim> -zolkis
16:41:48 <mounir> genelian_: the local app will keep its own index and have to handle the synchronization
16:42:18 <mounir> ... something else that you need to know is that the app only need
16:42:25 <mounir> ... to maintain the searches criteria
16:42:33 <Zakim> +[Microsoft]
16:42:45 <mounir> ... no need to index the entire data store but only the attributes
16:42:50 <mounir> ... you care about
16:43:10 <mounir> genelian_ goes trough an example on the screen
16:43:18 <zolkis> it would be nice to give examples for app makers on how to do the indexing
16:45:00 <zolkis> yes
16:45:28 <zolkis> the examples given for messaging are not the best; I have described in issue #18
16:45:56 <mounir> genelian_ is going trough another example (slide 7)
16:46:00 <zolkis> I suggest we decide that we will use DataStore in Messaging, do the implementation, and modify DataStore on need
16:46:15 <zolkis> ok
16:46:47 <Zakim> +??P22
16:46:56 <zolkis> zakim, ??P22 is me
16:46:56 <Zakim> +zolkis; got it
16:48:54 <zolkis> q+
16:51:00 <mounir> discussion around synchronization based on the example on the screen
16:51:16 <zolkis> main points being? :)
16:51:29 <mounir> marcos: we should have a way to just plug any data source to an IndexedDB
16:52:05 <mounir> cdumez: so then it would duplicate the hole thing, right?
16:52:17 <mounir> marcosc: indeed, it will. Maybe it could only duplicate what is needed
16:52:30 <mounir> gmandyam: IDB has to be sandboxed, right?
16:52:37 <mounir> ... this is different because we have declared access in the manifest
16:53:05 <mounir> marcosc: at some point it ends up in a database anyway
16:53:41 <mounir> gmandyam: after we had our f2f, I realised that you guys are using IDB for the apps storage in FxOS
16:54:04 <mounir> ... and then we understood why access was so long
16:54:20 <mounir> marcosc: maybe if it is readonly you could not duplicate the data?
16:54:28 <mounir> zolkis: how do you describe what you need?
16:54:35 <mounir> marcosc: maybe with the initial query to it?
16:55:26 <mounir> cdumez: I don't really want to force the app to use IDB
16:55:32 <zolkis> the idea of binding to IndexedDB is not bad, but needs a lot of details; genelian_ please raise an issue about this and let's discuss on github
16:55:39 <mounir> ... how much data they store and how they do should be up to the implementation
16:55:46 <mounir> ... so they can do exactly what they want
16:56:02 <mounir> cdumez: IDB is not about querying, it's a key-value database
16:56:08 <gmandyam> To clarify my point:  I think it is a mistake to assume (or require) that a Data Store API be built upon IndexedDB - there are potential  performance issues.
16:57:09 <mounir> mounir: we should move on
16:57:15 <zolkis> gmandyam: I agree, the spec should not require building on IndexedDB, but binding a DataStore to an IndexedDB may be worth exploring
16:57:57 <mounir> dsr: should we update the charter?
16:58:08 <mounir> gmandyam: it might be in scope with contacts
16:58:11 <zolkis> me says too many discussions there, please one speak at the time, and use the speaker queue
16:58:45 <mounir> wonsuk: in my opinion, it is case by case
16:58:50 <mounir> ... there is no data store api in the charter
16:59:06 <mounir> ... so in my opinion, we should make it more clearly in the charter
16:59:25 <mounir> wonsuk: we should change the charter
16:59:26 <mounir> q?
16:59:59 <mounir> ack anssik
16:59:59 <cdumez> q+
17:00:36 <mounir> anssik: can the owner limit the access to other apps to readonly?
17:00:39 <anssik> can the owner manage the privileges to other apps have, e.g. limit others to read only
17:01:06 <mounir> anssik: it seems that the permissions are managed in the manifest
17:01:09 <mounir> but that doesn't scale
17:01:16 <mounir> s/but that/... but that/
17:01:22 <zolkis> anssik, see a proposal in https://github.com/airpingu/data-store-api/issues/18#issuecomment-39950300
17:01:25 <anssik> s/to other/the other/
17:02:15 <Zakim> -[Microsoft]
17:03:07 <mounir> genelian_: an owner can specify the whether the data store is readonly or readwrite
17:03:14 <mounir> ... but can't have a fine grained permission model
17:03:19 <mounir> ... regarding which app can access the data stare
17:03:25 <mounir> s/data stare/data store/
17:03:26 <anssik> thanks for the clarification
17:03:32 <anssik> that answered my question
17:03:34 <mounir> ack zolkis
17:03:51 <mounir> q+ zolkis
17:03:54 <zolkis> I am talking
17:04:37 <Zakim> -zolkis
17:04:49 <mounir> ack cdumez
17:05:05 <mounir> cdumez: how does that work (sync)? how do you prevent races?
17:05:39 <mounir> genelian_: if an app call the sync function, you will get the sync changes
17:05:57 <mounir> ... <indistiguishable>
17:06:14 <mounir> cdumez: that's why there is a close() method?
17:06:17 <mounir> genelian_: yes
17:06:24 <mounir> q?
17:06:32 <zolkis> has to go by chat
17:06:38 <mounir> ack zolkis
17:06:41 <cdumez> q+\
17:06:45 <cdumez> g+
17:06:48 <cdumez> q+
17:06:48 <mounir> ack \
17:07:30 <zolkis> clearly there are 2 things to fix: permissions/manifest, and the sync part. I think here we should record all these questions and raise issues, and let's see if we can fix on github
17:07:47 <zolkis> I am not convinced that the replay mechanism is the best for sync
17:08:25 <zolkis> and in issue #18 I described a porposal for a coarse grain permission control through manifest, and a fine grained one via a user agent dialog
17:08:41 <BaopingCheng> BaopingCheng has joined #Sysapps
17:08:42 <zolkis> [end]
17:08:48 <genelian_> https://github.com/airpingu/data-store-api/issues/18
17:08:55 <mounir> mounir: zolkis are there issues opens?
17:09:04 <zolkis> more and more :)
17:09:21 <mounir> mounir: we can't raise official actions given that its not an official WG item
17:09:30 <zolkis> but we should start implementing this and see on the way
17:09:38 <Zakim> +??P29
17:09:54 <zolkis> zakim, ??P29 is me
17:09:54 <Zakim> +zolkis; got it
17:09:54 <mounir> q?
17:10:07 <mounir> ack cdumez
17:10:16 <mounir> cdumez: I will just talk with genelian_ offline, those are editorial issues
17:10:47 <mounir> mounir: we are way behind schedule, we should speed up and move to the next item
17:11:06 <mounir> mounir: we sholud do Contacts Manager and have a break after that
17:11:31 <mounir> cdumez: is someone from telefonica joining?
17:11:40 <mounir> mounir: I would have assumed so but they are not on the line
17:11:43 <mounir> ... you should start
17:11:49 <mounir> Topic: Contacts Manager API
17:11:57 <mounir> cdumez: there are a few changes since the last meeting
17:12:17 <mounir> ... one of the bugs was that we were not using Promises correctly
17:12:29 <mounir> ... right now, when we construct a contact, we add the contact
17:12:36 <mounir> ... to the database and create an id
17:12:47 <mounir> ... I think we should create the id after the contact is actually
17:12:48 <mounir> ... saved
17:13:02 <mounir> mounir: do you have a list of issues to go trough?
17:13:06 <mounir> cdumez: there is only two issues
17:13:09 <cdumez> https://github.com/sysapps/contacts-manager-api/pull/60
17:13:54 <mounir> ACTION: eduardo should review https://github.com/sysapps/contacts-manager-api/pull/60
17:13:57 <cdumez> Second issue: https://github.com/sysapps/contacts-manager-api/issues/62
17:14:18 <cdumez> http://cdumez.github.io/contacts-manager-api/index.html
17:14:36 <mounir> q+ to ask what the current involvment
17:15:29 <mounir> cdumez: the issue here is how do we know which DataStore is the default one?
17:15:36 <mounir> ... we need a system one but which one is that going to be?
17:15:39 <mounir> ... the first one?
17:17:32 <mounir> mounir: the owner field in DataStore should have a special value when the store is coming from the system
17:18:48 <mounir> cdumez describes his fork of the current ED of contacts api that is using datastore
17:19:06 <mounir> cdumez: if genelian_ can confirm if this is the idea, that would be great
17:19:12 <mounir> wonsuk: was that been reviewed by other editors?
17:19:21 <mounir> cdumez: not yet, it's quite new
17:19:41 <mounir> cdumez: otherwise, I think that Eduardo made the same comment: we are both in favour of updating the api to use datastore
17:20:29 <mounir> cdumez: so that's about it
17:20:30 <mounir> q?
17:20:38 <mounir> dsr: are you going to merge this?
17:20:51 <mounir> cdumez: once this is cleared with eduardo and genelian_ I will make a PR
17:21:05 <mounir> ... but I have trouble getting changes merged these days
17:21:08 <mounir> ack mounir
17:21:08 <Zakim> mounir, you wanted to ask what the current involvment
17:21:20 <anssik> q+ Contact, ContactField, ContactTelField etc. are exposed to the global, in total 6 interfaces
17:21:32 <zolkis> cdumez, let's work on DataStore related issues together with the Messaging API (Eduardo also involved)
17:21:37 <anssik> q+ to note Contact, ContactField, ContactTelField etc. are exposed to the global, in total 6 interfaces
17:22:01 <mounir> scribe: marcosc
17:22:05 <mounir> scribenic: marcosc
17:22:44 <marcosc> mounir: you say you have a hard time to get changes getting merged
17:23:02 <marcosc> cdumez: yeah, it took like 5 months to get things merged
17:25:39 <zolkis> Intel is going to implement Contacts API on Crosswalk
17:26:30 <anssik> if there's a spec that is complete and good quality we'll implement in Crosswalk
17:26:55 <dsr> q?
17:27:28 <dsr> scribe: dsr
17:27:40 <mounir> ack anssik
17:27:40 <Zakim> anssik, you wanted to note Contact, ContactField, ContactTelField etc. are exposed to the global, in total 6 interfaces
17:28:26 <dsr> Anssi: we need a decision on exposing Contact, ContactField, ContactTelField etc. to the global
17:28:43 <zolkis> q+
17:29:13 <dsr> cdumez: so you're fine keeping it this way with global constructors?
17:29:36 <dsr> Anssi: I think we can keep it as is, you have good reasons ...
17:29:45 <mounir> ack zolkis
17:30:14 <zolkis> Bluetooth PBAP support?
17:30:26 <dsr> Zoltan: a question would be to create a bluetooth profile
17:30:53 <dsr> ... we have some use cases for this, I know bluetooth is in phase2, but ...
17:31:18 <zolkis> 2 ways to implement:
17:31:26 <zolkis> either integrated in Contacts/ Messaging
17:31:33 <zolkis> or we design separate API's
17:32:13 <dsr> wonsuk: do you know what is needed for adding bluetooth support?
17:32:43 <dsr> zoltan: it depends on the middleware, e.g.bluez
17:32:58 <zolkis> we are using bluez/obex for implementing PBAP
17:33:14 <zolkis> I will change my client :)
17:33:33 <zolkis> I finished commenting.
17:34:00 <dsr> cdumez: contacts was previously limited to one data source, but with the switch to using the datastore API we can use many
17:34:23 <zolkis> actually there could be  a separate store for each device connected via Bluetoot
17:34:44 <mounir> ACTION: cdumez should investigate how the Contacts API should integrate with Bluetooth
17:34:46 <dsr> ... so in principle, an app could take contacts from bluetooth and put them into the shared datastore
17:35:40 <mounir> q?
17:35:43 <dsr> cdumez: I was hoping that the datastore API could be published
17:35:58 <mounir> 10 mins break
17:36:09 <dsr> rrsagent, make minutes
17:36:09 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/09-sysapps-minutes.html dsr
17:37:22 <anssik> +1 to the proposal to investigate how we might hook Bluetooth into the existing APIs or whether a standalone lower level Bluetooth API makes more sense
17:49:21 <dsr> Topic: Messaging
17:49:56 <zolkis> here, no voice
17:50:17 <dsr> zakim, who is on the phone?
17:50:17 <Zakim> On the phone I see [Paypal], anssik, zolkis
17:50:20 <zolkis> Messaging needs to be updated with DataStore. No other major outstanding issues
17:50:29 <bhill2> bhill2 has joined #sysapps
17:50:35 <mounir> q?
17:51:10 <zolkis> So, this one is quick: no major obstacles on Messaging. Questions?
17:51:16 <dsr> Mounir: what's the implementation status?
17:51:35 <dsr> Laszlo: we working on it ...
17:52:00 <zolkis> I am implementing it for Tizen and we have an Android implementation (both on Crosswalk)
17:52:44 <dsr> Wonsuk: in respect to tizen, we're interestde, but before making the decision we're looking for a stable version of the spec with consensus at W3C
17:53:12 <dsr> Gene: we haven't yet updated our implementation
17:53:22 <zolkis> looks like my phone call is hung at the bridge, and I cannot dial in!
17:53:56 <mounir> zakim, who is on the phone?
17:53:56 <Zakim> On the phone I see [Paypal], anssik, zolkis
17:54:24 <wonsuk> s/interestde/interested in the implementation/
17:54:26 <dsr> zakim, drop zolkis
17:54:26 <Zakim> zolkis is being disconnected
17:54:55 <zolkis> trying
17:55:05 <zolkis> any other comments on Messaging?
17:55:11 <dsr> no
17:55:18 <zolkis> moving to Telephony?
17:55:27 <zolkis> no pun intended :D
17:55:28 <dsr> yes, that's the idea
17:55:41 <dsr> Topic: Telephony
17:55:43 <anssik> zakim drop anssik
17:55:45 <zolkis> ok, here is my report: http://lists.w3.org/Archives/Public/public-sysapps/2014Feb/0034.html
17:55:51 <anssik> zakim, drop anssik
17:55:51 <Zakim> anssik is being disconnected
17:56:01 <zolkis> short summary: added use cases, fixed CDMA issues + described design choices made in the API, made conf calls much simpler, moved telephony services into informative appendix (making its implementation optional)
17:56:42 <zolkis> on implementation: it has low priority right now (except Call History), but the plan is that we implement the API
17:57:03 <dsr> Mounir: please q+ with your questions
17:57:20 <gmandyam> q+
17:57:38 <mounir> ack gmandyam
17:57:54 <zolkis> I propose we do this on IRC  - sorry for this
17:59:11 <mounir> q?
17:59:25 <mounir> Zakim, who is on the phone?
17:59:25 <Zakim> On the phone I see [Paypal], anssik, zolkis
17:59:40 <zolkis> Zakim, drop me
17:59:40 <Zakim> zolkis is being disconnected
18:00:21 <mounir> Zakim, who is on the phone?
18:00:21 <Zakim> On the phone I see [Paypal], anssik, zolkis
18:00:26 <gmandyam> (1) I appreciate all of Zoltan's efforts in revising this API - it is a difficult topic, (2) From QuIC perspective - we would like to see commitment from the companies in the room to implement AND expose this to 3rd party developers under the right permissions model, (3) If there is no commitment to do this, then the group should not continue working on this API
18:00:45 <wonsuk> q?, in the aspect implementation, dose Mozilla has a plan for that?
18:01:12 <wonsuk> q+, in the aspect implementation, dose Mozilla has a plan for that?
18:01:33 <wonsuk> q+ in the aspect implementation, dose Mozilla has a plan for that?
18:01:38 <zolkis> In the use cases, I made clear we have 2 separate classes: one is relevant to browsers and runtimes about "is there a phone call in the system", but that is a system info API
18:01:42 <marcosc> marcosc has joined #sysapps
18:02:03 <zolkis> then, the original use case of supporting 3rd party dialers is being challenged now
18:02:09 <dsr> Mounir: implementation status?
18:02:32 <wonsuk> q+ to in the aspect implementation, dose Mozilla has a plan for that?
18:02:34 <zolkis> I have made the Telephony spec really close now to the Mozilla API, to ease adoption
18:02:37 <dsr> Marcos: as far as I know, Mozilla has no plans to implement the telephony API
18:03:46 <dsr> Mounir: what about Samsung?
18:03:59 <dsr> Lazlo: no
18:04:26 <dsr> Mounir: so no one other than Intel has any plans to implement this in the short term?
18:04:27 <zolkis> I think we could keep this API in the works, until it's stable, let us try it in an implementation, and then we can retire it at least knowing we have done a good job :)
18:05:20 <zolkis> Personally I would be fine with 3 use cases concerning telephony:
18:05:31 <dsr> Mounir: Zoltan, is Intel interested in exposing the telephony API to 3rd parties?
18:05:33 <zolkis> 1. start the native dialer with a number + dtmf
18:05:47 <zolkis> 2. is there a call in the system and what resources is it using
18:06:15 <zolkis> 3. call history as DataStore source
18:06:29 <dsr> Mounir: for FirefoxOS telephony is for internal apps only, not 3rd parties
18:06:45 <zolkis> mounir: I need to check with Wayne, but when we started this work, the idea was to expose this to 3rd party developers
18:07:11 <zolkis> yes, use case 1 does not require a telephony API
18:07:30 <zolkis> and use case 2 can be done in a system info type of API
18:07:58 <dsr> Some discussion about which organizations support the tel: URL scheme
18:08:00 <zolkis> use case 3 is a must, and it would be good to standardize
18:08:42 <zolkis> OK. But this API is about a different thing.
18:08:46 <gmandyam> All implementations seem to support tel:URL the way it was intended.
18:09:00 <dsr> Mounir: how can you access call history from Tizen?
18:09:21 <dsr> Chris: we're working on an API for that
18:09:22 <zolkis> so, the question is, could we keep the Telephony API in the works?
18:09:53 <mounir> q?
18:09:57 <zolkis> We are interested in it, and nowadays I am the only one who is doing some work on it
18:10:26 <dsr> Mounir: anyone have any questions specific to the telephony API, please ask now, or otherwise we can move to the charter and future work topic
18:10:40 <dsr> ack wonsuk
18:10:40 <Zakim> wonsuk, you wanted to in the aspect implementation, dose Mozilla has a plan for that?
18:11:10 <zolkis> ok
18:11:14 <zolkis> thanks
18:11:30 <anssik> zakim, who's on the call?
18:11:30 <Zakim> On the phone I see [Paypal], anssik, zolkis
18:11:53 <cdumez> s/we're working on an API for that/There is an API for this in Tizen
18:12:12 <zolkis> please reset the phone... :) it is having ghost calls
18:12:19 <anssik> zakim, disconnect anssik
18:12:19 <Zakim> anssik is being disconnected
18:12:25 <anssik> zakim, who's on the call?
18:12:25 <Zakim> On the phone I see [Paypal], anssik, zolkis
18:12:42 <dsr> rrsagent, make minutes
18:12:42 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/09-sysapps-minutes.html dsr
18:14:34 <zolkis> what seems to happen is that Asterisk (behind Zakim) has one side of the bridge up
18:14:42 <zolkis> someone needs to restart the daemon
18:14:44 <dsr> zakim, room for 5 for 300m?
18:14:45 <Zakim> ok, dsr; conference Team_(sysapps)18:14Z scheduled with code 26631 (CONF1) for 300 minutes until 2314Z
18:15:08 <zolkis> or allocate a different conference
18:16:17 <zolkis> yes, the service times out
18:16:19 <mounir> Zakim, who is on the phone?
18:16:19 <Zakim> On the phone I see [Paypal], anssik, zolkis
18:16:31 <dsr> zakim, drop zolkis
18:16:31 <Zakim> zolkis is being disconnected
18:16:32 <zolkis> so, let's go on and we rely on the scribes
18:16:37 <dsr> zakim, drop anssik
18:16:37 <Zakim> anssik is being disconnected
18:16:38 <mounir> Zakim, drops [Paypal]
18:16:38 <Zakim> I don't understand 'drops [Paypal]', mounir
18:16:43 <mounir> Zakim, drops Paypal
18:16:43 <Zakim> I don't understand 'drops Paypal', mounir
18:16:43 <zolkis> or everybody types :)
18:16:43 <dsr> zakim, drop anssik
18:16:44 <Zakim> anssik is being disconnected
18:16:53 <mounir> Zakim drops [Paypal]
18:16:57 <dsr> zakim, who is on the phone?
18:16:57 <Zakim> On the phone I see [Paypal], anssik, zolkis
18:19:29 <opoto> new dial in: +12153674444 (US)  +358981710447 (Finland)  conference ID: 84905672
18:19:58 <opoto> (can provide other countries on demand)
18:21:21 <zolkis> Thanks a lot opoto! I dialed in, waiting for the leader :)
18:23:43 <terri> terri has joined #sysapps
18:24:41 <zolkis> I hear your conversations :)
18:26:07 <dsr> Topic: Discussing the charter and current work items
18:26:19 <zolkis> link to charter?
18:26:28 <mounir> http://www.w3.org/2012/09/sysapps-wg-charter.html
18:26:35 <dsr> Mounir: let's start with telelphony, but before that ...
18:26:35 <mounir> http://www.w3.org/2012/sysapps/
18:26:43 <anssik> http://www.w3.org/2012/09/sysapps-wg-charter.html
18:27:06 <anssik> s/http://www.w3.org/2012/09/sysapps-wg-charter.html//
18:27:07 <dsr> Mounir summarises the current situation
18:27:10 <anssik> q+
18:27:49 <dsr> ... we would like to add DataStore, but in general we need implementation support for the specs
18:28:33 <dsr> ... if telephony is only used by internal apps, then interoperability is not an issue
18:29:28 <dsr> dsr has changed the topic to: new bridge   +12153674444 (US)   conference ID: 84905672
18:29:57 <dsr> Mounir: I would prefer to drop the specs where we aren't seeing broad implementation interest
18:30:38 <zolkis> q+
18:31:51 <dsr> ... We all have different silos, and what we're trying to do is to define APIs for use by all the different silos, but we are very far away from succeeding with that
18:33:03 <mounir> q?
18:33:08 <dsr> ... Moving such APIs to W3C standards has low benefit, so maybe we should focus on APIs that have broader interest
18:33:15 <dsr> ack anssik
18:33:15 <mounir> ack anssik
18:34:12 <dsr> Anssi: Mounir that was a good summary. Specs designed around the web security model have been shown to move faster (in DAP WG)
18:34:42 <dsr> ... the App LifeCycle spec is currently dormant waiting for progress on ServiceWorker
18:35:09 <anssik> https://www.w3.org/wiki/Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces
18:35:48 <dsr> Anssik: Dave a couple on months ago asked about interest in a workshop on permissions etc. and that could be a valuable activity
18:36:21 <dsr> ... For SysApps, we should focus on a very small number of specs that could be moved forward efficiently
18:36:33 <dsr> ... with interest from the implementers
18:36:42 <dsr> s/etc./and marketplaces/
18:36:58 <anssik> +1
18:37:33 <anssik> I'm very interested in we trying to address the permission model problem in the browser context
18:37:43 <anssik> s/we trying/trying/
18:38:15 <mounir> q?
18:38:18 <mounir> ack zolkis
18:38:21 <dsr> Mounir: we might want to tackle permissions on web APIs.  Moving to a standard is a huge benefit in terms of developer confidence, but this doesn't apply to APIs used by internal apps
18:39:28 <dsr> Zoltan: I definitely see value in messaging and telephony APIs, and making sure that this work is usable
18:40:02 <opoto> q+
18:40:33 <lgombos> q+
18:40:48 <dsr> ... Since I am the only one working on telephony, we could shut it down, but it is a usable API and now that we have done the bulk of the work, it would be a shame to drop it
18:41:31 <anssik> q+
18:41:53 <dsr> Mounir: usually when W3C WG's drop work items these are turned into WG Notes which means that the work is not being worked on anymore but is available as a reference
18:42:32 <dsr> Anssi: these can be restored to a Working Draft if the WG deems it appropriate
18:43:34 <anssik> q+
18:43:51 <dsr> Zoltan: I think we could gracefully retire the telephony spec, it is now ready for implementation feedback, there were a lot of companies interested.
18:44:07 <mounir> ack opoto
18:44:15 <dsr> Anssi: we should give a clear reason when we republished APIs as WG Notes
18:44:55 <dsr> Olivier: we should clarify 3rd party use cases, without these it is not worth standardizing
18:46:10 <dsr> Mounir: raw socket is an interesting API, but no one is implementing the spec, so this isn't promising for a standard
18:46:52 <zolkis> well, Intel has implemented the Raw Socket API, so "no one" is not accurate :)
18:47:36 <zolkis> I agree: we are too early with this work. Is there any way to freeze the work without dropping them?
18:47:50 <dsr> Marcos: I think we are 5 years ahead of the curve, and that gives us the time to explore this space in proprietary ways, and to understand what works and what would really be worth standardizing
18:48:26 <dsr> Dave: what are developers saying?
18:48:26 <anssik> zolkis, W3C Note is technically freezing, you can resume
18:50:06 <dsr> Mounir: when developers write apps for each platform that don't care so much about standards, but they do care when they start developing for the web platform
18:50:37 <mounir> s/for each platform/for each packaged platform/
18:50:40 <wonsuk> q?
18:50:41 <mounir> q?
18:50:45 <mounir> ack lgombos
18:50:45 <anssik> q-
18:52:04 <dsr> lgombos: the concerns raised are quite generic, there is a concern about implementations, my comment on that is that we have all these proprietary APIs, developers would like open standards and these could be layered on top of the proprietary platforms
18:52:13 <dsr> Marcos: what is the benefit?
18:52:31 <dsr> lgombos: some benefits are for developers and some for the platform vendors
18:52:54 <dsr> ... over time there will come other benefits
18:52:54 <zolkis> lgombos: that is a very good point: platforms do benefit from this work
18:53:15 <anssik> q+
18:53:32 <dsr> Mounir: that's the wrong reason, ...
18:54:15 <dsr> lgombos: we can't expect the same volume of comments as for HTML5, as a lot of the system apps will be niche
18:55:01 <dsr> Wonsuk: it is important to create a better ecosystem for industry, we should look at which APIs will have a higher priority for the Web
18:55:20 <dsr> Marcos: we know that offline apps are very important
18:55:29 <dsr> Wonsuk: that's clear
18:56:08 <dsr> Marcos: the installability of web apps, we've  worked on manifest for that
18:56:31 <dsr> ... we need support for large web apps, and are getting there
18:56:46 <dsr> ... we need better performance e.g. for games
18:56:50 <mounir> q?
18:57:35 <dsr> lgobos: it is really hard to progress individual APIs unless we progress work on security and permissions
18:57:47 <dsr> Mounir: indeed
18:58:09 <zolkis> but these can be done in parallel... it is possible to detach a lot of things from security and permission model
18:58:18 <dsr> Mounir: I think it will be really hard to reach agreement on the model for packaged apps
18:59:09 <dsr> ... unless people around the table are willing to change their platforms
19:00:24 <mounir> ack anssik
19:00:26 <dsr> Mounir: everyone around the table have native Apps and want to make APIs like those for their native apps, but it would be better to focus on extending the web security model
19:00:54 <dsr> Anssi: I have a bunch of statements for the group to consider.
19:01:11 <dsr> 1. do we agree that apps must run on origins, and be part of the Web
19:01:40 <dsr> 2. I think we all believe that web apps need access to more advanced capabilities and features than they currently have
19:02:10 <dsr> 3. do we agree the users of these apps must have control over the capabilities these apps have, and that users can revoke these rights
19:03:09 <dsr> 4. this is about how we integrate with the host OS, manifest is part of the solution, home screen, etc.
19:04:09 <dsr> 5. offline is crucial for web apps to compete with native apps, service work is the solution, sysapps wg may not need to do much here. Users must be able to trust web apps
19:04:54 <dsr> 6. the current permissions models are broken and we need to fix that, one promising is to ask users in context of use
19:05:06 <dsr> what do you guys think?
19:05:16 <dsr> Mounir: I generally agree
19:05:53 <dsr> Marcos: re (1) origins/part of the web, I am not clear what the scope that leaves for things running under AppURI
19:06:03 <mounir> q?
19:06:16 <dsr> ... everything else I agree with
19:06:25 <zolkis> q+
19:06:46 <anssik> s/service work/service workers/
19:06:47 <dsr> Dave: do we want to fomalize the agreement on those points?
19:07:23 <anssik> s/promising is/promising approach is/
19:08:03 <dsr> Mounir: we need to change course, and to drop some work items. We could recharter to make this clear, and a 3rd way would be to completely change the way work is done, e.g. closing the WG in favor or a Community Group
19:08:07 <wonsuk> +1 for Anssi's opinion especially for #1 about origin!
19:08:27 <gmandyam> q+
19:08:46 <dsr> Mounir: making the web more appy not the apps more webby
19:08:50 <mounir> q?
19:08:54 <mounir> ack zolkis
19:09:28 <dsr> Zoltan: we don't really have a scoping problem, more an implementation problem
19:10:19 <dsr> ... I don't understand why we can't use the manifest as part of the permission solution
19:10:49 <anssik> zolkis, see my point 6.
19:11:01 <zolkis> yes, I agree with anssik point 6
19:11:03 <dsr> Mounir: we don't currently really know how to address the permissioning problem, so progress could take many years
19:11:11 <zolkis> and the other points, too
19:11:49 <dsr> Mounir: I don't think it is just a matter of dropping work items and continuing with the rest
19:12:09 <dsr> Zoltan: we should return to ? when we have working implementations
19:12:21 <mounir> q?
19:13:21 <zolkis> yes, coming...
19:13:40 <mounir> ack gmandyam
19:14:07 <gmandyam> If we don't focus on trusted apps alone, we should ensure that there is delineation between what is done in this group and what is done in DAP
19:14:20 <dsr> Giri: I think the example of DAP WG is good, if we want to support web apps, we are likely to overlap with the DAP WG,so we need to be careful about that.
19:14:30 <zolkis> So do we want to deal with solving the permissions problem? Every platform will need to do that, we do it one way in Crosswalk, may be good or bad, time will tell. I think we could get relatively easily to the point of a good enough mechanism, and leave the rest to the user agents.
19:14:50 <dsr> ... We should be addressing APIs with a different security context than DAP is addressing today
19:15:21 <dsr> Mounir: your concern is mostly about what if we (SysApps) decide to completely change everything
19:16:33 <dsr> Dave: rechartering would provide an opportunity to clarify the group's vision and roadmap
19:17:04 <dsr> Mounir: is there general support for discuss that further (on email)?
19:17:53 <anssik> q+ to note the group is currently chartered with an end date of 1 October 2014 -- I assume we'd like to recharted mid-term rather than wait 6 months?
19:18:29 <dsr> cdumez: if we we go to the web, then we may only need read access for contacts, and could go back to the DAP contacts API
19:18:49 <dsr> Dave: surely we want to enable much richer kinds of trusted web apps
19:19:22 <dsr> Mounir: if web intents come back, they could be a good solution for contacts
19:20:16 <dsr> ... if we think we can find ways to give web apps richer capabilities that would be good
19:20:38 <dsr> Marcos: DAP tried a number of different ways and failed in a good way
19:21:29 <dsr> ... If we show solutions that work well on proprietary platforms, we will then be ready to standardize based on what works
19:22:43 <dsr> Dave: it sounds like we are risk of fragmenting the web with proprietary silos
19:23:14 <dsr> Mounir: what is more dangerous is standardizing APIs that aren't widely adopted
19:24:30 <gmandyam> q+
19:24:30 <dsr> APIs for packaged apps fits the proprietary model well
19:24:59 <mounir> mounir: it's more dangerous to add APIs with the idea that they will b implemented
19:25:14 <mounir> ... than adding proprietary APIs to proprietary platforms
19:25:17 <mounir> ... which are not the web
19:25:28 <mounir> ... for example, push API in firefox OS is accessible from hosted apps
19:25:31 <mounir> ... which are in the Web
19:25:38 <mounir> ... but it's hurting the web
19:26:08 <mounir> ... if push was only for packaged apps, Mozilla could experiment without hurting the web
19:28:16 <dsr> Marcos: we should first sort out core issues before working on device aps
19:28:40 <gmandyam> Any recharter discussion should engage the framework providers (jQuery, Cordova/PG) - they are familiar with what developers need in a trusted framework
19:28:51 <dsr> cdumez: how about phonegap, this is really popular, so clearly there is a need for APIs that work across OSes
19:28:58 <gmandyam> q-
19:30:07 <dsr> Mounir: SysApps has been going for 2 years, but we aren't seeing people changing their implementations each time the spec changes
19:31:01 <dsr> Marcos: things are too experimental right now
19:31:29 <dsr> cdumez: phonegap is a minimal API that covers the intersection of all platforms
19:32:04 <dsr> Giri: my concern with phonegap is that it is too bottom up
19:32:56 <dsr> ... it would have been nice if the phonegap guys had stayed involved and provided us with their developer feedback
19:33:31 <mounir> ack anssik
19:33:31 <Zakim> anssik, you wanted to note the group is currently chartered with an end date of 1 October 2014 -- I assume we'd like to recharted mid-term rather than wait 6 months?
19:33:42 <bhill2_> bhill2_ has joined #sysapps
19:33:48 <anssik> current status re https://www.w3.org/wiki/Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces
19:33:59 <anssik> do we think this workshop would provide valuable input to the rechartering of this group?
19:34:00 <dsr> Anssi: I wanted to note the group is currently chartered with an end date of 1 October 2014 -- I assume we'd like to recharted mid-term rather than wait 6 months?
19:34:06 <anssik> if so, could we run this workshop in a more unconference-style (e.g. no formal position papers, expression of interest statements)
19:34:34 <dsr> Anssi: do you think a workshop would be a good way to set our new course, and to run in an unconference style?
19:34:44 <dsr> Marcos: we could do a meet up
19:35:34 <dsr> Anssi: yes that would be fine
19:36:03 <dsr> Mounir asks Dave if W3C workshops could run unconference style
19:36:27 <dsr> Anssi: we should name the workshop differently
19:36:42 <dsr> Mounir: how about web apps and permissions
19:36:58 <dsr> Giri: or even "trusted web app"
19:37:42 <mounir> q?
19:37:55 <dsr> Anssi: SysApps only has 6 months to run, so is it better to recharter now that wait
19:38:05 <dsr> Dave: better to change course earlier than later
19:40:04 <mounir> q?
19:40:20 <dsr> Anssi asks about plans for a whitepaper, this should allow for joint contributions
19:40:40 <dsr> Dave: yes, this is intended to be a data gathering exercise
19:41:14 <dsr> Zoltan: starting completely form scratch seems a bit harsh
19:41:28 <dsr> s/form/from/
19:41:32 <zolkis> but sometimes needed
19:41:42 <mounir> RESOLUTION: the group agreed that we should reconsider the future of the group
19:41:54 <mounir> ACTION: mounir will start a thread about the future of the group on the mailing list
19:42:17 <dsr> ... break for lunch, we will restart at 2pm PST
19:42:18 <anssik> thanks everyone, this was a great brainstorming session
19:59:38 <cyberphone> cyberphone has joined #sysapps
20:05:01 <zqzhang_> zqzhang_ has joined #sysapps
20:52:03 <marcos> marcos has joined #sysapps
20:52:25 <marcos> Can someone let me in from the side door? :)
20:54:18 <cyberphone> cyberphone has joined #sysapps
21:02:50 <mounir> scribe: mounir
21:02:53 <mounir> scribenick: mounir
21:03:00 <mounir> Topic: Secure Element API
21:03:53 <bhill2_> bhill2_ has joined #sysapps
21:06:33 <mounir> opoto: Garner Lee and Siddartha Pothapragoda are here from DT
21:06:44 <mounir> ... they are implementing something close to Secure Element on Firefox OS
21:06:49 <Sid> Sid has joined #sysapps
21:07:14 <mounir> opoto: following the presentation we made during TPAC, we had
21:07:21 <mounir> ... some feedback like security of the API
21:07:30 <mounir> ... for example, how to control access?
21:07:42 <mounir> opoto: there were other technical points
21:07:51 <mounir> ... that I will cover quickly because they might be too deep
21:07:57 <mounir> ... for the interest of most people here
21:08:20 <mounir> opoto: when you open a channel, you can specify an AID (application ID)
21:08:45 <mounir> Present+ Garner_Lee
21:08:55 <mounir> PResent+ Siddartha_Pothapragada
21:09:06 <mounir> opoto: we have added methods to transfer an arraybuffer
21:09:13 <mounir> ... there are different usage
21:09:27 <mounir> ... like a JS API building things and sending them to the application
21:09:41 <mounir> opoto: there may be more important usage like the service side
21:09:49 <mounir> ... commands created in the server and transferred to the client
21:09:52 <mounir> ... via the web app
21:10:00 <mounir> ... we have those two methods now to support those usages
21:10:35 <mounir> (the Secure Element draft is being shown and read at the same time:  http://opoto.github.io/secure-element/)
21:11:24 <mounir> opoto: the errors have also been changed to exceptions
21:11:37 <mounir> opoto: the main evolutions come from the access controls
21:11:56 <mounir> ... the good thing with secure elements is that there are
21:12:02 <mounir> ... different security mechanisms to access them
21:12:04 <mounir> ... like pin code
21:12:11 <mounir> ... (etc.)
21:12:33 <mounir> ... there are an additional way issues by GlobalPlatform (showing thing on screen)
21:12:50 <mounir> ... they provide a Secure Element Access Contol
21:12:58 <mounir> ... that filters out requests from client application
21:13:08 <mounir> ... if they are not allowed by an access rule in the secure element
21:13:53 <mounir> opoto: the implementation of this access control requires that the runtime cooperates
21:14:39 <mounir> marcosc: what's the license of that specification? because I it is asking me creepy things
21:14:47 <mounir> ... is there royalties? is it free to re-use?
21:15:14 <lgombos> lgombos has joined #sysapps
21:15:39 <mounir> (sparse discussion about whether or not it's free of use...)
21:16:20 <mounir> opoto is describing how the previous feature works using a schema
21:16:53 <mounir> opoto: it also means that it is only useful if the runtime is not compromised
21:17:06 <mounir> gmandyam: for the purpose of this API, the access control
21:17:40 <mounir> ... implementation in the secure element isn't important to the
21:17:43 <mounir> ... developers
21:19:14 <mounir> opoto: for these access controls to work, there need to be a
21:19:20 <mounir> ... trusted identifier for the application
21:19:28 <mounir> ... this is where we need to define something specific for this
21:19:34 <mounir> ... specification
21:19:41 <mounir> ... How do we get the trusted identifier for the application?
21:19:49 <mounir> ... the proposal here is based on the signature
21:20:11 <mounir> ... it distinguishes applications based on there protocal
21:20:23 <mounir> ... https vs app, hosted vs packaged
21:20:43 <mounir> ... it is using the signature application based on the
21:20:52 <mounir> ... Widget specification
21:21:14 <mounir> ... in the manifest
21:21:23 <mounir> ... I was told that we could use the distributor signature
21:21:29 <mounir> ... instead of the application signature instead
21:21:39 <mounir> marcosc: you don't need to have the signature in the manifest
21:21:46 <mounir> opoto: where would we get the signature from then?
21:21:56 <mounir> gmandyam: the distributors could inject that in the manifest
21:22:04 <mounir> opoto: altough we define something in the manifest, or we use
21:22:09 <mounir> ... a well-known location
21:22:18 <mounir> ... I have added this option to have an entry in the manifest
21:22:29 <mounir> ... to have an author-signature file
21:23:04 <mounir> opoto: for HTTPS applications, I propose to only use the URI
21:23:08 <mounir> ... as the identifier
21:23:44 <mounir> brad: what about I have a script sourcing evil.com?
21:23:58 <mounir> opoto: in this case, we are not signing the files themselves
21:24:50 <mounir> brad: but even a packaged apps could do that?
21:25:03 <mounir> mounir: the default CSP policy of packaged apps prevent that
21:25:58 <mounir> siddartha: what about web applications that get updated
21:26:03 <mounir> ... over the air after installation?
21:26:16 <mounir> ... for example, I have a wallet application using secure element
21:26:26 <mounir> ... but at some point I update the application
21:26:28 <mounir> ... with a new manifest
21:26:37 <mounir> ... what would the repercusion be on the signature?
21:26:49 <mounir> opoto: actually, I did not give a detailed enough explanation?
21:26:54 <mounir> s/explanation?/explanation
21:27:16 <mounir> opoto: the se_author_signature is not the signature, it's the
21:27:19 <dsr> In principle, the subresourceitegrity spec could be used for hosted apps for scripts. See http://w3c.github.io/webappsec/specs/subresourceintegrity/
21:27:25 <mounir> ... hash of the certificate that was used to compute the
21:27:28 <mounir> ... signature
21:28:23 <Github> Github has joined #sysapps
21:28:23 <Github> [13tcp-udp-sockets] 15ClaesNilsson opened pull request #67: Updated README.md with correct API name and correct link to rendered spe... (06gh-pages...06gh-pages) 02http://git.io/Agh9Uw
21:28:23 <Github> Github has left #sysapps
21:28:31 <Github> Github has joined #sysapps
21:28:31 <Github> [13tcp-udp-sockets] 15ClaesNilsson closed pull request #67: Updated README.md with correct API name and correct link to rendered spe... (06gh-pages...06gh-pages) 02http://git.io/Agh9Uw
21:28:31 <Github> Github has left #sysapps
21:28:32 <Github> Github has joined #sysapps
21:28:32 <Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 2 new commits to 06gh-pages: 02http://git.io/sY0u0w
21:28:32 <Github> 13tcp-udp-sockets/06gh-pages 14b64b3ea 15Claes Nilsson: Updated README.md with correct API name and correct link to rendered specification.
21:28:32 <Github> 13tcp-udp-sockets/06gh-pages 14d17dc8a 15Claes Nilsson: Merge pull request #67 from ClaesNilsson/gh-pages...
21:28:32 <Github> Github has left #sysapps
21:28:51 <mounir> brad: what's under that signature?
21:29:03 <mounir> opoto: the same origin and same path prefix
21:30:34 <mounir> brad: if you say that only application in a scope can access to some things
21:31:23 <mounir> ... you can't make that scope more granular than origin
21:31:37 <mounir> ... basically, https://foo.com/safe/index.html and
21:31:56 <mounir> ... htts://foo.com/~foo/evil.html can access each other
21:32:05 <mounir> ... so if the former has access to the secure element, the
21:32:10 <mounir> ... former could have acess too
21:32:30 <dsr> (Single origin policy as per RFC6454)
21:32:43 <mounir> brad: I would drop this entire hierarchy thing and say that
21:33:03 <lgombos> lgombos has joined #sysapps
21:33:04 <mounir> ... the hierachy is only scheme + host + port (origin)
21:33:35 <bhill2_> http://seclab.stanford.edu/websec/origins/fgo.pdf
21:34:45 <mounir> (mounir and brad rephrases what was said)
21:37:08 <dsr> s/Single/Same/
21:37:38 <mounir> opoto: one thing to note here is that we used the signature of the application
21:37:49 <mounir> ... there could be another option
21:38:02 <mounir> ... which wolud be to use the URI of the application
21:38:07 <mounir> ... as the identifier of the application
21:38:21 <mounir> ... the SHA1 of this URI as the access identifier
21:38:39 <mounir> opoto: it might not give much security in some cases
21:38:44 <mounir> ... like packaged applications
21:39:48 <mounir> (discussions about how the Firefox OS origin field in manifest can make that possible)
21:42:16 <mounir> opoto: for https apps, there are options to sign the entire
21:42:21 <mounir> ... content of the application
21:42:33 <mounir> ... for example, using the latest packaging format (in www-tag)
21:42:40 <mounir> ... the runtime could download all the content and
21:42:43 <mounir> ... sign it
21:43:11 <bhill2_> ISSUE for Secure Element unofficial draft "Resources which URL is not hierarchically below this URI MUST NOT be granted the application's access" implies a finer-grained access control structure than the web grants.  No more than RFC6454 Origin isolation can be achieved in general.
21:43:46 <bhill2_> does this group not use trackbot?
21:44:05 <mounir> bhill2_: we do not
21:44:19 <bhill2_> how can I assure my issue is formally recorded?
21:44:25 <bhill2_> github issue?
21:44:46 <mounir> bhill2_: yes
21:45:22 <terri_> terri_ has joined #sysapps
21:46:01 <mounir> brad: what if I am in a corporate system where I have injected
21:46:07 <mounir> ... CA by my employer?
21:47:46 <mounir> opoto: the idea is just to put the barier a bit higher compared to what is accepted with https, here we enforce that the certificate is valid and issued by a trusted CA
21:48:00 <mounir> ... we do not enforce how the trusted store is managed here
21:48:17 <mounir> siddartha: is there a test suite that you can run against to
21:48:26 <mounir> ... comply against GlobalPlatform?
21:48:39 <mounir> opoto: I think there is a test suite but not specific to SE API
21:48:56 <mounir> siddartha: so the intent of this specification with respect
21:49:46 <mounir> ... to GlobalPlatform is that compliance is required or preferred
21:49:49 <mounir> ... ?
21:50:00 <mounir> opoto: it is mandated (reading that it is a MUST)
21:50:12 <mounir> ???: what the relation between this API and the SIM Alliance API?
21:50:39 <mounir> opoto: this is very close, also the SIM Alliance API is also based on this notion of reader, sessions and channels
21:51:00 <mounir> ... you can implement this API on top of the SIM Alliance API
21:52:16 <jinsong> s/???/Jinsong
21:53:21 <mounir> siddartha: I have a question but we could take that offline too
21:53:36 <mounir> mounir: lets get technical details discussed offline
21:53:49 <mounir> brad: I'm not sure that GlobalPlatform solves the privacy issues
21:53:58 <mounir> ... what's the story here?
21:55:07 <mounir> q?
21:56:44 <mounir> mounir: as you mentioned Olivier, given the discussion we had
21:57:01 <mounir> ... earlier today, we might want to delay the decision wrt
21:59:04 <mounir> ... whether we work on this until the general discussion happens
21:59:15 <mounir> dsr: shouldn't we move this to the sysapps github area?
21:59:29 <mounir> mounir: I think we should keep specs we work on there
21:59:39 <mounir> ... and we do not officialy work on that
22:02:38 <mounir> ACTION: update the sysapps homepage to make it clear to the world what the group is up to
22:03:10 <mounir> Topic: Next F2F
22:10:02 <mounir> dsr: W3C is ogranizing TPAC in October, we need to give some estimate
22:10:19 <mounir> mounir: I think one day would be the most we should do, if we do something, so lets say a day that we might cancel
22:10:23 <mounir> dsr: sounds good
22:10:31 <mounir> dsr: also, what about this unconference
22:10:39 <mounir> ... we might want to set a timeline and define who should be invited
22:10:44 <mounir> mounir: what about June?
22:10:51 <mounir> dsr: early July would be a problem?
22:10:53 <mounir> mounir: not for me
22:10:58 <mounir> dsr: location?
22:11:02 <mounir> mounir: Europe maybe?
22:11:12 <mounir> dsr: who should be invited?
22:11:27 <lgombos> lgombos has joined #sysapps
22:11:29 <mounir> mounir: browsers. We should see if Apple, Microsoft and more Googlers could go
22:11:45 <zolkis> to Europe? you'd rather see them at tpac
22:13:14 <mounir> genelian: what about the current items? should we continue implementing them?
22:13:19 <mounir> mounir: yes, it's fine to do that
22:13:27 <mounir> ... the problem is that it seems that there is no interest to implement
22:13:40 <mounir> ... so feel free to implement and solve our concerns ;)
22:14:07 <zolkis> why are you saying that? well, maybe Intel doesn't count since not browser-maker, just runtime?
22:15:03 <dsr> mounir closes the meeting after thanking Brad for hosting.
22:15:10 <jmajnert> jmajnert has left #sysapps
22:15:10 <dsr> rrsagent, make minutes
22:15:10 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/09-sysapps-minutes.html dsr
22:23:47 <dsr> dsr has joined #sysapps
23:15:30 <lgombos> lgombos has joined #sysapps
23:19:44 <tantek> tantek has joined #sysapps
23:51:54 <terri> terri has joined #sysapps