System Applications Face to Face - 8 April 2014 -- 08 Apr 2014

<anssik> Claes, zolkis, the same, passcode invalid

<anssik> wonsuk, ok, thanks!

<zolkis> not enough privileges to open the log at http://www.w3.org/2014/04/08-sysapps-irc

<wonsuk> https://www.w3.org/wiki/System_Applications:_4th_F2F_Meeting_Agenda#Agenda

<mounir> scribe: mounir

Web Application Manifest

marcosc_: since the last time I saw you, since the manifest spec left this group, I analyzed the UC
... looked at the conventional wisdom, things like authors, etc.
... even though Firefox OS had that kind of information, it was never used (same with Widgets)
... so we reduced the manifest spec to be only things actually used by runtimes instead of any metadata
... We want to make the manifest a tool to leverage webapps so they can be powerful, like installable
... (explains how permissions and signature would work with manifest and packaged apps)

<cdumez> http://manifest.sysapps.org/

marcosc_ is explaining some behaviour of start_url based on the example in manifest.sysapps.org

(discussion paused until we get the phone line connected)

gmandyam: can you share the data of the runtime usage of metadata you mentioned?

<zolkis> zolkis

<anssik> dsr, thanks for fixing the conf :)

(phone is fixed)

(marcosc_ summarized what he was saying)

marcosc_: the big giant hole in that is obviously offline, appcache is there but not enough
... but hopefully we have serviceworker

<marcosc_> https://github.com/w3c/manifest/blob/gh-pages/README.md

marcosc_: in the readme file, we have the v1 and v2 goals

(marcosc_ is listing the v2 goals)

(... from the link above)

<anssik> v1: https://github.com/w3c/manifest/issues?labels=V1&page=1&state=open

<anssik> v2: https://github.com/w3c/manifest/issues?labels=V2&page=1&state=open

marcosc_: what happens if you load the manifest async regarding to csp policy? because you have already loaded scripts
... the manifest is an unblocking resource that you load after the load event so if there is a CSP policy, given that the manifest is not part of the critical path, it might create a different behaviour at the second load
... service worker would have a similar problem

brad: so far the answer is that the meta tag has to be loaded ahead
... we started with only headers to kind of avoid that kind of issues

anssik: I think that CSP1.1 not yet settled on the <meta> behavior

gmandyam: we had a pretty conservative default security policy
... like no default inline

brad: the current spec says that if you have a policy in the header, any meta policy is ignored
... it might be an issue to work trough

marcosc_: we are hoping to past this request feedback from the CSP folks soon on this
... updatable manifest, how to handle when the author update the manifest?

mounir: isn't that in the spec?

marcosc_: yes, but it's loose

mounir: it should be in v1 then?

marcosc_: yes
... HTTP Link Header, this may never happen because there is no much interest but Jonas and Hixie like it
... inline manifest, this could be a future thing if people start doing that

<anssik> Feature Requests: https://github.com/w3c/manifest/issues?labels=Feature+Request&page=1&state=open

marcosc_: splash screens are problematics

mounir: we talked about that a few times and always realized it's not a good idea to do

marcosc_: make installable apps sharable...

opoto: what does sharable mean?

marcosc_: <didn't hear the answer>
... there is then the question of how to do that with the standard track
... we could do a v1 then a v2 or a living document
... there is no decision yet and it's mostly process

opoto: there is no declarative permission requests

marcosc_: no, there is no real need for that for the moment
... and we do not know what's the best approach for this
... we need to look into that

<marcosc_> mounir: the permission model of Sockets is complicated... and it's not yet solved in a non-packaged app. But we still don't know how to bring this to the Web.

<marcosc_> dsr: do we have time to talk about security stuff later in the agenda

<marcosc_> ?

<scribe> scribe: marcosc_

opoto: maybe the manifest is good way to addressing the permissioning problem by gathering things together.

marcosc_: we could go and look at how the permissioning model works in FxOS and in Chrome apps

mounir: I disagree that it's the same. Those things are not quite the Web - so it's a bit different.

brad: there is also iOS and Android. Access control gadgets is work that microsoft did a few years ago that could be relevant for the discussion.
... it's a different model to look at for contrast

dsr: I've been asked to write a white paper about this

<bhill2> actually: Windows Phone and iOS work more like the Access Control Gadget model vs. Android's manifest model

dsr: I have a few months to work on this

marcosc: it would be great if you could work with WebMob IG

<anssik> Dom's work on permissions: https://github.com/dontcallmedom/web-permissions-req/

<bhill2> Link to ACG work: http://research.microsoft.com/apps/pubs/?id=152495

mounir: Dom has also done some work on this

<mounir> s/tome work/some work/

Claes: I don't have much to add right now. However, Marcos talked about making manifest CORS compatible. But I dont' see that there

<mounir> scribe: mounir

marcosc_: you are right, anssik, keneth and I talked of creating a spearate spec for packaged apps to be CORS compatible
... you need an origin member in the manifest that doesn't specify http:// [the protocal] but just the domain

(marcosc explains how the origin value would be checked on the server)

marcosc_: we are using such mechanism in firefox os for packaged apps
... i'm not volunteering to do it but it's doable

Claes: so it should be a separate spec?

marcosc_: yes, I can actually link to the extension point part of the spec

<marcosc_> http://manifest.sysapps.org/#dfn-extension-point

<anssik> [any packaged app specific features are out of scope for the core spec, should use the extension point]

marcosc_: any spec can use that extension point to hook in new features
... it should be little work and pretty trivial

Claes: we can have a look at that and see how that goes based on the needs we have

marcosc_: take a look at firefox os manifest

<marcosc_> https://developer.mozilla.org/en-US/Apps/Build/Manifest#origin

marcosc_: it is tried and tested and used in the wild

Claes: why have a separate specification?

marcosc_: it doesn't make sense for web pages
... it is something that only packaged applications would use

<marcosc_> Claes: we will look at that

<marcosc_> https://github.com/w3c/manifest/issues/161https://github.com/w3c/manifest/issues/161

marcosc_: bug related to servige worker ^

<wonsuk> https://github.com/w3c/manifest/issues/161

marcosc_: datastore defines its own model

Service Worker

<jungkees> https://github.com/slightlyoff/ServiceWorker/

jungkees: we are working on service worker, it is now in the charter of the webapps wg
... the actual work is made on GitHub
... Mozilla, Google and Samsung are working on this
... We are done with the v1 features

<jungkees> http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html

jungkees: the spec is still being drafted
... a servece worker can fetch the resources

jungkees is describing the service worker specification/features to the group

<wonsuk> ?

genelian_: the goal of the task scheduler is to open the app when it is no longer running
... how would service worker do that?

jungkees describes how task scheduler works

jungkees: the idea is to launch a service worker and run the script
... we don't need to open any tab
... within the worker code, the developer can create a notification, for example

cdumez: so every app using task scheduler will have to create a service worker?

jungkees: yes

jungkees explains how a service worker gets woken up by an event after the developer registered for it

jungkees shows example from the service worker GitHub repository

<wonsuk> Push integration example with ServiceWorker: https://github.com/slightlyoff/ServiceWorker/issues/177

opoto: when a web page register a service worker, is there a spec explaining how this is hapenning?
... because this is a service and it is persistent

jungkees: for the initial version, to install the service worker, we should do https only

opoto: it's good to require https but we should inform the user about what's hapenning
... and about the registration, is there any requirement about the display?

jungkees: no

wonsuk: there would be a problem if the web application uses memory uses without the user permission

<Zakim> dsr, you wanted to ask which companies are implementing ServiceWorker and whether this includes mobile devices?

dsr: what companies are implementing service worker? what about mobile device?

jungkees: Mozilla and Google are implementing
... it should be implemented in 2-3 months for a beta version

