Device APIs and Policy Working Group Teleconference -- 14 Jul 2010

<trackbot> Date: 14 July 2010

<fjh> ScribeNick: bryan_sullivan

<scribe> scribenick: bryan_sullivan

agenda review

Gallery and calendar will be tomorrow switched with privacy and powerbox

Friday morning we will add the initial draft of Application Launcher API

topc: minutes approval 7-July

RESOLUTION: 7-July minutes approved

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/att-0053/minutes-2010-07-07.html

review of W3C Privacy Workshop outcome

<DKA> W3C Privacy Workshop agenda (with links to papers and slides): http://www.w3.org/2010/api-privacy-ws/agenda.html

fjh: 2-day review - main topics were transparency and control, secondary use, privacy rulesets, icons, next steps e.g. best practices, definitions
... rulesets seem to be good to people, but discussion was ongoing

dka: summed up well

tlr: two big pieces - policies/preferences, and soft best practices work

dka: addtl point - attaching privacy info to an API was questioned - with the issue labeled "granularity" - data from different APIs may relate an an aggregate privacy concern of the user
... thus this may need followup work in DAP

<fjh> privacy workshop - papers and slides etc http://www.w3.org/2010/api-privacy-ws/

tlr: the resulting tecnhnical question might be how the composite privacy control is represented
... a 2nd outcome was to avoid being over-comprehensive (also "granularity") but represent privacy controls as a few simple things the user can assess including what types/number of icons if used

alissa: following on Dan's point - the premission model has had discussion here - when do you prompt etc
... the question of how to bound a permission re the user interface and effect on rulesets

dom: also the need of packaging an API call to get the needed authorization and enable rules on the permissions - the user needs to be able to relate to the privacy questions as presented in UI

<fjh> dom seems to ask if access control and privacy rulesets should be combined with features

anssik: were there any UI concepts presentedm and was the focus on the user vs developer

dom: there were a few UI things with focus on communicating the privacy policy to the user, vs user communicating their preferences

<fjh> see work from Marcos and Aza

<dom> Marcos' paper

<fjh> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf

tlr: marcos reviewed the geoloc APIs, position paper from google (ian) covering geoloc API, and aza's paper on privacy icons were related

