# Device APIs and Policy Working Group Teleconference

## 07 Apr 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    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

Regrets

    Dominique_Hazaël-Massieux, Ilkka_Oksanen, Thomas_Roessler

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    paddy

## Contents

  * [Topics][5]

    1. [Administrative][6]

    2. [Minutes][7]

    3. [Policy][8]

    4. [Policy Framework][9]

    5. [APIs][10]

    6. [AOB][11]

  * [Summary of Action Items][12]

* * *

<trackbot> Date: 07 April 2010

<marengo> Zaki, aaaa is me

I'll scribe

<darobin> thanks paddy!

<scribe> scribenick: paddy

### Administrative

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

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

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

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

### Minutes

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

**RESOLUTION: minutes of 31 March approved**

### Policy

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

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

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/][18]

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

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

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

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

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

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

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

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

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/][27]

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

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

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

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

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

fjh: issue 17 - should deal with file API - probably need to work on this

... but can't remember the status

... any comment?

### APIs

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/][34]

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

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

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

**[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][25]]

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


[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://lists.w3.org/Archives/Public/public-device-
apis/2010Apr/0007.html

   [4]: http://www.w3.org/2010/04/07-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #ActionSummary

   [13]: http://www.w3.org/News/2010#entry-8759

   [14]: http://www.w3.org/News/2010#entry-8762

   [15]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Mar/att-0242/minutes-2010-03-31.html

   [16]: http://www.w3.org/2009/dap/track/actions/153

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Apr/0011.html

   [18]: http://dev.w3.org/2009/dap/privacy-reqs/

   [19]: http://dev.w3.org/cvsweb/2009/dap/privacy-reqs/Overview.html

   [20]: http://dev.w3.org/2009/dap/docs/privacy-license.html

   [21]: http://dev.w3.org/2009/dap/docs/privacy-license.html#background

   [22]: http://www.w3.org/2010/04/07-dap-minutes.html#action01

   [23]: http://dev.w3.org/2009/dap/contacts/Overview.html#design-
considerations

   [24]: http://dev.w3.org/2009/dap/contacts/Overview.html#privacy-by-design

   [25]: http://www.w3.org/2010/04/07-dap-minutes.html#action02

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

   [27]: http://dev.w3.org/2009/dap/policy/

   [28]: http://www.w3.org/2009/dap/track/issues/79

   [29]: http://www.w3.org/2010/04/07-dap-minutes.html#action03

   [30]: http://dev.w3.org/2009/dap/system-info/#privacy-considerations-for-
implementors

   [31]: http://www.w3.org/2009/dap/track/issues/38

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

   [33]: http://www.w3.org/2009/dap/track/issues/17

   [34]: http://dev.w3.org/2009/dap/messaging/

   [35]: http://www.w3.org/2009/dap/track/actions/120

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

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