W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Draft minutes, 2009-12-16

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 16 Dec 2009 11:29:35 -0500
Message-Id: <E94EED3B-EF41-4AC0-BDAC-01E453A92453@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are draft HTML minutes from 2009-12-16 call - for review

regards, Frederick

Frederick Hirsch
Nokia



# Device APIs and Policy Working Group Teleconference

## 16 Dec 2009

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Robin_Berjon, Frederick_Hirsch, Dzung_Tran, Ilkka_Oksanen,
Suresh_Chitturi, Anssi_Kostiainen, Dominique_Hazael_Massieux, Max_Froumentin,
Claes_Nilsson, John_Morris, Richard_Tibbett

Regrets

    Paddy_Byers, Marcin_Hanclik, Marengo_Marco, Laura_Arribas

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    maxf

## Contents

  * [Topics][5]

    1. [Administration][6]

    2. [Minutes approval][7]

    3. [policy][8]

    4. [new TAG issue][9]

    5. [APIs][10]

  * [Summary of Action Items][11]

* * *

<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][12]

### Administration

<dom> [Mobile Security Barcamp in Sophia, January 19][12]

### Minutes approval

fjh: approval?

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/att-0169/minutes-2009-12-09.html][13]

no objection

**RESOLUTION: minutes from 9 dec approved**

### policy

<fhirsch> action-63?

<trackbot> ACTION-63 -- Laura Arribas to review
[http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html][14]
-- due 2009-11-25 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/63][15]

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][16]

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

### new 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][17]

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0188.html][18]

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> [Should the Geolocation API methods provide an optional parameter of
type URI that allows the location requesting service to advertise a policy
(P3P or XACML or some other) that applies to the request?][19]

<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][19]

…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][20]]

<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][21]]

<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.

### APIs

darobin: let's go over the progress made

<dom> [Contacts API update][22]

richt: about Contacts, I produced an update in CVS

… base on mailing list feedback

<dom> [Contacts API editors draft][23]

… 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][24]

… expecting feedback, and i'll update proposal before the end of the week.

<dom> [Thread on FileWriter][25]

<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][26]

… 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][27] 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][28]

… 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][29]

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][30]

… next topic is the hook for device objects.

… we have 2 proposals

<darobin>
[http://www.w3.org/mid/355A518BC0575547B2A3D6773AAF8EEF73A1A0@ftrdmel1][31]

… 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][32]

<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)][33]

<AnssiK> [http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0191.html][34]

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][35] .

darobin: anything else?

… then call adjourned

… next call: next year

<Suresh> happy holiday all

<richt> thanks

## Summary of Action Items

**[NEW]** **ACTION:** Dom to propose input to TAG response [recorded in
[http://www.w3.org/2009/12/16-dap-minutes.html#action01][20]]

**[NEW]** **ACTION:** John to provide a discussion of requirements for privacy
[recorded in [http://www.w3.org/2009/12/16-dap-minutes.html#action02][21]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][36] version 1.135 ([CVS
log][37])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://www.w3.org/mid/9C36793C-06B7-4B84-80F9-5E2A212FD4E3@nokia.com

   [4]: http://www.w3.org/2009/12/16-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #ActionSummary

   [12]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0205.html

   [13]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/att-0169/minutes-2009-12-09.html

   [14]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Nov/0044.html

   [15]: http://www.w3.org/2009/dap/track/actions/63

   [16]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0213.html

   [17]: http://www.w3.org/2009/dap/track/actions/73

   [18]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0188.html

   [19]: http://www.w3.org/2008/geolocation/track/issues/10

   [20]: http://www.w3.org/2009/12/16-dap-minutes.html#action01

   [21]: http://www.w3.org/2009/12/16-dap-minutes.html#action02

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0193.html

   [23]: http://dev.w3.org/2009/dap/contacts/

   [24]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0171.html

   [25]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0113.html

   [26]: http://www.w3.org/2009/dap/track/actions/74

   [27]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0217.html

   [28]: http://www.w3.org/2009/dap/track/actions/65

   [29]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0144.html

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0212.html

   [31]: http://www.w3.org/mid/355A518BC0575547B2A3D6773AAF8EEF73A1A0@ftrdmel1

   [32]: http://www.w3.org/2009/dap/track/issues/44

   [33]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0122.html)

   [34]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Dec/0191.html

   [35]: http://www.w3.org/2009/dap/track/issues/55/edit

   [36]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [37]: http://dev.w3.org/cvsweb/2002/scribe/





Received on Wednesday, 16 December 2009 16:30:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT