See also: IRC log
<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? :)
<anssik> zolkis: try redialing, should work now
<zolkis> Present Zoltan_Kis
<genelian_> Data Store API spec: http://airpingu.github.io/data-store-api/index.html
<genelian_> Data Store API slides: https://www.w3.org/wiki/images/e/e1/DataStoreAPI.pdf
<zolkis> anssi: +1
anssik: lets move the charter
... before lunch
mounir: I moved the charter
discussion to the morning
... and the afterneen session is starting at 13.30 instead of 13.00
<anssik> excellent, thank you
mounir: done, next topic is Data Store
<scribe> scribe: mounir
<scribe> scribenick: mounir
genelian_: we discussed this
specification in the past
... with some other editors too
... so, what does DataStore API do?
... in the past, SMSManager, MMSManager and other
... specification had a filtering mechanism described
... but it couldn't fulfil all applications needs
... this kind of API doesn't work well for third party apps
... we had to design a DataStore API for those
... you can see the different methods [on the screen]
... you can add, remove, update and finally sync data
... sync allow you to sync between the DataStore and your
... local storage
genelian_ describes a figure on the screen
gmandyam: how do you handle when two apps want to own the same datastore?
genelian_: there will be only one app
<zolkis> genelian_, raise an issue about concurrent access
gmandyam: so the app would not be installed if you try to own the same store?
mounir: we should not prevent an
app to get installed for
... something in the manifest
<zolkis> I would separate whether the app is installed (which is a policy) from handling concurrency
marcos: the readonly access thing scares me
cdumez: but facebook might not want to share readwrite
marcos: but it's a user decision, not a developer decision
cdumez: no, apps might not allow other apps to write their data
<zolkis> manifest and permissions is subject to more work, see also https://github.com/airpingu/data-store-api/issues/18
genelian_ continues reading the slides
genelian_: the local app will
keep its own index and have to handle the synchronization
... something else that you need to know is that the app only need
... to maintain the searches criteria
... no need to index the entire data store but only the attributes
... you care about
genelian_ goes trough an example on the screen
<zolkis> it would be nice to give examples for app makers on how to do the indexing
<zolkis> the examples given for messaging are not the best; I have described in issue #18
genelian_ is going trough another example (slide 7)
<zolkis> I suggest we decide that we will use DataStore in Messaging, do the implementation, and modify DataStore on need
discussion around synchronization based on the example on the screen
<zolkis> main points being? :)
marcos: we should have a way to just plug any data source to an IndexedDB
cdumez: so then it would duplicate the hole thing, right?
marcosc: indeed, it will. Maybe it could only duplicate what is needed
gmandyam: IDB has to be
... this is different because we have declared access in the manifest
marcosc: at some point it ends up in a database anyway
gmandyam: after we had our f2f, I
realised that you guys are using IDB for the apps storage in
... and then we understood why access was so long
marcosc: maybe if it is readonly you could not duplicate the data?
zolkis: how do you describe what you need?
marcosc: maybe with the initial query to it?
cdumez: I don't really want to force the app to use IDB
<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
cdumez: how much data they store
and how they do should be up to the implementation
... so they can do exactly what they want
... IDB is not about querying, it's a key-value database
<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.
mounir: we should move on
<zolkis> gmandyam: I agree, the spec should not require building on IndexedDB, but binding a DataStore to an IndexedDB may be worth exploring
dsr: should we update the charter?
gmandyam: it might be in scope with contacts
<zolkis> me says too many discussions there, please one speak at the time, and use the speaker queue
wonsuk: in my opinion, it is case
... there is no data store api in the charter
... so in my opinion, we should make it more clearly in the charter
... we should change the charter
anssik: can the owner limit the access to other apps to readonly?
<anssik> can the owner manage the privileges the other apps have, e.g. limit others to read only
anssik: it seems that the
permissions are managed in the manifest
... but that doesn't scale
<zolkis> anssik, see a proposal in https://github.com/airpingu/data-store-api/issues/18#issuecomment-39950300
genelian_: an owner can specify
the whether the data store is readonly or readwrite
... but can't have a fine grained permission model
... regarding which app can access the data store
<anssik> thanks for the clarification
<anssik> that answered my question
<zolkis> I am talking
cdumez: how does that work (sync)? how do you prevent races?
genelian_: if an app call the
sync function, you will get the sync changes
cdumez: that's why there is a close() method?
<zolkis> has to go by chat
<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
<zolkis> I am not convinced that the replay mechanism is the best for sync
<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
mounir: zolkis are there issues opens?
<zolkis> more and more :)
mounir: we can't raise official actions given that its not an official WG item
<zolkis> but we should start implementing this and see on the way
cdumez: I will just talk with genelian_ offline, those are editorial issues
mounir: we are way behind
schedule, we should speed up and move to the next item
... we sholud do Contacts Manager and have a break after that
cdumez: is someone from telefonica joining?
mounir: I would have assumed so
but they are not on the line
... you should start
cdumez: there are a few changes
since the last meeting
... one of the bugs was that we were not using Promises correctly
... right now, when we construct a contact, we add the contact
... to the database and create an id
... I think we should create the id after the contact is actually
mounir: do you have a list of issues to go trough?
cdumez: there is only two issues
<scribe> ACTION: eduardo should review https://github.com/sysapps/contacts-manager-api/pull/60 [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action01]
<cdumez> Second issue: https://github.com/sysapps/contacts-manager-api/issues/62
cdumez: the issue here is how do
we know which DataStore is the default one?
... we need a system one but which one is that going to be?
... the first one?
mounir: the owner field in DataStore should have a special value when the store is coming from the system
cdumez describes his fork of the current ED of contacts api that is using datastore
cdumez: if genelian_ can confirm if this is the idea, that would be great
wonsuk: was that been reviewed by other editors?
cdumez: not yet, it's quite
... otherwise, I think that Eduardo made the same comment: we are both in favour of updating the api to use datastore
... so that's about it
dsr: are you going to merge this?
cdumez: once this is cleared with
eduardo and genelian_ I will make a PR
... but I have trouble getting changes merged these days
<Zakim> mounir, you wanted to ask what the current involvment
<zolkis> cdumez, let's work on DataStore related issues together with the Messaging API (Eduardo also involved)
<scribe> scribe: marcosc
<mounir> scribenic: marcosc
mounir: you say you have a hard time to get changes getting merged
cdumez: yeah, it took like 5 months to get things merged
<zolkis> Intel is going to implement Contacts API on Crosswalk
<anssik> if there's a spec that is complete and good quality we'll implement in Crosswalk
<dsr> scribe: dsr
<Zakim> anssik, you wanted to note Contact, ContactField, ContactTelField etc. are exposed to the global, in total 6 interfaces
Anssi: we need a decision on exposing Contact, ContactField, ContactTelField etc. to the global
cdumez: so you're fine keeping it this way with global constructors?
Anssi: I think we can keep it as is, you have good reasons ...
<zolkis> Bluetooth PBAP support?
Zoltan: a question would be to
create a bluetooth profile
... we have some use cases for this, I know bluetooth is in phase2, but ...
<zolkis> 2 ways to implement:
<zolkis> either integrated in Contacts/ Messaging
<zolkis> or we design separate API's
wonsuk: do you know what is needed for adding bluetooth support?
zoltan: it depends on the middleware, e.g.bluez
<zolkis> we are using bluez/obex for implementing PBAP
<zolkis> I will change my client :)
<zolkis> I finished commenting.
cdumez: contacts was previously limited to one data source, but with the switch to using the datastore API we can use many
<zolkis> actually there could be a separate store for each device connected via Bluetoot
<mounir> ACTION: cdumez should investigate how the Contacts API should integrate with Bluetooth [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action02]
cdumez: so in principle, an app
could take contacts from bluetooth and put them into the shared
... I was hoping that the datastore API could be published
<mounir> 10 mins break
<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
<zolkis> here, no voice
<zolkis> Messaging needs to be updated with DataStore. No other major outstanding issues
<zolkis> So, this one is quick: no major obstacles on Messaging. Questions?
Mounir: what's the implementation status?
Laszlo: we working on it ...
<zolkis> I am implementing it for Tizen and we have an Android implementation (both on Crosswalk)
Wonsuk: in respect to tizen, we're interested in the implementation, but before making the decision we're looking for a stable version of the spec with consensus at W3C
Gene: we haven't yet updated our implementation
<zolkis> looks like my phone call is hung at the bridge, and I cannot dial in!
<zolkis> any other comments on Messaging?
<zolkis> moving to Telephony?
<zolkis> no pun intended :D
yes, that's the idea
<anssik> zakim drop anssik
<zolkis> ok, here is my report: http://lists.w3.org/Archives/Public/public-sysapps/2014Feb/0034.html
<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)
<zolkis> on implementation: it has low priority right now (except Call History), but the plan is that we implement the API
Mounir: please q+ with your questions
<zolkis> I propose we do this on IRC - sorry for this
<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
<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
<zolkis> then, the original use case of supporting 3rd party dialers is being challenged now
Mounir: implementation status?
<zolkis> I have made the Telephony spec really close now to the Mozilla API, to ease adoption
Marcos: as far as I know, Mozilla has no plans to implement the telephony API
Mounir: what about Samsung?
Mounir: so no one other than Intel has any plans to implement this in the short term?
<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 :)
<zolkis> Personally I would be fine with 3 use cases concerning telephony:
Mounir: Zoltan, is Intel interested in exposing the telephony API to 3rd parties?
<zolkis> 1. start the native dialer with a number + dtmf
<zolkis> 2. is there a call in the system and what resources is it using
<zolkis> 3. call history as DataStore source
Mounir: for FirefoxOS telephony is for internal apps only, not 3rd parties
<zolkis> mounir: I need to check with Wayne, but when we started this work, the idea was to expose this to 3rd party developers
<zolkis> yes, use case 1 does not require a telephony API
<zolkis> and use case 2 can be done in a system info type of API
Some discussion about which organizations support the tel: URL scheme
<zolkis> use case 3 is a must, and it would be good to standardize
<zolkis> OK. But this API is about a different thing.
<gmandyam> All implementations seem to support tel:URL the way it was intended.
Mounir: how can you access call history from Tizen?
Chris: There is an API for this in Tizen
<zolkis> so, the question is, could we keep the Telephony API in the works?
<zolkis> We are interested in it, and nowadays I am the only one who is doing some work on it
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
<Zakim> wonsuk, you wanted to in the aspect implementation, dose Mozilla has a plan for that?
<zolkis> please reset the phone... :) it is having ghost calls
<zolkis> what seems to happen is that Asterisk (behind Zakim) has one side of the bridge up
<zolkis> someone needs to restart the daemon
<zolkis> or allocate a different conference
<zolkis> yes, the service times out
<zolkis> so, let's go on and we rely on the scribes
<zolkis> or everybody types :)
<mounir> Zakim drops [Paypal]
<opoto> new dial in: +12153674444 (US) +358981710447 (Finland) conference ID: 84905672
<opoto> (can provide other countries on demand)
<zolkis> Thanks a lot opoto! I dialed in, waiting for the leader :)
<zolkis> I hear your conversations :)
<zolkis> link to charter?
Mounir: let's start with telelphony, but before that ...
Mounir summarises the current situation
scribe: we would like to add
DataStore, but in general we need implementation support for
... if telephony is only used by internal apps, then interoperability is not an issue
Mounir: I would prefer to drop
the specs where we aren't seeing broad implementation
... 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
... Moving such APIs to W3C standards has low benefit, so maybe we should focus on APIs that have broader interest
Anssi: Mounir that was a good
summary. Specs designed around the web security model have been
shown to move faster (in DAP WG)
... the App LifeCycle spec is currently dormant waiting for progress on ServiceWorker
Anssik: Dave a couple on months
ago asked about interest in a workshop on permissions and
marketplaces and that could be a valuable activity
... For SysApps, we should focus on a very small number of specs that could be moved forward efficiently
... with interest from the implementers
<anssik> I'm very interested in trying to address the permission model problem in the browser context
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
Zoltan: I definitely see value in
messaging and telephony APIs, and making sure that this work is
... 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
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
Anssi: these can be restored to a Working Draft if the WG deems it appropriate
Zoltan: I think we could gracefully retire the telephony spec, it is now ready for implementation feedback, there were a lot of companies interested.
Anssi: we should give a clear reason when we republished APIs as WG Notes
Olivier: we should clarify 3rd party use cases, without these it is not worth standardizing
Mounir: raw socket is an interesting API, but no one is implementing the spec, so this isn't promising for a standard
<zolkis> well, Intel has implemented the Raw Socket API, so "no one" is not accurate :)
<zolkis> I agree: we are too early with this work. Is there any way to freeze the work without dropping them?
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
Dave: what are developers saying?
<anssik> zolkis, W3C Note is technically freezing, you can resume
Mounir: when developers write apps for each packaged platform that don't care so much about standards, but they do care when they start developing for the web platform
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
Marcos: what is the benefit?
lgombos: some benefits are for
developers and some for the platform vendors
... over time there will come other benefits
<zolkis> lgombos: that is a very good point: platforms do benefit from this work
Mounir: that's the wrong reason, ...
lgombos: we can't expect the same volume of comments as for HTML5, as a lot of the system apps will be niche
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
Marcos: we know that offline apps are very important
Wonsuk: that's clear
Marcos: the installability of web
apps, we've worked on manifest for that
... we need support for large web apps, and are getting there
... we need better performance e.g. for games
lgobos: it is really hard to progress individual APIs unless we progress work on security and permissions
<zolkis> but these can be done in parallel... it is possible to detach a lot of things from security and permission model
Mounir: I think it will be really
hard to reach agreement on the model for packaged apps
... unless people around the table are willing to change their platforms
... 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
Anssi: I have a bunch of statements for the group to consider.
1. do we agree that apps must run on origins, and be part of the Web
2. I think we all believe that web apps need access to more advanced capabilities and features than they currently have
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
4. this is about how we integrate with the host OS, manifest is part of the solution, home screen, etc.
5. offline is crucial for web apps to compete with native apps, service workers is the solution, sysapps wg may not need to do much here. Users must be able to trust web apps
6. the current permissions models are broken and we need to fix that, one promising approach is to ask users in context of use
what do you guys think?
Mounir: I generally agree
Marcos: re (1) origins/part of
the web, I am not clear what the scope that leaves for things
running under AppURI
... everything else I agree with
Dave: do we want to fomalize the agreement on those points?
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
<wonsuk> +1 for Anssi's opinion especially for #1 about origin!
Mounir: making the web more appy not the apps more webby
Zoltan: we don't really have a
scoping problem, more an implementation problem
... I don't understand why we can't use the manifest as part of the permission solution
<anssik> zolkis, see my point 6.
<zolkis> yes, I agree with anssik point 6
Mounir: we don't currently really know how to address the permissioning problem, so progress could take many years
<zolkis> and the other points, too
Mounir: I don't think it is just a matter of dropping work items and continuing with the rest
Zoltan: we should return to ? when we have working implementations
<zolkis> yes, coming...
<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
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.
<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.
Giri: We should be addressing APIs with a different security context than DAP is addressing today
Mounir: your concern is mostly about what if we (SysApps) decide to completely change everything
Dave: rechartering would provide an opportunity to clarify the group's vision and roadmap
Mounir: is there general support for discuss that further (on email)?
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
Dave: surely we want to enable much richer kinds of trusted web apps
Mounir: if web intents come back,
they could be a good solution for contacts
... if we think we can find ways to give web apps richer capabilities that would be good
Marcos: DAP tried a number of
different ways and failed in a good way
... If we show solutions that work well on proprietary platforms, we will then be ready to standardize based on what works
Dave: it sounds like we are risk of fragmenting the web with proprietary silos
Mounir: what is more dangerous is standardizing APIs that aren't widely adopted
APIs for packaged apps fits the proprietary model well
<mounir> mounir: it's more dangerous to add APIs with the idea that they will b implemented
<mounir> ... than adding proprietary APIs to proprietary platforms
<mounir> ... which are not the web
<mounir> ... for example, push API in firefox OS is accessible from hosted apps
<mounir> ... which are in the Web
<mounir> ... but it's hurting the web
<mounir> ... if push was only for packaged apps, Mozilla could experiment without hurting the web
Marcos: we should first sort out core issues before working on device aps
<gmandyam> Any recharter discussion should engage the framework providers (jQuery, Cordova/PG) - they are familiar with what developers need in a trusted framework
cdumez: how about phonegap, this is really popular, so clearly there is a need for APIs that work across OSes
Mounir: SysApps has been going for 2 years, but we aren't seeing people changing their implementations each time the spec changes
Marcos: things are too experimental right now
cdumez: phonegap is a minimal API that covers the intersection of all platforms
Giri: my concern with phonegap is
that it is too bottom up
... it would have been nice if the phonegap guys had stayed involved and provided us with their developer feedback
<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?
<anssik> current status re https://www.w3.org/wiki/Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces
<anssik> do we think this workshop would provide valuable input to the rechartering of this group?
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?
<anssik> if so, could we run this workshop in a more unconference-style (e.g. no formal position papers, expression of interest statements)
Anssi: do you think a workshop would be a good way to set our new course, and to run in an unconference style?
Marcos: we could do a meet up
Anssi: yes that would be fine
Mounir asks Dave if W3C workshops could run unconference style
Anssi: we should name the workshop differently
Mounir: how about web apps and permissions
Giri: or even "trusted web app"
Anssi: SysApps only has 6 months to run, so is it better to recharter now that wait
Dave: better to change course earlier than later
Anssi asks about plans for a whitepaper, this should allow for joint contributions
Dave: yes, this is intended to be a data gathering exercise
Zoltan: starting completely from scratch seems a bit harsh
<zolkis> but sometimes needed
<mounir> RESOLUTION: the group agreed that we should reconsider the future of the group
<mounir> ACTION: mounir will start a thread about the future of the group on the mailing list [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action03]
Zoltan: break for lunch, we will restart at 2pm PST
<anssik> thanks everyone, this was a great brainstorming session
<marcos> Can someone let me in from the side door? :)
<mounir> scribe: mounir
<scribe> scribenick: mounir
opoto: Garner Lee and Siddartha
Pothapragoda are here from DT
... they are implementing something close to Secure Element on Firefox OS
... following the presentation we made during TPAC, we had
... some feedback like security of the API
... for example, how to control access?
... there were other technical points
... that I will cover quickly because they might be too deep
... for the interest of most people here
... when you open a channel, you can specify an AID (application ID)
... we have added methods to transfer an arraybuffer
... there are different usage
... like a JS API building things and sending them to the application
... there may be more important usage like the service side
... commands created in the server and transferred to the client
... via the web app
... we have those two methods now to support those usages
(the Secure Element draft is being shown and read at the same time: http://opoto.github.io/secure-element/)
opoto: the errors have also been
changed to exceptions
... the main evolutions come from the access controls
... the good thing with secure elements is that there are
... different security mechanisms to access them
... like pin code
... there are an additional way issues by GlobalPlatform (showing thing on screen)
... they provide a Secure Element Access Contol
... that filters out requests from client application
... if they are not allowed by an access rule in the secure element
... the implementation of this access control requires that the runtime cooperates
marcosc: what's the license of
that specification? because I it is asking me creepy
... is there royalties? is it free to re-use?
(sparse discussion about whether or not it's free of use...)
opoto is describing how the previous feature works using a schema
opoto: it also means that it is only useful if the runtime is not compromised
gmandyam: for the purpose of this
API, the access control
... implementation in the secure element isn't important to the
opoto: for these access controls
to work, there need to be a
... trusted identifier for the application
... this is where we need to define something specific for this
... How do we get the trusted identifier for the application?
... the proposal here is based on the signature
... it distinguishes applications based on there protocal
... https vs app, hosted vs packaged
... it is using the signature application based on the
... Widget specification
... in the manifest
... I was told that we could use the distributor signature
... instead of the application signature instead
marcosc: you don't need to have the signature in the manifest
opoto: where would we get the signature from then?
gmandyam: the distributors could inject that in the manifest
opoto: altough we define
something in the manifest, or we use
... a well-known location
... I have added this option to have an entry in the manifest
... to have an author-signature file
... for HTTPS applications, I propose to only use the URI
... as the identifier
brad: what about I have a script sourcing evil.com?
opoto: in this case, we are not signing the files themselves
brad: but even a packaged apps could do that?
mounir: the default CSP policy of packaged apps prevent that
siddartha: what about web
applications that get updated
... over the air after installation?
... for example, I have a wallet application using secure element
... but at some point I update the application
... with a new manifest
... what would the repercusion be on the signature?
opoto: actually, I did not give a
detailed enough explanation
... the se_author_signature is not the signature, it's the
<dsr> In principle, the subresourceitegrity spec could be used for hosted apps for scripts. See http://w3c.github.io/webappsec/specs/subresourceintegrity/
opoto: hash of the certificate
that was used to compute the
<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
<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
<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 2 new commits to 06gh-pages: 02http://git.io/sY0u0w
<Github> 13tcp-udp-sockets/06gh-pages 14b64b3ea 15Claes Nilsson: Updated README.md with correct API name and correct link to rendered specification.
<Github> 13tcp-udp-sockets/06gh-pages 14d17dc8a 15Claes Nilsson: Merge pull request #67 from ClaesNilsson/gh-pages...
brad: what's under that signature?
opoto: the same origin and same path prefix
brad: if you say that only
application in a scope can access to some things
... you can't make that scope more granular than origin
... basically, https://foo.com/safe/index.html and
... htts://foo.com/~foo/evil.html can access each other
... so if the former has access to the secure element, the
... former could have acess too
<dsr> (Same origin policy as per RFC6454)
brad: I would drop this entire
hierarchy thing and say that
... the hierachy is only scheme + host + port (origin)
(mounir and brad rephrases what was said)
opoto: one thing to note here is
that we used the signature of the application
... there could be another option
... which wolud be to use the URI of the application
... as the identifier of the application
... the SHA1 of this URI as the access identifier
... it might not give much security in some cases
... like packaged applications
(discussions about how the Firefox OS origin field in manifest can make that possible)
opoto: for https apps, there are
options to sign the entire
... content of the application
... for example, using the latest packaging format (in www-tag)
... the runtime could download all the content and
... sign it
<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.
<bhill2_> does this group not use trackbot?
bhill2_: we do not
<bhill2_> how can I assure my issue is formally recorded?
<bhill2_> github issue?
brad: what if I am in a corporate
system where I have injected
... CA by my employer?
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
... we do not enforce how the trusted store is managed here
siddartha: is there a test suite
that you can run against to
... comply against GlobalPlatform?
opoto: I think there is a test suite but not specific to SE API
siddartha: so the intent of this
specification with respect
... to GlobalPlatform is that compliance is required or preferred
opoto: it is mandated (reading that it is a MUST)
Jinsong: what the relation between this API and the SIM Alliance API?
opoto: this is very close, also
the SIM Alliance API is also based on this notion of reader,
sessions and channels
... you can implement this API on top of the SIM Alliance API
siddartha: I have a question but we could take that offline too
mounir: lets get technical details discussed offline
brad: I'm not sure that
GlobalPlatform solves the privacy issues
... what's the story here?
mounir: as you mentioned Olivier,
given the discussion we had
... earlier today, we might want to delay the decision wrt
... whether we work on this until the general discussion happens
dsr: shouldn't we move this to the sysapps github area?
mounir: I think we should keep
specs we work on there
... and we do not officialy work on that
<scribe> ACTION: update the sysapps homepage to make it clear to the world what the group is up to [recorded in http://www.w3.org/2014/04/09-sysapps-minutes.html#action04]
dsr: W3C is ogranizing TPAC in October, we need to give some estimate
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
dsr: sounds good
... also, what about this unconference
... we might want to set a timeline and define who should be invited
mounir: what about June?
dsr: early July would be a problem?
mounir: not for me
mounir: Europe maybe?
dsr: who should be invited?
mounir: browsers. We should see if Apple, Microsoft and more Googlers could go
<zolkis> to Europe? you'd rather see them at tpac
genelian: what about the current items? should we continue implementing them?
mounir: yes, it's fine to do
... the problem is that it seems that there is no interest to implement
... so feel free to implement and solve our concerns ;)
<zolkis> why are you saying that? well, maybe Intel doesn't count since not browser-maker, just runtime?
<dsr> mounir closes the meeting after thanking Brad for hosting.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/hown /own / Succeeded: s/but that/... but that/ Succeeded: s/to other/the other/ Succeeded: s/data stare/data store/ Succeeded: s/interestde/interested in the implementation/ Succeeded: s/we're working on an API for that/There is an API for this in Tizen/ WARNING: Bad s/// command: s/http://www.w3.org/2012/09/sysapps-wg-charter.html// Succeeded: s/etc./and marketplaces/ Succeeded: s/we trying/trying/ Succeeded: s/for each platform/for each packaged platform/ Succeeded: s/service work/service workers/ Succeeded: s/promising is/promising approach is/ Succeeded: s/form/from/ Succeeded: s/explanation?/explanation/ Succeeded: s/Single/Same/ Succeeded: s/???/Jinsong/ Found Scribe: mounir Inferring ScribeNick: mounir Found ScribeNick: mounir Found Scribe: marcosc Inferring ScribeNick: marcosc Found Scribe: dsr Inferring ScribeNick: dsr Found Scribe: mounir Inferring ScribeNick: mounir Found ScribeNick: mounir Scribes: mounir, marcosc, dsr ScribeNicks: mounir, marcosc, dsr Present: Gene_Lian Dave_Raggett Wonsuk_Lee Anssi_Kostiainen Jungkee_Song Zoltan_Kis Mounir_Lamouri Laszlo_Gombos Olivier_Potonniee Garner_Lee Siddartha_Pothapragada Agenda: https://www.w3.org/wiki/System_Applications:_4th_F2F_Meeting_Agenda#2nd_day_.289th_Wednesday.29 Got date from IRC log name: 09 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/09-sysapps-minutes.html People with action items: cdumez eduardo mounir update[End of scribe.perl diagnostic output]