Device APIs and Policy Working Group Teleconference -- 06 Oct 2010

<trackbot> Date: 06 October 2010

<fjh> DAP 3279 ; agenda http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0007.html ; Please register Present+ First_Last; also update zakim handle, zakim, aaa is handle

Administrative

<scribe> Scribenick: Claes

<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/

<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

TPAC registration

Reminder for everyone to register

<fjh> Agenda: ; Please register Present+ First_Last; also update zakim handle, zakim, aaa is handle

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0007.html

<fjh> "Permissions for Device API Access" published as First Public Working Draft, , http://w3.org/TR/api-perms

<fjh> Reminder, no call next week (13 October 2010 Teleconference Cancelled)

Reminder, no call next week

<fjh> Next teleconference 20 October, http://www.w3.org/2009/dap/minutes

Minutes approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0160/minutes-2010-09-29.html

<fjh> proposed RESOLUTION: Minutes from 29 Sept 2010 approved

<fjh> ]

RESOLUTION: Minutes from 29 Sept 2010 approved

Permissions

Draft published

<fjh> published, http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0006.html

<dom> welcome cecile!

<scribe> New member: Cecile Marc, Orange

Privacy

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0008.html

<fjh> Alissa added issues to draft

<dom> ACTION-210?

<trackbot> ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/210

<fjh> W3C Workshop on Privacy and data usage control held 4-5 October, http://www.w3.org/2010/policy-ws/agenda.html

Workshop in Boston

<fjh> 12http://www.w3.org/2010/policy-ws/papers/03-Doty-Wilde-Berkeley.pdf

<fjh> 12http://www.w3.org/2010/09/raggett-fresh-take-on-p3p/

<fjh> 12http://www.w3.org/2010/policy-ws/papers/04-Hart-stonybrook.pdf

APIs

Contacts

Event based invocation:

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0001.html

<fjh> http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom-events

<darobin> [+1 from me]

Richard: Added an informative section on invocation via dom events

Robin: Wants it normative
... go ahead and add it

<dom> (e.g. "touchstart")

Robin: worries if we start whitelisting events

<dom> (there is a new proposed wg to work on touch interfaces)

Richard: Will work on this and make it normative

<fjh> touch working group, http://www.w3.org/2010/07/touchinterface-charter.html

Ilkka: Good optimization. Also usable in capture API

<dom> (I would start putting it individually in specs, and factoring it out only when it's clear that it's productive)

Ilkka: could we make it reusable?

<Zakim> richt, you wanted to respond to Illka RE: device API

<darobin> [+1 to dom]

Richard: Agrees, it could be applicable in capture API as well
... need device element?
... a JS way to call JS API

<dom> (I'm doubtful about this; <device> had all sort of protections (in terms of styling, clickjacking, etc) IIRC)

<darobin> [I'm starting to think we're doing a little too much design on the fly orally]

Richard: could deprecate device element?

<fjh> Do we understand the privacy and security implications for this approach, and that be added to the section in this document?

<darobin> [fjh, no, we don't really yet, but it's worth investigating]

<dom> (the other thing that the <device> element is a streaming API, very relevant for capture, but possibly dinstiguishable)

<fjh> [agree that it is worth investigating]

More productive to continue this discussion by e-mail

<fjh> clickjacking, and coercion need review

Bryan: Could we describe clickjacking in security and privacy section?

Richard: Nothing is shared until the user chooses

<fjh> robin: denial of service not an issue since picker is modal unlike window.open

Rich: The prompt is modal..

sorry lost phone connection

Yes, I am calling

<fjh> rich: we should note this in the spec, even though it might appear controversial

having trouble calling in

<fjh> ansii: clickjacking could be a serious attach, a big concern

<fjh> ansii: attack could make it likely to take picture etc without intending to. should take this risk seriously

<fjh> rich: tested in various browsers with variety of means to generate click events, and can do now already, but gets stopped at dialog

<fjh> ansii: where do we find examples of clickjacking attacks

<dom> we could ask public-web-security?

Back, had to use US number

<scribe> Scribenick: Claes

<dom> (so, maybe the <device>-replacement idea should be put into a document on its own while we work on it?)

Rich: Normative or not?

<darobin> +1

<fjh> having separate document would address Ilkka's concern about reuse

<dom> (or just an action on rich?)

Proposed RESOLUTION: the <device>-replacement idea should be put into a document on its own while we work on it

<dom> ACTION: Richard to put his ideas on <device>-alternative in a separate editors draft [recorded in http://www.w3.org/2010/10/06-dap-minutes.html#action01]

<trackbot> Created ACTION-283 - Put his ideas on <device>-alternative in a separate editors draft [on Richard Tibbett - due 2010-10-13].

Capture API

Action on review to review Privacy

<trackbot> Sorry, couldn't find user - on

Will be done withi two weeks

<dom> ACTION-251 due +2 weeks

<trackbot> ACTION-251 Review privacy text related to ISSUE-78 for capture due date now +2 weeks

Calendar

Surresh not present

Sys Info

<fjh> ACTION-213?

<trackbot> ACTION-213 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-07-21 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/213

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0002.html

<richt> Is anyone aware of navigator.connection.type in Android?

<dom> I've pointed to it a couple of months ago

<richt> I'd like to approach Sys Info API security in a similar way...

<richt> ...limit the info available but no security prompts.

Rich: navigator.connection.type in Android says type of connection

<fjh> s/DAP 3279.*//

Rich: will aim to produce a propsal based on above

<fjh> s/\]//

<AnssiK> [some info on clickjacking from The Open Web Application Security Project: http://www.owasp.org/index.php/Clickjacking]

Rich: without security promting etc

<dom> (I agree network.connection.type is indeed pretty harmless a priori; enabling it would require a lot of changes to the architecture of sysinfo a priori)

<fjh> s/^12//g

Dong: Have reviewed Sys Info. Would like more examples

<dom> (looking at the network interface in sysinfo, everything seems actually pretty harmless, even taken in combination; maybe the security model for networkinfo should be no prompt?)

<darobin> ACTION-243?

<trackbot> ACTION-243 -- Dong-Young Lee to review sysinfo draft after edits made -- due 2010-08-09 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/243

<darobin> ACTION-243 closed

<trackbot> ACTION-243 Review sysinfo draft after edits made closed

<dom> ACTION-243: feedback is: more examples would make the document easier to understand

<trackbot> ACTION-243 Review sysinfo draft after edits made notes added

- DRAFT -

Device APIs and Policy Working Group Teleconference

06 Oct 2010

Attendees

Contents