W3C

Device APIs Working Group Teleconference

20 Mar 2014

Agenda

See also: IRC log

Attendees

Present
Frederick_Hirsch, Mats_Wichmann, Giri_Mandyam, Cathy_Chan, Lisa_DeLuca
Regrets
Chair
Frederick_Hirsch
Scribe
fjh

Contents


<trackbot> Date: 20 March 2014

<scribe> ScribeNick: fjh

Welcome, agenda review, announcements

Alpha pubrules checker: http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0004.html

RESOLUTION: Cancel 3 April 2014 teleconference

Minutes approval

Approve minutes from 27 February 2014

http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/att-0058/minutes-2014-02-27.html

RESOLUTION: Minutes from 27 February 2014 are approved

Network Information

CfC concluded, will shelve Network Information API specification, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0003.html

Planning publication for 27 March - publication draft preparation needed

fjh: might delay this publication for a week so that we can properly reference the use cases document being published as a W3C Note on 27 March
... simpler than working on simultaneous publication, no rush here

HTML Media Capture Testing

Test pull request proposal, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0005.html

Review Security and Privacy considerations section - how to handle generally in test reports/tool

http://www.w3.org/TR/2013/CR-html-media-capture-20130509/

fjh: the tests look reasonable as noted in my email, the issue is with the nature of security/privacy considerations due to need for flexibility with regards to implementations and some higher level or non testable guidance
... Here is extract from document

[[ The user agent should not enable any device for media capture, such as a microphone or camera, until a user interaction giving implicit consent is completed. A user agent should also provide an indication when such an input device is enabled and make it possible to terminate such capture. Similarly, the user agent should allow the user:

to select the exact media capture device to be used if there exists multiple devices of the same type (e.g. a front-facing camera in addition to a primary camera).

to disable sound capture when in the video capture mode.

This specification builds upon the security and privacy protections provided by the <input type="file"> [HTML5] and the [FILE-API] specifications; in particular, it is expected that any offer to start capturing content from the user’s device would require a specific user interaction on an HTML element that is entirely controlled by the user agent.

Implementors should take care of additional leakage of privacy-sensitive data from captured media. For instance, embedding the user’s location in a captured media metadata (e.g. EXIF) might transmit more private data than the user might be expecting.]]

fjh: perhaps we should add sentence to conformance section regarding fact that security/privacy considerations are hard to test, special case etc

<scribe> ACTION: fjh to draft proposal for conformance and testing related to security and privacy [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action01]

<trackbot> Created ACTION-683 - Draft proposal for conformance and testing related to security and privacy [on Frederick Hirsch - due 2014-03-27].

cathy: not an issue in other tests

fjh: right, light and proximity do not have any SHOULDs in security,privacy section and vibration has no security, privacy section
... similar issue appears to be in network service discovery

cathy: suggest we update implementation report rather than conformance section
... should check geolocation

fjh: yes, looking at geolocation they have musts in the security,privacy considerations section
... also tests, but some pass by referencing the web site privacy policy it seems

http://www.w3.org/2008/geolocation/drafts/API/Implementation-Report.html

http://www.w3.org/TR/geolocation-API/

fjh: so it looks like it is possible to go to REC with security and privacy normative requirements
... we need to review the language in the spec some more, I'll take another look
... geolocation also had conformance targets, web site and user agent
... we might need for review roles as well (note will update action to include looking more closely at geolocation approach etc)

Other Testing

Updated test links on home page, http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0006.html

Pull request status summary : http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0049.html

cathy: pull request from Lisa for battery status, comments from intel
... that file is testing battery interface, so not right place for that test
... so we should close that pull without accepting, and can say done with battery
... that pull was a duplicate

<scribe> ACTION: dom to help close pull request #376 on battery, duplicate so does not need to be incorporate [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action02]

<trackbot> Created ACTION-684 - Help close pull request #376 on battery, duplicate so does not need to be incorporate [on Dominique Hazaël-Massieux - due 2014-03-27].

Cordova update, http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0059.html

fjh: what should this group do with regards to Cordova

lisa: we could use help knowing what needs to be done to align specs, jira issues say that they need to be aligned

note - we need to determine who can help with reviewing the various issues to note the differences

lisa: need to prioritize and work through the list

<scribe> ACTION: fjh to review priorities of cordova alignment [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action03]

<trackbot> Created ACTION-685 - Review priorities of cordova alignment [on Frederick Hirsch - due 2014-03-27].

lisa: we could arrange another call if needed

Network Service Discovery

fjh: defer until we have Rich

Meeting Scheduling

Update to alternative week schedule, see http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0007.html

fjh: I believe someone asked about keeping weekly schedule as place holder but with small group we can adjust if needed, but we haven't needed weekly call for some time so I think it is better to go to alternate weeks now.

<mats> it was, but I'm fine with the change to alternate weeks

RESOLUTION: adopt meeting schedule in http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0007.html

Other Business

fjh: we probably should work through one spec with a draft implementation report etc even though all testing isn't done, so we can test out the approach and make sure we are on track, then we can apply to others, hopefully ease process of getting to REC.

Adjourn

Summary of Action Items

[NEW] ACTION: dom to help close pull request #376 on battery, duplicate so does not need to be incorporate [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action02]
[NEW] ACTION: fjh to draft proposal for conformance and testing related to security and privacy [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action01]
[NEW] ACTION: fjh to review priorities of cordova alignment [recorded in http://www.w3.org/2014/03/20-dap-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $