Device APIs and Policy Working Group Teleconference

07 Apr 2010


See also: IRC log


Robin_Berjon, Frederick_Hirsch, Marco_Marengo, Alissa_Cooper, Kangchan_Lee(IRC, only), Dzung_Tran, David_Rogers, Claes_Nilsson, LauraA, Paddy_Byers, John_Morris, Aurelien_Guillou, Richard_Tibbett, Ingmar_Kliche, Suresh_Chitturi, Wonsuk_Lee, DanielColoma, Maria_Oteo
Dominique_Hazaƫl-Massieux, Ilkka_Oksanen, Thomas_Roessler
Robin_Berjon, Frederick_Hirsch


<trackbot> Date: 07 April 2010

<marengo> Zaki, aaaa is me

I'll scribe

<darobin> thanks paddy!

<scribe> scribenick: paddy


<fjh> Updated Capture API draft published, 1 April 2010

<fjh> http://www.w3.org/News/2010#entry-8759

<fjh> FPWD of File API: Writer published, 6 April 2010

<fjh> http://www.w3.org/News/2010#entry-8762


fjh: minutes are out: any changes wanted?

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0242/minutes-2010-03-31.html

RESOLUTION: minutes of 31 March approved


<fjh> ACTION-153

<fjh> ACTION-153?

<trackbot> ACTION-153 -- Alissa Cooper to refine privacy requirements (with John) -- due 2010-04-07 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/153

fjh: Had actions to review requirements - Alissa, do you have anything to say?

alissa: I tried to pare down to just talking about the requirements on APIs

<fjh> comments from Frederick at http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0011.html

alissa: we decided to separate from policy stuff and best practices for app developers

<fjh> updated editors draft with this revision, see http://dev.w3.org/2009/dap/privacy-reqs/

alissa: decided just to adjust text without changing too much

<fjh> Previous versions are visible in the CVS history

alissa: did some other editorial changes: tried to fill in big table with other elements of privacy

<fjh> http://dev.w3.org/cvsweb/2009/dap/privacy-reqs/Overview.html

alissa: I just don't think that the complete picture of what gets addressed where is obvious

jmorris: I thinkit would be helpful to have a couple of diagrams on architecture as discussed in Prague

fjh: alissa,, were you proposing additional text to address that?
... just to make sure new readers understand what we are trying to do

<darobin> -> some unfinished noodling http://dev.w3.org/2009/dap/docs/privacy-license.html

fjh: we do need to have a bit more to set out scope, context

jmorris: do we do it in this document? My personal vote is yes

fjh: yes, don't want to proliferate documents unnecessarily

darobin: I have an action to look at separate solutions, have drafted some text in a separate document

<fjh> Robin suggests using material from background section

darobin: are you looking for something like what's in the background section of that document?

<fjh> http://dev.w3.org/2009/dap/docs/privacy-license.html#background

alissa: yes, I think if something like this doc exists, then the API requirements doc can refer to it

jmorris: I don't think we need explanation in every doc; but should be somewhere publically visible when we first publish
... alissa and I can look at it, but it's a good start

<fjh> I suggest we copy background section from Robin's draft into requirements document

darobin: doc was just a brain dump, so steal the text and put in the requirements doc

fjh: alissa, jmorris: do you wish to take on editorial control?

<darobin> +1 to either or both alissa and jmorris to have editorial access

jmorris: I think it should be alissa

<fjh> ACTION: fjh to add background section into requirements with some edits [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action01]

<trackbot> Created ACTION-157 - Add background section into requirements with some edits [on Frederick Hirsch - due 2010-04-14].

darobin: review the text before copying it :)
... dom will set up access for editing

fjh: took out abuse cases; some of this might be in the requirements doc
... do you want to review how it relates to your part?

alissa: I can review but also welcome suggestions from the list

fjh: is there more to be said about this?
... next step is to decide what we do in the various API docs
... do we subsume these requirements into the individual API docs?
... should it be up to the document owners?

alissa: do we want the privacy issues to be explicit requirements on the APIs?

