See also: IRC log
<trackbot> Date: 16 December 2009
<scribe> Scribe: maxf
<scribe> ScribeNick: maxf
<fhirsch> Next meeting is 6 January 2010
<fhirsch> Mobile Security barcamp - 19th January 2010, Sophia Antipolis
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0205.html
<dom> Mobile Security Barcamp in Sophia, January 19
fjh: approval?
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/att-0169/minutes-2009-12-09.html
no objection
RESOLUTION: minutes from 9 dec approved
<fhirsch> action-63?
<trackbot> ACTION-63 -- Laura Arribas to review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html -- due 2009-11-25 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/63
fjh: action 63 is deferred until Laura is back
<fhirsch> File granularity access policy, Secure Cred Manager
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0213.html
fjh: Claes you sent a proposal?
claes: typical uses case is storing keys for social web applications
<fhirsch> I may have some comments on Secure Cred Manager later, but believe this is for future work
… there's a problem today about where to store those keys
… so I propose a JS api to store those keys on the device.
… There was a discussion on the mailing list, about the fact that it's about restricting access to applications for an API
… the conclusion was that taking the proposal from Steve is a good starts and that I should build from that
… restraining certain parts of the API to certain applications.
<Zakim> fhirsch, you wanted to ask what an application is
… the main use case is allowing an application to access this application's data through that API
… What I'm proposing adds the possibility to add the application ID, which you can pass to the actual device API you're calling
… which restricts what you get out of that API
fjh: how would this work on the web as opposed to widgets? Seems that there's a management issue there, and that it could be a topic for future work
… I'm not sure I understand it makes sense to pass application ID to API call, because there might be other ways of doing it. I'm not getting what an application is on the web.
… my inclination is to sibject it should be future work, cause it requires more thought
… we might want to figure out the extensibility model.
Claes: I think that my credential manager is more realistically put into future work
… but a possibility to have a granularity of applications should be in this version of the specification.
… I'll reply to your questions on how to secure identified aplications, on the mailing list.
… we can just consider the possibility of having the granularity of application IDs in this version.
fhirsch: I'd like to make a decision today about the future work, if that's ok.
… about the application ID, I'd like to understand how it work in the various use cases.
Claes: I can reply to that and elaborate a little more on the mailing list.
Suresh: I'd like to echo fhirsch's comment on the secure credential manager
… I don't know if it's a deviceAPI-specific problem or a secure storage problem.
… so I would recommend talking to the web/offline storage guys
… Can you clarify what the proposal in terms of granularity?
… seems that it's used when evaluating the policy framework, is that right?
… it might be relevant to the WARP spec, something we discussed in the widgets group.
Claes: I will consider this. I thought it would be part of the policy framework...
… and I also think it shouldn't be restricted to widgets, like the WARP specification
… I'll think about it and come back.
<Zakim> darobin, you wanted to talk about WARP
darobin: the reason WARP is currently so simple is that when webapps were working on it, we deliberately kept it simple until there would be more policy work.
… this may mean it should included in DAP and this WG could take over WARP
Suresh: I'm not clear on this particular proposal on application ID. Is it going to be used to evaluate a policy, or along the lines of WARP
fhirsch: my question too.
Claes: we have a framework for defining access to API according to the model defined by Steve, based on trust domains of the application
… I'm extending that concept to applications within a domain
… The application is sort of a finer granularity
<Suresh> sounds like the apporach BONDI has taken?
fjh: we're verging into the management aspects
… without understanding those issues I don't know what it means. So let's take it to the list, and relate the issue to the browser web model, that possibly doesn't have a policy.
… just need to see more use cases.
… hard to tell what's going on right now.
Claes: I will elaborate on the mailing list.
<Zakim> fhirsch, you wanted to ask for resolution re security credential manager for future work
RESOLUTION: security credential manager proposal is a possible item for future work.
<Zakim> fjh, you wanted to discuss TAG issue
<dom> ACTION-73?
<trackbot> ACTION-73 -- Frederick Hirsch to draft a response TAG issue on privacy and policy -- due 2009-12-16 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/73
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0188.html
fjh: I haven't responded to the message yet
… as some may know there was a discussion between geolocaiton and geopriv, about data retention, etc.
… the geolocation spec include statements to that effect, but no mechanism defined.
… disagreement ensued, which escalated to the TAG
… I'm not sure, but they probably are asking us to include retention policy text in our documents.
… How are we going to work with the tag?
jmorris: I am one of the participants of the geolocation WG. And the cause of some of the controversy
[…]
… I am scrampbling to get up to speed on the DAP work so I don't yet have suggestion on what to say back to the TAG.
… the history of the geolocation battle is that the IETF developed a geolcation provacy protocol, 8 years ago, where the privacy rules are bound together with the location.
… we have urged the W3C to adopt that aproach, but the WG rejected that approach
… One of the pushback is that the policy sending should be not just done with geolocation but generally. therefore it's not to be addressed by the geolocation WG
<fhirsch> question - how can user privacy information be included in DAP apis without requiring additional user queries?
… in other words: "go talk to DAP"
<Zakim> dom, you wanted to discuss whether "let's not do it about Geo-only" was really the feedback from geolocation and to ask the TAG their opinion on the objections from Geolocation WG
… So we claim that privacy is something that should be sent along with data.
dom: john, you said that the geolocation WG refused to do it. Some people said that, but others said that the reason would be that it would create confusion with implementers
… that it would also entail complex UIs.
jmorris: yes. Primarily the browser makers are opposed to it, for a host of different reasons. They have no interest in having to manage privacy group.
… but some people participating in the discussion did like the idea, but said it shouldn't just be geolocation but something larger like DAP
dom: that has 2 consequences: how does that affect work in DAP. DAP might want to consider sending policy with data
… I don't think it makes much sense to have the exact same debate
<dom> dom: we should also ask if the TAG has responses to the discussions/objections that the Geolocation WG already had on that topic
fhirsch: if we do something in DAP, how's that going to apply to geolocation
jmorris: the WG doing geolocation are not envisaging anything more than what's there now.
<tlr> DAP is the group that has the topic within its charter.
<dom> “The gist of the arguments against the proposal is the following: if the proposal was adopted, the browsers would end up showing the user an interface that appears to be a user-agent enforced privacy preference panel. However, since the privacy information is provided by the website, there is no way for the user-agent to ensure that the claims made by the website are actually true. This could result in the users being mislead by a user-agent prompt. This would brea
<dom> k the separation between the user-agent UI (which users trust) and the site content (which users don't necessarily trust) and would therefore undermine the user's trust in the user-agent, with extremely severe consequences for Web security.” http://www.w3.org/2008/geolocation/track/issues/10
…if you look at this more broadly is that the main objection in geolocation is "we've never done it this way, it would confuse users. It's better to read the privacy policy"
… the IETF was trying to change that model, with geopriv
… if DAP were to change the model, if would perhaps put pressure to go back to geolocation and fix it
fhirsch: I see a situation where both parties could be right
… privacy is an important concern, but it can also be complicated and confusing
jmorris: I completely agree. My view is not a simple thing, and I appreciate the evidence of browser makes, but would argue that the IETF approach has strong privacy-protecting defaults.
… so in most cases it would be simple, but others not so.
<jmorris> agreed on thinking more broadly than geopriv
fhirsch: we should perhaps not lock ourselves into geopriv for now, but look elsewhere, too
… We're focusing our work on access controls, which is separate. So we don't have requirements for policies.
… so we need something to work with. Any volunteers to write something up about models and requirements, choices, options?
… it could lead to a constructive discussion
… meanwhile I will send a response to the TAG saying thanks, it's hard, could you please help us and explain how you reached your decision
<Zakim> dom, you wanted to note Geolocation WG resolution on that topic
<fhirsch> I think geolocation focused on using geopriv specifically
fhirsch: maybe dom you could respond. I'll talk to you offline
<dom> ACTION: Dom to propose input to TAG response [recorded in http://www.w3.org/2009/12/16-dap-minutes.html#action01]
<trackbot> Created ACTION-76 - Propose input to TAG response [on Dominique Hazaël-Massieux - due 2009-12-23].
<dom> Dom: would be useful to ask feedback from the TAG on the Geolocation WG issue resolution
jmorris: to dom, the argument in geolocation was that the browser cannot guarantee that the rules are enforced
… but law can guarantee that.
… So this WG cannot create a mechanism to enforce rules
… but law can penalise anyway
dom: I think that they idea of providing rules as part of a data is good, but the browser vendor didn't claim it was a problem with complying with the law, but it was something with the browser UI
… which would fool the user into claiming to enforce something they can't
<fhirsch> we should correct misperception of TAG that we are necessarily going to address this issue
<fhirsch> it will depend on the proposals made by WG participants
<Zakim> fhirsch, you wanted to talk about charter
jmorris: I disagree that the user would assume that the browser would ensure their privacy rules
fhirsch: our charter talks about security policy and access controls. Maybe I'm wrong I'm not seeing privacy mentioned.
… I'm not hearing any volunteers to help with it, either.
… so me might not do it, and I want the TAG to understand the actual reasons why we aren't able to do it.
<jmorris> fwiw, many would argue that privacy is a subset of security
… I think privacy is important but we need help to address it, and I'd like the TAG to understand that.
Thomas: I'm extremely suprised that it says security policy and not privacy policy
dom: probably an omission from the charter editors
<darobin> "During Workshop discussions, this specification was frequently cited as a prototypical example for the kinds of security and privacy considerations that are expected in future device APIs."
<tlr> +1 to "we need editors", btw
<tlr> darobin, right, that's the one place where we mention it.
dom: is there any chance that john or someone from CDT to take the lead on that?
jmorris: I'm happy to be deeply involved in that effort
… My efforts will be more productive if there are people not from the same policy background as me.
… I would make the same plea as frederic that we need people to help.
… I'll ne working with Alissa Cooper and we could do it alone, but...
dom: I'm interested, and not an expert. I can't take the lead on this but I'm more than happy to give feedback, establish a roadmap, avoid going into a technical solution first.
… we need to find the obstacles first and the geo WG would be something to dive into.
fhirsch: dom, it would be helpful to mention in the message to the TAG. John must have some ideas of the requirements, the depth of the importance of some of them, the tradeoff, etc.
… would be good to be made aware of the legal/policy aspects so that we don't do needless tachnical work
<dom> ACTION: John to provide a discussion of requirements for privacy [recorded in http://www.w3.org/2009/12/16-dap-minutes.html#action02]
<trackbot> Created ACTION-77 - Provide a discussion of requirements for privacy [on John Morris - due 2009-12-23].
jmorris: realistically, the 2nd week in Jan is the earliest.
fhirsch: do we have an extensibility mechanism to allow passing policies?
darobin: there is, in Javascript, but we haven't added anything at this point
… there certainly are technical solutions, and we need to figure out what we need before deciding which.
darobin: let's go over the progress made
<dom> Contacts API update
richt: about Contacts, I produced an update in CVS
… base on mailing list feedback
<dom> Contacts API editors draft
… planning to continue updates this week, and call for review on Friday
… simplified things a great deal
… based on input by potential implementers like phonegap
darobin: how close are we to FPWD?
richt: I think we're reado to go to FPWD. There's still a lot of feedback required, but we have something solid to put forward.
Suresh: I'm very happy with the current version, it's reasonably specified and it'll be useful.
richt: the filtering is perhaps the least stable part of the specification
… there's a current proposal, but it's hard to see where it needs ot go in the short term
<dom> richt, I suggest marking the fact that Search is very unstable as an editors note
darobin: what do you think about putting out a call for consensus for publication at the beginning of january?
<Zakim> dom, you wanted to say we probably ought to make a Call for Consensus on FPWD publication (for publication probably early Jan)
Suresh: ok for me to have FPWD, even including editor's notes.
dom: I support making a call for consensus
… I suggest adding more editor notes, like about the hook where the API hangs off of
richt: I'll put an update on Friday
darobin: that would be listing the issues?
richt: yes
darobin: so I could be pushing a CfC in early january. Takes a week normally, but could take longer because of the holiday
dom: earliest would be January 6
<dom> +1
<Suresh> +1
<AnssiK> +1
richt: FPWD is also to get patent exclusions, right?
darobin: yes, and it's automatic
<darobin> RESOLUTION: Richard will include changes in Contacts by Friday, Robin to follow up Monday with a CfC for FPWD
darobin: no progress with Calendar...
Suresh: I worked with Richard on that, and we have requirements to submit the the WG
… should be modeled closely after the contacts API
darobin: agreed
… if you could send something soon, it'd be great.
<Suresh> Will send out an initial list of Calender use cases and requirements later today..
darobin: next is filesystem/filewriter
<dom> File Systems and Directories proposal
… expecting feedback, and i'll update proposal before the end of the week.
<dom> Thread on FileWriter
<dom> ACTION-74?
<trackbot> ACTION-74 -- Robin Berjon to send an email to list summarising the options for <input> or not in Capture -- due 2009-12-16 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/74
… next is capture: we need to discuss a bunch of items still.
<dom> -> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0217.html Hixie's <device> proposal
… in particular the new <device> thing, which we should talk about on the list, still
<Dzung_Tran> About Ian's proposal on <device>, what should we do with Capture API?
… people are invited to check the proposal to see if it breaks anything. Do we need a new element, etc.
<dom> ACTION-65?
<trackbot> ACTION-65 -- Niklas Widell to provide an editors draft of the Messaging API -- due 2009-12-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/65
… messaging: daniel and niklas aren't here, so no input there
<dom> (they said end of December for an editors draft)
<dom> SysInfo API updates
max: I'll be sending a call for review by the end of the week
darobin: ok, and we can then talk about publish in January
<dom> Hanging the APIs off navigator.device
… next topic is the hook for device objects.
… we have 2 proposals
<darobin> http://www.w3.org/mid/355A518BC0575547B2A3D6773AAF8EEF73A1A0@ftrdmel1
… and it would be useful if people would participate in the thread and express there views.
<dom> ISSUE-44?
<trackbot> ISSUE-44 -- What do APIs hang off of? -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/44
<Suresh> I like to keep the "*.device.* concept
… not 2 proposals, 3 proposals
… to me Doug's proposal makes sense, but people should express opinions, ideally before next week.
Suresh: my current opinion is that hanging off device makes our work a bit more visible. And keeps us in control of our work.
<AnssiK> one advantage is that the device enables to enumerate its properties
… and let us extend it, and avoid namespace conflicts.
<Dzung_Tran> I thought we had this discussion before. We also had a poll and it seems that the concessus was "navigator.device.*"
darobin: AOB?
<AnssiK> one thing on APIs
<richt> Dzung_Tran, the question is on the consistency of that '*' which is currently ambiguous.
<dom> (note on risks of clash from hixie: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0122.html)
<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0191.html
Anssi: some dojo contributor is along the line of using objects as parameters, as opposed to arguments list.
<dom> (Wolfram is indeed a DoJo contributor)
… maybe we shoudl reply to send goodwill to the JS developer community
darobin: it's more than goodwill, but also a coding style. More than 3 parameters, for instance. Or whether it's callbacks, etc.
… I'm not sure how to move it forwards. Would editors be interested in discussing it?
<dom> +1 on raising an issue
<darobin> ISSUE: Should we use object literals in place of positional parameters and if so when?
<trackbot> Created ISSUE-55 - Should we use object literals in place of positional parameters and if so when? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/55/edit .
darobin: anything else?
… then call adjourned
… next call: next year
<Suresh> happy holiday all
<richt> thanks