W3C

Device APIs and Policy Working Group Teleconference

16 Feb 2011

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, Robin_Berjon, Frederick_Hirsch, Dzung_Tran, jerome_giraud, cecile_Marc, Laszlo_Gombos, Harald_Alvestrand, Kyung-Tak_Lee, Suresh_Chitturi, Cathy_Chan, Rich_Tibbett
Regrets
Dom
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
Anssi_Kostiainen

Contents


<trackbot> Date: 16 February 2011

Administrative

<scribe> ScribeNick: AnssiK

<scribe> Scribe: Anssi_Kostiainen

<fjh> Seoul F2F and workshop planning

<fjh> please complete registration page, http://www.w3.org/2002/09/wbs/43696/seoul-f2f-reg/

Announcements, meeting planning, logistics

fjh: everyone register to the f2f meeting
... for planning purposes we need to know if you're attending or not
... there's also a workshop in between on Thu
... we'll need to start f2f agenda planning
... please send proposals on the list

Minutes approval

<fjh> Approve 9 February minutes

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/att-0077/minutes-2011-02-09.html

RESOLUTION: Minutes from 9 February 2011 approved

Rechartering

<fjh> http://www.w3.org/2010/11/DeviceAPICharter.html

<fjh> Privacy, security deliverables?

fjh: we have an issue for Charter draft, missing some explicit deliverables

darobin: the simplest way would be to send the proposed changed to the list

<fjh> ACTION: fjh to propose charter changes related to security and privacy deliverables [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action01]

<trackbot> Created ACTION-335 - Propose charter changes related to security and privacy deliverables [on Frederick Hirsch - due 2011-02-23].

suresh: is there a timeline for the Charter approval

fjh: we should have a draft before f2f
... and approve at the f2f, but would need to check with Dom

darobin: to be clear, it's not this group that approved the Charter, it's Advisory Committee decision

<Zakim> AnssiK, you wanted to comment on Feature Permissions

http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html

http://lists.w3.org/Archives/Public/public-web-notification/2010Nov/0001.html

<darobin> +1

http://www.chromium.org/developers/design-documents/desktop-notifications/api-specification

<darobin> you mean http://dev.w3.org/2009/dap/api-perms/ ?

<fjh> Feature Permissions was moving forward but we need to consider other aspects of security/privacy as well, so probably more than one spec to move forward

<fjh> +1 to progressing it

<lgombos> lgombos: How the two http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html spec relates to http://www.w3.org/TR/api-perms/

requestPermission(navigator.contact)

requestPermission('navigator.contact')

<richt> FWIW, that's not a great design. It's better to request permission on the actual object. It might not exist or all developers need to do: if(navigator.contact) { /* request permission*/ }

<fjh> ACTION: fjh to ask about sharing draft workshop agenda with WG [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action02]

<trackbot> Created ACTION-336 - Ask about sharing draft workshop agenda with WG [on Frederick Hirsch - due 2011-02-23].

AnssiK: i.e. pass either a reference, or a stringification of it

laszlo: at the moment both specs assume strings
... reason for that is needs to be re-usable in the P&C

<darobin> [so, richt, Contacts implements RequestPermission?]

<richt> darobin, possibly. that might work...maybe...perhaps.

<darobin> [if (navigator.contacts) navigator.contacts.requestPermission(success, error)?]

<richt> :)

laszlo: we'll need to figure out the dependency together with the WebNot WG

<richt> just do navigator.contacts.find(). maybe permissions don't need to be codified and standardized at all?

Laszlo: we could define a FeatureRequest interface, and the API implements that as per richt proposal

window.webkitNotifications.checkPermission

<fjh> laszlo suggests http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html could be approach for all APIs in DAP

add to the Charter: "an API for web pages to request permission to use privileged user agent features"

<fjh> +1

<darobin> robin: not all APIs, but perhaps for some

richt: I'm still unsure about this whole are, if you want to do something you just do it
... not sure standardizing this is good, quite controversial still
... expect the Web Notifications stuff change a bit still