mounir: on Mobile, the problem is more complicated than desktop because waking up the service would take memory and cpu...

<Zakim> anssik, you wanted to note Chrome Canary has an experimental UI for unregistering SWs meant for debugging purposes only: chrome://serviceworker-internals/

anssik: there is a UI for Canary
... is Google working on a better UI?

mounir: don't know

anssik: developers as well as users might want to be in control of that UI

jungkees: we might want to talk about service worker integration with manifest

mounir: we should keep manifest/service worker integration to the webapps meeting so we don't repeat ourselves

<anssik> http://status.modern.ie/ says Service Workers is Under Consideration

mounir: we might want to move task sceduler to webapps because it will reach a broader audience

<Zakim> anssik, you wanted to ask about the plan for extension points in the SW spec for future events, if not deemed out of scope for this session

anssik: i remember talking to alex about extensions point for the spec
... is there an issue I should follow to track the progress on this?

jungkees: you are talking of application lifecycle events?

anssik: no

jungkees: let's talk about that offline

anssik: it would be good for people that want to build on top of SW

jungkees: yes

<dsr> .... coffee break for 15 minutes ....

Brain storming and discussion about the direction of security and privacy model

<dsr> scribe: dsr

<scribe> scribenick: dsr

Opoto: the web security model today is mostly based upon the document origin, but we now need to consider system applications.
... There could be access to sensitive data including credential stores. We need some form of access control for sensitive APIs, and to identify that an application can be trusted. This is missing today.

<terri> dsr: is that really the zakim code? I'm not able to join.

Wonsuk: we need to use existing mechanisms or we need to look for new ways based upon the principles of the Web
... in my opinion package signing would not be good, as it doesn't work well with hyperlinking
... hosted apps gets you the latest version, but this isn't the case for packaged apps.
... we can have security mechanisms for packaged and hosted apps, but my focus is on hosted apps, and to cover packaged apps as corner cases.
... Vendors are using their own signed package schemes

opoto: we should try to find a common security/trust model for packaged and hosted apps.

Mounir: this has proven to be hard in practice, you can't trust websites much

Marcos: I am not sure agree. It is a very challenging problem. The web security model is deeply embedded into the browser code, so we need to align with the origin model.
... I am optimistic that we will eventually be able to address, but it will take more than the people in this room.

opoto: do we agree that there is a need for this?

Marcos: absolutely, yes!
... The Node community are also interested in this. However, there are huge UX challenges.
... normal users won't want to see technical permission dialogs
... people are using iOS and Android and the World hasn't collapsed.

Mournir: there is a difference due to the ease of following a link. There isn't the same curated app store model.

opoto: do you see this being done in SysApps?

Marcos: we need to deal with this in a broader community. The HTML WG is still some way to go before addressing this.
... current focus is on extending the markup, HTML6 primarily about web components, and further work on expanding scope of CSS.
... we don't have all of the major players here in SysApps. Previous efforts e.g. Bondi didn't work out as they didn't involve sufficient range of stakeholders.

Giri: it is about how apps are distributed and it has proven hard to reconcile different approaches.

Marcos: the packaged app approach hasn't worked out, so we should focus more on hosted apps and approach matters from the web security model perspective and try to embrace packaged apps as there is a clear demand for them.

<gmandyam> Slight modification: I think BONDI didn't solve the security/permission/signing problem was because the platforms that existed at the time were so different i ntheir approaches that it was difficult to commonalize.

Marcos talks about phonegap experience.

Dave: automotive domain where web apps are starting to appear in cars, these folks are seeking guidance

Marcos: suggest looking at best commercial experience and experiment, but trying to experiment in a standards body isn't a recipe for success
... there are lots of things you can look at e.g. widgets

Wonsuk: I had a private meeting last week with Mozilla and Google, and they are also interested in moving this forward.
... What things can we progress within the existing web security model (same origin), and what things would break that e.g. raw sockets.
... We should clarify which APIs can fit within the existing model
... We need to go step by step

