See also: IRC log
<trackbot> Date: 19 May 2010
<fjh> scribenick: arve
<fjh> 12 May 2010
RESOLUTION: 12 may 2010 minutes approved
RESOLUTION: Regrouping requirements OK
<fjh> max status summary
maxf: one outstanding issue remaining
<trackbot> ISSUE-64 -- "Generic" sensors may permit discovering sensitive information -- RAISED
<dom> Alissa's comments
maxf will implement changes as suggested
<fjh> ACTION: maxf to implement privacy changes noted by alissa, see http://lists.w3.org/Archives/Public/public-device-apis/2010May/0072.html [recorded in http://www.w3.org/2010/05/19-dap-minutes.html#action01]
<trackbot> Created ACTION-173 - Implement privacy changes noted by alissa, see http://lists.w3.org/Archives/Public/public-device-apis/2010May/0072.html [on Max Froumentin - due 2010-05-26].
<fjh> action-173: target is sysinfo
<trackbot> ACTION-173 Implement privacy changes noted by alissa, see http://lists.w3.org/Archives/Public/public-device-apis/2010May/0072.html notes added
<fjh> suresh asks about 4.7, naming
<jmorris> +1 on a complete table
<fjh> suresh talking about table in annex portion of his comments
maxf: will be responding to suresh's concerns one by one on mailing list
rberjon: primary non-editorial concern is the synchronicity of getters
... some sensors might be slow to respond, hence use of async for get
suresh: are we optimizing for corner cases with use of callbacks?
... sysinfo is information you have readily available
<fjh> suresh proposes should use monitor function instead of get in this kind of case
arve: should we really increase API complexity by adding another method for synchronous getters
<fjh> prefer consistency in using async methods, reducing complexity of number of choices
arve: implementors complexity increases by adding synchronous getters
<darobin> [I tend to agree with arve and max, developers are used to using async nowadays]
<maxf> the same argument could be made for Contacts API
<darobin> [privacy and security]
<maxf> Arve: some properties like SSID are static. Privacy sensitive APIs which will ask the user for consent will need asynchronous
<fjh> we agreed on general async approach to avoid blocking, enable privacy consent etc
darobin: will not want to block on modal dialogs
<maxf> webworkers might help, but they wouldn't prevent authors to make blocking dialogs if they wanted.
<fjh> +1 to consistent model, uniformity and enabling flexibility in changing which need consent or dialogs
RESOLUTION: will keep getters asynchronous
<Zakim> fjh, you wanted to ask about minimization, http://lists.w3.org/Archives/Public/public-device-apis/2010May/0076.html
alissa: in terms of the network property
<fjh> network properties minimization
alissa: provide only information about the active connection?
<darobin> [on mobiles, it is common to have 3G and MMS :)]
arve: how common are multiple active connections? e.g. wired and wireless at once etc
<darobin> [in general, I think it makes sense to only expose active connections]
<maxf> it's a reality that devices have more than one connection, but no one seems to know whether it's worth supporting in the API. That's noted in the specification.
alissa: wants to discuss use cases for multiple active connections
<jmorris> also want to know use cases more broadly, for MAC address, SSID, etc.
alissa: do you need to know the sensitive information from particular active or inactive connections
<Zakim> maxf, you wanted to say more
maxf: no proper discussion on the properties in the network interfaces have taken place
<jmorris> +1 on proper discussion
maxf: this would be a good opportunity to initialize this discussion
<fjh> can we use alissa's email as a starting point?
<jmorris> +1 on doing discussion on list
<scribe> ACTION: alissa will provide an initial analysis of properties [recorded in http://www.w3.org/2010/05/19-dap-minutes.html#action02]
<trackbot> Created ACTION-174 - Will provide an initial analysis of properties [on Alissa Cooper - due 2010-05-26].
fjh: do we remove speculation on when we go to CR?
... (on the DAP home page)
darobin: discussion about FileReader (by WebApps)
... please provide feedback to that WG, as it is of some importance to this group
<fjh> s/scribenick arve//