# Device APIs Working Group Teleconference ## 27 Mar 2014 [Agenda][3] See also: [IRC log][4] ## Attendees Present Cathy_Chan, Frederick_Hirsch, Mats_Wichmann, Rich_Tibbett, Anssi_Kostiainen(IRC), Dominique_Hazael-Massieux, Giri_Mandyam(IRC), JeanClaude_Dufourd(IRC) Regrets Chair Frederick_Hirsch Scribe dom ## Contents * [Topics][5] 1. [Welcome, agenda review, announcements][6] 2. [Welcome, agenda review, scribe selection, announcements][7] 3. [Minutes approval][8] 4. [Netinfo API][9] 5. [Testing update][10] 6. [Cordova priorities][11] 7. [HTML Media Capture testing][12] 8. [Network Service Discovery][13] 9. [Action items review][14] 10. [Other Business][15] 11. [Adjourn][16] * [Summary of Action Items][17] * * * Date: 27 March 2014 ### Welcome, agenda review, announcements ScribeNick: dom ### Welcome, agenda review, scribe selection, announcements Vibration API related to WebApps gamepad API, discussion [http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0016.html][18] Frederick: we might want to think about that at some point, but it's probably OK to leave the current API as is ... I'll just notify them when we go to CR that sounds good to me ### Minutes approval Approve minutes from 20 March 2014 [http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/att-0014/minutes-2014-03-20.html][19] **RESOLUTION: [http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/att-0014/minutes-2014-03-20.html][19] are approved as minutes of March 20 call** ### Netinfo API Frederick: we've agreed to shelve it; I'm having trouble reaching Mounir ... I'm thinking to just go ahead and do it myself (update, Mounir replied on chat with update) Dom: sounds good to me ### Testing update ### Cordova priorities [http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/0022.html][20] Frederick: we discuss the usefulness of priotirizing work from a Cordova perspective In CR, two implementations (Blink/webkit), testing progressing (despite pull request not accepted yet), relatively straightforward spec Frederick: we have tests, implementations ... for HTML Media Capture ... next put Battery, then Light dom, you wanted to comment on light vs vibration dom: clarify, prioritization of alignment and contributing to tests dom: ambient light has less traction than vibration which is implemented in firefox and chrome ambient light implementation is happening in Chromium/Blink Frederick: I'm conflating alignment and testing dom: do we know if cordova will contribute to testing our QA ppl are working on completing Vibration, Battery, HTML Media Capture test suites dom: cordova is not using webIDL Frederick: [summarizing] there is quite a bit of work for them to align with our specs ... their implementations is not matching our specs at this time, but getting that alignment is separate from our Rec-track goals dom: yeah, reducing fragmentation in the HTML5-apps ecosystem (incl hybrid) is a good goal, but separate from proving implementation at the CR level fjh: attempting to summarize what dom said - one goal is to achieve adoption and uniform APIs which hasn't happened yet and can be quite a bit of work with code, docs etc. Another goal is to move to REC which requires W3C Process but different activity, possibly differen players fjh: achieving Cordova compatibilty is a useful direction but may not contribute directly to getting to rec in the short term ### HTML Media Capture testing Frederick: I've been looking at the pull requests -> [http://www.w3.org/mid/F5C5CDD5-6255-4027-8B9A-B222F1A5C7DC@nokia.com][21] Frederick on HTML Media Capture testing scribe: still waiting for review ... a comment thread in github about testability for privacy and security considerations which has normative statements ... questioning whether that's appropriate ... Cathy mentioned geolocation as an example ... which has normative requirements in privacy / security ... and they have related tests as well ... e.g. checking for permission denied ... my conclusion is that we don't have to gut the security and privacy considerations ... and that we should go ahead with what we have dom, you wanted to comment on geo as example and to comment on normative considerations, testing of shoulds dom: not sure geolocation is the best model, despite my involvement our QA person who wrote the test suite is waiting for +1s from reviewers or feedback on how to improve the suite if there are issues -- please let him know if there's something he can help with still dom: need to consider two items: security,privacy be normative and whether to create test cases for should cases dom: want to avoid security privacy considerations related to UI implementation dom: would personally prefer non-normative, if we keep them normative then should ask about testing, prefer not to test them due to UI considerations, requiring manual testing dom: processing should requirements is an issue Frederick: I'm concerned about taking privacy seriously without having normative text on it ... if privacy matters, we need to make sure it is actually taken into account in implementations ... agree that testing privacy doesn't fit as cleanly dom: normative requirements are for interoperability hence not approriate for privacy/security, and implementers will do what they want in this space dom: important to document but not as normative requirements, can be informative dom: key is to be clear on risks and way to mitigate them, cannot force implementation, misguided dom: geolocation requires URL to be displayed in prompts and that requirement is not followed by any implementations, for good reasons dom: be careful not to say it is not meaningful if not normative, e.g. if browser ignores threats and then exploited fjh: you are making competitive implementation argument **ACTION:** dom to react on testing html media capture privacy & security considerations [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action01][22]] Created ACTION-686 - React on testing html media capture privacy & security considerations [on Dominique Hazaël-Massieux - due 2014-04-03]. ### Network Service Discovery Frederick: would like to do 3 things: ... * go through the issues and see whether and how to resolve them ... * process around editing ... * how to move forward in general ... Rich, could you maybe start by describing where you think we are? ... and then I could get into our editing process Rich: sounds good; let's tackle high priority items first Frederick: in general, does this teleconference time work for you on regular basis, rich? Rich: yes: Frederick: so, summary of current status and news? Rich: in terms of the spec, the last major change was adding CORS a while ago ... I've made some comments on the technical discussions; they can be picked up again ... The main update is around intents to implement ... there was one intent in Chromium/Blink which started some of the changes we brought to the spec ... not clear where we stand in terms of getting implementors buy in ... Getting feedback from implementors is key in making progress, more than finetuning what we already have Frederick: my viewpoint on how the WG works: the way I see it is that WG makes decisions, and the editor brings them in in the spec ... getting WG agreement before getting stuff in the spec is important ... the decision lies within the WG consensus ... contributions can be made as issues, or specific text proposal, which in some cases can find their way directly in the spec ... of course, we need some implementors buy-in ... but I don't think there is a harm to think things through even if we don't have implementors buy-in yet ... I don't think implementors should decide everything; not sure how that would work with our own timelines and goals ... I'm not sure how to move forward if we don't have implementors buy-in dom, you wanted to discuss meaningful privacy and to Frederick: we have people interested in this spec from the TV space ... but they got pushed back from Adam?, and went into using something else Rich: Yeah, I've seen this ... I would have preferred these discussions to happen in W3C ... there are alternatives that are emerging which may be put NSD into a difficult position ... e.g. Chrome is now looking at the Presentation API ... In terms of next steps, we need to get feedback / buy-in from implementors Frederick: I looked at the Presentation API — it seemed complementary rather than in competition Rich: it's not a replacement API, but it does solve some use cases that NSD also solve ... e.g. what chromecast enables the group where the Presentation API is being worked on: [http://www.w3.org/community/webscreens/][23] Rich: display sharing is only a subset, but maybe that's the most useful subset we have Google, Mozilla, and Apple in the group Frederick: another worm will be how testable the spec would be given how complex it is Rich: at the network level, I have some ideas ... the UI stuff is more complicated for automated testing ... when it comes to service messaging, that's beyond what we would need to check ... but no testing plan since no implementation plan Frederick: so you would do this by sniffing the network Rich: possibly; but that only becomes a problem once we have implementation plans ... You also mentioned that the spec has lots of moving parts, and that's true ... the API started from a very ambitious approach ... maybe we can simply it, e.g. getting inspiration from the sockets idea ... the current stage is a bit frustrating, but I don't think we can move forward without implementations dom, you wanted to propose that next steps is to get people that want NSD to work with us on trying to get implementors' attention dom: seems right to wait for implementers feedback and interest dom: need to get right level of abstraction dom: next step should be to get more feedback from implementers, could ask Web & TV interest group for help dom: could specifically contact implementers we know to get feedback, if fundamental concerns with overall approach I already asked multiple times for web&tv ig help, to no avail dom: yes **ACTION:** fjh to make request to Web and TV interest group re network service discovery [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action02][24]] Created ACTION-687 - Make request to web and tv interest group re network service discovery [on Frederick Hirsch - due 2014-04-03]. **ACTION:** fjh to contact implementers re network service discovery directly [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action03][25]] Created ACTION-688 - Contact implementers re network service discovery directly [on Frederick Hirsch - due 2014-04-03]. Frederick: so, should we look at issues in the meantime of getting implementors feedback? Rich: I think it is difficult to focus on issues without implementors interest we are looking into implementing NSD as a Chrome extension Rich: I agree with dom we should be proactive on contacting implementors ... I've also been thinking about Web pages as advertising themselves on the network, which was supposed to be the 2nd stage after discovery ... but it could be a good thing to explore ... might also raise interest on discovery Frederick: could you share more about that? Rich: I've been doing some brainstorming around that ... you can create channels among some-origin pages ... but there isn't a generic cross-origin channel ... enabling this would open very interesting use cases ... we could look at this either from an NSD perspective (relying on UPNP etc) ... or using a different sockets approach ... I have some early design thoughts Frederick: we would want to be careful in light of NSD ... I would certainly support the simple approach Rich: as a reminder, Opera originally implemented NSD ... but we switched browser engine in the meantime Frederick: can we coordinate on contacts with implementors? Rich: probably best if it comes from you as chair Frederick: OK, based on this, I think we'll stay off issues for now; Rich, might want to look at some of the minor editorial ones ### Action items review ACTION-684? ACTION-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on batter, duplicate so does not need to be incorporate -- due 2014-03-27 -- OPEN [http://www.w3.org/2009/dap/track/actions/684][26] ACTION-682? ACTION-682 -- Frederick Hirsch to Follow up on how to approve pull requests and to identify correct reviewers, remove inappropriate critics etc -- due 2014-03-06 -- OPEN [http://www.w3.org/2009/dap/track/actions/682][27] ACTION-684: see [https://github.com/w3c/web-platform- tests/pull/376#issuecomment-38816061][28] Notes added to ACTION-684 Help close pull request #376 on batter, duplicate so does not need to be incorporate. trackbot, close ACTION-684 Closed ACTION-684. action-684? action-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on batter, duplicate so does not need to be incorporate -- due 2014-03-27 -- CLOSED [http://www.w3.org/2009/dap/track/actions/684][26] ACTION-684? ACTION-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on battery, duplicate so does not need to be incorporate -- due 2014-03-27 -- CLOSED [http://www.w3.org/2009/dap/track/actions/684][26] ### Other Business next meeting 10 april, see schedule for upcoming dates, [http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences][29] ### Adjourn ## Summary of Action Items **[NEW]** **ACTION:** dom to react on testing html media capture privacy & security considerations [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action01][22]] **[NEW]** **ACTION:** fjh to contact implementers re network service discovery directly [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action03][25]] **[NEW]** **ACTION:** fjh to make request to Web and TV interest group re network service discovery [recorded in [http://www.w3.org/2014/03/27-dap- minutes.html#action02][24]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][30] version 1.135 ([CVS log][31]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/0021.html [4]: http://www.w3.org/2014/03/27-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #item09 [15]: #item10 [16]: #item11 [17]: #ActionSummary [18]: http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/0016.html [19]: http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/att-0014/minutes-2014-03-20.html [20]: http://lists.w3.org/Archives/Public/public-device- apis/2014Mar/0022.html [21]: http://www.w3.org/mid/F5C5CDD5-6255-4027-8B9A-B222F1A5C7DC@nokia.com [22]: http://www.w3.org/2014/03/27-dap-minutes.html#action01 [23]: http://www.w3.org/community/webscreens/ [24]: http://www.w3.org/2014/03/27-dap-minutes.html#action02 [25]: http://www.w3.org/2014/03/27-dap-minutes.html#action03 [26]: http://www.w3.org/2009/dap/track/actions/684 [27]: http://www.w3.org/2009/dap/track/actions/682 [28]: https://github.com/w3c/web-platform- tests/pull/376#issuecomment-38816061 [29]: http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences [30]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [31]: http://dev.w3.org/cvsweb/2002/scribe/