<dom> Practical Privacy Concerns in a Real World Browser (Chrome's implementation nremkars)

<dom> Privacy: A Pictographic Approach, Aza Raskin

jmorris: there seemed to be conflcting signals on whether we should give guidance on UI in the privacy documents

<fjh> Privacy of Geolocation Implementations, Marcos, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf

dom: understanding is that implementers don't like normative UI statements but normative language drives the UI experience - if not up front it may be too late

jmorris: there seem to be great uncertainty about whether rules should be transmitted with info
... ian etc would seem to argue against that

fjh: we should talk about that tomorrow with ian in the room
... in the context of firefox implementation there is some expectation of work in this area

tlr: normative guidance we were able to get to said show this in that context with a few words - but if you make hard normative UI statements you don't change the market's desire to dfferentiate
... also new UI methods e.g. touch screens move past the scope of the normative statements

<darobin> Web Security Context: User Interface Guidelines

<fjh> john noted one question for the group is whether to give UI guidance or not, another is decision of this WG needed on whether to convey privacy information with API requests

tlr: thus non-normative statements that are clear about intent are useful

alissa: at least one example - the requirement to display the origin of a document

tlr: the position paper brought up a good point for this work: with frameset, everything is same window/origin and fine
... with iframe, once you give permission to an ad network in an iframe it can give future permission without a direct UI relationship
... a suggestion was to key permission off the pairing of window and frames that were involved in the original permission

<darobin> Ian and Jochen's paper about geolocation security UI

fjh: we discussed a lot about what users want and what they can understand, e.g. re rulesets

tlr: the argument was that users are bad an articulating their preferences - their behavior can give us hints as to what they want but that might differ from what they say when asked directly

flh: a couple of issues were opened, e.g. contacts - is there a privacy issue with sharing someone else's contact

<dom> ISSUE-86?

<trackbot> ISSUE-86 -- Privacy issue about sharing other users contact information from own address book -- raised

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

jmorris: re 2nd use of private data, e.g. a friends info. it's a primary use to send a card to the contact on their birthday, but if the birthday is put into a database and used later for ads that's a 2nd use and should be non-permissable

fjh: ruleset should enable that
... how do rulesets interact with pre-existing relationships

<dom> ISSUE-89?

<trackbot> ISSUE-89 -- Clarify how rulesets interact with pre-existing relationships -- raised

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

alissa: for sites with preexisting rules on how you can interact with data e.g. facebook, how would the API and facebooks application interact

fjh: we talked about negotiation e.g. P3P, there did not seem to be a resolution

bryan_sullivan: I mentioned conceptual similasrity of negotiation to oauth or other protocols

<fjh> alissa also noted that issue with pre-existing relationships might also depend on frequency of ruleset sending (eg. with each API request or less frequently)

alissa: app has to figure out which rule takes precedence in the facebook example

<fjh> another lesson was that sites might not have incentive

alissa: if people start sending their preferences to the sites, there may be a need for negotiation, but whether websites have a desire to negotiate is questioned

<dom> ISSUE-90?

<trackbot> ISSUE-90 -- Create privacy best practices document for web site developer -- raised

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

fjh: we talked about having a best practices doc for website developers

claes: are there any examples of rulesets yet?

alissa: there was talk about getting a reference implementation together but nothing concrete

fjh: thats a summary - more organized one to come
... the primary decision is rulesets and delivering info to sites, how UI integration will work, and what granularity is best
... we need to agree before we invest work in this

jmorris: the question of whether rules are sent with data is a basic question - we should not decide without ian etc - but is there a value in discussing that today as a preview

dom: an important step would be to document the arguments - need further investigation and that may help having these on paper

<richt> Isn't there a much quicker win to be made here: communicating existing terms and conditions and privacy policy (adding a URL to a 'Device API' request that the user must accept)?

dom: what was mentioned as difficult with rulesets - there was a granularity question as to whether this is API by API

<richt> ...education and information over data exchange interoperability

dom: also how likely will the service provider deal with a variety of user preferences
... also the UI should not make promises it can't keep
... re ui promises, if the user picks some contacts and can select some ruleset in the action, through the browser chrome, but later on finds that the preferences were not adhered to, the user will blame the browser\

darobin: that's a valid concern as it undermines other things the browser tells the user

alissa: an error in handling the user preference may not really be blamed on the browser after all

drogers: this is similar to issues in the mobile industry, where users blame the service provider instead of the browser

<fjh> Issues listed by dom - 1. granularity, 2. variability of user policies for developer and difficulty of managing this (enforcing, keeping intent with data), 3. UI promises (concern regarding misinterprentation in case of problem)

dom: re UI, nothing is easy, it complicates the UI more than it already is, and markup is already complex
... a path to simplifying is to consider reducing the number of policies the user has to assess
... also given ramificatons of data reuse over time/features, the user doesn't understand the side-effects of reducing 2nd use permission
... this can have confusing effects upon subsequent features

<bryan_sullivan_> scribenick: bryan_sullivan_

jmorris: there should be ways to present this without over-complicating the UI

anssi: we can make recommendations on the default settings

<darobin> ack \

tlr: user decisions work well when the user knows what they are deciding about and when they make the decision in context (at the time) - earlier decisions may have different effect
... when making a decision in real-time there are task-specific decisions that need to be related to a default
... ancillary - who is in the best position to interact with the user re e.g. secondary use

<tlr> browser or site?

dom: the impact of user decision on what they are trying to achieve will not be clear - e.g. if everyone backs out of search data mining, all search will suffer

fjh: it sounds like 2 things: multiple parties that can interact with the user - yet it seems we need one common data preferences info - so it seems the data needs to come from the user with the device rather than the task - i.e. based upon the nature of the data rather than the task

tlr: question brought up about that is depending upon where a decision is generated, we may not need an interoperable method
... its related to what you need agree upon and what not

fjh: seems to be getting abstract - the idea of rulesets is to provide a few straightforward concepts in rules - missing something about why it is so hard

alissa: as simple as they may be, say 3 total, that is still more than you get in chrome - getting any one of three as a developer is more than you are used to

fjh: with different rulesets and in mashups this can be complicated for developers

<Zakim> fjh, you wanted to ask about distributed privacy decision yet unified user communication

drogers: the developer needs an indication of whether necessary information is alllowed - in BONDI e.g. we give a specific response that the developer can rely upon
... we may have innovation in UI re policy and we should not stifle that
... we have abstracted the policy decisions away from the UI and that's good, that enables us to put the user or policy provider in control

<drogersuk> so to expand - previously (with things like firewalls) the application just stops

<drogersuk> in the case of the APIs we've designed, the web developer gets a response to the effect that 'the policy does not permit this'

<drogersuk> this allows the developer to do much more

<drogersuk> e.g. in the case of a store locator, you could provide the user with 'positive action' option, to override

<drogersuk> rather than a 'prompt'

<drogersuk> 3rd party providers can be delegated by users to help them, this takes a lot of decision away from the user and reduces decisions to what matters

<drogersuk> e.g. I know I normally don't give out my location, but I want to for x

<drogersuk> we will also see innovation in implementations of user interfaces to help the user in the decision heirarchy

<fjh> bryan asks about unintended side effects of user privacy decisions

<fjh> q

<fjh> ?

<drogersuk> logically, the user must be in control - the policy decision mechanism absolutely has to be abstracted away from the web application itself

<richt> For the record, I think we are missing an opportunity to integrate existing plain-text privacy policies and T&Cs in a simple way by jumping in to rulesets. I'd expect something similar to Opera's Geolocation 'T&C review' implementation explained here to work better at a user level: http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf

<fjh> issue: be clear to distinguish site (service) privacy policy versus included location provider policy etc

<trackbot> Created ISSUE-91 - Be clear to distinguish site (service) privacy policy versus included location provider policy etc ; please complete additional details at http://www.w3.org/2009/dap/track/issues/91/edit .

<fjh> dan noted that Marcos presentation included showing URI link for policy in UI

<bryan_sullivan> scribenick: bryan_sullivan

dka: another issue from the workshop out of marcos' paper - in the geoloc api you can't click a link to see the policy of the website only the user agent

<darobin> dom: it could be <link rel='privacy' href='...'/>

<fjh> http://www.w3.org/2010/api-privacy-ws/slides/caceres.pdf

richt: allowing websites to provide a privacy URL to interact with the user is good for education and interoperability (avoids browser dependency)

<fjh> moving from ":take it or leave it" from service provider to more user centric approach

dom: we should enable the user to make a decision and the service provider to adapt to it - its not clear privacy rulesets will enable that

richt: its a big step to put the user at the center of the process - there is a big body of work privacy policies and T&C as they stand

jmorris: to respond, a goal of the ruleset least-permissive approach still allows contextual use of information
... you can decide should a site get info at all, in many cases rulesets would allow services to do what it needs, but not what it may want for e.g. 2nd use
... thus immediate response will not be broken, while the service can work out how to enable broader purposes

dom: adapting to a new paradigm e.g. rulesets will be difficult for service providers

jmorris: the proposal is not suggesting that low-layer standard stuff such as ip address etc are restricted

<Zakim> darobin, you wanted to talk about PEL, and composability

darobin: another issue - composability - what happens when you merge a mashup with different data and policies
... if a single composite item e.g. a jpeg is created, how are the various rules represented

<fjh> e.g. upload pictures and geolocation for each, create single jpeg, what if different rulesets used?

darobin: another is p3p appel, an exchange format

tlr: there is useful work but a fundamental flaw in the spec, and it has not made it out of working draft

<bblfish> hi, anything interesting for me to come over?

<scribe> ACTION: alissa to summarize and add issues to ruleset doc [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action01]

<trackbot> Created ACTION-210 - Summarize and add issues to ruleset doc [on Alissa Cooper - due 2010-07-21].

fjh: 2 questions - what do we do with this "privacy is hard" question and what do we do tomorrow

alissa: do we have the same idea of the ruleset model and how to keep it simple - if we take today to think about three - what does it mean for the issues on the table

jmorris: three levels may be: one-shot interaction, personalized service, targeted ads
... we're not proposing giving the user 12 decisions that feed into the rulesets

dom: 2 choices is better than 12

<fjh> potential to address UI issue

jomorris: ui promises issue is the same for 2 or 12'

<fjh> dom highlights user decision complexity and variability of user policies for developer as two critical issues

dom: the hard issues are variability of user policies for developer, and decision complexity for the user

jmorris: boiling down the options to fewer choices will help the user, while privacy advocates need the details to understand what went into the decision

fjh: that would simplify the user decision

<dom> dom: the point John has made about distinguishing one-shot requests vs other cases is probably important

jmorris: re decision complexity, we may not be able to get the user to understand that

<fjh> jmorris notes simplification of privacy choices grounded in rulesets is one shot, personalization profile

dom: the key question is whether this group in the position to make a decision on that

jmorris: govt entities will make that decision

<fjh> bryan disagrees that enabling privacy would "break the web", and notes that service providers have responsibilities and need to notify

<fjh> +1 bryan

<richt> How about we started by integrating web-based privacy policies html/txt to Device APIs as an immediate step for communicating privacy by providing a URL along with Device API request(s). Whether the data at the URL provided could then be structured policy data, and whether privacy could subsequently be negotiated between the service and the user via this structured data exchange, could then be built in to the same URL-based approach.

bryan_sullivan: we should not worry about the larger impacts, just clarify impact to users at a service level

alissa: the concern over "breaking the web" assumes the market is a monolith - if we disable cookies websites will not function - that's different from passing a ruleset that affects the features of a site but does not have to break it totally

<fjh> allisa notes that site could ignore rulesets, some won't, thus letting market determines

dom: if no implementer is interested in this work, we have a problem

fjh: there will be various benefits and the support of implementers is unknown at this point

jmorris: we should work hard to address these things, but not expect a UI to be able to represent the bigger questions

alissa: we could describe the effect of rules as "if you get this ruleset, here's what you could do"

<fjh> tlr agrees to list simple and few rulesets, enumerate what you can do with them

tlr: re very simple rulesets and what services can do: if we dont find user agents or sites leveraging them, it will not help - we need a way for websites to describe what they intend to do with the data

<fjh> tlr notes aza site-self identification might be relevant, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-22.txt

<fjh> having only three rulesets could converge with fewer self-identification icons per aza's work

fjh: what about the developer issue, would database backends simplify it (e.g. apply rules in the query process)

dom: does not think a useful discussion on variability will result tomorrow

jmorris: of the three choices being suggested, people will be concerned over the profiling rule, and most of a service providers' services would be affected - thus the service provider would be concerned with supporting that

alissa: disagrees - service providers offer personalized and non-personalized service - there is a difference between profiling and personalization

<dom> the terms are defined (somewhat) in http://dev.w3.org/2009/dap/privacy-rulesets/#privacy-rulesets

<fjh> alissa notes if one shot is default then most web sites would be fine without any additional work, in spirit of the web

bryan_sullivan: can we get these terms defined

fjh: we have proposals on simplifying the rulesets, how to address the icons

niklas: will we be creating an interoperability issues in the format of the rulesets?

jmorris: from the developers's view they may only need to deal with three things

SysInfo API

<dom> Systems Info API Editors draft

<dom> navigator.connection in Android browser

darobin: we have a well-discussed draft pretty stable, except for Security and Privacy Considerations which is empty.

tlr: the specs have distinct privacy concerns so we should not just cut & paste

darobin: that is good

bryan_sullivan: can we create a simple set of categories this week?

jmorris: we had discussed three buckets - network, device, sensors

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0343/minutes-2010-06-30.html#item05

jmorris: sensors have a lower sensitivity maybe

<richt> John's follow up email to the mailing list: http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0322.html

darobin: that would help but we need to address the permission model for the different groups - this needs to be reflected as well

<fjh> john suggests reordering document sections to correspond to the buckets

alissa: we need permissions model discussion

darobin: we did want to avoid prompting all the time - coarse grained permissions

<fjh> john asks about use case - app to tell friend the temperature near me, use contacts to get friend email, sysinfo to get temperature

<fjh> john asks about multiple prompts here

darobin: the interrelationships between API permissions may not be solved by grouping

dom: two things. we need a plan for multiple permissions, and how do we present the permissions by default outside the framework
... short term, check if the three buckets match the state of the art

darobin: grouping permissions to get user agreement about the APIs to be used for multi-permission granting

<fjh> robin notes that could have bucket for permissions that includes sysinfo sensors, camera as logical grouping

alissa: how far do we go for consumers of the API - do we mandate prompts or require that user permissions be obtained generically?

dom: we should say if you are going to access bucket a, you MUST get consent, bucket b you SHOULD etc

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0058.html

<fjh> msg from dom

dom: another point is that navigator.connection API overlaps

bryan_sullivan: also the HTML online interface

<fjh> issue: sysinfo, permissions for get vs monitor;

<trackbot> Created ISSUE-92 - Sysinfo, permissions for get vs monitor; ; please complete additional details at http://www.w3.org/2009/dap/track/issues/92/edit .

alissa: also consider whether permission addresses monitoring or one-shot
... in geoloc, there were normative requirements on developers - we don't expect that right?

darobin: no

alissa: there was also recommending UI so people know what they are gicing permission for

darobin: that would be good

alissa: that covers also permissions that will last beyond a session

jmorris: also that you shouldn;t have to give permission in order to revoke it

<fjh> ACTION: alissa to make proposal on list for sysinfo privacy section [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action02]

<trackbot> Created ACTION-211 - Make proposal on list for sysinfo privacy section [on Alissa Cooper - due 2010-07-21].

<fjh> ACTION: bryan to incorporate proposal from ACTION-211 into SysInfo draft [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action03]

<trackbot> Created ACTION-212 - Incorporate proposal from ACTION-211 into SysInfo draft [on Bryan Sullivan - due 2010-07-21].

darobin: since we are nearing it last call it would be good to get two people to agree to review the draft

dong: what's the main reason for buckets

<fjh> review should happen after edit to incorporate buckets, update to privacy section

darobin: to guide the UI development to create a consistent user experience

<scribe> ACTION: to Richard and Dong-Young to review the SysInfo draft after edits are made this week [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action04]

<trackbot> Sorry, couldn't find user - to

<scribe> ACTION: to Richard to review the SysInfo draft after edits are made this week [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action05]

<trackbot> Sorry, couldn't find user - to

<scribe> ACTION: to Richard review the SysInfo draft after edits are made this week [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action06]

<trackbot> Sorry, couldn't find user - to

<Dong-Young> I (Dong-Young Lee, LGE) volunteered.

<fjh> ACTION: richard to review sysinfo draft after edits made [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action07]

<trackbot> Created ACTION-213 - Review sysinfo draft after edits made [on Richard Tibbett - due 2010-07-21].

<fjh> ACTION: Dong-Young to review sysinfo draft after edits made [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action08]

<trackbot> Sorry, couldn't find user - Dong-Young

<Dong-Young> Sorry. I'm not in the WG yet.

<fjh> ACTION:-213: also Dong-Young to review [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action09]

<fjh> ACTION-213: also Dong-Young to review

<trackbot> ACTION-213 Review sysinfo draft after edits made notes added

alissa: there are concerns on how to quantify some of the values obtained from the sysinfo API, e.g. ambient noise, download bandwidth, luminance, etc

<tlr> ACTION: thomas to request IETF community review of sysinfo API Last Call WD through W3C/IETF liaison channel [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action10]

<trackbot> Created ACTION-214 - Request IETF community review of sysinfo API Last Call WD through W3C/IETF liaison channel [on Thomas Roessler - due 2010-07-21].

drogers: we may want to put statements in the spec e.g. implementers shall not abuse this interface to provide other information
... an example is using the temperature sensor as a way to provide data on system overheating e.g. as a fire sensor

dom: its the same as saying a conformant implementation shall be conformant - doesn't add anything

drogers: it's a security issue, not just a functional compliance issue

<fjh> reconvene at 1pm

<jmorris> suresh, we are close to finishing lunch break

<Suresh> thanks, i'll stay on the line

<marengo> ScribeNick: marengo

<darobin> we're back

Gallery API

darobin: several offline discussions. initial BONDI input is too complicated, possible use of IndexDB API.

<Dong-Young> Presence+ Dong-Young_Lee

<fjh> s/Presence+ Dong-Young_Lee//

<dom> Editors draft of IndexedDB API

?: it could be provided like the Contacts API, as provided info is similar. Gallery could create Media objects

<dom> (should we thus consider building the contacts API on top of IndexedDB as well?)

<dom> s/?:/Wonsuk:/

AnssiK: suggests to use the most mature api as a guideline. what is the status of indexedDB

darobin: IndexedDB does not solve UI and privacy issues

<dom> Gallery DE

<dom> s/DE/API Editors Draft/

Suresh: curent gallery api looks like the contacts api already.

dom: about IndexedDB. it would be interesting to explore this way

<dom> s/present +/present+/

<Suresh> Suresh: all the operations in Gallery may not be available through a contact-style API, but there are commonalities

darobin: they're not designed to include user approval. what happens if you insert() on a cursor?

<fjh> dom notes we might want read-only contacts

tlr: is a local JS api a useful layer of abstraction? what if the gallery is on a remote server?
... gallery is a case where I see direct mapping w/ collection of resources from the web

AnssiK: contacts api in mozilla integrate with twitter, gmail. that is an example where a well designed api can support integration with rest apis

darobin: we don't have metaphors for removing stuff (at the UI level)

<Suresh> i think we should keep the UI issues separate

darobin: that could mean that we don't provide some functionalities from the beginning, to speed up implementation

<Suresh> my concern is the API will become very limited in what developers can do

darobin: doesn't mean we're not working on such things in the background

bryan_sullivan: we're missing 1) UI representation for deleting 2) UI representation of overwriting. is there any UI functionality to do that (also wrt persistentStorage)?

darobin: localStorage is created by interacting with a specific website, other sites cannot delete it
... you don't want to have contacts deleted by "something else"

dom: creating UIs for such actions is still at the experimental stage

darobin: deleting & updating can be postponed to future documents

bryan_sullivan: do we just avoid adressing the "remove data" problem?

darobin: draws picture about differences btw deleting on localStorage and deleting on distributed galleries.

bryan_sullivan: this means users cannot have their own private editable set of contacts on their device before syncing with external dbs

dom: that's why dom was suggesting IndexedDB for local storage on the device

bryan_sullivan: we shouldn't stop if we have a reasonable use case

dom: if you want to use the same apis, you can wrap your db with a Contacts API compliant interface

darobin: we're not abandoning such use cases, we're just defining the stages
... as we don't have access control at the moment and things should be safe

<hwoo> Dong-Young: if addressbook is important data, why not just use the same mechanism for read and write operations?

Suresh: without being able to delete & update, the api is very limited

darobin: we're not killing features, just staging their release

Suresh:

darobin: we can get half now, half later or the whole.... later
... and most of the use cases are read-only

dom: what about splitting the doc in read and write? they could be even be ready at the same time, but that would be easier to manage
... we have to 1) find the right technical solution and 2) deliver it in a reasonable time

Suresh: we as implementors don't see it as an issue

wmaslowski: calendar apis will have a lot of use cases with write requirements. contacts are similar, similar solutions could be applied

<darobin> Suresh, please try not to interrupt people

<Suresh> sorry about that - i can't see:-)

<Suresh> +q

dom: we have very specific technical issues (eg. from Mozilla) for writing. they need to be adressed

<richt> there is no such things as a 'read-only' scope. Both read and write are in scope but will be separated for different publication timelines. We have a complete read stuff. We need to do more work on the write and delete stuff. Hence publishing both parts on different timelines

<dom> ACTION: Dom to write up issues with write/delete access for Contacts APIs [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action11]

<trackbot> Created ACTION-215 - Write up issues with write/delete access for Contacts APIs [on Dominique Hazaël-Massieux - due 2010-07-21].

<dom> ISSUE: do we want to stage the release of contacts API between read and write access?

<trackbot> Created ISSUE-93 - Do we want to stage the release of contacts API between read and write access? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/93/edit .

bryan_sullivan: the delete operation is something we cannot represent at the moment with a good metaphor. and we need to have the user engaged. are we deferring such operations for all APIs until we solve this issue?

darobin: for some apis it could be easier (calendar?)

<Suresh> isn't buttons and checkboxes to delete not considered a UI paradigm?

