See also: IRC log
<trackbot> Date: 20 October 2010
<fjh> ScribeNick: jmorris
fjh: talk about f2f
... will send f2f agenda soon
... any suggestions for agenda would be welcome
... possibly we should talk with Web Notifications about permissions stuff
<dom> (it doesn't look like they will meet there)
<dom> http://www.w3.org/2010/11/TPAC/#GroupSchedule
<darobin> (yeah, I'd be surprised if they ever met, given the group)
fjh: what is going on with Geolocation
Claes: I am working with Geolocation
... they are not working specifically on security/privacy right now
... perhaps discussion on geoloc privacy, but not directly related to DAP
fjh: we are overlapping with HTML WG, perhaps we should talk with them
darobin: I can contact Web Notification, and we should also talk to html
<darobin> ACTION: Robin to ping HTML chairs, Notifications chair to see about potential joint meetings [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action01]
<trackbot> Created ACTION-284 - Ping HTML chairs, Notifications chair to see about potential joint meetings [on Robin Berjon - due 2010-10-27].
fjh: darobin to contact HTML, fjh to contact Web Notification
<scribe> ACTION: fjh to ping web notification group [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action02]
<trackbot> Created ACTION-285 - Ping web notification group [on Frederick Hirsch - due 2010-10-27].
darobin: possibly talk at f2f about test suites
<dom> +1 on reusing PhoneGap's stuff if possible
<darobin> +1 too
AnssiK: can re reuse test suite phonegap
<fjh> anssi: asks about reusing phonegap test suite
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0031.html
<Zakim> dom, you wanted to talk on licenses
<dom> http://www.w3.org/Consortium/Legal/2008/04-testsuite-license.html
dom: w3c has special license for document and PST? license
... so we can probably reuse the PhoneGap test suite either because
... license covers it or we can ask if needed
<dom> http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html
jmorris: should we put an action on dom to check on license
<richt> Proposed test suite methodology for e.g. Contacts: http://www.w3.org/TR/test-methodology/
<fjh> ACTION: dom to check licensing issues on phonegap test suite [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action03]
<trackbot> Created ACTION-286 - Check licensing issues on phonegap test suite [on Dominique Hazaël-Massieux - due 2010-10-27].
<dom> (I wonder if Anssi would be interested in presenting/demoing the phonegap tests)
richt: discussing contacts test suite
<fjh> ok, it looks like we need some time at F2F to work through test suite topics
<darobin> +1 to AnssiK demoing the PG tests
<dom> (I could probably make a quick intro to testing @w3c, and the test methodology)
<darobin> +1 to that
fjh: could Anssi demo PhoneGap test suite
<fjh> +1 to dom introducing testing at w3 and ansii sharing understanding of PhoneGap test suite
AnssiK: I am not a PhoneGap guy, but I will look at it
<dom> ACTION: Anssi to introduce phonegap tests during F2F [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action04]
<trackbot> Created ACTION-287 - Introduce phonegap tests during F2F [on Anssi Kostiainen - due 2010-10-27].
<dom> ACTION: Dom to introduce testing@w3c during F2F [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action05]
<trackbot> Created ACTION-288 - Introduce testing@w3c during F2F [on Dominique Hazaël-Massieux - due 2010-10-27].
<richt> agree with fjh, Dom to introduce testing at W3C and demo of PG tests.
<richt> ...at the F2F
darobin: should we do a wiki page for the agenda?
<darobin> ACTION: Robin to create Wiki page for f2f agenda [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action06]
<trackbot> Created ACTION-289 - Create Wiki page for f2f agenda [on Robin Berjon - due 2010-10-27].
<Zakim> dom, you wanted to comment on agenda
dom: at f2f, we should spend time on roadmap
<fjh> dom suggests review of RoadMap
dom: we should have a written roadmap by end of year
<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
fjh: our home page is our roadmap, do we need another document?
<fjh> TPAC registration fee increases on 22 October
<fjh> DST difference to consider if dialing in to TPAC - http://lists.w3.org/Archives/Member/member-device-apis/2010Oct/0002.html
<dom> (we have 32 registered participants for the F2F, not too bad)
<darobin> TPAC 10 agenda scratchpad
fjh: registration for TPAC closes soon
<fjh> File API updates
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0027.html
fjh: if you are dialing in you must be careful about timezones, daylight savings, etc.
... update of file permissions spec
<fjh> Approve 6 October minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/att-0014/minutes-2010-10-06.html
<fjh> proposed RESOLUTION: Minutes from 6 October 2010 approved
RESOLUTION: Minutes from 6 October 2010 approved
<nwidell> I'm here
<fjh> parameterization, http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0034.html
fjh: niklas sent a message re granuality
<dom> (the permissions may need to be parametrized per recipient/sender)
niklas: problem is not what you mentioned
... problem is that widget will be notified for every message on system
... need to be clear on what kinds of messages the widget can see
dom: one way would be to paramaterize the permissions, or have the API be minimized so you can only use it for a well defined set or recipients
<fjh> issue is limiting permission on api to only allow messages to/from given address etc. also separate different types of messaging
dom: messaging API should give access only to well defined set of recipients
<dom> ACTION-132?
<trackbot> ACTION-132 -- Max Froumentin to look at messaging subscribe with filtering and events -- due 2010-03-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/132
<dom> see also http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0180/minutes-2010-03-18.html#item01
nwidell: want to have permission up front
... when get it otherwise?
fjh: how would I assign permissions
... I might want to receive from someone I did not anticipate
dom: it is about the application, not the user
... I agree that we need to decide on defining up front or not
... we need use cases for messaging where we can define a proper security model
<darobin> +1 to knowing what it is we want to do with messaging in the first place
<Zakim> fjh, you wanted to ask about use case
<AnssiK> Mozilla released their Open Web Apps platform I think yesterday, they'reeyeing at "Permissions for Device API Access" spec and might have good feedback based on impl experiences: https://apps.mozillalabs.com/web_or_native.html
AnssiK: openwebapps platform is attacking similar problems
... they are stating that they are looking into permissions for device API
... who would be a good mozilla contact
... we should get feedback from people implementing stuff
<dom> (I hadn't seen the ref to the permissions draft in https://apps.mozillalabs.com/web_or_native.html - cool!)
AnssiK: hanson from mozilla seems to be working on plug ins
... those guys seem to be following what we are doing
... I do not know the mozilla people personally
<tlr> Mike Hanson
<fjh> ACTION: contact mozilla for thoughts on messaging and permission spec [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action07]
<trackbot> Sorry, couldn't find user - contact
<fjh> ACTION: fjh contact mozilla for thoughts on messaging and permission spec [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action08]
<trackbot> Created ACTION-290 - Contact mozilla for thoughts on messaging and permission spec [on Frederick Hirsch - due 2010-10-27].
<dom> (not sure we need to contacts Mozilla on messaging; permissions sounds enough)
<darobin> (agreed)
dom: asking re who is working on messaging spec
<dom> ACTION: Maria to work on security model for messaging [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action09]
<trackbot> Created ACTION-291 - Work on security model for messaging [on Maria Angeles Oteo - due 2010-10-27].
<AnssiK> (the Moz Open Web Apps experiment at GitHub: http://github.com/mozilla/openwebapps)
<fjh> 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: Alissa added issues to ruleset document
darobin: do we discuss publishing at f2f
dom: we want to have idea of how to address issues raised at f2f
... some of the issues are fundamental
... before issuing document we need to understand that some issues are not addressable
... we need to
get an idea of what issues we would not be able to address
dom: starting a FPWD suggests we know what we are doing
...
...
fjh: all, please look at issues listed in Rulesets document
... before the f2f
<fjh> ACTION: fjh to review ruleset issues [recorded in http://www.w3.org/2010/10/20-dap-minutes.html#action10]
<trackbot> Created ACTION-292 - Review ruleset issues [on Frederick Hirsch - due 2010-10-27].
fjh: clickjacking
<fjh> Clickjacking threat and countermeasures
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0017.html
darobin: it is not clear that clickjacking is something we need to solve at API level
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0018.html
darobin: or something that needs to be solved more generally
<darobin> CSP
darobin: this might provide a path toward solution
... but I'm not a security expert
<richt> +1 agree with Robin but not too sure on the CSP connection :/
dom: CSP may help solve some of problem but cannot
<fjh> dom: CSP is server side, so not enough for client-side API
dom: use is as a security argument in API
darobin: soluitons will come from broader options
<darobin> +1 to not doing anything new
AnssiK: we should not do anything that has not been done before
... let's not open can of worms
... so let's use, for example, fileinput, rather than obscure way for user input
... if we use general mechanisms that have been tested, we are safer
darobin: agree not to invent new input methods
richt: looked only briefly at it
... idea is to go straight to trusted events
... talks about synthesized events and how they can be mitigated
... but I still need to put some language into the contact spec
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0021.html
AnssiK: robin's e-mail raises issue - Anssi could not find it in spec
darobin: look at link
... if they make this possible, it may suggest that the security issue has been solved
<richt> that's is an important point Robin. Thanks for the link.
richt: this is helpful input
... this reenforces our approach to this
darobin: this helps decide the issue
richt: a synthesized event is possible
... I will put some of this into document by TPAC
darobin: now to phonegap implemention
... good that they have implemented, but not sure we need to discuss more now
richt: good we have phonegap reenforcing what we are doing
... good that UI is nonnormative
AnssiK: android is having hard time including all elements ?
richt: we should clarify spec re whether all fields included
darobin: phonegap is implemeting read and write?
richt: yes, both
darobin: read only is one way to avoid quirks
<darobin> quirks in Contacts
darobin: worth looking at quirks in Android implementation
... many of them are "not supported" and "will return null"
<darobin> "In order to save the Contact object on the device call the save method on the Contact object."
<darobin> save support
<darobin> ACTION-251?
<trackbot> ACTION-251 -- John Morris to review privacy text related to ISSUE-78 for capture -- due 2010-10-20 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/251
<darobin> ACTION-216?
<trackbot> ACTION-216 -- WonSuk Lee to reformulate gallery API to look like contacts API -- due 2010-07-21 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/216
jmorris: re Capture - I will turn to action 251
<dom> (I think starting with readonly for gallery makes plenty of sense)
Anssi: we can look to reuse contacts approach
... we can make major changes to gallery
... let's proceed with contacts design model
darobin: do we need to wait another week?
<darobin> PROPOSED RESOLUTION: move forward with read-only gallery
AnssiK: could we just copy the contacts scheme, with media parts
... we can move faster if we split into smaller parts
<dom> +1
<darobin> RESOLUTION: move forward with read-only gallery
RESOLUTION: move forward with read-only gallery
No discussion as Suresh is not on the call.
darobin: reviewing Sysinfo
... almost done, finding small nits
... anything else for call?