<fjh> I believe api docs should each list the privacy items and how they are addressed

alissa: I think there should be, but others may disagree

<darobin> +1

fjh: agree it should be explicit as requirements
... then we can determine the degree to which each API satisfies those requirements
... also we need a caveat about privacy requirements changing

bryan: I agree should indicate the scope of the requirements in the API docs
... but there should be a central place where the concepts, requirements are discussed in general terms

<fjh> each api should indicate how it supports or does not support, items in API table

<Zakim> richt, you wanted to talk about latest addition to Contacts API: http://dev.w3.org/2009/dap/contacts/Overview.html#design-considerations

richt: I added a section to contacts API to try out this idea
... to discuss issues relating to privacy and also other design considerations relating to the API
... added section "privacy by design"

<fjh> http://dev.w3.org/2009/dap/contacts/Overview.html#privacy-by-design

richt: but done in parallel to what has been happening in the privacy requirements document
... .. it would be great to get feedback, this is just embryonic at this stage

<fjh> maybe we should focus on contacts first, then revise other docs with similar agreed model

richt: quite useful to have as design considerations explicitly tailored to the requirements/issues of each API
... every API has different issues

<fjh> ok, so start is to get the facts for each API, then worry about formatting

<darobin> +1

fjh: get the facts down in each doc first, then worry about formatting
... if each API doc owner can create a privacy section, this will be a good starting point
... thanks to richt for this input
... next step for privacy will be to go through each API
... add background section
... review the big table
... decide what needs to be added in
... alissa, jmorris, did you have concerns about the text? were you going to do something about that?
... what is the size of the concern, and when will we have an update?

jmorris: concerns were mostly minor
... there were multiple contributors, and existing text is raising questions/issues rather than being presented logically

alissa: jmorris should forward proposed changes to list

fjh: trying to figure out what needs to happen before we can make a public draft

jmorris: can send input to list in next few days

fjh: licensing stuff as well?

<fjh> ACTION: jmorris to send proposed changes to list re privacy requirements [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action02]

<trackbot> Created ACTION-158 - Send proposed changes to list re privacy requirements [on John Morris - due 2010-04-14].

alissa: need more time for that part

fjh: achievable this month?

alissa: probably, but need another week

fjh: more comments on that requirements doc?

Policy Framework

fjh: Laura, you did some edits on the policy framework - do you want to talk to what you did?

<fjh> ACTION-152?

<trackbot> ACTION-152 -- Laura Arribas to edit policy framework, reviewing BONDI material and editorial update -- due 2010-04-07 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/152

laura: yes

lauraA: I continued what drogers started, based on input from BONDI

<scribe> .. finished passing BONDI appendices document

<fjh> http://dev.w3.org/2009/dap/policy/

LauraA: focussing now on architecture based on BONDi A&S
... then will look at how to merge the Nokia submission
... the current draft now has a formal model
... but not yet ready for review, so people should wait until it is ready
... will email the list when ready for review

<fjh> ISSUE-79?

<trackbot> ISSUE-79 -- Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/79

fjh: can we make progress on other policy issues?
... do we have a solution to this issue? I'm not sure what we want to do
... is anyone thinking about this?
... I'm going to suggest that we focus on the functionality of sysinfo
... maxf - are you the editor?

<fjh> perhaps this is a minimization issue

jmorris: I think it is right to address via minimisation

fjh: then we do have a way to address it, so we have to talk about minimisation

<fjh> ACTION: maxf note minimization in sysinfo to address ISSUE-79 [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action03]

<trackbot> Created ACTION-159 - Note minimization in sysinfo to address ISSUE-79 [on Max Froumentin - due 2010-04-14].

<maxf> I'll try again

<maxf> and hang up

darobin: one thing that worries me is that the document is mature and nearly ready for LC

<maxf> to answer the question, I am the editor and I've not thought about policy much

darobin: so we need to address this issue before LC
... so we don't carry the issue into LC
... perhaps the resolution is simple, but it still needs to be written up

fjh: we need to say how it is addressed, eg the API design permits incomplete responses