nwidell: do we have any idea on the timing needed to solve such issues?
... who's working on this, implementors?

<bryan_sullivan> My understanding of the rationale for delaying write operations to Contacts V2 is that "there is no UI paradigm for representing a delete operation" to ensure user permission for the operation. "User permission" is essential because DAP has not agreed yet on a policy model, and thus there is no other security mechanism in place.

darobin: it depends on the commitment of people
... staging releases is an editorial decision

Dong-Young: concurrent writing. is this a problem that we have to solve?

<dom> ACTION: Wonsuk to reformulate gallery API to look like contacts API [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action12]

<trackbot> Created ACTION-216 - Reformulate gallery API to look like contacts API [on WonSuk Lee - due 2010-07-21].

<dom> http://mozillalabs.com/blog/2010/03/contacts-in-the-browser/

darobin: contacts are moved to tomorrow in the afternoon

<fjh> plan to discuss contacts and app launcher tomorrow in slot #10 where privacy was in afternoon

<Suresh> will contacts be discussed tomorrow after lunch, along with calendar?

<dom> yes

Security

<Suresh> thanks Dom

<Suresh> agreed, solidifying features is a good start

<fjh> goal - create feature specification that defines feature, both in terms of widget feature element and for web case

<fjh> also list every feature for every DAP API

