# Device APIs and Policy Working Group Teleconference ## 05 May 2010 [Agenda][3] See also: [IRC log][4] ## Attendees Present Robin_Berjon, Frederick_Hirsch, Dzung_Tran, Soonho_Lee, LauraA, enewland, Anssi_Kostiainen, Suresh_Chitturi, Brian_Leroux, Claes_Nilsson, Max_Froumentin Regrets Alissa_Cooper, John_Morris, Dom, Ilkka_Oksanen Chair Robin_Berjon, Frederick_Hirsch Scribe Erica ## Contents * [Topics][5] 1. [administrative][6] 2. [Minutes approval][7] 3. [Policy requirements and rulesets][8] 4. [Privacy requrements and rulesets][9] 5. [APIs - SysInfo][10] 6. [APIs - Testing][11] 7. [APIs messaging][12] * [Summary of Action Items][13] * * * Date: 05 May 2010 scribenick: enewland Scribe: Erica ### administrative Call for Exclusions, System Info API call for exclusions for system info [http://lists.w3.org/Archives/Member/member-device- apis/2010May/0000.html][14] no other announcements ### Minutes approval [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/att-0117/minutes-2010-04-28.html][15] **RESOLUTION: minutes from 28 April 2010 approved** meeting to be held next week as usual ### Policy requirements and rulesets policy framework [http://lists.w3.org/Archives/Public/public-device- apis/2010May/0011.html][16] Laura: introducing email she sent morning of May 5, 2010. ... outlined some differences between NOKIA document and policy document ... NOKIA document covers trust domain and access policies ... trust manager and access manager are independent elements ... first major difference: to match NOKIA's input, need to define trust policies and access policies separately, instead of one generic security policy for everything. ... for example. Trust domain request picture: data flow from access request to assign appropriate trust domain to given Web content. ... NOKIA document has separate trust manager, with separate trust domain and sends that back to access requester. when access requester needs to request access to specific api it sends trust domain that had been requested previously, ... trust policy and access policy would be handled by same PDP ...concerns: if we follow this approach, there are a few major changes that need to be done to security model as it now stands ... need to define trust policies from scratch ... different structures, naming, etc. ... this trust domain approach can already be done using security model as we have it now. ... may not need explicit trust manager or trust policy. possible to write a security policy following a trust domain approach ... one section for each trust domain that policy writer wants to define ... first question to answer: where are we now and what are steps forward? choice between having explicit trust domains as nokia has proposed versus doing as we have in bondi submission fjh: we need to think more deeply about this. Figure out what else the implications are there. LauraA: I understand we need to be explicit defining trust domains. We could modifiy what we already have to make it more trust domain explicit. Trying to explain how a policy will be written following trust domain approach but not necessarily demanding such an approach from the beginning. bryan_sullivan: changes are what is necessary. Trust domain concept and management of trust domains as separate set of directives is something that was discussed early in bondi as well. To manage trust separately from policy ... to simplify evolution of what we wanted to do in bondi. To find mechanisms for delegation of trust, etc. It is easily doable throughwhat LauraA has presented. fjh: it might be beneficial to go through with trust domain approach but let's give it a little time on the list suresh: question for clarification. In current draft, step #2 is access request. Seems as though this access request, which is same as bondi's, is generic in that it combines trust domain and access information. But with this new, modified approach, trust domain and access are separated. So, in document it is difficult to understand what gets passed in step #2 in terms of data and how this is a change. is it just making things more explicit or is there more my understanding from conversation is that from BONDI perspective changing to make explicit trust domains should not be a big problem, and could be done LauraA: In step 2 there is this access request. When access requester has to request access to a specific API, this access request would be sent together with the trust domain that was assigned before hand. For widgets, the trust domain request may usually be carried out by the installer, so trust domain is assigned from beginning suresh: so you would first validate trust domain and then make access request, but if trust domain is already available then you can skip the first step. ... so key difference in terms of data flow is one-step approach versus goosestep approach. fjh: you wouldn't need first step repeatedly in a series of API calls. LauraA: web content would be assigned trust domain and that would work for all access requests afterward fjh: seems like this change is doable. If we think this is right thing to do, we can go ahead and do it. ... We will talk about it next week. There is an email from Paddy on this subject ### Privacy requrements and rulesets enewland: nothing new to report ### APIs - SysInfo darobin: is it enough to have four positions in sysinfo orientation? max: four positions is enough. **RESOLUTION: SysInfo - four orientations are enough** keep current list of camera properties? supportsVideo, hasFlash, sensorPixels, maxZoomFactor darobin: list of camera properties. is current list enough? maxf: there is no need to go beyond that. Claes: what we have today is fine. Thomas: we have maximum zoom factor, do we have minimum zoom factor? ... for example, wide angle lenses Max: idea was to avoid going into focal length. ... idea was to avoid going into focal length darobin: We are near last call, could ask for some review before last call and make that part of the email. **RESOLUTION: SysInfo - the current list of camera properties is enough** darobin: flag it as a resolution that we are ok but will flag as needing to be reviewed in email ... should we have no sensors, such as heart rate, step counters ... etc including question of focal length in email requesting review max: ambient noise, atmospheric pressure, etc. are environmental sensors. But what about more human sensors? heart rate, etc. Claes: The main purpose in including sensors in this specification is that this specification is supposed to be a simple interface that explains common use cases. human sensors have even more privacy considerations Claes: perhaps it is a bit inconsistent to say that the current sensors are all environmental sensors but not the user. So perhaps we should change scope of sensors we support. ... more generic specification for sensors may be coming in the future, but if we want to get something out within this release, that would be good. there are common use cases for heart rate and step counter fjh: there are privacy implications here ... different privacy concerns, ways of addressing them, limits on how they can be used Thomas: We are not talking about the properties of the device but of the individual. This is a different set of sensors from what we have been discussing so far I like the idea of specifying that the sensors we are supporting is environmental type We address the heart rate and other type of sensors in next release Thomas: we are starting to talk about the user, and should probably put them in separate API +1 to tlr, different type of information darobin: probably want to make it a separate spec **RESOLUTION: scope of SysInfo stays the same, we will look into user sensors later** darobin: this is on the road map for future improvements ISSUE-76? ISSUE-76 -- Available/Preferred Networks in sysinfo -- OPEN [http://www.w3.org/2009/dap/track/issues/76][17] close ISSUE-76 ISSUE-76 Available/Preferred Networks in sysinfo closed darobin: that issue should be closed ISSUE-79? ISSUE-79 -- Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk -- OPEN [http://www.w3.org/2009/dap/track/issues/79][18] close ISSUE-79 ISSUE-79 Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk closed darobin: intend to release last call of ISSUE-79 within week. how does that sound? ... clarification. The idea is to tell people that we are planning to go to last call, point them to draft and go to last call suresh: clarification - is intention of last call to gather feedback on current draft or also can we change something if we notice something missing. Is it open to new properties? darobin: the idea is to ask people to review it very carefully and if all goes well then we move on to the recommendations and implementation testing. would not be open to new things suresh: unfortunately, we haven't done thorough review of the scope of this draft. Could we delay by one week? darobin: proposal was to give people one or two weeks to review before going to last call. Purpose was to announce that we were thinking of going to last call soon. 2 weeks **RESOLUTION: announce a two week pre-LC review period for SysInfo, then move it to LC if all goes well** RESOLUTION: The WG love Max ### APIs - Testing :) [http://docs.jquery.com/QUnit][19] [http://github.com/phonegap/mobile-spec][20] darobin: Appropriate given that we are planning first last call. Last call is period when we should start thinking seriously about testing. ... we discussed using QUnit and mobile-spec. brian: mobile-spec is suite of QUnit spec. We have been favoring performance over total compliance. ... For the most part it works well. Supports asynchronous testing, which is critical. ... automation is still a problem. You can run inside emulators but they don't really emulate anything. Tend to have manual tests, run on actual devices ... there will be failures on some devices. Sometimes device doesn't have capability to run a particular interface. For example, if phone doesn't have GPS then that test will fail, but that doesn't mean we shouldn't have GPS test. ... QUnit is good. mobile-spec is a good starting point, even if we don't eventually use it. It is complete and well organized. ... we also have some techs coming in soon from Deutch Telecom, they have added Bondi 1.1 APIs. Soon you will be able to choose which APIs you want to use. darobin: Having looked at number of testing frameworks, it seems that QUnit is most adapted to our needs. ... has anyone else looked into similar questions? AnssiK: QUnit is a fairly solid choice. [http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0132.html][21] AnssiK: good presentation by John Resig. Will find it and paste it to IRC brian: There's also another program, device anywhere. Proprietary but offer automated testing. Perhaps could look into that so we could take this to next step of automation [http://www.slideshare.net/jeresig/understanding-javascript- testing][22] darobin: presumably DAP would not get involved in creating an automated framework. But if tests we produce can be imported into another system, that would be a big plus. People can feed their tests back to us. bryan_sullivan: We can compare this to test framework that has been developed for use in bondi. ... Question. If I want to validate that I can send a message - sending an email to myself, for example - is that easily done within this test framework. darobin: When people fill out instantation reports they report whether or not they successfully, for instance, received an email afterwords. bryan_sullivan: Will test framework directly support ability to send and receive a message, for example. Or do we need to create mini-test apps. brianleroux: Get into functional testing.... bryan_sullivan: The problem is that to fully test an API, you need to see if API supports normative validation. darobin: There is some level of agreement on qUnit and moving forward with mobile specs. ... group should look into sysinfo testing in mobile spec brianleroux: i can work on putting that in over the next week ... will send message to list with pointers to documentation darobin: no other comments with respect to testing. moving on ### APIs messaging darobin: any other API topics ... none raised. frederick: request that people look at LauraA's email on policy framework. darobin: adjourned for this week. darobin won't be here next week ## Summary of Action Items [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][23] version 1.135 ([CVS log][24]) $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/2010May/0006.html [4]: http://www.w3.org/2010/05/05-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #ActionSummary [14]: http://lists.w3.org/Archives/Member/member-device- apis/2010May/0000.html [15]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/att-0117/minutes-2010-04-28.html [16]: http://lists.w3.org/Archives/Public/public-device- apis/2010May/0011.html [17]: http://www.w3.org/2009/dap/track/issues/76 [18]: http://www.w3.org/2009/dap/track/issues/79 [19]: http://docs.jquery.com/QUnit [20]: http://github.com/phonegap/mobile-spec [21]: http://lists.w3.org/Archives/Public/public-device- apis/2010Apr/0132.html [22]: http://www.slideshare.net/jeresig/understanding-javascript-testing [23]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [24]: http://dev.w3.org/cvsweb/2002/scribe/