07:45:20 RRSAgent has joined #dap 07:45:20 logging to http://www.w3.org/2010/07/14-dap-irc 07:45:22 RRSAgent, make logs world 07:45:22 Zakim has joined #dap 07:45:24 Zakim, this will be DAP 07:45:24 ok, trackbot; I see UW_DAP(F2F)3:30AM scheduled to start 15 minutes ago 07:45:25 Meeting: Device APIs and Policy Working Group Teleconference 07:45:25 Date: 14 July 2010 07:45:41 Present+ John_Morris 07:45:54 soonho has joined #dap 07:48:46 Present+ Frederick_Hirsch 07:48:53 Chair: Robin_Berjon, Frederick_Hirsch 07:49:32 ScribeNick: bryan_sullivan 07:50:13 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0042.html 07:56:51 Present+ Soonho_Lee 07:57:00 marengo has joined #dap 07:59:17 Present+ Marco_Marengo 07:59:33 nwidell has joined #dap 07:59:43 Claes has joined #dap 07:59:43 Present+ Niklas_Widell 08:00:01 Present+ Claes_Nilsson 08:00:27 nstratford has joined #dap 08:00:53 AnssiK has joined #dap 08:01:01 bryan_sullivan has joined #dap 08:01:22 wonsuk has joined #dap 08:01:30 present+ bryan_sullivan 08:01:42 scribenick: bryan_sullivan 08:01:58 Present+ Neil_Stratford 08:03:16 darobin has joined #dap 08:03:17 Present+ Anssi_Kostiainen 08:03:34 Present+ Robin_Berjon 08:07:07 tlr has joined #dap 08:07:10 Present+ Dominique_Hazael-Massieux 08:07:57 DKA has joined #dap 08:08:19 Present+ Alissa_Cooper 08:08:29 zakim, who is here? 08:08:29 UW_DAP(F2F)3:30AM has not yet started, DKA 08:08:30 Present+ Wonsuk_Lee 08:08:31 On IRC I see DKA, tlr, darobin, wonsuk, bryan_sullivan, AnssiK, nstratford, Claes, nwidell, marengo, soonho, Zakim, RRSAgent, jmorris, fjh, alissa, paddy, karl, lgombos, shepazu, 08:08:33 ... trackbot, dom, ilkka, ingmar 08:08:53 drogersuk has joined #dap 08:10:55 Present+ Ilkka_Oksanen 08:11:58 Fan_HU has joined #dap 08:12:52 RRSAgent, draft minutes 08:12:52 I have made the request to generate http://www.w3.org/2010/07/14-dap-minutes.html dom 08:13:21 topic: agenda review 08:13:27 Gallery and calendar will be tomorrow switched with privacy and powerbox 08:14:18 Friday morning we will add the initial draft of Application Launcher API 08:14:34 wmaslowski has joined #dap 08:15:38 topc: minutes approval 7-July 08:15:38 Kangchan has joined #dap 08:15:59 RESOLUTION: 7-July minutes approved 08:16:53 richt has joined #dap 08:16:57 http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/att-0053/minutes-2010-07-07.html 08:17:21 topic: review of W3C Privacy Workshop outcome 08:17:55 W3C Privacy Workshop agenda (with links to papers and slides): http://www.w3.org/2010/api-privacy-ws/agenda.html 08:19:09 fjh: 2-day review - main topics were transparency and control, secondary use, privacy rulesets, icons, next steps e.g. best practices, definitions 08:19:48 fjh: rulesets seem to be good to people, but discussion was ongoing 08:19:54 dka: summed up well 08:20:27 danielcoloma has joined #dap 08:20:36 Present+ Daniel_Coloma 08:21:02 tlr: two big pieces - policies/preferences, and soft best practices work 08:21:40 maoteo has joined #dap 08:22:09 Present+ Maria_Oteo 08:22:14 nwidell has joined #dap 08:22:28 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 08:22:59 dka: thus this may need followup work in DAP 08:23:24 privacy workshop - papers and slides etc http://www.w3.org/2010/api-privacy-ws/ 08:23:42 tlr: the resulting tecnhnical question was that how the composite privacy control is represented 08:24:30 LauraA has joined #dap 08:24:36 s/was that/might be/ 08:24:40 present+ LauraA 08:24:46 Present+ ThomasRoessler 08:25:02 tlr: 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 08:25:04 Present+ Wojciech_Mas³owski 08:25:29 Present+ Richard_Tibbett 08:25:46 alissa: following on Dan's point - the premission model has had discussion here - when do you prompt etc 08:26:51 alissa: the question of how to bound a permission re the user interface and effect on rulesets 08:27:57 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 08:28:06 dom seems to ask if access control and privacy rulesets should be combined with features 08:28:26 anssik: were there any UI concepts presentedm and was the focus on the user vs developer 08:28:58 dom: there were a few UI things with focus on communicating the privacy policy to the user, vs user communicating their preferences 08:29:03 see work from Marcos and Aza 08:29:26 -> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf Marcos' paper 08:29:47 http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf 08:29:53 tlr: marcos reviewed the geoloc APIs, position paper from google (ian) covering geoloc API, and aza's paper on privacy icons were related 08:29:54 -> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf Practical Privacy Concerns in a Real World Browser (Chrome's implementation nremkars) 08:30:13 -> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-22.txt Privacy: A Pictographic Approach, Aza Raskin 08:30:29 jmorris: there seemed to be conflcting signals on whether we should give guidance on UI in the privacy documents 08:30:46 Younsung has joined #dap 08:30:58 Privacy of Geolocation Implementations, Marcos, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf 08:31:14 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 08:31:30 q+ 08:31:55 jmorris: there seem to be great uncertainty about whether rules should be transmitted with info 08:32:22 jmorris: ian etc would seem to argue against that 08:32:42 fjh: we should talk about that tomorrow with ian in the room 08:33:29 fjh: in the context of firefox implementation there is some expectation of work in this area 08:34:21 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 08:34:53 tlr: also new UI methods e.g. touch screens move past the scope of the normative statements 08:35:00 -> http://www.w3.org/TR/wsc-ui/ Web Security Context: User Interface Guidelines 08:35:02 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 08:35:13 tlr: thus non-normative statements that are clear about intent are useful 08:35:58 alissa: at least one example - the requirement to display the origin of a document 08:36:07 wonsuk has left #dap 08:36:48 q? 08:36:51 tlr: the position paper brought up a good point for this work: with frameset, everything is same window/origin and fine 08:37:25 tlr: with iframe, once you give permission to an ad network in an iframe it can give future permission without a direct UI relationship 08:37:26 bblfish has joined #dap 08:37:58 tlr: a suggestion was to key permission off the pairing of window and frames that were involved in the original permission 08:38:08 wonsuk has joined #dap 08:38:29 -> http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf Ian and Jochen's paper about geolocation security UI 08:39:21 fjh: we discussed a lot about what users want and what they can understand, e.g. re rulesets 08:40:02 tlr: the argument was that users are bad an articulating their preferences - they can give us hints as to what they want but that might differ from what they say when asked directly 08:40:30 s/they can give us/their behavior can give us/ 08:41:41 flh: a couple of issues were opened, e.g. contacts - is there a privacy issue with sharing someone else's contact 08:42:02 ISSUE-86? 08:42:02 ISSUE-86 -- Privacy issue about sharing other users contact information from own address book -- raised 08:42:02 http://www.w3.org/2009/dap/track/issues/86 08:43:01 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 08:43:50 fjh: ruleset should enable that 08:44:45 fjh: how do rulesets interact with pre-existing relationships 08:45:22 ISSUE-89? 08:45:22 ISSUE-89 -- Clarify how rulesets interact with pre-existing relationships -- raised 08:45:22 http://www.w3.org/2009/dap/track/issues/89 08:45:25 alissa: for sites with preexisting rules on how you can interact with data e.g. facebook, how would the API and facebooks application interact 08:46:05 fjh: we talked about negotiation e.g. P3P, there did not seem to be a resolution 08:47:03 bryan_sullivan: I mentioned conceptual similasrity of negotiation to oauth or other protocols 08:47:14 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) 08:47:36 alissa: app has to figure out which rule takes precedence in the facebook example 08:48:22 another lesson was that sites might not have incentive 08:48:55 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 08:48:58 ISSUE-90? 08:48:58 ISSUE-90 -- Create privacy best practices document for web site developer -- raised 08:48:58 http://www.w3.org/2009/dap/track/issues/90 08:49:10 fjh: we talked about having a best practices doc for website developers 08:49:36 claes: are there any examples of rulesets yet? 08:49:48 q? 08:50:22 alissa: there was talk about getting a reference implementation together but nothing concrete 08:50:44 fjh: thats a summary - more organized one to come 08:51:23 fjh: the primary decision is rulesets and delivering info to sites, how UI integration will work, and what granularity is best 08:52:11 fjh: we need to agree before we invest work in this 08:53:18 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 08:54:28 dom: an important step would be to document the arguments - need further investigation and that may help having these on paper 08:54:40 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)? 08:56:21 dom: what was mentioned as difficult with rulesets - there was a granularity question as to whether this is API by API 08:56:25 ...education and information over data exchange interoperability 08:56:57 dom: also how likely will the service provider deal with a variety of user preferences 08:58:26 dom: also the UI should not make promises it can't keep 09:00:31 dom: 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\ 09:01:11 darobin: that's a valid concern as it undermines other things the browser tells the user 09:03:08 alissa: an error in handling the user preference may not really be blamed on the browser after all 09:04:16 drogers: this is similar to issues in the mobile industry, where users blame the service provider instead of the browser 09:04:30 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) 09:05:21 dom: re UI, nothing is easy, it complicates the UI more than it already is, and markup is already complex 09:05:48 dom: a path to simplifying is to consider reducing the number of policies the user has to assess 09:06:53 dom: also given ramificatons of data reuse over time/features, the user doesn't understand the side-effects of reducing 2nd use permission 09:07:16 dom: this can have confusing effects upon subsequent features 09:08:03 q+ to talk about PEL, and composability 09:10:42 bryan_sullivan_ has joined #dap 09:11:02 scribenick: bryan_sullivan_ 09:12:10 jmorris: there should be ways to present this without over-complicating the UI 09:12:50 anssi: we can make recommendations on the default settings 09:13:00 q? 09:13:06 q+\ 09:13:26 ack \ 09:13:32 q+ bryan_sullivan_ 09:15:03 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 09:15:46 tlr: when making a decision in real-time there are task-specific decisions that need to be related to a default 09:16:07 tlr: ancillary - who is in the best position to interact with the user re e.g. secondary use 09:16:30 browser or site? 09:16:40 q+ to ask about distributed privacy decision yet unified user communication 09:17:24 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 09:17:25 q+ 09:17:27 q- 09:17:30 q+ 09:18:59 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 09:19:44 tlr: question brought up about that is depending upon where a decision is generated, we may not need an interoperable method 09:20:04 tlr: its related to what you need agree upon and what not 09:20:39 Claes has joined #dap 09:20:49 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 09:21:31 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 09:21:58 fjh: with different rulesets and in mashups this can be complicated for developers 09:22:04 q? 09:22:07 ack fjh 09:22:07 fjh, you wanted to ask about distributed privacy decision yet unified user communication 09:22:12 ack drogersuk 09:24:18 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 09:24:53 drogers: we may have innovation in UI re policy and we should not stifle that 09:25:44 drogers: 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 09:26:00 ack bryan_sullivan 09:26:12 so to expand - previously (with things like firewalls) the application just stops 09:26:51 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' 09:26:58 this allows the developer to do much more 09:27:36 e.g. in the case of a store locator, you could provide the user with 'positive action' option, to override 09:27:44 rather than a 'prompt' 09:28:25 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 09:28:39 q+ DKA 09:28:42 e.g. I know I normally don't give out my location, but I want to for x 09:29:21 we will also see innovation in implementations of user interfaces to help the user in the decision heirarchy 09:29:47 bryan asks about unintended side effects of user privacy decisions 09:30:08 q 09:30:11 q? 09:30:12 logically, the user must be in control - the policy decision mechanism absolutely has to be abstracted away from the web application itself 09:30:15 s/q// 09:30:29 paddy has joined #dap 09:32:00 ack dka 09:32:26 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 09:33:54 issue: be clear to distinguish site (service) privacy policy versus included location provider policy etc 09:33:54 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 . 09:34:52 dan noted that Marcos presentation included showing URI link for policy in UI 09:34:56 bryan_sullivan has joined #dap 09:35:09 scribenick: bryan_sullivan 09:35:22 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 09:35:28 dom: it could be 09:35:43 http://www.w3.org/2010/api-privacy-ws/slides/caceres.pdf 09:37:02 richt: allowing websites to provide a privacy URL to interact with the user is good for education and interoperability (avoids browser dependency) 09:37:43 moving from ":take it or leave it" from service provider to more user centric approach 09:38:01 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 09:39:39 q+ 09:39:51 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 09:39:58 ack jmorris 09:40:23 jmorris: to respond, a goal of the ruleset least-permissive approach still allows contextual use of information 09:41:22 jmorris: 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 09:41:58 jmorris: thus immediate response will not be broken, while the service can work out how to enable broader purposes 09:42:27 dom: adapting to a new paradigm e.g. rulesets will be difficult for service providers 09:43:02 jmorris: the proposal is not suggesting that low-layer standard stuff such as ip address etc are restricted 09:43:47 ack darobin 09:43:47 darobin, you wanted to talk about PEL, and composability 09:44:16 darobin: another issue - composability - what happens when you merge a mashup with different data and policies 09:44:57 darobin: if a single composite item e.g. a jpeg is created, how are the various rules represented 09:45:36 e.g. upload pictures and geolocation for each, create single jpeg, what if different rulesets used? 09:45:39 darobin: another is p3p appel, an exchange format 09:46:18 tlr: there is useful work but a fundamental flaw in the spec, and it has not made it out of working draft 09:46:25 q? 09:56:35 hi, anything interesting for me to come over? 10:08:16 action: alissa to summarize and add issues to ruleset doc 10:08:16 Created ACTION-210 - Summarize and add issues to ruleset doc [on Alissa Cooper - due 2010-07-21]. 10:09:21 fjh: 2 questions - what do we do with this "privacy is hard" question and what do we do tomorrow 10:10:19 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 10:11:50 jmorris: three levels may be: one-shot interaction, personalized service, targeted ads 10:12:10 jmorris: we're not proposing giving the user 12 decisions that feed into the rulesets 10:12:22 dom: 2 choices is better than 12 10:12:32 potential to address UI issue 10:12:37 jomorris: ui promises issue is the same for 2 or 12' 10:13:43 dom highlights user decision complexity and variability of user policies for developer as two critical issues 10:14:08 dom: the hard issues are variability of user policies for developer, and .... 10:15:08 s/..../decision complexity for the user/ 10:15:16 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 10:15:45 fjh: that would simplify the user decision 10:15:57 dom: the point John has made about distinguishing one-shot requests vs other cases is probably important 10:16:17 jmorris: re decision complexity, we may not be able to get the user to understand that 10:16:49 jmorris notes simplification of privacy choices grounded in rulesets is one shot, personalization  profile 10:17:06 dom: they key question is whether this group in the position to make a decision on that 10:17:32 jmorris: govt entities will make that decision 10:17:39 s/they key/the key 10:18:46 bryan disagrees that enabling privacy would "break the web", and notes that service providers have responsibilities and need to notify 10:18:52 +1 bryan 10:19:11 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. 10:19:13 bryan_sullivan: we should not worry about the larger impacts, just clarify impact to users at a service level 10:20:42 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 10:21:31 allisa notes that site could ignore rulesets, some won't, thus letting market determines 10:21:39 dom: if no implementer is interested in this work, we have a problem 10:22:05 fjh: there will be various benefits and the support of implementers is unknown at this point 10:23:01 jmorris: we should work hard to address these things, but not expect a UI to be able to represent the bigger questions 10:23:44 alissa: we could describe the effect of rules as "if you get this ruleset, here's what you could do" 10:24:21 tlr agrees to list simple and few rulesets, enumerate what you can do with them 10:25:12 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 10:25:13 tlr notes aza site-self identification might be relevant, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-22.txt 10:26:12 having only three rulesets could converge with fewer self-identification icons per aza's work 10:27:27 fjh: what about the developer issue, would database backends simplify it (e.g. apply rules in the query process) 10:28:52 Present+ Kangchan_Lee 10:29:17 dom: does not think a useful discussion on variability will result tomorrow 10:30:54 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 10:31:42 alissa: disagrees - service providers offer personalized and non-personalized service - there is a difference between profiling and personalization 10:32:21 the terms are defined (somewhat) in http://dev.w3.org/2009/dap/privacy-rulesets/#privacy-rulesets 10:32:22 alissa notes if one shot is default then most web sites would be fine without any additional work, in spirit of the web 10:32:40 bryan_sullivan: can we get these terms defined 10:34:53 fjh: we have proposals on simplifying the rulesets, how to address the icons 10:36:32 darobin has joined #dap 10:36:34 niklas: will we be creating an interoperability issues in the format of the rulesets? 10:37:13 jmorris: from the developers's view they may only need to deal with three things 10:38:40 topic: SysInfo API 10:39:18 -> http://dev.w3.org/2009/dap/system-info/ Systems Info API Editors draft 10:39:56 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0058.html navigator.connection in Android browser 10:40:06 darobin: we have a well-discussed draft pretty stable, except for Security and Privacy Considerations which is empty. 10:40:51 tlr: the specs have distinct privacy concerns so we should not just cut & paste 10:41:02 darobin: that is good 10:42:14 bryan_sullivan: can we create a simple set of categories this week? 10:42:46 jmorris: we had discussed three buckets - network, device, sensors 10:42:59 http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0343/minutes-2010-06-30.html#item05 10:43:30 jmorris: sensors have a lower sensitivity maybe 10:43:37 John's follow up email to the mailing list: http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0322.html 10:44:17 darobin: that would help but we need to address the permission model for the different groups - this needs to be reflected as well 10:45:21 john suggests reordering document sections to correspond to the buckets 10:45:53 alissa: we need permissions model discussion 10:46:22 darobin: we did want to avoid prompting all the time - coarse grained permissions 10:48:57 john asks about use case - app to tell friend the temperature near me, use contacts to get friend email, sysinfo to get temperature 10:49:20 john asks about multiple prompts here 10:50:21 darobin: the interrelationships between API permissions may not be solved by grouping 10:51:11 dom: two things. we need a plan for multiple permissions, and how do we present the permissions by default outside the framework 10:51:32 dom: short term, check if the three buckets match the state of the art 10:53:42 darobin: grouping permissions to get user agreement about the APIs to be used for multi-permission granting 10:54:09 Regrets: Dzung_Tran, Balaji_Nerella_Venkataramana 10:55:15 robin notes that could have bucket for permissions that includes sysinfo sensors, camera as logical grouping 10:56:36 alissa: how far do we go for consumers of the API - do we mandate prompts or require that user permissions be obtained generically? 10:57:27 dom: we should say if you are going to access bucket a, you MUST get consent, bucket b you SHOULD etc 10:57:58 http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0058.html 10:58:02 msg from dom 10:58:33 dom: another point is that navigator.connection API overlaps 10:58:41 bryan_sullivan: also the HTML online interface 10:58:58 issue: sysinfo, permissions for get vs monitor; 10:58:58 Created ISSUE-92 - Sysinfo, permissions for get vs monitor; ; please complete additional details at http://www.w3.org/2009/dap/track/issues/92/edit . 10:59:14 alissa: also consider whether permission addresses monitoring or one-shot 11:02:12 alissa: in geoloc, there were normative requirements on developers - we don't expect that right? 11:02:17 darobin: no 11:02:36 alissa: there was also recommending UI so people know what they are gicing permission for 11:02:46 Dong-Young has joined #dap 11:02:50 darobin: that would be good 11:03:07 alissa: that covers also permissions that will last beyond a session 11:03:21 Present+ Dong-Young_Lee 11:03:29 jmorris: also that you shouldn;t have to give permission in order to revoke it 11:04:15 action: alissa to make proposal on list for sysinfo privacy section 11:04:15 Created ACTION-211 - Make proposal on list for sysinfo privacy section [on Alissa Cooper - due 2010-07-21]. 11:04:32 action: bryan to incorporate proposal from ACTION-211 into SysInfo draft 11:04:32 Created ACTION-212 - Incorporate proposal from ACTION-211 into SysInfo draft [on Bryan Sullivan - due 2010-07-21]. 11:06:04 darobin: since we are nearing it last call it would be good to get two people to agree to review the draft 11:06:42 Zakim, pick scribe 11:06:42 I don't understand 'pick scribe', darobin 11:06:45 Zakim, pick victim 11:06:45 I don't understand 'pick victim', darobin 11:09:00 Ki has joined #dap 11:09:07 dong: what's the main reason for buckets 11:09:22 review should happen after edit to incorporate buckets, update to privacy section 11:09:27 darobin: to guide the UI development to create a consistent user experience 11:10:35 ACTION: to Richard and Dong-Young to review the SysInfo draft after edits are made this week 11:10:35 Sorry, couldn't find user - to 11:10:46 ACTION: to Richard to review the SysInfo draft after edits are made this week 11:10:46 Sorry, couldn't find user - to 11:10:54 ACTION: to Richard review the SysInfo draft after edits are made this week 11:10:54 Sorry, couldn't find user - to 11:11:08 I (Dong-Young Lee, LGE) volunteered. 11:11:10 ACTION: richard to review sysinfo draft after edits made 11:11:10 Created ACTION-213 - Review sysinfo draft after edits made [on Richard Tibbett - due 2010-07-21]. 11:11:32 ACTION: Dong-Young to review sysinfo draft after edits made 11:11:33 Sorry, couldn't find user - Dong-Young 11:12:02 Sorry. I'm not in the WG yet. 11:12:25 paddy has joined #dap 11:12:42 present+ Paddy_Byers 11:12:43 ACTION:-213: also Dong-Young to review 11:13:00 ACTION-213: also Dong-Young to review 11:13:00 ACTION-213 Review sysinfo draft after edits made notes added 11:13:12 rrsagent, generate minutes 11:13:12 I have made the request to generate http://www.w3.org/2010/07/14-dap-minutes.html fjh 11:13:44 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 11:13:55 ACTION: thomas to request IETF community review of sysinfo API Last Call WD through W3C/IETF liaison channel 11:13:55 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]. 11:14:19 Present+ Kangchan_Lee 11:14:33 Seung has joined #dap 11:14:47 Present+ Younsung_Chu 11:15:50 drogers: we may want to put statements in the spec e.g. implementers shall not abuse this interface to provide other information 11:17:32 drogers: an example is using the temperature sensor as a way to provide data on system overheating e.g. as a fire sensor 11:17:33 Kiyoung has joined #dap 11:18:40 dom: its the same as saying a conformant implementation shall be conformant - doesn't add anything 11:19:57 drogers: it's a security issue, not just a functional compliance issue 11:21:10 reconvene at 1pm 11:26:44 paddybyers has joined #dap 11:26:47 jmorris_ has joined #dap 11:30:09 KY has joined #dap 11:44:02 marengo has joined #dap 11:52:04 Suresh has joined #dap 11:52:25 Present+ Suresh_Chitturi 11:54:47 alissa has joined #dap 11:57:20 UW_DAP(F2F)3:30AM has now started 11:57:26 + +1.408.216.aaaa 11:57:35 zakim, aaaa is Suresh 11:57:35 +Suresh; got it 11:57:52 suresh, we are close to finishing lunch break 11:58:14 thanks, i'll stay on the line 12:01:42 Claes has joined #dap 12:02:19 wmaslowski has joined #dap 12:02:37 zakim, code? 12:02:37 the conference code is 3279 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), dom 12:05:04 + +44.207.868.aabb 12:05:12 ScribeNick: marengo 12:05:13 we're back 12:05:16 Zakim, aabb is meeting_room 12:05:16 +meeting_room; got it 12:05:49 zakim, who is here? 12:05:49 On the phone I see Suresh, meeting_room 12:05:50 On IRC I see wmaslowski, Claes, alissa, Suresh, marengo, KY, jmorris, paddybyers, Seung, darobin, wonsuk, Younsung, LauraA, maoteo, danielcoloma, Kangchan, tlr, AnssiK, soonho, 12:05:53 ... Zakim, RRSAgent, fjh, lgombos, shepazu, trackbot, dom, ilkka, ingmar 12:06:50 nstratford has joined #dap 12:07:23 Topic: Gallery API 12:07:42 present+ Ingmar_Kliche 12:07:46 Present+ Suresh_Chitturi 12:08:43 darobin: several offline discussions. initial BONDI input is too complicated, possible use of IndexDB API. 12:08:49 present+ KiYoung_Kim 12:09:22 Dong-Young has joined #dap 12:09:34 Presence+ Dong-Young_Lee 12:10:36 Present+ Dong-Young_Lee 12:10:43 s/Presence+ Dong-Young_Lee// 12:11:14 bryan_sullivan has joined #dap 12:11:31 present+ bryan_sullivan 12:11:46 FanH has joined #dap 12:11:54 -> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html Editors draft of IndexedDB API 12:12:48 ?: it could be provided like the Contacts API, as provided info is similar. Gallery could create Media objects 12:12:55 (should we thus consider building the contacts API on top of IndexedDB as well?) 12:14:08 s/?:/Wonsuk:/ 12:14:40 AnssiK: suggests to use the most mature api as a guideline. what is the status of indexedDB 12:14:58 darobin: IndexedDB does not solve UI and privacy issues 12:15:51 -> http://dev.w3.org/2009/dap/gallery/ Gallery DE 12:16:00 s/DE/API Editors Draft/ 12:16:03 nwidell has joined #dap 12:16:05 RRSAgent, draft minutes 12:16:05 I have made the request to generate http://www.w3.org/2010/07/14-dap-minutes.html dom 12:16:22 Suresh: curent gallery api looks like the contacts api already. 12:17:53 present + Seung-Yeon_Lee 12:19:22 dom: about IndexedDB. it would be interesting to explore this way 12:19:28 s/present +/present+/ 12:20:00 Suresh: all the operations in Gallery may not be available through a contact-style API, but there are commonalities 12:20:29 darobin: they're not designed to include user approval. what happens if you insert() on a cursor? 12:21:27 dom notes we might want read-only contacts 12:22:12 tlr: is a local JS api a useful layer of abstraction? what if the gallery is on a remote server? 12:22:53 ... gallery is a case where I see direct mapping w/ collection of resources from the web 12:25:44 AnssiK: contacts api in mozilla integrate with twitter, gmail. that is an example where a well designed api can support integration with rest apis 12:27:30 darobin: we don't have metaphors for removing stuff (at the UI level) 12:28:44 hwoo has joined #dap 12:28:45 i think we should keep the UI issues separate 12:29:10 ... that could mean that we don't provide some functionalities from the beginning, to speed up implementation 12:29:34 my concern is the API will become very limited in what developers can do 12:29:39 ... doesn't mean we're not working on such things in the background 12:31:02 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)? 12:32:34 darobin: localStorage is created by interacting with a specific website, other sites cannot delete it 12:33:03 ... you don't want to have contacts deleted by "something else" 12:33:45 dom: creating UIs for such actions is still at the experimental stage 12:34:15 darobin: deleting & updating can be postponed to future documents 12:34:50 bryan_sullivan: do we just avoid adressing the "remove data" problem? 12:36:39 darobin: draws picture about differences btw deleting on localStorage and deleting on distributed galleries. 12:38:01 bryan_sullivan: this means users cannot have their own private editable set of contacts on their device before syncing with external dbs 12:38:33 AnssiK has joined #dap 12:39:33 dom: that's why dom was suggesting IndexedDB for local storage on the device 12:40:09 bryan_sullivan: we shouldn't stop if we have a reasonable use case 12:42:44 dom: if you want to use the same apis, you can wrap your db with a Contacts API compliant interface 12:43:48 darobin: we're not abandoning such use cases, we're just defining the stages 12:44:43 ... as we don't have access control at the moment and things should be safe 12:45:26 Dong-Young: if addressbook is important data, why not just use the same mechanism for read and write operations? 12:47:12 Suresh: without being able to delete & update, the api is very limited 12:47:43 darobin: we're not killing features, just staging their release 12:49:40 Suresh: 12:50:40 darobin: we can get half now, half later or the whole.... later 12:50:54 ... and most of the use cases are read-only 12:52:13 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 12:52:41 drogersuk has joined #dap 12:52:48 ... we have to 1) find the right technical solution and 2) deliver it in a reasonable time 12:53:13 Suresh: we as implementors don't see it as an issue 12:54:42 wmaslowski: calendar apis will have a lot of use cases with write requirements. contacts are similar, similar solutions could be applied 12:54:55 Suresh, please try not to interrupt people 12:55:16 sorry about that - i can't see:-) 12:57:09 +q 12:57:53 ack Suresh 12:58:21 richt has joined #dap 12:59:59 dom: we have very specific technical issues (eg. from Mozilla) for writing. they need to be adressed 13:00:05 q+ 13:00:30 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 13:00:57 ACTION: Dom to write up issues with write/delete access for Contacts APIs 13:00:57 Created ACTION-215 - Write up issues with write/delete access for Contacts APIs [on Dominique HazaĆ«l-Massieux - due 2010-07-21]. 13:01:49 ISSUE: do we want to stage the release of contacts API between read and write access? 13:01:49 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 . 13:03:10 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? 13:03:29 darobin: for some apis it could be easier (calendar?) 13:03:50 isn't buttons and checkboxes to delete not considered a UI paradigm? 13:03:53 DKA has joined #dap 13:03:55 q+ 13:04:01 ack bryan_sullivan 13:04:08 ack nwidell 13:04:43 nwidell: do we have any idea on the timing needed to solve such issues? 13:04:59 ... who's working on this, implementors? 13:05:37 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. 13:05:48 darobin: it depends on the commitment of people 13:06:21 ... staging releases is an editorial decision 13:08:46 Dong-Young: concurrent writing. is this a problem that we have to solve? 13:10:00 ACTION: Wonsuk to reformulate gallery API to look like contacts API 13:10:00 Created ACTION-216 - Reformulate gallery API to look like contacts API [on WonSuk Lee - due 2010-07-21]. 13:10:43 http://mozillalabs.com/blog/2010/03/contacts-in-the-browser/ 13:12:18 darobin: contacts are moved to tomorrow in the afternoon 13:12:32 plan to discuss contacts and app launcher tomorrow in slot #10 where privacy was in afternoon 13:12:36 will contacts be discussed tomorrow after lunch, along with calendar? 13:12:40 yes 13:12:41 Topic: Security 13:12:56 thanks Dom 13:14:38 agreed, solidifying features is a good start 13:15:07 goal - create feature specification that defines feature, both in terms of widget feature element and for web case 13:15:16 also list every feature for every DAP API 13:15:32 dom: nobody (except bondi) has defined what a feature should be 13:16:18 what about device capabilities? 13:16:33 is that considered to be part of the policy spec? 13:17:22 this is an open (and clearly) related question; I think it would be simpler to answer it once we have the features list 13:18:56 fjh: it would be useful to have a separate doc to list all the features - who's willing to be the editor? 13:19:26 (Paddy and FJH have volunteered to edit an "API Features" document) 13:19:58 ACTION: Frederick to create an API features document, with Paddy 13:19:58 Created ACTION-217 - Create an API features document, with Paddy [on Frederick Hirsch - due 2010-07-21]. 13:20:26 ... scoping issue: two different type of use cases 13:21:56 ... enterprise/operators - web/browsers 13:29:42 fjh: how does bondi apply to non-widget environments? 13:30:00 Claes has joined #dap 13:31:46 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 13:32:01 ... the user can add additional prefs to policies 13:32:28 ... the specification is not mobile specific, the use cases are 13:32:36 q+ 13:35:05 ... and there will be implementors 13:36:15 q? 13:36:24 q+ to ask about open source 13:36:37 drogersuk: there will be browser implementors, but cannot disclose names and roadmap 13:36:42 nwidell: 13:36:52 ack nwidell 13:37:15 AnssiK has joined #dap 13:38:27 q+ 13:39:40 action: paddy to provide proposal for feature architecture text regarding web and widgets cases for feature document 13:39:41 Created ACTION-218 - Provide proposal for feature architecture text regarding web and widgets cases for feature document [on Paddy Byers - due 2010-07-21]. 13:41:25 ack claes 13:41:27 ack fjh 13:41:27 fjh, you wanted to ask about open source 13:42:37 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 13:47:13 dom: who's implementing the policy framework? 13:47:28 ... that has to be public at some point 13:50:26 drogersuk: in 2-3 weeks we'll be in the position of disclosing more. but there will be browser implementors coming to this table. 13:51:09 paddybyers: people don't contribute if they're not sure it will be adopted 13:56:46 fjh: we need to revisit dom's questions 13:58:15 possible use case - use policy for child protection, third party (e.g parent or guardian) setting it 13:58:23 Claes: what's the impact of configurable policies on developers? 13:58:45 TIME CHECK 2 MIN 13:58:55 david WAC work is not limited to widgets but also applicable to web browser cases in mobile context 13:59:14 s/david WAC/david: WAC/ 13:59:18 drogersuk: developers will probably ask for "everything", that could not be good for the user 14:00:08 (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) 14:00:22 fjh: running out of time. we're starting again tomorrow at 8.30 14:02:36 http://www.benihana.co.uk/piccadilly_benihana.html?p=piccadilly 14:05:22 rrsagent, generate minutes 14:05:22 I have made the request to generate http://www.w3.org/2010/07/14-dap-minutes.html fjh 14:07:05 FanH has left #dap 14:07:20 wonsuk has left #dap 14:07:41 -Suresh 14:07:44 wmaslowski has left #dap 14:10:28 paddy has joined #dap 14:11:27 AnssiK has joined #dap 15:01:22 -meeting_room 15:01:23 UW_DAP(F2F)3:30AM has ended 15:01:25 Attendees were +1.408.216.aaaa, Suresh, +44.207.868.aabb, meeting_room 15:05:47 AnssiK has joined #dap 15:43:25 alissa has joined #dap 15:46:48 alissa has joined #dap 15:59:11 Zakim has left #dap 17:14:06 Marcos has joined #dap 17:30:01 alissa has joined #dap 19:00:56 alissa has joined #dap 19:04:44 alissa has joined #dap 19:04:57 alissa has left #dap 19:29:54 paddy has joined #dap 20:13:25 alissa_ has joined #dap 21:47:00 jmorris has joined #dap 22:01:53 jmorris has joined #dap 22:08:33 paddy has joined #dap 23:20:20 karl has joined #dap