W3C home > Mailing lists > Public > public-web-mobile@w3.org > November 2013

[minutes] TPAC F2F Nov 14-15

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 19 Nov 2013 12:01:37 +0100
Message-ID: <1384858897.5878.59.camel@cumulustier>
To: public-web-mobile@w3.org

The draft minutes of our F2F last week during TPAC are available at:

and copied as text below; please send corrections and additions to the

More importantly, Natasha compiled a summary of the most salient points
of our discussions at:


                            WebMob TPAC F2F

14 Nov 2013

   See also: [2]IRC log

      [2] http://www.w3.org/2013/11/14-webmob-irc


          Mohammed, Natasha, DKA, Bryan, Mounir, Ruinan, Kotakagi,
          Christine Perey, Tobie, Sangwhan, JonathanJ, DanSun,
          Kenneth, wonsuk, koichi

          Dom, Marcos, Jo


          mounir_, Dan, sangwhan, bryan


     * [3]Topics
         1. [4]First round of focus topics
         2. [5]Update on Coremob Report
         3. [6]Scrolling
         4. [7]Testing
         5. [8]Push API
         6. [9]homescreen bookmarking
         7. [10]API gap
     * [11]Summary of Action Items

   <kotakagi> Intro presented by Natasha

   <Ruinan> [12]http://www.w3.org/wiki/Mobile/Work

     [12] http://www.w3.org/wiki/Mobile/Work

   <schuki> [13]http://www.w3.org/wiki/InternetRelayChat

     [13] http://www.w3.org/wiki/InternetRelayChat

   <Ruinan> [14]http://www.w3.org/2008/04/scribe

     [14] http://www.w3.org/2008/04/scribe

   <schuki> action Natasha to speak to marcos re having no

   <trackbot> Created ACTION-76 - Speak to marcos re having no
   teleconfs [on Natasha Rooney - due 2013-11-21].

   <mounir_> ScribeNick: mounir_

First round of focus topics

   schuki: we are going to discuss a few topics that we discussed
   before because we believe they are important for the web and
   ... we will discuss the history of these topics, the issues
   that exists in current proposals/implementations and new
   work/potential issues
   ... we want to make sure we get some outcome from this work
   ... we will have some guest speakers for some topics
   ... lets begin with the first topic, which is offline
   ... it has been a hot topic here at tpac
   ... if anybody has extra insights, please feel free to raise
   your hands

   <scribe> Scribe: mounir_

   schuki: <describes appcache and localStorage>
   ... <describes what IndexedDB is>
   ... regarding the issues, appcache is hard to use, especially
   for large applications
   ... appcache has a fallback system when there is no network
   ... this method is assumed to be broken
   ... people expect to use the cache first and download in the
   ... this creates strange issues
   ... lot of times with appcache, you have to declare things in
   the server
   ... which is a bit hairy sometimes
   ... local storage seems robust enough but can only use strings

   mounir_: the main issue is that it is actually doing sync

   schuki: regarding IndexedDB, the main problem is the learning
   ... I will go to the new proposals to solve offline
   ... the first one is Service Worker, proposed by Alex, from
   ... <showing the GitHub project>
   ... service worker is more robust that appcache
   ... it is solving the issues so far
   ... my personal opinion is that we should go and implement that
   ... and I would encourage every one to follow the repo
   ... so, how can WebMob help with that?
   ... we could write a testing demo app
   ... any question or comment to the offline conversation?
   ... we will break for 45 minutes because the next topic
   involves Bryan Sullivan and he is not here yet
   ... thank you everyone

Update on Coremob Report

   <dka> Scribe: Dan

   <dka> ScribeNick: dka

   NR: We are evolution of the CoreMob group.


     [15] http://coremob.github.io/coremob-2012/FR-coremob-20130131.html

   NR: [presents the CoreMob report]
   ... Since the report was published, geolocation and video are

   dan: what does that mean? can we wait until marcus comes online
   to clarify?

   koichi: [speaking of yesterday's geolocation session]


     [16] http://www.w3.org/wiki/TPAC2013/session-geolocation#Notes

   koichi: [making reference to yesterday's TPAC breakout on
   geolocation - and nest steps for geo API]

   NR: I will add this as a note to the github.
   ... Marcus has raised a number of issues associated with the
   coremob report. He's flagged a few of them as needing review -
   meaning priority is higher. This give us the opportunity to
   make further comments.


     [17] https://github.com/w3c-webmob/coremob-report


     [18] http://coremob.github.io/coremob-2012/FR-coremob-20130131.html

   NR: is this report applicable to what we do, or should we
   create something else?

   dka: I think we should not issue a new report, but rather we
   should move forward on the basis of this report. Possibly we
   should consider the issues raised and issue a new version.

   NR: [more description of CoreMob report]
   ... [ presenting www.w3.org/Mobile/mobile-web-app-state/ ]
   ... this is a way to keep up to date with the specifications...
   ... [going through some additional comments]

   <schuki> [19]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face

     [19] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face



   <schuki> 3 options to move forward:

   <schuki> 1. continue to build the report

   <schuki> 2. leave the report as it is and work on a new coremob
   2013 / 2014 doc

   <schuki> 3. leave the report as it is and work on

   tobie: having edited coremob report. There is some overlap
   between coremob report and Dom's report (mobile web app state).
   One reason I started it was to have the info in one place on
   status of specs and implementations that we care about for
   ... I don't think publishing a document is the best thing -
   rather something with a shorter lifespan. Maybe something
   slightly different - a central place that people can look at -
   what's missing, what's the state and what should people look
   at? I would try to merge these two documents.

   <schuki> +1

   NR: A document is pretty static...

   tobie: another point - I've been building infrastructure to
   make a document be a more live doc - there is info on the state
   of specs available via an API - a document could have fresh
   data on the state of certain APIs and so be up to date all the

   NR: that would be awesome.


   NR: any suggestions on keeping up to date with implementations?

   tobie: this is related to running tests - I am leading this
   effort to have a system to make it easy to run the test suites
   people are building for each stack and make it easy for mobile
   industry to run these tests internally, in a single place, with
   an API - which could be build upon to show what the "state of
   the union" is - we need resources to continue to this work.

   <tobie> dka: we should wait for dom to make a decision on this

   Mounir: if you go to chromestatus.com you have a huge list of
   features you can reference in chrome.

   <tobie> … also see if there are info from the current vendors
   available we could leverage.

   <schuki> [21]http://www.chromestatus.com/features

     [21] http://www.chromestatus.com/features

   NR: we could pull this kind of thing into automatically update
   the document that we choose...

   dka: what does it mean to have a live document?

   NR: I'd like to choose one or the other - my preference would
   be to continue with the webapp state document.
   ... we can manually add to it in the short term, incorporate
   material from other sources with the goal having it be
   completely automated.

   <schuki> action Natasha to check coremob and webappstate doc
   include the same spec

   <trackbot> Created ACTION-77 - Check coremob and webappstate
   doc include the same spec [on Natasha Rooney - due 2013-11-21].

   dka: do we update the coremob doc to point to mobile web app
   state? and does mobile web app state contain all the same specs
   as coremob?

   <schuki> action natasha to check with dom whether we can
   discontinue coremob and just work on webappstate

   <trackbot> Created ACTION-78 - Check with dom whether we can
   discontinue coremob and just work on webappstate [on Natasha
   Rooney - due 2013-11-21].

   <schuki> action natasha to check status of chromestatus +
   testing effort and see if we can add apis to manage the
   webappstate document automatically (long term goal)

   <trackbot> Created ACTION-79 - Check status of chromestatus +
   testing effort and see if we can add apis to manage the
   webappstate document automatically (long term goal) [on Natasha
   Rooney - due 2013-11-21].

   NR: if people are interested in working on webapp state
   document or coremob doc - then please let us know.

   dka: how are we going to continue the work of coremob? e.g. for
   new use cases, new features, new specs, etc...

   NR: we are going to work on focus topics, e.g. offline, spec is
   service worker, service worker spec will be included into this

   dka: where will we document the use cases that come out of the
   focus topics?

   NR: there is no need to work on use cases or requirements for
   these focus topics...
   ... we can continue to write scenarios such as in the coremob
   document - we can say "we thing web apps should be able to do
   XYZ in the future"... but we need people to write those
   scenarios down.
   ... the only way it will happen with people being busy is if
   its a regular recurring action / topic.
   ... sometimes the answer might be we don't have any new ones -
   or new ones may arise, e.g. with augmented reality.

   dka: does that document become a document of this working

   NR: in some cases we don't need to create requirements - e.g.
   offline where they already have use cases and requirements. We
   need to find out what is missing and then put it in.
   ... the wiki describes the group in better detail. We can add
   use cases and requirements.

   <schuki> action Natasha to add to DELIVERABLES: adding use
   cases / requirements section to coremob / mobilewebapp state
   document and add use cases / requirements to regular meetings

   <trackbot> Created ACTION-80 - Add to deliverables: adding use
   cases / requirements section to coremob / mobilewebapp state
   document and add use cases / requirements to regular meetings
   [on Natasha Rooney - due 2013-11-21].

   NR: I'm going to add "the document" to our deliverables and add
   use cases and requirements to our regular meetings - a regular
   deliverable for us.

   dka: cordova is starting to produce stats about what apis apps
   produced with cordova actually use.

   tobie: we worked on this at Facebook 2 years ago - it's a good
   exercise [analyzing top 100 apps]. I saw work on the mailing
   list that did some not manual work - automated analysis of
   android APIs. the output of that data is wrong, and brings the
   focus on the wrong feature set. Intrepreting the data is the
   tricky thing. The permissioning model of android is different
   from android - a lot of the key APIs that came out of that
   discussion don't transpose to the Web.
   ... you need to do some manual work.

   dka: I don't disagree.

   NR: we will talk about that in closing the gap with dom
   tomorrow as well.

   <tobie> Phonegap data looks like a great source of information

   NR: Any other comments?

   CP: did anyone look at business models?

   NR: We want to do that - it's key to organizations who are
   members - especially from operators.
   ... business models are important - use cases might dip into
   ... we could have business use cases.

   CP: I was more thinking that native apps have business models -
   they are sold or have something sold in them [in-app].

   NR: One of the focus topics is on payments - which is related.
   It's different with apps - it's a "closing the gap" topic.
   There is an easy way for a native app developer to [monetize].

   Mounir: there is business on the web and also you can sell
   ... i don't feel there is much technical solution /
   [discussion] we need to have there...

   tobie: when we started the coremob CG - we were looking at 3
   ... one is closing the gap
   ... two is the business model. You need to have developers who
   are making money.
   ... the last is distribution - app markets, search, social
   ... making money building web applications is a problem - it is
   solved to some extent through ads and through payments. One
   thing that hasn't been addressed yet is to think about carrier
   billing - these apps are running on devices that are connected
   to users' phone bills?

   mounir: is carrier billing something that people use out of
   developing countries.

   dka: Telefónica has direct-to-bill payments rolled out with
   Microsoft and Google (app markets) in Spain and for Microsoft
   app market in the UK. It is effective when it can be done.
   There are challenging regulatory and integration issues which
   have held them back.

   NR: I like the idea. Dave Ragget will come talk about web
   payments tomorrow.

   dka: I am co-chairing the upcoming workshop on web payments
   happening in March - a core part of this will be mobile

   NR: one thing we could do in this IG is to work on use cases
   and requirements.

   CP: not everyone is looking for financial payment - focusing on
   payment might be limiting.

   NR: examples?

   CP: social reach, branding outreach, barter...
   ... other economies -

   NR: the Web naturally reaches more people than native
   ... lots more web users - I will find the research.

   <Zakim> tobie, you wanted to comment on biz models and to

   tobie: interesting - about other incentives - but that said it
   would be good for this group to answer the question of
   precisely what part of the ecosystems are needed for there to
   be a turning point where mobile web is good enough to compete
   with native.
   ... what's missing is the quality applications and premium
   content on mobile which is not accessible on the web right now.

   <Zakim> tobie, you wanted to comment on mobile strategies

   dka: star trek example - star trek poster on the underground
   says "download our app" at the bottom - there is a reason they
   put that there to engage the end user to go to the cinema to
   watch a movie - what's stopping them from putting "go to our
   web site"?

   tobie: use case for looking up flight times in genevva -
   couldn't access landing times for planes from an iPhone... so
   what was wrong with the airport? after that, I saw "gvapp" -
   the airport's mobile strategy is "let's have an IOS app and an
   android App".
   ... an international traveler going to download an app just to
   get airport info? doesn't make sense. Companies are trying to
   have a mobile strategy and they hire someone to build apps -
   and the only thing they know because it's cool and trendy is
   IOS and Android. But for a ton of use cases which would be
   better served by the web - this a key item to discuss. We need
   a strategy to address this.


   NR: this will get taken up as closing the gap.

   tobie: it's not a technological problem - it's educating
   developers and also addressing the business-level people -
   giving the message out that the web solves a bunch of use cases
   better than native.
   ... having an add with "download this app to engage" is a daft
   ... it's hurting businesses - there is a strong business case
   to be made for the web in lots of scenarios.

   Mounir: from a tech standpoint we are mostly ready - but people
   are not used to using web apps on the mobile - it's a mind-set
   issue. If you go back a couple of years ago, it was "IOS app"
   now it's "android and IOS" so hopefully it will change...

   dka: as the number of platforms increase will the
   interoperability story of the web start to resonate more?

   Mounir: do we know how much cordova is used - e.g. in the
   android app stores?

   tobie: I believe it is something like 4% - so 1000s of apps.

   <schuki> action Natasha to add 'education to devs on how the
   web solves your app use cases' to things we want to work on, as
   maybe the gap in development is due to education as well as
   other factors

   <trackbot> Created ACTION-81 - Add 'education to devs on how
   the web solves your app use cases' to things we want to work
   on, as maybe the gap in development is due to education as well
   as other factors [on Natasha Rooney - due 2013-11-21].

   tobie: still today a lot of content in the native Facebook app
   is HTML5 - one of the reason we expanded the native element was
   the performance issue.
   ... I will dive deeper into this - e.g. scrolling performance -
   later today.
   ... the technological gap needs to be addressed. Companies that
   have enough resources are handling the technical challenge by
   going native and handling the multiple code bases problem by
   keeping as much code as possible as html5.
   ... not addressing the cross-operating system thing that much.
   what they are addressing is that it's difficult to ship a new
   application. On the web you ship the code and agile companies
   are shipping code to production many times a day - you can't do
   that with native. Outside of this particular issue which is
   applications that have requirements to be native - there are a
   lot of use cases that would be better for everyone if they were
   a [expletive deleted] web site.

   NR: I've added education as an action.

   tobie: also education to c-types; to business guys.

   NR: lunch now
   ... back at 2

   <tobie> OWP on mobile has a branding problem

   <sangwhan> scribenick: sangwhan

   <schuki> [22]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face

     [22] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face





   [Self introduction time]


   Natasha: this afternoon we will be covering several topics
   ... as on the screen (wiki page)
   ... we are doing some small task forces to help developers
   write mobile apps
   ... if you have questions add yourself to the queue
   ... please use the irc if possible
   ... tobie will talk a bit about scrolling, and sangwhan might
   add some commentary

   tobie: i looked into this a bit, while i'm not the best
   candidate to talk about this
   ... before working testing in w3c i worked on mobile related
   ... one of the reasons why we did a transition between
   web/native was scrolling performance
   ... smoothness is key, and smooth scrolling is a difficult
   problem to solve
   ... apart from gaming, it is one of the most intensive
   operations on mobile platforms
   ... i've been trying to get the css working group to find a
   solution to this

   <dom> [25]http://dev.w3.org/csswg/cssom-view/#scrolling

     [25] http://dev.w3.org/csswg/cssom-view/#scrolling

   tobie: some of the suggestions i got from fb engineers have
   been shared on the coremob list
   ... while i don't have a solution this group should definitely
   look into this
   ... infinite scroll is something i would like to see in future
   ... this isn't particularly easy due technical challenges of
   how browsers work
   ... the big problem is that devs are implementing these
   features in js

   mounir_: Does using a worker to fetch data help?

   <dka> Good example of infinite scroll: qz.com - also one of the
   companies /web sites on the forefront of the progressive mobile

   tobie: workers are pretty much what everyone uses
   ... but it still doesn't help because layout et al is done in
   the main thread
   ... cloning the dom tree into a worker might be one approach
   ... you could possibly bind processors to particular elements
   in the dom
   ... neither i nor the group should be the ones who come up with
   the solutions
   ... and we should bring the problems to the groups and have
   them solve it

   Dan: the web is a page, with a top and a bottom - and infinite
   scrolling is a different metaphor
   ... there are clear philosophical differences between the
   initial design and infinite scrolling so far is a hack that
   goes on top of it
   ... has this been discussed or is this a tag issue?

   tobie: probably tag
   ... ever since i started working with the w3c the market has
   already changed from documents to applications

   <bryan> +1 the infinite scrolling ship has already arrived in

   <schuki> [26]http://dev.w3.org/csswg/cssom-view/#scrolling

     [26] http://dev.w3.org/csswg/cssom-view/#scrolling

   tobie: scrolling through a lot of content is something that we
   would want to do

   Dan: I was talking about a page, where a end of the page is the
   end of the page
   ... what i was noting is that you are bringing up that now the
   end of a page isn't really the end of the page

   tobie: Ads probably influenced this
   ... but on a mobile device scrolling and swiping is a natural

   schuki: thanks for the input

   <schuki> sangwhan: appending things to the dom comes with a
   memory problem, so there needs to be some work on garbage



   sangwhan: mobile devices have limited memory, and while
   infinite scrolling is a natural ux you'll eventually run out of
   ... e.g. explicit gc of elements that have left the viewport

   tobie: while you have a point and this is necessary, this is
   not necessarily gc but there should be a solution

   bryan: re what tobie posted to the coremob list, we researched
   those issues and verified many of them, e.g. particularly for
   HTML5 games - Scrolling and UI fluidity, touch events/tracking,
   Hardware acceleration control, Multiple audio tracks for
   background & effects, Audio sync with animation & video

   christine: i consider the infinite scrolling problem as a
   infinite map
   ... we should think about this in a approach where this is a
   map, not a list

   tobie: good point
   ... it should be made so that there are components that can be

   <bryan> these items I listed are on our performance priority
   list for WebMob re closing the gap with native

   tobie: if you have a blob of data that you want to look at, you
   want the native layer to do the heavy lifting
   ... a lot of data in a small screen, we just need to figure out
   the most sound technical solution to address this

   <bryan> we need to document the gaps on the wiki with links to
   examples and analyses that people can reference



   tobie: there are a lot of things that fall into the scrolling
   ... not sure if css wg has looked into this

   <dom> has anyone brought up CSS OM View yet?

   mounir_: @@@ has been trying to address this problem

   <dom> [29]http://dev.w3.org/csswg/cssom-view/#scrolling

     [29] http://dev.w3.org/csswg/cssom-view/#scrolling

   tobie: we should come up with the problems and approach the wgs

   mounir_: nowadays, browsers are doing off the main thread
   scrolling/compositing, if you use those modern browsers,
   workers and be mindful with memory usage (do not keep the
   entire newsfeed in the DOM), maybe things could already be
   better? I feel that there are some experiment that could be
   done here.

   tobie: if you keep adding stuff at the end of the dom you'll
   hit problems
   ... the reason why devs get it "wrong" is because it's not a
   simple problem
   ... browsers should try to address this

   schuki: we need to move on to the next topic
   ... next topic is testing
   ... which is also covered by tobie


   [Tobie asking people if they are familiar with the testing

   <schuki> action scrolling use cases should be documented, also
   make notes as we may need user agent action as well as
   developer-focused options

   <trackbot> Error finding 'scrolling'. You can review and
   register nicknames at

     [30] http://www.w3.org/Mobile/IG/track/users%3E.

   <bryan> how to continue the CoreMob focus on setting priorities
   for testing of features

   tobie: those who are unfamiliar feel free to ask questions

   tobie: wrt testing is that it's expensive and companies need to
   fund it

   <schuki> action Natasha (to reassign) scrolling use cases
   should be documented, also make notes as we may need user agent
   action as well as developer-focused options

   <trackbot> Created ACTION-82 - (to reassign) scrolling use
   cases should be documented, also make notes as we may need user
   agent action as well as developer-focused options [on Natasha
   Rooney - due 2013-11-21].

   <bryan> we need to know what the users need, and focusing the
   effort to analyze priorities will help optimize the ROI for
   mobile stakeholders

   <bryan> we need to measure what users need explicitly through
   outreach, polls, etc. depending just upon what the insiders
   think will only take us so far

   <bryan> the WebMob group can help focus this effort as a
   community of interest


   <bryan> we need a WebMob 2014 document or something similar, to
   help frame the current thought on key testing goals. Our
   position at the close of CoreMob was that CoreMob 2012 was not
   a "one and done"

   mounir_: We discussed testing APIs that are hardware related a
   few months ago, like battery api or a messaging api. It is hard
   to test because you do not have access to the hardware to
   verify if what should happen happen. Do you have any update on

   schuki: next topic will be covered by bryan

Push API

   <JonathanJ> [31]http://www.w3.org/TR/push-api/

     [31] http://www.w3.org/TR/push-api/

   bryan: if we want someone to fund the mobile testing we need to
   make sure that people understand that we will make good use of
   ... the spec you are seeing is a working draft of the push api,
   from 4 months ago

   <JonathanJ> [32]http://www.w3.org/2013/03/push-pag-charter

     [32] http://www.w3.org/2013/03/push-pag-charter

   bryan: we are currently going through a pag
   ... we had some other work in att going on to send
   ... what we have here is similar to that, but the current spec
   needs a prior agreement
   ... there was wap, but for the web we needed something simpler
   ... for this we came up with a api that is delivery system
   ... the spec doesn't talk about what the transport mechanism
   is, and that was part of the goal
   ... in the spec we mention a couple standard transport methods,
   but there are many non-standard methods as well
   ... the toc in the spec gives you a pretty good outline
   ... the security model is based on the DAP approach
   ... initially we did not use promises, but now most specs
   including ours has changed to make use of promises and service
   ... there are some things we need to work on, i don't have a
   very good understanding of service workers

   <JonathanJ> Service Worker -


   [Q&A about technical details of Service Workers]

   DanS: my understanding of SW is that it won't work when there
   is no browser
   ... how to make this transport independent?

   bryan: that is what the spec looks like as it is
   ... it's explained to some extent in the flow chart (in spec)
   ... how the push registration would work we'll need the UAs to
   figure out
   ... the current api lets implementations even work completely

   tobie: what do you mean by offline?

   bryan: mobile phones can have data off
   ... there is a signalling system that lets you make phone calls
   ... i was mentioning this

   tobie: the next step should be to take the spec and look at
   which parts of the spec can be implemented using service

   <anssik> +1 to tobie's suggestion

   <anssik> re push & ServiceWorkers, see

     [34] https://gist.github.com/slightlyoff/7fae65a908ac318f69a3

   <JonathanJ> I think that ServiceWorker likes active service
   manager, Push API likes passive service manager

   <schuki> action Natasha (tp reassign) in push api doc there are
   use cases, we should map them against the push use case in
   service worker and see what the gap is between the two

   <trackbot> Created ACTION-83 - (tp reassign) in push api doc
   there are use cases, we should map them against the push use
   case in service worker and see what the gap is between the two
   [on Natasha Rooney - due 2013-11-21].

   Ruinan: @@@

   mounir_: @@@

   bryan: we had two considerations when designing the spec, one
   is scalability

   mounir_: i disagree with your position regarding privacy
   ... #@!#@!

   <bryan> +1 to Eduardo's support (the major contributions so far

   <JonathanJ> +1 me too

   bryan: is this group interested in discussing unresolved
   questions of the push api

   <schuki> action Bryan to send email to public mailing list
   about anymore work to be done on push api

   <trackbot> Created ACTION-84 - Send email to public mailing
   list about anymore work to be done on push api [on Bryan
   Sullivan - due 2013-11-21].

   <bryan> ScribeNick: bryan

homescreen bookmarking

   natasha: discussion on the list led by Marcos and Ernesto on
   homescreen bookmarking
   ... link is

     [35] http://w3c-webmob.github.io/installable-webapps/

   dka: are they looking at the manifest-based bookmarking?
   ... in FFOS we have a manifest based upon the W3C Widgets
   Manifest format
   ... this is where we think things re going, to install via
   manifest via an appstore
   ... looking at FT (Financial Times) on FFOS, it uses the API
   FFOS exposes to check if installed, and offer to user to
   install if not. It's a hosted app with a JSON manifest.

   <JonathanJ> web manifest -

     [36] http://www.w3.org/2008/webapps/manifest/

   dka: those are our use cases. we've seen Chrome implement a
   similar functionality. So it would be a mistake just to focus
   on the iOS save to homescreen capability

   schuki: our focus is not limited to that

   dka: we should document that set of use cases as described
   ... documenting the user experience that is wanted should be
   part of the document

   schuki: all of the approaches should be included; some action
   on the TF to ensure that, may need some help
   ... other call for any more collaborators, please let Marcos
   and Ernesto know. we need people to help out

   <wonsuk> Use Cases and Requirements for Installable Web Apps:

     [37] http://w3c-webmob.github.io/installable-webapps/

   <schuki> [38]https://github.com/w3c-webmob/installable-webapps

     [38] https://github.com/w3c-webmob/installable-webapps

   bryan: we should get actual user input on what the install
   experience should be or would be nice, with some example/demo
   videos on which we could get user feedback

   schuki: developer events may be one way to get that input

   dka: someone could step up with money to do a user mockup

   bryan: maybe thru ADA?

   kenneth: maybe a google+ group since there are a lot of devs
   there; also for getting feedback on issues to avoid

   schuki: if anyone wants something else they need to get
   ... next is to setup a google+ or github group for comments on

   <schuki> action Marcos check whether you have firefoxOS
   included in the installable web apps doc, and if not add it,
   ask Dan A for help

   <trackbot> Created ACTION-85 - Check whether you have firefoxos
   included in the installable web apps doc, and if not add it,
   ask dan a for help [on Marcos Caceres - due 2013-11-21].

   <schuki> action Natasha setup a github repo / google+ group to
   canvas opinions from devs on this topic

   <trackbot> Created ACTION-86 - Setup a github repo / google+
   group to canvas opinions from devs on this topic [on Natasha
   Rooney - due 2013-11-21].

   bryan: we could also include some demo code in the doc to show
   how devs currently and in the future might use the features
   (maybe it's already there)

API gap



   dka: you may have read this report from vision mobile,
   sponsored by Telefonica
   ... the idea was to canvas the dev community and tools vendors
   on key gaps between native and web on mobile
   ... one key finding was around performance
   ... as an issue its on the radar as a key focus area; tobie was
   addressing performance earlier;
   ... but other urgency is on APIs - there is some controversy
   around this re bringing it to par with native
   ... devs go native to get access to APIs not available on the
   web; this is changing, and the more APIs we have, the stronger
   the argument about embracing the web
   ... e.g. the starwars poster with a QR code linking to an app
   store vs a web app - fgor now they say it wont work and go away
   ... Jo feels that to a certain extent the web will never catch
   up to native
   ... e.e. latest dark matter or alien detection API
   ... the argument I would like to put forward is that we need a
   major shift in how users use the web on mobile devices
   ... a UI that is from the 80s e.g. mouse/pointers, is not
   aligned with a world of touch screens
   ... kids learn how to use a mouse at school as they did not
   grow up with it.
   ... the point is that accelerated of development in the
   platform is not sustainable; we will go thru further shifts but
   should expect that the touch interface and APIs will be around
   for a while
   ... with these key APIs and knowing which are popular, let's
   add them to the web; native will still be attractive to those
   that need what the web can't provide, but let's add the core
   features we can
   ... the point is what is the relative priority on APIs that are
   currently in the gap
   ... Tobie raised some issues around how to survey; but let's
   have some discussion on what's important on that list



   <dka> Popular Cordova APIs

   <dka> org.apache.cordova.file

   <dka> org.apache.cordova.camera

   <dka> org.apache.cordova.splashscreen

   <dka> org.apache.cordova.network-information

   <dka> org.apache.cordova.geolocation

   <dka> org.apache.cordova.vibration

   <dka> org.apache.cordova.media

   <dka> org.apache.cordova.media-capture

   <dka> org.apache.cordova.contacts

   <dka> org.apache.cordova.device-motion

   <dka> org.apache.cordova.device-orientation

   <dka> org.apache.cordova.battery-status

   dka: e.g. talked to Phonegap on that are the popular APIs in
   that platform; through tht product they have been able to ID
   what are popular APIs in the system or requested
   ... this is initial data, popular APIs that Cordova devs are
   ... interesting that net info is a highly requested API; its
   been a persistent question in W3C e.g. whether this is a short
   term issue

   <JonathanJ> Standards for Web Applications on Mobile -

     [41] http://www.w3.org/2013/09/mobile-web-app-state/

   dka: I would argue that devs are still requesting this API, IMO
   this falls under the category that "the device knows about it
   but we are not letting the webapp know about it" - why?
   ... I asked about the use cases for offline and knowledge of
   the net info ... (missed the rest)
   ... going on, some are contentious - some are already in scope
   for W3C e.g. battery
   ... hoping to bring more voices into this, and to put this into
   a report

   <schuki> khronos

   christine: I've been working closely with different stds orgs,
   one common question e.g. with Kronos, WebGL, WebCL are
   available for devs

   <dka> [42]http://www.khronos.org

     [42] http://www.khronos.org/

   christine: Khronos would like to make all these APIs available
   to devs on the web; Khronos do not do the web so need help
   ... on Dan's list, 7 of 10 are known/used by the Khronos APIs
   ... camera is being worked on; a new one is stream input on
   devices capturing sensor data; Khronos would like to ensure
   these APIs are supported by lower-level silicon APIs
   ... several meetings so far but no actions have been taken

   <schuki> bryan: we have a problem getting APIs built in w3c

   <schuki> ... sys apps has picked up some stuff, DAPs is still
   running with stuff

   <schuki> ... network information: I wrote a report about the
   saga on this

   <schuki> ... we don't need to know what network we're connected

   <schuki> ... we should express what the developer wants

   <schuki> ... dev wants to deliver a request effectively

   <schuki> ... network info api is good for network efficiency

   <schuki> ... another way to say to the browser "get me the
   resource within the next 10 mins"

   <schuki> ... another idea is to get the resource, and i don't
   care how, just get it

   <schuki> ... network info api as a way to promote efficiency
   has other approaches

   <schuki> kenneth: service worker can do this

   kenneth: that works pretty well with the service worker concept

   dka: looking at the vision mobile report, limited access to
   hardware APIs is second only to performance issues

   <dka> Vision mobile report says 37% of developers don't choose
   Mobile Web (HTML5) because of lack of API support.

   wonsuk: I am curious why power and wifi APIs are in here

   dka: this is one source of info in looking at most popular
   APIs. programmatic research was used to determine which APIs
   are popular, but also there was a lot of 1-on-1 interviews of
   devs and tools vendors

   wonsuk: we can consider which APIs e.g. power and wifi are
   possible based upon this input

   dans: I am surprised that FFOS have so many APIs, in slide 6,
   98% of Android apps can be implemented in FFOS in terms of the
   APIs they use

   <schuki> bryan: when we started doing wac we found a few number
   of webapps used no APIs at all

   <schuki> ... so we could just package them

   dka: many FFOS APIs are not standard, and support animated
   games for example. the 98% figure needs to be verfied
   ... some games e.g. do not need APIs

   schuki: going back to Kenneth's comment on service worker, we
   will take data-driven approach rather than a documentation
   approach (captured correctly?)

   dka: the idea of the report is to make this data public through
   the group, so we can point to it when we need to. we need work
   on the backup data, but when people ask for research this is a
   data source

   schuki: Dom will give us an overview in the closing the gap
   report in a later session
   ... suggest we defer the UI Primitives topic to tomorrow


     [43] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday

   some suggestions for tomorrow on WebMob focus - Help review and
   improve mobile-focused info on [44]http://docs.webplatform.org/
   - Linking to WebMob from [45]http://www.w3.org/Mobile/ -
   Helping Dom maintain the info on [46]http://www.w3.org/Mobile/

     [44] http://docs.webplatform.org/
     [45] http://www.w3.org/Mobile/
     [46] http://www.w3.org/Mobile/

Summary of Action Items

   [End of minutes]


           Web and Mobile Interest Group F2F meeting (day 2)

15 Nov 2013


      [2] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday


          Dominique_Hazael-Massieux, Jonathan_Jeon, Natasha, DKA,
          Bryan, Ruinan, Kotakagi, Christine Perey, DanSun, koichi

          Marcos, Jo


          schuki, dom


     * [3]Topics
         1. [4]closing the gap
         2. [5]web standards roadmap
         3. [6]Payments
         4. [7]permissions on the web
         5. [8]WebDriver
         6. [9]Security
         7. [10]Developer tools / debugging gap
         8. [11]Summary
     * [12]Summary of Action Items

   trackbot, prepare meeting

   <trackbot> Date: 15 November 2013

closing the gap

   dom: most people think the mobile landscape is between ios and

   ... the good news is most of this analysis html5 is the 3rd

   ... on desktop however, it seems web is no 1

   dom: anyone making a choice about providing content to their
   users need to make a decision

   ... when a dev is making a trade off between web and native,
   what do they consider?

   ... user experience, and provider considerations

   ... in user experience some of the things that are important
   are: discoverability, obtainablity, usability, upgrade process,
   secuirty / safety / privacy

   ... provider consideratons: develop costs, deploy, profit, ??

   dom: when you weigh it up you find

   ... web is better for discoverability, obtainability, upgrade,
   deployment, develop costs, and security (some people might

   ... native is usally better for use and profit

   ... this analysis is for desktop

   ... when put this way it seems web has much better opportunity
   for desktop

   dom: for mobile you get a much different picture

   ... on web discovery, obtainability, upgrade, staying safe and
   deployment is easier than on native, but the ease / advantage
   isn't as large as in the desktop model

   ... and native use, development and profit is stronger


     [13] http://w3c-webmob.github.io/gap-analysis/

   ...the payment process is much more streamlined in native,
   making money is a lot easier in mobile native development

   ... web payment is not as efficient in mobile

   ... therefore native is probably stronger for mobile at this

   ... web has a larger number of plus points, but the negative
   points outweight these

   dom: I imagine people here today want to strengthen the web for

   ... the question is; what can we do to change this balance?

   ... i think we need to reduce the disadvantages (starting with
   user exp) and then work on building on the advantages

   dom: in this ppt I didn't go through the finer details of the
   gap, but in the report I wrote it has a lot more of this detail

   ... my point is what we need to do is look at these values and
   find out what are the priorities to making the web the place to
   build mobile applications

   ... what is making the users and developers choose native -
   lets answer this.

   dom: the one thing i haven't looked at is the type of apps
   people are building

   dom: we would like to see where the web has a stronger presence
   on desktop

   dom: lets take news for example

   ... whilst many people go to the web for news

   ... newspapers still think they need to have a native

   ... i would be interested to know whether people feel like this
   is an interesting topic

   bryan: this is great, it would be good to think of how we're
   going to have a dialogue on the doc

   dom: the doc is on github, i would like people to do pull
   requests on the document

   ... you are also welcome to send tips to the mailing list

   <schuki> a/comments/comments

   bryan: what research states that offline is problematic

   ... and what do people do to breach that gap

   ... so why is it a gap, what are the alternatives, and how will
   they satisfy the market?

   dom: a lot of this info stems from what facebook brought to
   coremob last year

   dom: yes you can do offline on the web

   dom: but quota management is difficult

   ... app cache doesn't work

   ... etc

   bryan: for certain types of apps, what do devs want to do

   bryan: I have been doing this with a number of apps (building
   offline) very successfully for 3 years

   bryan: i think we need to provide some more perspectives

   dom: i agree

   <bryan> The lifecycle and roles could be looked at in more
   detail, to identity gaps that may be hidden by the high level
   of abstraction in the lifecycle from user & developer, as shown
   on the slides. For example, as shown by my 2012 presentation at
   the AT&T Developer Summit
   df), the areas to consider include: developer communities, open
   source code availability, SDKs, emulators,
   platform/ecosystem-specific ce[CUT]

     [14] http://developer.att.com/home/community/conference/HTML5.pdf)

   bryan: at wac we put a lot of effort into thinking of the

   ... of how a dev build an app

   ... we also went into how a user discovers apps

   dom: one of the great advantages the web has are the links

   <bryan> The application category is one dimension, but there
   are others that are more horizontal e.g. accessibility - or
   maybe that needs to be another column

   bryan: horizontal aspects would be good

   ... e.g. accessibility

   dom: the reason why native is so strong over mobile is native
   has learnt a lot from the web

   ... as native on mobile came after the web native could learn
   from the trends on the web

   ... accessibility is on the document but it is a bit of a bolt
   on atm

   ... security and privacy could also do with some work

   bryan: I had a discussion with Lisa (seacat deluca) about
   closing the gap

   ... and we need some experts to talk about accesibility

   dom: there is a new accessibility task force that has been

   ... this should be able to help us

   <bryan> one of our goals for WebMob is to look at gaps in
   various domains including accessibiity, e.g. are native device
   accessible features also innately applicable/usable in the web
   browser environment, or are there further gaps to close

   DanS: I concur that it would be good to keep up with

   ... images is another interesting topic

   dom: on native you can download as much as you want for offline

   ... but for web it is a lot harder

   ... so I mentioned images because they are heavy and take up a
   lot of space

   DanS: what about the file apis?

   dom: last I heard there was a discussion in the web apps group
   re file system apis

   ... there may be a new approach to file system

   ... one of the biggest limitations to all these solutions (web
   storage, file, indexed db)

   ... the issue is space

   ... for app developers it's a real difficulty

   schuki: generally speaking, there are ways to run offline web
   ... but there are problems with scalability
   ... the current solutions are built in a difficult flow
   ... there are interesting trends in app development
   ... you would want to pull content in the background when on a
   better connection

   dom: there are a number of things that are critical in closing
   the gap

   ... development tools is one of these issues

   ... also deployment steps

   ... and making a business out of apps

   dom: as we know advertising on mobile (smaller screen) is hard
   to get right and keep the user exp

   ... app stores makes it easier to make money

   ... one of the items we can discuss in the payment session
   could be getting paid

   ... how does a developer get paid on the web? in app stores
   there is a standard model

   dom: google is doing well with new payment systems

   ... making it easier for users to complete payments

   dom: so we should think about how we can close the gap, and
   build on this document to help this

   dom: one thing that this group could have a role to play is
   looking at different types of devices

   ... on the screen is a car, tablet, tv, camera, clock

   ... users will change from one device to the other

   ... connected devices are getting more and more diverse, we as
   a group should be working on what the web could do for all the
   different user experiences

   ... the web could also help not by competing with native, but
   by embracing it

   schuki: google request auto complete for filling out forms:

     [15] http://www.chromium.org/developers/using-requestautocomplete

   dom: how can we make sure we are pushing away the silos

   <JonathanJ> [16]http://www.w3.org/2013/Talks/dhm-mobicase/

     [16] http://www.w3.org/2013/Talks/dhm-mobicase/


   ... this area od links, intents and activities (around hybrid
   apps) is something we should look at

   ... hybrid app's dom is different from browser dom

   ... there is no method to do messaging between them, etc.

   ... the openID foundation is working on distributing keys based
   on the URI concept

   ... it works but there would be some things that would work
   better if we had messaging between web and hybrid apps

   dom: a few other examples of what we may want to look at
   include; appurl (quixey) is using a url by detecting the device
   and redirecting where a user goes based on their device


     [17] http://www.w3.org/2013/Talks/dhm-bringing-web-native-closer/

   dom: i am interested to know with web intents / activities etc,
   do we want to take this on?

   shucki: Web Intents and Activities might be a good way to look
   at this
   ... similar to what DKA presented on top APIs used in PhoneGap

   <bryan> event if we don't have bandwidth to address all these
   issues, it would be good to put them on a wiki as gaps that we
   could close in the future, or watch and report on how things
   develop in the interim

   DanS: question about ads, is there something going on to help
   with this?

   dom: we don't have an answer right now

   schuki: next steps?

   dom: bryan will send input on the report

   <schuki> action bryan to send input to the closing to the gap
   report to the listy

   <trackbot> Created ACTION-87 - Send input to the closing to the
   gap report to the list [on Bryan Sullivan - due 2013-11-22].

   dom: i am wondering if the type of app analysis should continue

   schuki: +1

   dom: can DanS help on ads?

   DanS: not sure, too early for me

   dom: i will just add it as a line item for now

   <schuki> action dom add ads on closing the gap report (just add
   a title for now)

   <trackbot> Created ACTION-88 - Add ads on closing the gap
   report (just add a title for now) [on Dominique Hazaël-Massieux
   - due 2013-11-22].

   <schuki> action natasha (to reassign) get someone to help out
   on ads on doms closing the gap doc (Dan Sun)

   <trackbot> Created ACTION-89 - (to reassign) get someone to
   help out on ads on doms closing the gap doc (dan sun) [on
   Natasha Rooney - due 2013-11-22].

   <schuki> action bryan to ask Lisa to see if she can help out on
   accessibility on the closing the gap doc

   <trackbot> Created ACTION-90 - Ask lisa to see if she can help
   out on accessibility on the closing the gap doc [on Bryan
   Sullivan - due 2013-11-22].

   dom: can people let me know if they want to continue this work?

   schuki: I've heard people want to see it continue

   <schuki> +1

   <manu2> +1

   schuki: we need people to give feedback/input

   <dka> +1

   <JonathanJ> +1

   <Ruinan> +1

   dom: this analysis framework is good, although we are looking
   to go to a different structure and put this in a more accesible

   bryan: I think it is a good idea, taking this stuff to become a

   <schuki> +1

   dom: i know we talked about this with reference to the coremob

   <Zakim> dka, you wanted to say it's important to show how far
   we've come as well.

   dom: after the break we will talk about the web app standards
   doc and we can discuss this dashboard idea

   dka: the other thing I wanted to ask was about the vision of
   where the web plays in the web of things discussion

   dom: this is a demo where I move a phone and it replicated a
   canvas on a browser on another device

   dom: this is cool but I think the thing we need is design

   ... we might not have the right people here to do that

   ... but it would be great if we could

   <schuki> [18]http://specs.wacapps.net/

     [18] http://specs.wacapps.net/

   <schuki> bryan ^

   dom: one of the important thing in this area is discovery

   ... i am hopinh the group can help

   <schuki> ?

   <JonathanJ> It can also figure out how to work open web app
   store and manifest -

     [19] http://www.w3.org/wiki/System_Applications_WG:_Manifest

web standards roadmap

   dom: this document looks at the various standards that w3c

   ... for each specs the doc identifies the relevant feature /

   <schuki> .. how stable it is, gives a link to the editors
   draft, which mobile browsers are implementing the feature

   <asahiro> join #webmob

   ... i have also linked to the relevant w3c courses

   dom: the purpose of the document is to show you what is
   currently available and what is coming

   ... and I have tried to take a feature based approach rather
   than a spec approach

   ... as devs want to know about features

   dom: the document is divided into categories of features

   ... i want to talk about how i have been building it, and how i
   want to change it

   ... and make it easier to reuse the data

   ... inparticular i am thinking about this dashboard idea

   dom: i have been maintaining for the last 2 years



   dom: this wiki page has the same content with less of the
   graphical aspect

   ... there has been few contributions

   ... i have extracted the data and uploaded to github

   ... 1 json file per each feature


     [21] https://github.com/w3c-webmob/mobile-web-app-standards

   dom: 3 different groups want to build this document

   ... so I have created this repo

   dom: do people want to continue working on this?

   <bryan> +1 to this approach - a JSON-based "state of the web"
   database with different presentation formats is a great idea

   dom: I could use help in maintaining the data

   <schuki> +1 from me too

   dom: i am taking a lot of data from 'can i use'




     [23] https://github.com/dontcallmedom/w3c-editors-draft-tracker

   dom: I can see people are in support of the json approach

   ... i will continue with this

   dom: I would love help on how to design it and make it more

   manu2: ideally this is automated, so what are you looking at to
   gather this info?

   dom: it's semi automated

   ... stability is manual

   ... some things need people to ask standards setters

   ... there could be some work on making the automation better

   ddavis: how easy would it be to provide this to other groups?

   dom: hopefully with moving it to a wiki that could help

   ... i would like it if people added to the json files and
   pulled those in automatically

   bryan: there's a lot of info here which is great

   bryan: web platform docs, they have some stuff about mobile,
   it's more educated focused,

   ... the majority of the info from your doc will be valuable, so
   we could consider pulling it in

   dom: the document could be hard to read, but by extracting the
   data we can allow them to use it

   bryan: the json approach is great

   <ddavis> +1

   dom: right now the implementation doesn't go too much into the

   <JonathanJ> +1


   <scribe> ScribeNick: dom

   dsr: W3C looked at payments early on
   ... esp. on micropayments
   ... but didn't quite work out
   ... lots of innovation in this space
   ... but it's a burden for developers to get in relation with
   all the payment providers
   ... also hard on users to have freedom in their payment systems
   ... We have an upcoming workshop in March 2014 in Paris
   ... the call for participation will be sent in a few weeks,
   probably early December
   ... we want to create a level playing field
   ... interested parties come from a variety of background
   ... mobile network operators, credit card systems (with lots of
   variation on associated costs)
   ... also plenty of innovation from start up

   <manu2> manu: In general, the purpose of the Web Payments work
   at W3C is to integrate payments into the core architecture of
   the Web.

   <manu2> manu: The work touches on identity, security, mobile,
   banking, and financial industry in general. There is a lot of
   coordination that will need to be done if we are going to be

   <manu2> manu: Here are a couple of useful links for learning a
   bit more about Web Payments

   <manu2> manu: We had a breakout session on Wednesday that
   provided a quick introduction to the space:

     [24] http://www.w3.org/wiki/TPAC2013/session-web-payments

   <manu2> manu: The minutes from the breakout session are here:


   <manu2> manu: We are planning a W3C Web Payments Workshop
   during the last week of March 2014 in Paris, we'll notify this
   group when we put out the Call for Position Papers

   <manu2> manu: If you want a technical introduction to the
   space, you can go here: [26]https://payswarm.com/intro

     [26] https://payswarm.com/intro

   <manu2> manu: If you want to join the Web Payments CG,
   instructions on how to do so are here:

     [27] https://payswarm.com/join

   <manu2> manu: Things that WebMob can help with: Coordination
   and raising technology issues across various groups.

   <manu2> manu: SysApps - Secure Element API is vital for
   high-value financial transactions. How does it work with NFC
   and Web Payments stack?

   <manu2> manu: WebCrypto - Web Crypto API is important for doing
   client-side digital signatures for purchasing. How do you
   coordinate a Secure Element w/ the Web Crypto API to perform a
   digital signature on a purchase request or purchase

   <manu2> manu: NFC - NFC API is important for both online and
   offline purchases, does it integrate cleanly with Secure
   Element, Web Crypto, and Web Payments?

   <manu2> manu: geolocation - There are use cases where you would
   want to use geolocation to determine an indoor location when
   performing a purchase, such as access to a particular portion
   of a building (like a museum) based on payment. Authorization
   of purchases is also important (is your mobile phone in the
   same vicinity as the physical purchase you're performing?)

   <manu2> manu: Offline - How do you perform an offline purchase
   using SysApps, WebCrypto and Web Payments. Is there a clear
   integration story for all of the applications?

   dsr: we can hear from Manu on the Web Payments CG

   <manu2> manu: Web Payments - Making sure that the mobile
   payment use cases are defined clearly up front. Ensure that any
   sort of native mobile payment story is also possible via Web
   Payments on mobile. Suggest new business models that are
   possible w/ Web Payments that are not possible via mobile.
   Create a clear Mobile Web App Store payment story.

   <manu2> manu: In general, make sure there are clear technology
   integration stories for the mobile use cases and be very
   aggressive at making sure the Working Groups are coordinated to
   ensure the realization of those use cases.

   dsr: levelling the playing field can mean moving beyond the
   device barrier for virtual wallets
   ... also dealing with offline payments
   ... person to person payments
   ... what are the red lines for the different players?

   manu: players include governments, operators, banks, credit
   card companies, online payment companies (e.g. paypal)
   ... none of them want to get disrupted
   ... we want to advance the state of the art
   ... what can this group do to help?
   ... lots of coordination needed
   ... coordination happens at the technology level, not around
   user stories
   ... sysapps, webapps, nfc, etc all develop relevant pieces
   ... but nobody has looked at building a consistent story
   ... e.g. sysapps has a proposed secured element API that would
   be critical to high value transactions
   ... the webcrypto API defines crypto that would be needed to
   sign these transactions
   ... likewise, NFC is important to online/offline payments
   ... but this needs integration with secure/payments

   <dsr> Also work on Bluetooth that is chartered for the SysApps,
   and its role for in store payments

   manu: Geo is starting to look at indoor location, which can be
   used to facilitate short range payments
   ... Offline is a huge use case for payments — you won't be
   connected at all time
   ... you want to run transactions even when not connected
   ... It's very important that WebMob helps coordinate this
   beyond the technical work
   ... build the big picture story

   Bryan: it's a key part of the User Experience with a number of
   technologies under development
   ... it's a great opportunity to take a look at this and with a
   number of other W3C technologies (WebRTC, Speech API), there
   are a number of technologies that integrate beyond the browser
   and affect the user experience, opens up choices in terms of
   ... really excited to see this coming up
   ... right now, we have an over the top approach where we expose
   this through network apis
   ... this is widely used by content providers; I'm not seeing
   this changing
   ... but integrating that in the browser with discoverability is
   a great area to concern

   dka: very excited about the workshop too
   ... I just wonder if it makes sense to think of as another
   web-native gap
   ... and thus look there again at the status of the various
   relevant specs
   ... there are other scenarios where credit card readers are
   integrated in the phone, but for which you need an app
   ... clearly we're dealing with a multiplicity of scenarios and
   ... we should try to grasp that diversity

   dsr: the sysapps work on secure element is probably relevant

   <dsr> The secure element API is intended to allow trusted apps
   access to secure elements via a variety of means, including for
   example, SIM, microSD, contactless Cards, and so forth.

   dom: two level of possible integration: hardware API, vs more
   high level à la Web Intents
   ... would be useful to add a section on payments to the roadmap

   Ruinan: can you clarify what you see behind Web Payments? how
   does this different from what e.g. paypal already enables

   dsr: the idea is to level the playing field with more
   integration of payment systems within the Web, esp. the browser
   ... this raises also important questions on identity, hardware
   ... we can't work on all of them, but we should identify which
   can be worked on

   <Zakim> manu, you wanted to ask WebMob to put forward some use
   cases that we don't consider in the Web Payments Use Cases
   document: [28]https://payswarm.com/specs/source/use-cases/

     [28] https://payswarm.com/specs/source/use-cases/

   manu: the core idea is that there is no core open standards for
   the Web
   ... sending an email around the world is easy today
   ... we should make payments on the Web as easy as that

   <bryan> Payments is a particularly important area for mobile
   user experiences, particularly re usability, payment method
   options, and payment provider choice. There are a lot of
   players with an interest here, and W3C should help ensure that
   as payments develop on the web, the platform remains open and
   level to all players and technologies that may help drive its
   development. We currently support payments via RESTful network
   APIs (N-API), which an over-the-top approac[CUT]

   manu: This is also a much bigger problem: we want to make it
   easy, but also available to a much broader set of users
   ... which currently have no link to a payment/finance situation

   <bryan> (continuing) also are active in NFC-based payments
   (with the launch of ISIS in the U.S.). Augmenting these with a
   browser-native payment API framework which can integrate a
   variety of technologies and providers, we should be able to
   provide a robust set of options for developers and users.

   manu: if we can bring this to them via mobile and Web, we can
   have a significant impact

   <dsr> Improving the user experience, reducing the burden on
   developers and providing a level playing field for payment
   solution providers. What are the missing standards and where
   can we find a consensus for further work.

   manu: getting WebMob to build use cases and contribute
   mobile-use cases to our document would be extremely useful

   <bryan> +1 to creating use cases

   <manu2> [29]https://payswarm.com/specs/source/use-cases/

     [29] https://payswarm.com/specs/source/use-cases/

   schuki: we'll work on getting volunteers with marcos

   DKA: I'm interested to help
   ... I'll try to get more resources from Telefonica
   ... we want to bring up our use cases based on our experience
   on mobile payments

   <scribe> ACTION: Schuki to hunt for volunteers on payments
   [recorded in

   <trackbot> Created ACTION-91 - Hunt for volunteers on payments
   [on Natasha Rooney - due 2013-11-22].

   <schuki> action natasha (to reassign) use cases for payments
   (dka said TEF could help)

   <trackbot> Created ACTION-92 - (to reassign) use cases for
   payments (dka said tef could help) [on Natasha Rooney - due

permissions on the web

   dom: the web started with a sandbox approach

   ... now we are moving more to a consent approach

   <JonathanJ> [31]http://www.w3.org/2012/Talks/dhm-tag/

     [31] http://www.w3.org/2012/Talks/dhm-tag/

   dom: this area sometimes comes with a curse of affecting what
   apis we can bring to the web


     [32] http://www.w3.org/2012/Talks/dhm-tag/#%284%29

   dom: risks come in the form of privacy, or with security

   ... privacy: data leakage, fingerprinting (relating what
   cookies make possible but without relinquishing the control of
   the user, so you should be able to tell a site to remove data
   attributable to you - fingerprinting is this association with

   ... and context leakage (if i can determine you have a highend
   web cam plugged in your computer then i can assume you like
   video and i can charge you more for video)

   dom: UI mitigation - now seeing many prompts when sites want to
   use functionality, integrate the flow (showing your intent
   through UI), state indicator (e.g. your camera is on because
   you can see a green light by the camera and it is on),

   ... web intents (mediation between apis on native and web - but
   this is not bein worked on anymore),

   dom: how do you keep prompt etc meaningful to the user?

   ... many groups considering all these issues and what they
   should do

   dom: I don't want pages / sites / apps I don't know to hurt me

   ... need to deal with dependancies among permissions

   ... there is also the issues with how many prompts we see on
   the screen?

   dom: Sys Apps have been looking into this

   ... trying to figure out what is the permissions model

   dom: many people have suggested we adopt the model of native

   ... having permissions managed by network provider

   ... it's harder to manage this space atm

   dom: so I have asked the tag to help

   ... i hope we can spend some resources on working on this

   <Zakim> PhilA, you wanted to talk about fingerprinting/PDM

   PhilA: the problem space here is establishing a connection
   between service provider and the user

   ... any kind of comm needs to be 2 way

   ... the incentive for the user to know about this stuff is to
   know why they are being tracked / monitored / etc

   ... what is the incentive of the servive provider?

   ... could charge more money by watching whether a person will
   continue to look at a item to buy and charge more if they do

   PhilA: so we have to get incentives on both sides, and this can
   cvause issues

   <bryan> What is privacy sensitive should be a choice of the
   user, with APIs following those choices to determine how much
   information is acceptable to share with apps, for what
   purposes, for how long, etc. We did a bunch of good work on
   this in WAC and can bring that back to the table as a policy
   proposal, updated for JSON representation.

   <bryan> Having a link in web pages to a document (e.g.
   well-known resource) defining the privacy-affecting
   considerations related to apps would be a first step in
   educating and giving the user effective choice tools.

   bryan: we did some research and found prompting doesn't work,
   just way be our only hope!

   ... i think we should revisit this subject

   ... in wac te platform wasn't ready

   ... in sys apps it is much more ready

   ... we should encourage developers and let the user make
   choiced in effective UI

   ... browser vendord are struggling with implementation

   ... we should focus on what is acceptable, not spend too much
   time defining or figuring out

   bryan: what about the unknown knowns!?

   bryan: we're evolving with rich apis. Is it time to get the
   devs involved

   <schuki> +1 for ponies

   dom: i had suggested to the tag to help with the web app
   permissions problem

   ... fingerprinting etc

   ... data minimisation would be one of these topics too

   ... I have a distinction between prompting all the time or just
   once for the app lifetime

   ... i think we ned to consider this, because if we don't we
   will hit a wall for what we can do

   <dka> +1 on continuing the work

   schuki: we're looking for interest and volunteers as always :)

   <manu2> +1 continue with permissions (would love to help, but

   <JonathanJ> +1

   <scribe> ACTION: Dom to bring back up permissions on the TAG
   agenda [recorded in

   <trackbot> Created ACTION-93 - Bring back up permissions on the
   tag agenda [on Dominique Hazaël-Massieux - due 2013-11-22].

   <bryan> s/{????]/the fact that the policy and user-engagement
   approach failed in DAP had more to do with the unreadiness of
   browsers to support rich APIs at the time, and the related lack
   of need for a policy expression; that was OK, we can't force
   implementers, but times have changed and the web platform has
   moved on, e.g. with sysapps and web-based OSs. We should
   restart the discussion with no preconceptions./

   <schuki> action natasha (to reassign) continue permissions
   work, decide on task force to manage - get task force to decide
   on next step

   <trackbot> Created ACTION-94 - (to reassign) continue
   permissions work, decide on task force to manage - get task
   force to decide on next step [on Natasha Rooney - due


   <scribe> ScribeNick: dom

   schuki: David Burnes from Mozilla here to present WebDriver

   David: I'm the coeditor of the Web Driver spec
   ... it lets you automate browser interaction
   ... you tell the browser what to do via a user script
   ... we're not bound by the javascript sandbox, in an elevated
   privilege context
   ... I'll show it in action to illustrate
   ... [showing a python-based Web driver example
   ... ]
   ... [showing how you can get a page loaded in a Web-driver
   controlled browser]
   ... Once the page has loaded, I can get access to the DOM, find
   elements (via CSS selector, id, name)
   ... also has xpath support to enable back- and forward lookup
   ... [showing how to access a link and click on it]

   schuki: can you measure the time it takes?

   david: you could, but without the true value since you're
   outside of the browser
   ... you can tie to the events sent from the browser
   ... you can really simple things like clicking and typing
   ... using a "do what I mean" approach
   ... we have a more advanced API with more detailed interaction
   ... (hold shift, move the mouse by x and y, click, ...)
   ... that's the "do as I say" approach
   ... it's not always a one-to-one mapping, but we try to get as
   close to it
   ... This is in the Web browser
   ... we have started to look at mobile too
   ... I've been involved in applying this to Firefox OS
   ... [demonstrating the Firefox simulator running tests
   automatically via Web driver]
   ... There is an open source version of the Firefox WebDriver
   ... currently showing mozilla's own implementation
   ... we have really nice FirefoxOS interactions
   ... access to both the chrome part of the browser as well as
   the content layer
   ... you can detect e.g. vibration

   dom: is that part of the WebDriver API or an extension?

   David: currently an extension
   ... level 1 is about driving content
   ... level 2 will have what's needed for mobile
   ... including links to hardware APIs
   ... this level 2 is particularly useful given the 3 open
   sources projects that are looking at this space
   ... Apium, SelenDroid, iOSDriver
   ... [showing Web driver typing text as a user would]
   ... Testing is the major use case (80%); some for automation

   schuki: we have debugging and diagnostic on our agenda for
   later today
   ... how would this apply to other mobile Web Apps?

   david: we've tried to keep the API as simple as possible
   ... "executeScript" is the basic action that enables all the
   ... e.g. geolocation is implemented that way
   ... this could be used likewise for other systems

   <Zakim> dom, you wanted to ask about permissions management

   dom: how can this be used for interacting with permission

   david: we can set the permissions in the profile
   ... in Mozilla
   ... in our architecture, we can also drive the browser chrome
   ... via XUL
   ... we might need to look at a broader permission management
   ... but no interoperability on this in sight at this point

   manu: WebDriver incredibly important to our continuous
   integration in my company
   ... we've had to do a lot of integration to make repeatable
   ... which I think has been a barrier for Web developers to
   adopt that kind of workflow
   ... is there any plan to facilitate this?

   david: interop in this space is really hard
   ... the biggest user base for Web driver is for people that are
   not technical
   ... at the other end of the spectrum, some people dedicate a
   lot of resources to Web driver automatic testing
   ... finding the right balance between these two extremes is
   ... from a W3C perspective, we only care about the browser side
   of things
   ... getting interop at the lower layer of continuous
   integration seems like just too big a goal

   <Zakim> manu, you wanted to ask about test frameworks.

   schuki: thanks david! this will be useful input in our
   discussions on debugging and testing


   dom: as part of the closing the gap analysis the web is seen as
   being a less secure platform than nativw

   <schuki> s/nativm/native

   ... in native you have specific storage space

   ... the question is what should w3c do?

   ... it is difficult to disentangle what is perception and what
   is reality

   ... I recommend we work with security group to assess what the
   risks are and hiw we can reduce these


     [34] http://www.w3.org/Security/wiki/IG/Mobile_Security_analysis

   dom: a reoccuring topic is offline storage

   ... most mobile platforms have compartmentalisation

   ... a browser that hosts several apps cannot use

   ... there is the same origin method of compartmentalisation

   ... how do we ensure the browser gives the amount of security
   necessary to run web apps?

   dom: in the context of enterprise software (and other similar
   cases) is the way to manage keys and certificates

   <schuki> the web crypto working group has started looking into

   ... but i think we should start looking at which topics we
   should address in this field

   ... I think the topics are stream encryption

   ... but we should check this with the security group

   dom: another popular topic is because javascript is
   interpretted by the browser then there are a number of secuirty
   risks around cross site scripting

   ... web app source code is always open - you can see it

   ... there are tehcniques around that

   dom: use cases might be a good topic

   ... i would love some volunteers to help

   <schuki> action natasha (to reassign) build secuirty task force
   then task with finding use cases, requirements, and working
   with sec group

   <trackbot> Created ACTION-95 - (to reassign) build secuirty
   task force then task with finding use cases, requirements, and
   working with sec group [on Natasha Rooney - due 2013-11-22].

   bryan: do you think it would be a good idea to work with (e.g.)
   testing programme to find if we are working with the guidelines

   bryan: if we did find and link to some test suites would we be
   fine to publish them?

   dom: probably ok, does this group think we should produce some
   guidance to developers

   ... we still have room to have impact me in this space

   bryan: maybe we can work with gsma, David Rogers, maybe give
   some help here

   fan: we can help with use cases here

   <fan> obfuscation use cases are what irdeto would like to

   dom: maybe a good idea to include this in the dashboard, but
   yes we need to decide the exact next steps

Developer tools / debugging gap

   schuki: there are some tools out there that can help with
   debugging/developing on devices
   ... WebDriver provides clearly some useful stuff here

   dom: diagnostic api proposal

   ... this is being discussed in w3c

   ... we may want to look into this

   <schuki> action Natasha (to reassign) recruit dev tools /
   debugging experts

   <trackbot> Created ACTION-96 - (to reassign) recruit dev tools
   / debugging experts [on Natasha Rooney - due 2013-11-22].

   <bryan> For some of these purposes, esp resource efficiency, we
   can reference the free AT&T Application Resource Optimizer
   (ARO) tool at


   <schuki> action Natasha (to reassign) document or add to wiki a
   selection of dev tools, assess and list what we feel is missing
   for mobile web app developers

   <trackbot> Created ACTION-97 - (to reassign) document or add to
   wiki a selection of dev tools, assess and list what we feel is
   missing for mobile web app developers [on Natasha Rooney - due

   bryan: there are tools available

   <Zakim> bryan, you wanted to say that here again we need to
   reach out to actual users (devs) on what they need and percieve
   as the tooling gaps

   schuki: individuals in this group probably aren't necessarily
   very expert in this field
   ... so it would be useful to see that we bring people with that
   expertise in the group from our various companies
   ... I've take an action item toward that
   ... we should discuss how to get to a better understanding if
   the current state
   ... with input from social media and the list
   ... I'm particularly interested in on-device debugging


     [36] http://www.w3.org/wiki/Mobile/#New_and_Popular_Pages


     [37] http://www.w3.org/wiki/Mobile/Dev_Tools

   <bryan> I do believe we've had real progress in web platform
   support for developers in the last few years, web performance,
   web driver, etc - much of what's needed may be an educational
   outreach e.g. thru webplatform; if we find that there are
   further gaps in the actual platform (instead of just tools that
   the market provides), that would be the real value this group
   could add.



   dom: a useful next step might be to look at what has happened
   if anything to this diagnostics API proposal?

   <schuki> action natasha (to reassign) pull in diagnostics api
   into the docs

   <trackbot> Created ACTION-98 - (to reassign) pull in
   diagnostics api into the docs [on Natasha Rooney - due


   schuki: summarizing our meeting
   ... we're an IG, not creating standards
   ... we'll collaborate with other groups to achieve our goals of
   promoting the Web as a platform to mobile dev
   ... to be successful, we need to keep our wiki up to date and
   well organized
   ... we've discussed a lot of documentation
   ... out of coremob and dom's work
   ... some of it automated, some manual
   ... we're looking at moving some of it to dashboards through a
   more data-driven approach
   ... we'll pull in documents into that approach
   ... and look at how use cases and requirements fit in that
   ... Marcos raised issues on the coremob report in github
   ... I'll send a reminder on this to the list
   ... We talked about the offline situation, with ServiceWorker
   to the rescue
   ... it sounds like something we'll come out soon
   ... in Chromium, and I hope we can work together on demos and
   ... we'll keep track of that technology in the dashboard
   ... We talked about scrolling (in the context of new trends
   such "infinite scrolling")
   ... the question was raised whether garbage collection is
   something on which developers should have influence
   ... momentum scrolling is another related topic that is
   important to touch-screen devices
   ... Tobie presented briefly the testing effort
   ... this group can benefit a lot from this
   ... they are still looking for funds
   ... it would be great if your company can be interested in
   sponsoring on it
   ... if this continues and gets set up, we should be able to
   integrate the data that comes out of it in our dashboard
   ... Marcos and Ernesto have been working on homescreen
   ... right now somewhat iOS heavy, will push Marcos to bring
   perspectives from other platforms
   ... Bryan presented the Push API; the PAG that was raised on
   this spec has been resolved
   ... clearly needed to close the gap

   DKA: Safari on Mavericks has a similar but proprietary API
   ... we're looking at a possible polyfills to fallback between
   one API and the other
   ... we'd be happy to report back on that if and when we do it

   <scribe> ACTION: DKA to report back on push API polyfill
   [recorded in

   <trackbot> Created ACTION-99 - Report back on push api polyfill
   [on Daniel Appelquist - due 2013-11-22].

   schuki: we went through the API Gap identified out of the
   visionmobile research

   <scribe> ... completed by the analysis of PhoneGap most used

   UNKNOWN_SPEAKER: incl camera and network info
   ... We discussed this morning on "closing the gap" which got
   support for continuation
   ... support also to continue the app category approach
   ... Dom also presented the evolution of the WebAppState report
   ... with JSON files that Dom extracted from the existing report
   ... mix of manual and automation
   ... will continue to work on this
   ... Dave and Manu presented the ongoing work on payments with
   the workshop in Paris in March
   ... lots more to it than I had realized
   ... this group can help with use cases and requirements
   ... Permissions and Security covered by Dom, with the
   differences with Native
   ... Dom will bring it to the TAG
   ... further analysis is needed, possibly based on feedback from
   the TAG
   ... We need to understand how the sandbox model of the Web can
   apply to the requirements of mobile
   ... We need to make sure to collaborate effectively with the
   Web Security IG
   ... Finally, we had a light discussion on developer tools and
   ... we had a good demonstration of WebDriver applied to
   ... we should try to collect links to dev tools, incl via
   social networking
   ... and get more involvement from dev tools experts in the
   ... The next steps will include building task forces
   ... where people that are not here today will be needed
   ... I'll prepare this list of task forces and will ask people
   to sign up to these
   ... if you have a particular affinity to a topic, please
   consider signing up

   <schuki> action Natasha (to reassign) take top 100 / 200 apps
   and find the gap - this will show the gap in games

   <trackbot> Created ACTION-100 - (to reassign) take top 100 /
   200 apps and find the gap - this will show the gap in games [on
   Natasha Rooney - due 2013-11-22].

   <dka> +1 to doing something about mobile-web-games - e.g. a

   DKA: the intersection of developer tools, outreach and feedback
   and games shows a possible interest in organizing one or a
   series of event on the topic
   ... maybe not a formal workshop, a meetup of some sort
   ... between game developers and e.g. browser vendors in
   ... W3C should put some energy behind this, and I would be
   happy to help with that

   Bryan: we've done a considerable testing of the water in this
   ... it would be good to have focus on games

   dom: I'm looking into how we can involve dev community better

   schuki: I'm creating a wiki page to help us organize ourselves
   ... Thank you all for coming, travel safely!
   ... Great to have our F2F at TPAC
   ... I think we have a good way forward
   ... I want your feedback on what we may have done wrong
   ... feel free to email, IRC, chat with Dom if about me
   ... we want to steer this group into the right direction
   ... hoping to see through our various communication channels

   Bryan: excellent job natasha, thank you!

   dom: +1


   <Ruinan> +1

   <kotakagi> +1

   <PhilA> rrsagent generate minutes

Summary of Action Items

   [NEW] ACTION: DKA to report back on push API polyfill [recorded
   [NEW] ACTION: Dom to bring back up permissions on the TAG
   agenda [recorded in
   [NEW] ACTION: Schuki to hunt for volunteers on payments
   [recorded in

   [End of minutes]
Received on Tuesday, 19 November 2013 11:01:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:59:28 UTC