dom: nobody (except bondi) has defined what a feature should be

<Suresh> what about device capabilities?

<Suresh> is that considered to be part of the policy spec?

<dom> this is an open (and clearly) related question; I think it would be simpler to answer it once we have the features list

fjh: it would be useful to have a separate doc to list all the features - who's willing to be the editor?

<dom> (Paddy and FJH have volunteered to edit an "API Features" document)

<dom> ACTION: Frederick to create an API features document, with Paddy [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action13]

<trackbot> Created ACTION-217 - Create an API features document, with Paddy [on Frederick Hirsch - due 2010-07-21].

fjh: scoping issue: two different type of use cases
... enterprise/operators - web/browsers
... how does bondi apply to non-widget environments?

drogersuk: WAC's intention is to cover (mobile) browsers as well. the underlying platform is controlled. the intent is the same as bondi: the user is in control and can choose a 3rd party to provide the policies
... the user can add additional prefs to policies
... the specification is not mobile specific, the use cases are
... and there will be implementors
... there will be browser implementors, but cannot disclose names and roadmap

nwidell:

<fjh> ACTION: paddy to provide proposal for feature architecture text regarding web and widgets cases for feature document [recorded in http://www.w3.org/2010/07/14-dap-minutes.html#action14]

<trackbot> Created ACTION-218 - Provide proposal for feature architecture text regarding web and widgets cases for feature document [on Paddy Byers - due 2010-07-21].

<Zakim> fjh, you wanted to ask about open source

drogersuk: WAC is committed to be as open as possible. No more details at the moment, as the organization is still at an early stage

dom: who's implementing the policy framework?
... that has to be public at some point

drogersuk: in 2-3 weeks we'll be in the position of disclosing more. but there will be browser implementors coming to this table.

paddybyers: people don't contribute if they're not sure it will be adopted

fjh: we need to revisit dom's questions

<fjh> possible use case - use policy for child protection, third party (e.g parent or guardian) setting it

Claes: what's the impact of configurable policies on developers?

<darobin> TIME CHECK 2 MIN

<fjh> david WAC work is not limited to widgets but also applicable to web browser cases in mobile context

<dom> s/david WAC/david: WAC/

drogersuk: developers will probably ask for "everything", that could not be good for the user

<dom> (I don't know how the policy framework enables graceful degradation; that's something that I hope can be looked in the "api features" sepc)

fjh: running out of time. we're starting again tomorrow at 8.30

<tlr> http://www.benihana.co.uk/piccadilly_benihana.html?p=piccadilly

- DRAFT -

Device APIs and Policy Working Group Teleconference

14 Jul 2010

Attendees

Contents

agenda review

review of W3C Privacy Workshop outcome

SysInfo API

Gallery API

Security

Summary of Action Items

Scribe.perl diagnostic output