laszlo: one of the design guidelines behind the current Feat Perms: decouple the feature request from the API invocation

darobin: this is decoupled from the policy*
... I'm not sure if this applies to lots of other specs
... e.g. not very well to Contacts
... we should spec out what Web Not people need, at the minimum

richt: requesting all permissions up-front, interesting scenario

Chrome > Wrench > Preferences > Under the Hood > Content Settings... > Notifications

fjh: we should agree that we'll probably need something in the Charter for Feature Permissions

richt: Chrome has the same config UI for Location (Geolocation API)
... would like to document the diff to Notifications

<richt> my question is what does a permissioning interface give us on top of how geolocation (in Chrome Preferences) currently works? If we have solid use cases beyond those already implemented for geolocation then we're motoring :)

laszlo: I'm taking an action on this and catch up with John Gregg

<darobin> ACTION: Laszlo to find out about current status of permissions/notifications with John Gregg [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action03]

<trackbot> Created ACTION-337 - Find out about current status of permissions/notifications with John Gregg [on Laszlo Gombos - due 2011-02-23].

darobin: multiple permissions UC, support on that?

laszlo: +1

<darobin> ACTION: Laszlo to look into multiple permission/installable designs for APIs [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action04]

<trackbot> Created ACTION-338 - Look into multiple permission/installable designs for APIs [on Laszlo Gombos - due 2011-02-23].

laszlo: another related action, go though the existing DAP APIs and see if Feat Perms works with them
... I'm happy taking that action as well

<darobin> ACTION: Laszlo to go through existing DAP APIs to see if there are use cases there for Feat Perms (or if the existing approaches work better) [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action05]

<trackbot> Created ACTION-339 - Go through existing DAP APIs to see if there are use cases there for Feat Perms (or if the existing approaches work better) [on Laszlo Gombos - due 2011-02-23].

richt: can we also look into the use cases, as described above?

darobin: any takers for use cases action?

<richt> strong solid use cases will sell the proposal if it adds value on top of what we already have without permisioning interfaces.

darobin: perhaps an issue for UCs is ok?

<darobin> ISSUE: We need solid use cases for Feat Perms if it's going to fly

<trackbot> Created ISSUE-109 - We need solid use cases for Feat Perms if it's going to fly ; please complete additional details at http://www.w3.org/2009/dap/track/issues/109/edit .

Privacy

fjh: other than cdt folks involved with privacy?

<fjh> need to move privacy work forward

darobin: privacy by design, relationship of rulesets with DoNotTrack proposal

<darobin> ACTION: Frederick to look at how we're doing privacy by design [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action06]

<trackbot> Created ACTION-340 - Look at how we're doing privacy by design [on Frederick Hirsch - due 2011-02-23].

richt: I agree with darobin, privacy should be baked into the API design
... proposing privacy papers should end up being W3C Notes

fjh: do not track, secondary use, retention require some thought
... might apply across all the APIs

richt: all the APIs should consider all those points individually

fjh: understanding privacy by design is important, there may be privacy deliverables

richt: we may want to put W3C Note deliverables into "Other Deliverables" section in the Charter

Sysinfo

darobin: Bryan's not on the call, so perhaps not good idea to discuss SysInfo

Adjourn

Summary of Action Items

[NEW] ACTION: fjh to ask about sharing draft workshop agenda with WG [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action02]
[NEW] ACTION: fjh to propose charter changes related to security and privacy deliverables [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action01]
[NEW] ACTION: Frederick to look at how we're doing privacy by design [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action06]
[NEW] ACTION: Laszlo to find out about current status of permissions/notifications with John Gregg [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action03]
[NEW] ACTION: Laszlo to go through existing DAP APIs to see if there are use cases there for Feat Perms (or if the existing approaches work better) [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action05]
[NEW] ACTION: Laszlo to look into multiple permission/installable designs for APIs [recorded in http://www.w3.org/2011/02/16-dap-minutes.html#action04]
 
[End of minutes]

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