darobin: currently in the API, it is an implementation decision as to what information is returned

<fjh> need note to warn implementations about need for minimization

fjh: so we have an implementation guideline

<darobin> [I think that adding concerns of fingerprinting and minimisation to http://dev.w3.org/2009/dap/system-info/#privacy-considerations-for-implementors might be enough]

fjh: need a paragraph in the doc saying the minimisation is important, and implementations may make minimised responses
... not necessarily controlled via policy
... darobin says address it before LC

maxf: ok

<fjh> ISSUE-38?

<trackbot> ISSUE-38 -- Use cases and threat model for security requirements -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/38

fjh: other issue is about use cases and threat model
... drogers did something, is there more we need to do?

drogers: had to take a week off so unable to progress as intended

<fjh> david notes that we need linkages from threats to requirements

drogers: but have agreed to put a placeholder in the policy document so policy requirements are traceable back to threats

fjh: will you do a proposal for that?

drogers: yes, I will be able to progress soon
... already captured in existing action

<fjh> issue-37?

<trackbot> ISSUE-37 -- Domain spoofing and trust in the network layer -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/37

fjh: another issue - out of scope?
... network layer, different layers of protocol stack
... and threats arising from network-layer attacks
... is this in scope?

drogers: yes, eg 3G vs Wifi

<fjh> david notes he will capture in threats, then we can discuss

drogers: need to capture in threats, and important consideration
... but decision will be later as to whether or not in scope

<fjh> ISSUE-17?

<trackbot> ISSUE-17 -- Summarize security issues and related requirements for file API -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/issues/17

fjh: issue 17 - should deal with file API - probably need to work on this
... but can't remember the status
... any comment?


darobin: hasn't been a whole lot of progress in last week
... one issue: rename "capture" to "media capture"

RESOLUTION: change "capture" to "media capture"

<fjh> but no change to shortname

darobin: we published capture and file writer
... hopefully getting some feedback
... richt, anything new on contacts you want to bring up?

richt: only really did the privacy section
... not many other changes
... similarly calendar is progressing, but slowly

darobin: will update the docs based on what we agreed today?

richt: sure

darobin: maxf indicated that changes agreed at f2f in messaging are addressed
... is that true?

maxf: yes, did first part of changes but not much time in last couple of weeks
... committed some changes this morning
... so should now be synchronised with what was agreed at f2f

darobin: doc seems to be broken, some styling isn't working

<richt> FYI, messaging URL: http://dev.w3.org/2009/dap/messaging/

darobin: also we agreed removing section 7 as it relates more to application launcher

maxf: I should have checked, that wasn't implemented in draft

darobin: would this then be ready for publication next week?

maxf: yes

darobin: as soon as checks are completed, send an email and we will issue CfC
... lets look at sysinfo

maxf: did changes discussed at f2f
... there are 2 or 3 things still to do, but should be really quick to complete it
... then will publish a new draft for the group
... since at the f2f we didn't create a definitive list of issues

darobin: if can focus on getting to LC it would be great
... looking at other drafts - anything else we haven't covered?
... if there's nothing else in terms of progress on APIs, suggest move to AOB


fjh: edits to ReSpec - will this break our docs?

darobin: this should not break anything, but report any problems you see
... there are at least 4 or 5 other groups using ReSpec but these have added nice new features
... anything else?

<darobin> ACTION-120?

<trackbot> ACTION-120 -- Robin Berjon to check with Geolocation WG re choice of object literals vs positional parameters in geo API -- due 2010-03-24 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/120

richt: wanted to focus on action 120
... related to style of these APIs - does this have significant impact on publication?

darobin: will do it now
... hope we don't get bogged down in long discussion on API styles
... nothing more to discuss

Summary of Action Items

[NEW] ACTION: fjh to add background section into requirements with some edits [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action01]
[NEW] ACTION: jmorris to send proposed changes to list re privacy requirements [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action02]
[NEW] ACTION: maxf note minimization in sysinfo to address ISSUE-79 [recorded in http://www.w3.org/2010/04/07-dap-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $