See also: IRC log
<trackbot> Date: 16 February 2011
<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/
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
<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
<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 .
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
darobin: Bryan's not on the call, so perhaps not good idea to discuss SysInfo