lgombos: it is likely that many of the SysApps APIs will break the same origin model

Mounir: perhaps all of them except task scheduler

ServiceWorker is interesting in how it relates to the security model

Jungkee: maybe we can try to come up with a solution for APIs that break the sandbox model

Wonsuk: I attended the W3C TAG meeting last week, one idea that came up was to use the website's reputation

Marcos: Alex has been throwing around the idea that if a site meets sufficient criteria, e.g. uses SSL, has been used so many times etc. then it is more likely to be trusted.

Mounir: some APIs should be limited to https, e.g. geolocation
... for apps that include a manifest, that in its own merits some trust
... the push API is not about sensitive data

jinsong: my understanding is that there is 2 levels of security for the web -- hosted and packaged
... I have been learning about work relating to this in China. They want to protect user's privacy/security. They didn't accept the use of pop-ups
... They have the notion of certified apps, and they require explicit user confirmation for sensitive APIs e.g, access to camera or microphone.
... They also need a means to allow users to switch on and off app permissions.

Marcos: iOS allows you to alter privacy settings in an app specific way.

opoto: this relies on users to control security which isn't very effective for everyone

Marcos: on iOS this can be many levels deep in the settings

opto: it is also unclear how changing the settings effect the application

Dave: maybe there is a market for 3rd party tools for monitoring and managing your security as a way to get around individual users level of technical savvy

<Zakim> anssik, you wanted to note https://developer.mozilla.org/en/docs/The_Places_frecency_algorithm et al.

Jinsong: there are indeed tools for monitoring what apps are doing, but there is a need for such tools to update the security settings for apps.

<anssik> another interesting research-y area is http://en.wikipedia.org/wiki/Reputation_system

Anssi: I've droped a link to work that looks at the frecency at which you've visited a site, and it would be interesting to combine with reputation. This still feels like a research areas for innovation before we start on standardization.

<anssik> The word "frecency" itself is a combination of the words "frequency" and "recency."

Dave: is there any work on being able to sign hosted apps?

Marcos: for FirefoxOS you can only sign packaged apps

<anssik> [ The frecency algorithm https://developer.mozilla.org/en/docs/The_Places_frecency_algorithm ]

Wonsuk: hosted apps keep changing which creates challenges for signing

Dave: you can make signing dynamic as a work around when needed

Maros: Anders R. has some ideas

<lgombos> slightly related work - http://w3c.github.io/webappsec/specs/subresourceintegrity/

Brad: scaling issues, e.g. with certificate expiry, competing approaches, but these generally haven't mapped well into the Web space.

Marco talks about the experience during work on the widget spec

<jungkees> Packaging on the web discussed last week: http://oksoclap.com/p/packaging-on-the-web

opoto: most of the sysapps APIs require a solution so we are faced with a real challenge!

Marcos: yes, Adam B. insisted we work on the security model for SysApps, but we have not lived up to that
... we break for lunch and will resume at 1pm PST ...

<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 3 new commits to 06gh-pages: 02http://git.io/QS_55g

<Github> 13tcp-udp-sockets/06gh-pages 14d1d6956 15Claes Nilsson: interface UDPSocket rewritten to be based on Streams API

<Github> 13tcp-udp-sockets/06gh-pages 140600e85 15Claes Nilsson: Updates according to comments bt Domenic.

<Github> 13tcp-udp-sockets/06gh-pages 14690a29c 15Claes Nilsson: Merge pull request #64 from ClaesNilsson/gh-pages...

<Github> [13tcp-udp-sockets] 15ClaesNilsson opened pull request #65: Corrections (06gh-pages...06gh-pages) 02http://git.io/Bk2ykQ

<Github> [13tcp-udp-sockets] 15ClaesNilsson closed pull request #65: Corrections (06gh-pages...06gh-pages) 02http://git.io/Bk2ykQ

<Github> [13tcp-udp-sockets] 15ClaesNilsson pushed 2 new commits to 06gh-pages: 02http://git.io/_8Dd2w

<Github> 13tcp-udp-sockets/06gh-pages 14834186c 15Claes Nilsson: Corrections

<Github> 13tcp-udp-sockets/06gh-pages 14afcbf90 15Claes Nilsson: Merge pull request #65 from ClaesNilsson/gh-pages...

Raw Socket API

<Claes> http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/att-0035/TCP_UDP_Socket_API_based_on_Streams_-_San_Jose_April_2014.pdf

<marcosc> Claes: I sent the presentation to the list

<marcosc> [Claes will walk through his presentations ... slide link forthcoming ]

<mounir> scribe: mounir

<scribe> scribenick: mounir

http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/att-0035/TCP_UDP_Socket_API_based_on_Streams_-_San_Jose_April_2014.pdf

Claes is going trough the slides

Claes: the api name is "TCP and UDP Socket API" because "Raw Sockets" wasn't very clear
... the API is being re-written to be based on Streams API
... the motivation is to handle the complexity of sending, receiving, buffering the backpressure
... there are two Streams API being aligned
... the rebasing work is done on top of WHATWG API instead of W3C Streams API

marcosc: the WHATWG Streams is going to be the primitive Streams API for the platform
... which is going to be moved te ECMAScript
... the W3C spec is going to be on top of that
... this is a great primitive for a ton of API using Streams

Claes: what's the Streams API?
... it provides an interface for creating, composing and consuming streams of data

Claes read the slides

s/Cleas read /Claes reads /

<terri> I can hear Claes on the bridge fine, so it might be on your end

<marcosc> Claes, I think it might be us

<marcosc> Claes: we are dialing in again

<Claes> ok

Claes continues reading the slides after some phone connectivity issues

Claes: slide 11 is the previous version that is not Stream based
... if we look at the next slide, we have two attributes, one is ReadableStream and the other one is WritableStream

http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/att-0035/TCP_UDP_Socket_API_based_on_Streams_-_San_Jose_April_2014.pdf

Claes continues reading the slides

Claes: the example in slides 16 is using the new TCP interface based on Streams
... input is the writable Stream
... so you are write a text and then if the promise return resolve, you wait for the readable side (output.wait())
... then you receive data
... and read out the data

cdumez: why are we calling the method socketClose() and socketHalfClose()?

Claes: I have actually changed that
... 10 mins ago

opoto: so halfClose() is for closing the input?

Claes: it's for closing the writable side indeed

opoto: shouldn't the close() be on the writable stream interface?

Claes: input.close() is a possibility
... ppl familiar with TCP Socket are familiar with halfClose() term

gmandyam: is server socket stable or do you plan similar changes on that?

Claes: yes

marcosc: what are your plans from here wrt this?

Claes: finish the specification and have a prototype implementation
... I can't promise that I will have time to do the implementation
... but I hope that it could be done by someone else
... any voluntary resource would be appreciated

marcosc: as a reference it might be possible to wrap the Firefox OS API

anssik: we have some persons interested in this and could write an experimental implementation

marcosc: you go to the whatwg streams repo, you can find a reference implementation there

marcosc is looking for a link

<marcosc> https://github.com/whatwg/streams/tree/master/reference-implementation

<Zakim> anssik, you wanted to ask whether one could wrap the previous iteration of the API?

Claes: we should see if it could be implemented on top of Firefox OS TCP API
... I will check some alternatives and come back on that

mounir: implementation status?

anssik: we are interested but we implement the previous one

marcosc: we are watching and seeing

lgombos: what's the story regarding permission for TCP/UDP?

Claes: this relates to the discussion we had before lunch
... it has to be a store security model, we can't do a simple security model
... it opens up too much stuff
... we have to relate to the discussion for security/privacy

lgombos: are you saying that it belongs to the spec but we can't spec it out?
... or do you mean that it's outside of the specification?

Claes: it's a sensitive api like other apis

mounir: to answer lgombos' question, I think this is bigger than the spec

jungkees: I think lgombos' question was more that we currently have a specification but no permission model for it, so what should we do with it?

Application Management API

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/att-0041/AppManagementAPI.pdf

<wonsuk> slide: https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=53293ca563&view=att&th=1454160492b8137f&attid=0.1&disp=inline&safe=1&zw&saduie=AG9B_P_9ZyqSId_uZvO2K-Bes8iX&sadet=1396990101753&sads=g8k7O62q8uIis8Xvs13F4IwtVHo

Claes reads the slides

Claes: so that's the proposal, any comment?

mounir: I don't think we should work on that

marcosc: I will send my comments to the list and give my rational on that
... on firefox os there is an alternative screen homescreen

<scribe> scribe: marcosc

<scribe> scribenick: marcosc

mounir: I also wanted to point out that this API is very closly tied to the permission and security model. So moving it forward might complicate things further with regards security. The APIs are very very different and they have very limited interop. It might be too optimistic/early to try to standardize this.

lgombos: is the entire set of use cases related to security - or can there be a subset that is more limited that we all have agreement on?

Claes: maybe that would be good

mounir: I don't know if we can find such a baseline

<anssik> we had an API in the Manifest to "install" an app, but dropped it based on feedback

mounir: there is complexity with regards to the kinds of apps your can launch (priveliged vs hosted, etc.)

lgombos: the thing that we hate on the web is getting a bunch of install buttons for native apps

mounir: as anssik said, we had an API, but now we dropped it because it's better to let the browser handle it.
... I'm not saying this is the final thing, but we should experiment in the browsers first

lgombos: the initial intent of this API was to allow people to create a store, but I agree that that is very ambitious

<mounir> scribe: marcosc

<mounir> scribenick: marcosc

<mounir> scribe: mounir

<scribe> scribenick: mounir

marcosc: I personally wouldn't want to have us work on this
... like Mounir said earlier, it goes back to the manifest
... that could be used as a start, using that metadata
... to build a store site and share half the metadata with
... the store and the application itself

mounir and marcosc chats about things and how the web could be better

marcosc: it's complicated
... that's my perspective
... I'm not in favour in working on this or bringing this to the group

RESOLUTION: the group believes it is not ready to start working on that deliverable

break - 10 mins - 14:20

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

Task Scheduler

<wonsuk> http://www.w3.org/2012/sysapps/web-alarms/

cdumez: let's review the requirements section
... an application can only access its own scheduled tasks
... a task id must be unique within its origin
... a scheduled task must be restorted at restart
... a scheduled task must wake the system
... a scheduled task that was supposed to run when the system was shutdown must run at startup

mounir: I think we sholud say that if you miss a task you should run it ASAP

<zolkis> i.e. instead of "must" use "should"?

cdumez continues reading the list of requirements

cdumez: but there is uninstalled mentions here
... which doesn't really exist anymore

<zolkis> say if you leave the phone off for two weeks, then you switch on, and get all missed daily alarms?

marcosc: what owns the tasks? what is an application? should that be the service worker? the origin? the document?

jungkees: we might want to use the service worker scope

marcosc: we could go further and make this only apply in the context of service worker

cdumez: but we should be able to register from the page

marcosc: but then you need to pass a service worker when you register the task

cdumez: I didn't understand that was needed

genelian: so the timezone issue is covered by item #6, right?

cdumez: timezone change is indeed

<Zakim> anssik, you wanted to ask about plans to expose TaskScheduler in ServiceWorkerGlobalScope

anssik: it seems that we reach a consensus here

marcosc: we need to ask the service worker people

<scribe> ACTION: cdumez will change the requirements to specify that a missing task must be restored (regardless of why it was missed) [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action01]

<scribe> ACTION: cdumez will investigate how to correctly plug the API to Service Worker - probably using the Thursday session [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action02]

discussions about service worker and how it works

<scribe> ACTION: make the task scheduler task not aware of application install/uninstall - use SW unregistration instead of uninstall [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action03]

mounir: is Mozilla implementing the spec?

genelian: no, we are still using our old version

cdumez: there is an open bug about adding a privacy and security issue section

marcosc: I believe Jonas sent an email about that a year ago

cdumez: okay

<scribe> ACTION: cdumez should write a privacy and security issues [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action04]

App-URI

marcosc makes odd sounds

marcosc: after not looking at this for a couple of months, I read it again
... and layered it on top of fetch

<wonsuk> http://www.w3.org/2012/sysapps/app-uri/

marcosc: the result of doing that is that the spec reduced quite a lot
... as hoped
... there is like no spec now, it's like five sentences
... all I need to do is to handle the scheme
... the URL spec handles all the parsing
... and the fetch spec all the parsing
... I sent a pull request to Anne to plug 'app' in the fetch spec
... anne might tell me to take a hike

genelian: aren't you guys in the same team?

marcosc: literally, yes

opoto: regarding the instance identifier, you said that it could be provided by the developer, do you have any more information?

marcosc: in the manifest, we spake about the 'origin' thing, in that case we would use that component

brad: does that mean that I can access an app's resources if I set 'origin'?

mounir: no because you will be http vs app, so the domain/sub-domain would be the same but not the protocal wrt origin

brad: it would be interesting to discuss that in the context of subresourceintegrity from webappssec

marcosc: that's the current status, still waiting for anne's answer

gmandyam: what would be the handle?
... would the entire spec move in fetch?

marcosc: no, just a part of it

<dsr> http://w3c.github.io/webappsec/specs/subresourceintegrity/

mounir: implementation status?

marcosc: firefox os implements it
... not exactly the same but could be changed to match
... if there is interest

lgombos: and crosswalk too

<anssik> I can confirm Crosswalk implements the spec

marcosc: it would be interested to see how it's done in crosswalk

<Zakim> anssik, you wanted to ask whether there is a test suite (planned) for the Fetch spec?

anssik: is there a test suite for the fetch spec?

marcosc: I imagine that there will be but fetch just captures what the web currently does
... in term of test suite, there will be an actual api for fetch
... Look at fetch as a meta spec that describes the behaviour of the web
... however, there is a test suite for the app uri that Marta has build - she did a very nice job there

<anssik> we can look at that if there's something to improve

marcosc: that spec is sitting on the w3c web platform test repo waiting review
... and I've been too lazy to review it

<anssik> pointer?

<marcosc> https://github.com/w3c/web-platform-tests/pull/325

<anssik> ok, we're already looking at that then :)

ack

<Zakim> mounir, you wanted to ask what's the added value of that spec

mounir: what's the added value of that spec?

marcosc: given that the platform does not define how to deal with local resources
... given the security and privacy issues of using the file://
... (like iOS will show the username)
... we avoid some of those issues
... we also get the added benefit of using the web platform technology
... without that you can't use xhr
... localstorage
... (because of missing origin)

mounir: this is the value of having a scheme, but not an interoperable one

marcosc: the hole purpose is having the same behaviour, not the name

Task Scheduler API

genelian: I just recall why we kept the respect-timezone part of the api
... it seems that your api only need the absolute change
... how can you get the new timezone?

<scribe> ACTION: cdumez will look at how native platforms handle the alarms wrt timezone [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action05]

<scribe> ACTION: mounir will look at how Android handle the alarm clock features like week-ends and week days and what API is used for alarms [recorded in http://www.w3.org/2014/04/08-sysapps-minutes.html#action06]

<dsr> Android's alarm clock distinguishes weekends from weekdays, what do they rely on to achieve that?

we are done for today

thank you all

- DRAFT -

System Applications Face to Face - 8 April 2014

08 Apr 2014

Attendees

Contents

Web Application Manifest

Service Worker

Brain storming and discussion about the direction of security and privacy model

Raw Socket API

Application Management API

Task Scheduler

App-URI

Task Scheduler API

Summary of Action Items

Scribe.perl diagnostic output