See also: IRC log
<trackbot> Date: 06 October 2010
<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/
Reminder for everyone to register
<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
<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
RESOLUTION: Minutes from 29 Sept 2010 approved
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
<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> http://www.w3.org/2010/policy-ws/papers/03-Doty-Wilde-Berkeley.pdf
<fjh> http://www.w3.org/2010/09/raggett-fresh-take-on-p3p/
<fjh> http://www.w3.org/2010/policy-ws/papers/04-Hart-stonybrook.pdf
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].
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
Surresh not present
<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
... will aim to produce a propsal based on above
<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)
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