09:11:00 RRSAgent has joined #dap 09:11:00 logging to http://www.w3.org/2010/03/16-dap-irc 09:11:02 RRSAgent, make logs world 09:11:02 Zakim has joined #dap 09:11:04 Zakim, this will be DAP 09:11:04 ok, trackbot; I see UW_DAP(F2F)3:30AM scheduled to start 101 minutes ago 09:11:05 Meeting: Device APIs and Policy Working Group Teleconference 09:11:05 Date: 16 March 2010 09:11:58 s/Teleconference/F2F Day 1/ 09:12:04 alissa has joined #dap 09:12:38 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0079.html 09:12:44 Chair: Robin, Frederick 09:15:15 marengo has joined #dap 09:15:17 richt has joined #dap 09:17:19 danielcoloma has joined #dap 09:17:37 Present+ Daniel_Coloma 09:17:48 Present+ Marco_Marengo 09:20:54 Present+ Richard_Tibbett 09:21:30 Present+ Dominique_Hazael-Massieux 09:21:44 bsulliva has joined #dap 09:21:57 scribenick: bsulliva 09:22:01 drogersuk has joined #dap 09:22:50 LauraA has joined #dap 09:22:58 Claes has joined #dap 09:24:52 aguillou has joined #dap 09:25:40 Present+Aurelien_Guillou 09:26:07 present+ David_Rogers 09:26:10 Present+ Alissa_Cooper 09:26:16 Present+ Ilkka_Oksanen 09:27:33 AnssiK has joined #dap 09:29:08 maxf has joined #dap 09:32:23 Kangchan has joined #dap 09:32:40 bsulliva has joined #dap 09:33:17 JohnsonW has joined #dap 09:33:25 ScribeNick: bsulliva 09:33:29 Scribe: Bryan 09:33:30 Scribe, day 1 AM Bryan. PM Ingmar 09:33:39 Day 2 AM, Laura 09:33:48 FH: call for agenda updates 09:34:24 Request to add gallery API update on agenda 09:34:34 FH: work this into agenda for day 3 09:34:51 Request to add support for lunar calendar in agenda discussion of calendar. 09:35:11 jmarting has joined #dap 09:35:22 RESOLUTION: Minutes of last teleconference (10 March) are approved. 09:36:28 Present+ Anssi_Kostiainen 09:37:22 fjh2 has joined #dap 09:37:30 zakim, who is here? 09:37:30 UW_DAP(F2F)3:30AM has not yet started, fjh2 09:37:31 On IRC I see fjh2, jmarting, JohnsonW, bsulliva, Kangchan, maxf, AnssiK, aguillou, Claes, LauraA, drogersuk, danielcoloma, richt, marengo, alissa, Zakim, RRSAgent, arve, tlr, 09:37:34 ... Marcos, ilkka, trackbot, dom 09:37:48 Present+ bryan_sullivan 09:37:50 Present+ Johnson_Wang 09:38:04 Present+ Frederick_Hirsch, Robin_Berjon 09:38:09 darobin has joined #dap 09:38:15 Present+ LauraA 09:38:24 Present+ Robin_Berjon 09:39:14 seungyun has joined #dap 09:39:38 Claes1 has joined #dap 09:39:54 Present+ Claes_Nilsson 09:40:15 RuthVazquez has joined #dap 09:41:36 Present+ Kangchan_Lee 09:43:01 Topic: Policy: Security, Privacy and Policy Requirements 09:43:20 http://dev.w3.org/2009/dap/policy-reqs/ 09:43:23 Present+ Jesus_Martin 09:45:02 fjh: restructured the document, added input on privacy use cases, collected requirements 09:46:08 ingmar has joined #dap 09:46:23 present+ Ingmar_Kliche 09:46:35 fjh: added access control input from Suresh 09:47:05 -> http://www.w3.org/mid/8080D5B5C113E940BA8A461A91BFFFCD1117D578@BD01MSXMB015.US.Cingular.Net Bryan's comments on policy-reqs 09:47:43 Zakim, what conferences? 09:47:43 I see no active conferences 09:47:45 scheduled at this time are Team_Europe()6:00AM, UW_DAP(F2F)3:30AM 09:47:51 fjh: some language in defs that is more explanatory may need to move 09:49:03 fjh: conformance targets were defined for different entities, e.g. user agent and application 09:51:38 fjh: other targets e.g. data use are on the content sources 09:51:54 darobin: this might be affected by the technical solution 09:52:16 bsulliva: use of data conformance is on the application on the device and network servers 09:52:33 fjh: content and application may be the same 09:53:20 dom: an important piece is to decide whether we can make useful requirements for the content parts, it's not clear this will have useful effects 09:53:40 fjh: you could require content to include the information needed 09:53:46 darobin: that's UA level 09:54:25 dom: if the API requires something that's a UA aspect, re use of the content it's useful but out scope 09:54:42 fjh: we should try to consider it 09:55:00 claes: we should give recommendations but normative requirements may be difficult 09:55:10 darobin: the requirements need to be normative if at all 09:55:41 have UA conformance target, then note implications for content/application and best practices 09:55:47 darobin: in addition to the UA requirements we could have best practices, and beyond that we are in unenforceable space 09:56:40 dom: in the geoloc API there are statements re conformance for applications, but not many may read it - at the least it should be separate and focused e.g. on best practices 09:57:20 darobin: implementers read specs, not developers. specific documents focused on that are more usable in a non-technical document e.g. best practices 09:58:19 fjh: concern is that privacy is a system-wide, DAP's charter is a small piece, and the overall system may not hang together unless it's considered on a broader basis 09:58:37 darobin: people expect us to produce guidelines 09:59:25 bsulliva: the best practices type info does get used by dev programs etc 09:59:53 darobin: should we split this into two different workstreams? a dfferent knowledge set is involved 10:00:46 allissa: in favor of a structure where the readers are interested in the privacy-related parts, but the technical parts will have some impact and need to be corrdinated 10:01:07 -> Mobile Web Best Practices: http://www.w3.org/TR/mobile-bp/ 10:01:24 -> WAI: http://www.w3.org/WAI/ 10:01:29 fjh: we need to focus on both, and should not leave it out of scope ala geoloc 10:01:56 fjh: is anyone object to technically enabling privacy through the API's? 10:02:28 Jirka has joined #dap 10:02:59 bsulliva: are we considering a metadata type approach ala inclusion of p3p headers in HTTP? 10:03:40 fjh: thinking about a small amount of data that can augment the API operations without adding a lot of complexity 10:03:55 richt: are we waiting on a technical input on this to proceed? 10:04:17 fjh: we can get started on the key things 10:04:54 dom: a number of the requirements related to the content side and should be clarified as not UA focused 10:05:35 alissa: going thru new privacy use cases would be useful to help identify easy ways to encapsulate the intent 10:06:06 richt: this comes down to conveying the info to the user as a key need 10:06:48 need to focus effort on minimum to get maximum result, not complexity of P3P, e.g. data retention and redistribution 10:06:49 darobin: creative commons was mentioned not only because its simple but we can build parallels and leverage tools etc that have been successful 10:07:06 licensing versus privacy related metadata 10:07:40 anssik: using a license template is a common approach, we can base this on that 10:07:45 Zakim, who's here? 10:07:45 UW_DAP(F2F)3:30AM has not yet started, RuthVazquez 10:07:46 On IRC I see Jirka, ingmar, RuthVazquez, Claes1, Seungyun, darobin, fjh2, jmarting, JohnsonW, bsulliva, Kangchan, maxf, AnssiK, aguillou, LauraA, drogersuk, danielcoloma, richt, 10:07:48 ... marengo, alissa, Zakim, RRSAgent, arve, Marcos, ilkka, trackbot, dom 10:07:59 fjh: this is different from licensing 10:08:12 s/that have been successful/that have been successful and privacy is reverse licensing of sorts/ 10:08:14 anssik: thinks they are closer 10:08:25 shepazu has joined #dap 10:08:32 claes: resolution on the way forward? 10:08:41 fjh: we will go thru the doc first 10:09:53 fjh: privacy areas 10:10:18 bsulliva: we should remove the statement re legal liability re comments on the mail list 10:11:06 fjh: intent was to clarify some after-effects of failure to comply may result 10:11:13 Kangchan has joined #dap 10:11:46 :D 10:11:54 "COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF." 10:12:08 drogersuk: agree that the statement should be removed - impacts upon health and safety could occur but are out of scope 10:13:55 fjh: re notice, use cases will help 10:15:08 fjh: re minimization, this will affect the API's 10:15:50 darobin: powerbox models make this easier to implement, as you a return a user interafce that complies with the requirements 10:16:48 fjh: retention could get complicated 10:17:06 dom: secondary use relates to unintended usage of the information 10:18:30 fjh: re the privacy use cases, minimization is easy to understand (ability to convey what app needs to know) 10:19:03 fjh: re access privacy, need to understand 10:19:34 alissa: about access to the data you have shared previously and how it has been used 10:20:30 drogersuk: API requirements may affect ability to do this, e.g. if we have the ability to send, and not read or delete messages 10:20:43 IF the server keeps data, then need to be able to review, delete, modify 10:20:45 ? 10:21:28 dom: once you have shared data with the app, access relates to keeping track of that data, and you should have the right to have access to find out what the organization (app in this case) knows about you 10:22:11 fjh: if the application does not retain it, it has no obligations re providing access 10:22:30 darobin: once data is sent to a server, its out of the scope of the user agent 10:22:48 robin notes potential UA rqmt -retain info on type of data provided to specific URIs service 10:22:54 drogersuk: we need to focus on the device use of the information at least 10:23:08 dom: you will not really know what has happened with the data once its shared 10:23:10 jmarting has joined #dap 10:23:38 dom: it may not be useful to delineate the two cases (local and remote use) 10:24:45 drogersuk: would that would mean that as soon as the browser is used, the data is gone - a widget use case may be different, as it potentially may still ebe on the device 10:25:19 drogersuk: record of data being sent may be on the device (e.g. sent folder) but is not held by the application 10:25:39 allissa: from the user perspective, is there a difference between local and remote retention? 10:25:52 section 6.2.1 example 10:26:09 drogersuk: do I have access to everything that google maps has retained? 10:26:41 alissa: we might make requirements about everything you share with google maps when you are logged in 10:26:58 fjh: maybe we should update the use cases to be more clear on these points 10:27:08 good example online ordering? 10:27:32 possible requirement - UA history 10:27:43 dom: you might want UA requirements on what the UA can share based upon privacy preferences, but the rest is on the best practices side 10:28:12 dom: you could say "I am giving this data but require access later" 10:28:31 possibly include with API note that access is needed , ability to see and review data 10:28:38 drogersuk: is the question that the user is concerned about transfer off the device? 10:28:58 alissa: just that the user needs to be able to access the data once used/sent 10:29:36 anssik: one use case is a webapp with access to contacts etc and has local caching of them 10:29:52 fjh: do privacy people work about caching? 10:30:02 alissa: what is not cached is more salient 10:30:43 dom: suggests to classify the user cases, re requirements on the API, policy sent with the data, minimization etc 10:31:12 fjh: minimization is a UA requirement 10:31:43 fjh: webcam use caswe 10:32:03 alissa: the relevant policy here is the application retaining the video 10:32:14 fjh: ala conference call recordings 10:32:44 alissa: if there is a log and the user doesn't know, it would be bad 10:33:03 richt: this is largely unenforceable 10:33:07 s/anssik/ilkka 10:33:33 alissa: things in the "policy with data" column are largely unenforceable but important to clarfy 10:33:44 another example, don't retain my visa 10:34:03 alissa: re voice search, does this get recorded and strored, or is it a one-time search 10:34:36 drogersuk: does include the derivatives of the search? 10:35:17 darobin: it should apply to derived content as well, e.g. face recognition 10:35:48 fjh: can we define the user's ability to say for example don't do face recognition? 10:36:37 ingmar: is it the capture API or a data processing API (e.g. recognition) that is responsible for this case 10:37:01 JohnsonW has joined #dap 10:37:22 dom: the notion is that the policy is on the data, and not the API in this case 10:37:50 alissa: the policy needs to get conveyed to the point of relevance 10:38:37 richt: the application may know best how it uses the data, e.g. may retain data to provide better service 10:39:06 ArtB has joined #dap 10:39:45 identifiability - face recognition when not wanted, could be example, retaining 10:39:55 alissa: a use case for identifiability, i.e. ability to retain without being able to identify the user - this may be a secondary use case to come back to 10:40:09 negotiation with server over details of retention time etc needs to be considered as noted by Richard, suggest after core issues 10:41:06 alissa: secondary use is for other purpose than immediate reason for API invocation, e.g. ads based upon setting a reminder (immediate), or upon the next invocation the app offers ads related to prior API usage 10:41:33 fjh: any scarier use cases than ads: 10:42:13 alissa: the app can generate statistics about the user, friends etc and share/sell that info 10:43:19 alissa: an example is use the API to find friends and the app sends an email to the friends - that's a secondary use 10:44:03 dom: secondary use can fall into the "policy with data" column 10:44:19 secondary use can be considered as disclosure 10:44:27 dom: also "privacy best practices" column 10:45:53 alissa: last example is disclosure, e.g. a privacy-protected disclosure policy is intended to limit use for a specified purpose only, without further disclosure 10:46:25 dom: what about CPU utilization, i.e. what types of data are considered privacy-sensitive? 10:46:40 fjh: there may be some risk cases 10:48:26 dom: there may be resistance to going too far with detail on privacy-sensitivity requirements on generic information and API's 10:49:07 richt: an alternative is to abstract the policy into some license that is a template and well-known, rather than setting each preference 10:49:31 dom: that is a good strategy but doesn't solve the issue of too much granularity 10:51:39 fjh: wonders about reaction to license vs data policy approach 10:52:31 alissa: they are not too different, UA's could implement more granular policies as an option, but licenses are more condensed 10:53:01 fjh: the license paradigm reduces the UA complexity 10:54:00 dom: we could define user information requirements based upon different license types, e.g. loose vs strict 10:54:32 API Req Minimization, access to history of usage, support license and/or policy with data 10:54:42 richt: the provider could explain the details of the license and allow the user to customize it 10:54:51 Policy with Data - access, retention, secondary use, disclosure 10:55:09 Privacy best practice - access, retention, secondary use, disclosure 10:55:25 drogersuk: that doesn't work in some cases, there can be a lot of room for abuse once a license is granted 10:55:40 fjh: need more time for this 10:56:08 fjh: next steps and actions 10:56:39 fjh: sounds like we are leaning toward a licensing approach, as simpler for users and developers - or do we need more work? 10:56:54 dom: prefer to see a concrete proposal - in theory sounds good 10:57:09 fjh: ala how an API would support it in methods? 10:57:19 need proposal - concrete licenses, API implications 10:57:37 dom: getting a few examples and which aspects would need to be covered by the licenses 10:57:50 richt: We don't have to necessarily create a programmatic approach. For example, it may be a requirement for a Provider to state their policies (via a CC-like policy URL) and the user may use that service according to this. 10:58:13 The issue here is that negotiation seems inevitable. Users don't always know what's best for them. 10:58:14 ACTION: alissa to make a proposal for a license-based privacy approach 10:58:15 Created ACTION-105 - Make a proposal for a license-based privacy approach [on Alissa Cooper - due 2010-03-23]. 10:58:27 Although I agree users should be in a position to interaction in that negotiation. 10:58:45 ACTION: robin to address how licenses could be handled by the API's 10:58:45 Created ACTION-106 - Address how licenses could be handled by the API's [on Robin Berjon - due 2010-03-23]. 11:09:05 ArtB has left #dap 11:16:21 tlr has joined #dap 11:57:54 tlr has joined #dap 12:15:47 jmorris has joined #dap 12:33:48 arve has joined #dap 12:35:23 Zakim has left #dap 12:48:22 Jirka has joined #dap 12:51:08 marengo has joined #dap 12:52:10 scribenick ingmar 12:52:39 scribenick: ingmar 12:55:07 Seungyun has joined #dap 12:55:46 David has joined #dap 12:55:48 hello, I'm Ruth Vazquez from Telefónica, may I join the conference via phone? 12:57:23 potential resolution: To work toward having API hooks for expressing user policies. 12:57:45 Zakim has joined #dap 12:58:03 zakim, this is dap 12:58:03 darobin, I see UW_DAP(F2F)3:30AM in the schedule but not yet started. Perhaps you mean "this will be dap". 12:58:12 dom: thinks that the action items are enough for resolution 12:58:16 zakim, this will be DAP 12:58:16 ok, dom; I see UW_DAP(F2F)3:30AM scheduled to start 328 minutes ago 12:59:04 Zakim, code? 12:59:04 the conference code is 3279 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dom 12:59:40 UW_DAP(F2F)3:30AM has now started 12:59:47 +[IPcaller] 12:59:59 Zakim, IPCaller is me 12:59:59 +darobin; got it 13:00:21 RESOLUTION: from the past discussion on policies: to work toward having API hooks for expressing policies using creative commons style licenses 13:01:26 brian: has some further comments on the policy reqs document 13:01:29 + +34.91.337.aaaa 13:01:40 Zakim, aaaa is RuthVazquez 13:01:40 +RuthVazquez; got it 13:01:52 Ruth Vazquez present+ 13:02:01 Present+ Ruth_Vazquez 13:02:20 maxf has joined #dap 13:02:33 -> http://www.w3.org/mid/8080D5B5C113E940BA8A461A91BFFFCD1117D578@BD01MSXMB015.US.Cingular.Net Bryan's comments on policy-reqs 13:02:53 fjh2 has joined #dap 13:03:00 zakim, who is here? 13:03:00 On the phone I see darobin, RuthVazquez 13:03:01 On IRC I see fjh2, maxf, Zakim, David, Seungyun, marengo, Jirka, arve, tlr, JohnsonW, jmarting, Kangchan, shepazu, ingmar, RuthVazquez, darobin, AnssiK, aguillou, LauraA, 13:03:03 ... drogersuk, richt, alissa, RRSAgent, Marcos, ilkka, trackbot, dom 13:03:51 bsulliva: implicit consent based on explixit action, should add explicit consent 13:04:46 alissa: it is not only implicit or explicit consent but also about trust model 13:04:52 alissa notes that section 5 issue relates to explicit consent defn 13:05:18 Claes has joined #dap 13:05:30 bsulliva: comment about chapter 4, proposal to change wording 13:08:06 Jirka has left #dap 13:08:59 8.1 add "while application running." 13:09:03 bsulliva: adds another comment on chapter 8.1, modal dialog is ok for installation, but not during app run 13:09:57 language independent - web language 13:10:13 bsulliva: chapter 8.2 what does app language mean? JavaScript? 13:10:25 bryan asks what requirement Javascript capable means for policy 13:10:59 RESOLUTION: accept proposed changes made by bsulliva 13:12:13 dom: proposes to replace "HTML 5 security model" with "same origin policy" 13:12:18 bsulliva has joined #dap 13:13:15 In 8.1 User Control Requirements, first bullet, add to the end of the sentence ", while the application is running", and add a sub-bullet beneath "Note: modal dialogs may be required for security prompts provided during application installation or invocation" 13:14:15 action: fjh to update policy requirements document with changes proposed by Bryan, update on conformance targets as discussed and information on where privacy aspects may be addressed as discussed in meeting 13:14:16 Created ACTION-107 - Update policy requirements document with changes proposed by Bryan, update on conformance targets as discussed and information on where privacy aspects may be addressed as discussed in meeting [on Frederick Hirsch - due 2010-03-23]. 13:14:39 Topic: Policy use cases 13:14:56 Topic: Threat cases 13:15:18 zakim, who is here? 13:15:18 On the phone I see darobin, RuthVazquez (muted) 13:15:19 On IRC I see bsulliva, Claes, fjh2, maxf, Zakim, David, Seungyun, marengo, arve, JohnsonW, jmarting, Kangchan, shepazu, ingmar, RuthVazquez, darobin, AnssiK, aguillou, LauraA, 13:15:22 ... drogersuk, richt, alissa, RRSAgent, Marcos, ilkka, trackbot, dom 13:15:50 drogersuk: will send slides to the list later 13:15:55 thx 13:16:06 drogersuk: example 1 - premium rate abuse 13:16:47 "safe" widget sends out SMSs to premium rate numbers 13:17:48 tlr has joined #dap 13:18:31 drogersuk:this is a real threat, how can we defend against this scenario? 13:18:42 -> http://news.bbc.co.uk/2/hi/technology/8459898.stm BBC article mentioned from David's slide on Premium Rate abuse 13:19:22 drogersuk: example 2 - privacy breach 13:20:22 silent uploads data to a site from a game 13:20:35 example 3 - privacy breach 13:22:03 try to improve security by reducing the number of prompts 13:22:10 example 3 - integrity breach 13:22:40 example of application changing data on device, number, files etc 13:23:03 example: A widget that replaces the voicemail number with a premium rate number 13:24:06 fjh: this example is different because it writes data 13:24:23 fjh: do we care about this in this working groupß 13:24:35 s/ß// 13:25:04 example 4 - phishing 13:25:16 bryan notes can get tagged by filter for having too much of fair use for example, so attacker could get you banned by modifying your upload content 13:25:19 example from Android market place 13:26:18 masquerade attack for phishing etc 13:26:33 widget contain web content - easy to duplicate and masquerade 13:27:51 drogersuk: this is where signatures come into the scene 13:29:11 there are contries, where various technologies are illegal to use 13:29:38 e.g. GPS illegal to use in Egypt, Syria and North Korea 13:29:57 hence we can not have blanket policies 13:30:50 drogersuk and lauraA working on some text to be send around soon 13:30:56 ACTION-45? 13:30:56 ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2010-03-16 -- OPEN 13:30:56 http://www.w3.org/2009/dap/track/actions/45 13:32:41 Topic: Powerbox 13:33:08 http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html 13:33:19 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0136/openprovider.html Rich's OpenProvider 13:33:20 web security context working group have had comments 13:33:29 other comments have been given on powerbox as well 13:33:31 danielcoloma has joined #dap 13:33:39 robin: the Google people working on an updated draft 13:34:01 s/robin/darobin 13:34:52 plan is for Google contributors to update draft based on comments 13:35:25 richt: powerbox doesn't talk about the data format for providers 13:36:20 richt: this first proposal of OpenProvider is based on JavaScript APIs 13:37:19 OpenProvider is a way for web based service providers to describe there endpoints 13:37:49 ... and to allow developers to discover endpoints 13:38:13 -> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0136/openprovider.html OpenProvider description document 13:39:55 it is related to OpenSearch http://www.opensearch.org 13:39:58 [there is a new element: the root element :) ] 13:41:26 element is important, rel attribute corresponds to the JavaScript method 13:42:08 parameters of javascript methods go into the "template" attribute 13:43:30 selection of installed openproviders it the same way as Powerbox providers, user selection 13:43:44 two modes of operation 13:44:36 1) Non-Interactive 13:44:42 2) Interactive 13:45:17 Claes: the OpenProvider container is the UA? 13:46:46 darobin: seems to be a replacement of WebIDL and is not really RESTful 13:47:20 richt: 2nd example is more in RESTful style 13:49:10 richt: proposal is to define APIs in WebIDL and define JSON/XML bindings 13:51:02 fjh2: we don't have a requirement to support RESTful API's 13:52:46 13:53:40 Robin notes that definition of using WebIDL to generate REST has not been designed/implemented and could be a lot of work 13:53:53 he also notes that it would harm interop for developers 13:53:57 drogersuk: there are a lot of companies around that table which want to see JavaScript API's 13:54:09 if only having WebIDL 13:55:16 darobin: proposal could be to work on WebIDL and another document of how to map WebIDL to REST 13:56:51 robin notes that there might be some best practices to follow in WebIDL to enable REST 13:57:24 need to understand what limits REST implies on webidl definitinos 13:58:51 david notes that if javascript is used as a wrapper for REST interfaces, then why not use the current WG Javascript APIs as that interface, continue with current approach 13:59:16 dom: my preference would be the same as Robins to continue work on JavaScript API's 13:59:19 ACTION: Robin to make a proposal on WebIDL REST mapping 13:59:19 Created ACTION-108 - Make a proposal on WebIDL REST mapping [on Robin Berjon - due 2010-03-23]. 14:00:10 need to figure out technical requirements on WebIDL for REST APIs 14:00:47 scalability is concern for number of APIs, need generic mechanisms 14:01:28 drogersuk: question would be on how to map policies to web services 14:02:06 ACTION: Robin to write up Prague Doctrine (define in WebIDL, have mappings to JS and REST as needed, leave which is implemented up to implementers just like they could decide to map WebIDL to Java, have orthogonal installation/exposing aspects like PB defined, well, orthogonally) 14:02:06 Created ACTION-109 - Write up Prague Doctrine (define in WebIDL, have mappings to JS and REST as needed, leave which is implemented up to implementers just like they could decide to map WebIDL to Java, have orthogonal installation/exposing aspects like PB defined, well, orthogonally) [on Robin Berjon - due 2010-03-23]. 14:02:09 Claes: discovery mechanism of OpenProvider and Powerbox is also interesing 14:02:20 "Prague Doctrine", nice 14:02:57 fjh2: Discovery is not in the charter 14:06:07 s/charter/charter - it's not a matter of blocking work in this area, but a matter of prioritizing 14:06:32 bryan has joined #dap 14:08:37 PROPOSED RESOLUTION: the group focuses on defining WebIDL-based APIs, trying to make them REST-ful compatible 14:09:27 PROPOSED RESOLUTION: the group is interested in seeing prototypes and explorations of discoverable API providers 14:10:21 bsulliva: makes proposal for next step: protoype Powerbox and OpenProvider proposals 14:10:31 fjh2: Google is already working on a Powerbox prototype 14:11:51 David has left #dap 14:12:03 drogersuk has left #dap 14:12:32 David has joined #dap 14:13:07 darobin: I wouldn't recommend to spend to much time for a full implementation 14:13:44 bryan: we should spend time on more developed examples 14:14:30 ACTION-109? 14:14:30 ACTION-109 -- Robin Berjon to write up Prague Doctrine (define in WebIDL, have mappings to JS and REST as needed, leave which is implemented up to implementers just like they could decide to map WebIDL to Java, have orthogonal installation/exposing aspects like PB defined, well, orthogonally) -- due 2010-03-23 -- OPEN 14:14:30 http://www.w3.org/2009/dap/track/actions/109 14:14:43 somebody_ has joined #dap 14:15:28 danielcoloma has joined #dap 14:16:33 Claes: what are the major differences of OpenProvider and Powerbox? 14:16:38 richt: OpenProvider does not rely on the element 14:17:10 also request/response defined, not using UMP/XHR 14:17:55 richt: OpenProvider container has more responsibilities (enforcement point) compared to Powerbox 14:21:15 PROPOSED RESOLUTION: the group focuses on defining WebIDL-based APIs, trying to make them REST-ful compatible 14:21:48 should we s/trying to make them/making them/ ? 14:21:52 PROPOSED RESOLUTION: the group is interested in seeing prototypes and explorations of discoverable API providers 14:23:58 openprovider proposal introduces unique callback address which interactive service provider calls when the call is completed. 14:24:38 If the provider is located in the network, does it mean that HTTP connection is initiated from the network side. That is problematic 14:24:43 I propose that we also add that we still however concentrate primarily on the work as defined in the charter 14:25:02 in order that we can deliver in a timely fashion and not get too distracted by the other things 14:25:19 (that's the intent of "focuses on") 14:27:08 RESOLUTION: the group focuses on defining WebIDL-based APIs, making them REST-ful compatible 14:29:04 PROPOSED RESOLUTION: the group puts its priorities in defining WebIDL REST-compatible APIs; the group is interested in seeing prototypes and explorations of discoverable API providers, but will not focus on this in the short term 14:29:56 RESOLUTION: the group puts its priorities in defining WebIDL REST-compatible APIs; the group is interested in seeing prototypes and explorations of discoverable API providers, but will not focus on this in the short term 14:29:59 OK, let's see how it goes :-) 14:30:10 -RuthVazquez 14:30:13 -darobin 14:30:14 UW_DAP(F2F)3:30AM has ended 14:30:15 Attendees were darobin, +34.91.337.aaaa, RuthVazquez 14:45:29 Claes2 has joined #dap 14:48:08 ScribeNick: maxf 14:51:26 Topic: policy stuff from bondi, nokia: what are we going to do with it? 14:52:00 fjh: might be a chance for Bondi to make us aware of things changed 14:52:22 david: no changes since all is defined in the policy framework 14:53:14 ... future work: bondi 1.1 approved release 14:53:24 ... 1.5 work introduces new APIs 14:53:52 ... crypto, SIM-related... 14:54:59 ... not directly trusted services, but may lead the ground for it ... 14:56:10 ... we've redesigned some APIs as synchronicity would slow down systems too much 14:57:08 fjh2: there's been work on conformance testing, implementation. Anything on policy specifically? 14:57:09 darobin has joined #dap 14:57:36 david: we do have a policy building tool, and current mailing list discussions are about specific policies 14:58:01 ... the reference implementation of Bondi was demonstrated on many platforms 14:58:19 ... so we could try out different policies to see what happens 14:58:26 alissa: any policy you could share? 14:58:45 bryan: we're going to provide a guidance document to policy writers 14:58:57 ... we wouldn't initially share our examples though 14:59:21 ... we may want to anonymize to make it public 14:59:55 David: we can take policy fragments independently. E.g. to stop redirect clause. 15:00:24 blassey has joined #dap 15:00:32 Seungyun has joined #dap 15:00:44 fjh: to get some feel about how the real thing is, a sample would be useful, rather than scratching from scratch 15:01:25 David: we've already submitted something. There's an appendix to the A&S document pointing to examples 15:01:25 http://bondi.omtp.org/1.1/ 15:02:17 dom: can't find an example in the appendices 15:02:47 david: we do have examples and we could explain here how they work 15:03:03 danielcoloma: looking for whole policy docs? We may have one 15:03:12 ... we can send that one today 15:03:19 ... might not be valid, though 15:03:31 david and Laura will provide example policy to WG 15:03:45 David: checking if I can give access to the policy building tool 15:04:52 fjh2: what next for the policy framework? We have to review stuff, but right now we need to have the requirements done 15:05:01 ... we have contributions from Nokia and Bondi 15:05:18 ... at the last f2f we said that they were pretty compatible 15:05:36 ACTION-47? 15:05:37 tlr has joined #dap 15:05:37 ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- CLOSED 15:05:37 http://www.w3.org/2009/dap/track/actions/47 15:05:48 -> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0128.html Laura's summary 15:06:30 LauraA: Nokia apprach had a trust manager in which the trust domain would be assigned separately from the access permissions, while Bondi has them together 15:07:09 fjh2: we never made a decision how to go forward. Trying to find how to get started. 15:07:41 David: what do you mean about managing policy 15:07:55 fjh2: bondi has revokation managemenet, etc. 15:08:15 David: it's for the future 15:08:31 bryan: document doesn't say how policy is installed 15:10:10 fjh2: I'd like to merge nokia and bondi. Any volunteers? 15:11:29 ... start from scratch? Start from one and merge the other in?... 15:11:40 dom: the person doing the word will decide 15:13:54 [editorial discussion] 15:14:30 [david has been volunteered] 15:14:59 ACTION: David to lead the merging of Bondi/Nokia policy docs 15:14:59 Created ACTION-110 - Lead the merging of Bondi/Nokia policy docs [on David Rogers - due 2010-03-23]. 15:16:00 fjh2: take original documents, ReSpec them, put into CVS 15:16:34 action: fjh to create framework directory, and template for framework 15:16:34 Created ACTION-111 - Create framework directory, and template for framework [on Frederick Hirsch - due 2010-03-23]. 15:19:24 fjh2: the big decision is going to be about trust domains 15:19:33 ... which is the main difference between Nokia and Bondi 15:19:54 ... although they seem functionaly similar 15:20:06 darobin: yes, more syntax than semantics 15:21:23 fjh2: that brings up to the end of the agenda for today 15:21:48 ... however, we can talk about privacy 15:22:20 ... can we talk about a specific API that's a good example of privacy rules usage? 15:22:35 -> http://dev.w3.org/2009/dap/contacts/Overview.html Contacts API Editors draft 15:22:37 richt: contacts 15:23:09 darobin: we should look at this morning's requirements and see how they apply to contacts (e.g. minimization) 15:23:33 alissa: are we talking about the actual functionality of the API, or the privacy text? 15:23:36 darobin: the former 15:25:07 TOPIC: Contacts and privacy considerations 15:25:32 richt: good place to start is use cases 15:26:23 ... first, minimization 15:26:38 ... looking at 2.1 15:26:54 ... contact object containing all attributes was a problem 15:27:28 ... now there's a new parameter to specify the attributes requested 15:27:55 ... you only get what you request. 15:28:01 ... rest is null 15:29:38 alissa: can you search within groups? 15:29:46 jmorris has joined #dap 15:29:57 richt: can use filter to specify group 15:31:29 UW_DAP(F2F)3:30AM has now started 15:31:33 dom: spec doesn't let you request *all* the fields in one go 15:31:35 shepazu has joined #dap 15:31:36 +Ari_Schwartz 15:31:38 -Ari_Schwartz 15:31:40 UW_DAP(F2F)3:30AM has ended 15:31:40 Attendees were Ari_Schwartz 15:31:45 ... maybe there would need to be a wildcard 15:32:52 Present+ John_Morris 15:33:14 Is there a conf. bridge or skype access? 15:33:18 darobin: for the specific widget situation, we don't need as many privacy-oriented features 15:33:55 jmorris, we're setting it up 15:34:01 zakim, code? 15:34:01 the conference code is 3279 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dom 15:34:09 richard noted that can search for group using parameter, and then get only items requested in that group 15:34:29 UW_DAP(F2F)3:30AM has now started 15:34:36 +Ari_Schwartz 15:34:39 David: yes, widgets are different because of installing context 15:34:57 zakim, Ari_Schwartz is John_Morris 15:34:57 +John_Morris; got it 15:35:03 darobin: and you don't want, in a widget scenario, to go through the same steps as webapps. Not for all widgets. 15:35:30 Present+ John_Morris 15:35:31 ... e.g. address book widget needs more access and would have a wildcard 15:36:12 e.g. searching for a group in the Contacts API example: navigator.service.contacts.find(['name', 'phones'], successCallback, null, {filter: {categories: ['w3c'], name: 'rich'}}); 15:36:12 David: e.g. facebook apps on Android open browser windows that may confuse the user into thinking of a real app 15:36:32 ... in Bondi, we'd like to use the same policy framework 15:37:52 darobin: it's application-supposed-to-managed-data vs application-useing that data 15:38:03 fjh2: different roles, different policies 15:38:35 David: but I'm thinking of the FB application masquerading as a real one. 15:38:51 issue: contacts need management of address book, different role than contacts user 15:38:52 Created ISSUE-77 - Contacts need management of address book, different role than contacts user ; please complete additional details at http://www.w3.org/2009/dap/track/issues/77/edit . 15:39:29 fjh2: does error-handling cause privacy concerns? 15:40:16 darobin: if you get a security error, you may be able to guess what's there, like trying different URLs and getting information whether your getting a 403 or 404 15:40:28 -John_Morris 15:40:29 UW_DAP(F2F)3:30AM has ended 15:40:29 Attendees were John_Morris 15:41:57 access to history of usage - which sites did find results get shared with? 15:42:30 [reviewing the privacy considerations section] 15:42:44 scribenick: dom 15:43:01 [looking at revokation vs "access to history of usage"] 15:43:52 3.2 paragraph 1 - should uppercase, on UA 15:44:06 note to Richard for editing 15:44:07 robin: access to history of usage is purely UA - you don't want to grant API access to history of usage 15:44:40 Richard: instead of the wiggly requirements on applications section 3, I'd like to move to our policy-profiles based approach we discussed this morning 15:45:21 Scribenick: maxf 15:46:27 once we've got a good single text, we can change each spec. That avoids reviewing all of them 15:47:16 fjh2: we need something that covers all the spec, otherwise there's too much replicating 15:47:38 dom: danger is to start designing UA features 15:48:04 darobin: we don't have to constrain UAs, we can just express functionality 15:48:45 alissa: UAs don't want to design UAs for features they don't want to support ;) 15:48:58 dom: but it won't happen magically because we put it in a spec. 15:49:39 ... the concrete impact of making a normative appendix is that it creates requirements on user-agents 15:49:59 s/appendix/requirement/ 15:50:37 ... doesn't achieve any purpose making the user click 25 times. 15:50:52 fjh2: we should keep track of it 15:51:12 darobin: a good way forward would be to talk about extensions, that handle that stuff 15:51:16 [laughter] 15:51:56 bryan: if you say something like the "UA is not allowed to resend information"... 15:52:01 Note - need to keep track of User Agent requirements then later revisit testability and suitability after seeing how many, nature , impact etc 15:52:05 darobin: it's impossible 15:52:51 shepazu has joined #dap 15:54:10 [general confusion on actions] 15:54:32 example - UA MUST allow user to visit history of usage 15:55:44 richt: the only key requirement on this API itslef is minimization 15:56:08 ... privacy goes around it, b ut isn't necessarilly built-in 15:56:24 ACTION: alissa to separate privacy requirements on UA from other privacy requirements (on APIs, for user policies, and for best practices for recipients) 15:56:25 Created ACTION-112 - Separate privacy requirements on UA from other privacy requirements (on APIs, for user policies, and for best practices for recipients) [on Alissa Cooper - due 2010-03-23]. 15:57:28 dom: suggesting an API review list 15:57:39 ... pre-last call 15:58:18 fjh2: potential issues on Calendar events? 15:58:28 richt: definitely up for review 15:58:37 ACTION: Dom to propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding 15:58:37 Created ACTION-113 - Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding [on Dominique Hazaël-Massieux - due 2010-03-23]. 15:59:56 alissa: about Capture. It doesn't say anything about privacy so far. 16:00:04 -> http://dev.w3.org/2009/dap/camera/ Editors draft of Capture API 16:00:05 ... it's probably a good idea to have something 16:00:23 fjh2: you can't really minimize capture 16:00:40 alissa: just talking about privacy section in other specs 16:01:04 ... we should have some strategy for publishing 16:01:17 minimization in capture: drop every other pixel? 16:01:58 fjh2: do we want a boilerplate saying "privacy section under construction"? 16:02:07 alissa: yeah, like an issue 16:02:44 RESOLUTION: add to every draft an issue saying "we're working on a privacy framework" 16:03:52 ACTION: alissa to phrase the temporary privacy section 16:03:52 Created ACTION-114 - Phrase the temporary privacy section [on Alissa Cooper - due 2010-03-23]. 16:04:26 maxf: and existing specs that have a section 16:04:34 fjh2: just add the issue at the beginning 16:04:45 s/section/section?/ 16:05:14 darobin: about the exif data of pictures? 16:05:18 dom: could be a parameter 16:05:23 concern for capture EXIF data is not minimization 16:05:27 darobin: could be geotagged 16:06:01 ISSUE: Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged) 16:06:03 Created ISSUE-78 - Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged) ; please complete additional details at http://www.w3.org/2009/dap/track/issues/78/edit . 16:06:45 David: could apply to a document with name and address, too. Not just that specific one 16:06:58 dom: but a word document has the data explicity, not a picture 16:07:30 richt: does the API deal with non-image data? 16:07:38 David: we need to be more abstract anyway 16:07:55 fjh2: a warning is appropriate at least 16:08:28 fjh2: there's SysInfo and it's privacy concerns 16:08:56 richt: The Capture API deals with URLs only...so the transmission of EXIF with the audio/video/image at that URL is out of scope...right? 16:09:52 ... you can get all sorts of information, sensitive ones like network 16:10:02 Wifi SSID gives locations 16:10:17 David: IMEI number is considered an identifier in germany 16:10:35 ... not in SysInfo though 16:10:49 s/.../fjh2/ 16:11:22 [disagreement about the importance of IMEI taken offline] 16:12:57 darobin: my one concern about sysinfo is gathering everything together 16:13:09 ... you narrow people down very quickly 16:13:12 creates a fingerprint of user 16:14:18 possible access control solution 16:14:46 issue: fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk 16:14:46 Created ISSUE-79 - Fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk ; please complete additional details at http://www.w3.org/2009/dap/track/issues/79/edit . 16:15:06 action: max to add warning to sysinfo re fingerprinting privacy risk 16:15:06 Created ACTION-115 - Add warning to sysinfo re fingerprinting privacy risk [on Max Froumentin - due 2010-03-23]. 16:16:01 Traffic analysis, idle computer privacy risk for sysinfo 16:16:19 alissa notes combination of data a privacy risk, e.g. geolocation + sysinfo etc 16:16:37 David: if this stuff is also used in plant equipment, knowing things like temperature may be useful for mischievous uses 16:17:40 bryan: there's lots of dangers with atmospheric pressure, ambient noise, etc. All potential leaks 16:18:30 darobin: not sure about minimization since sysinfo is already fine-grained 16:20:05 [discussion on spec readability] 16:21:07 alissa: about wildcards, like in contacts, is that to be decided spec-by-spec? 16:21:24 darobin: that should go on the API review checklist 16:22:13 ACTION-113: also: do we allow wildcard/trust-delegated access to the said API? 16:22:13 ACTION-113 Propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding notes added 16:23:15 dom: policy framework doesn't solve the question. Policy will need to be written and adopted by users/user-agents anyway. 16:23:20 action-115: and traffic analysis 16:23:20 ACTION-115 Add warning to sysinfo re fingerprinting privacy risk notes added 16:24:34 [scribe slightly losing the plot] 16:25:26 David: does sysinfo prompt or not? If we have a framework for policy, doesn't matter 16:25:55 In the SysInfo spec, prompting is implied in Section 3: Security and Privacy Considerations. 16:26:22 ... there is an edge case -- desktop ;) but implication is we're shifing policy to provacy provider 16:26:35 ... shift to expert making the right decision 16:27:21 ... I disagree that we're shifting the problem to the wrong place. We have this problem anyway: some people will design APIs without any policy 16:27:36 ... in the mobile indistry we have an anserw already 16:28:01 ... but laptops and PCs will have a problem. 16:28:37 dom: if most devices get the framework implemented, you need to get the operators implement it in a right way 16:29:27 David: WAC will be a major deployment, harmonizing policies 16:30:33 @maxf - 'the intention would be to' 16:30:44 bryan: you have to assume that whoever implements the policy makes the right choice for their users 16:31:40 adjourned 16:31:42 [adjourned.] 16:31:45 RRSAgent, draft minutes 16:31:45 I have made the request to generate http://www.w3.org/2010/03/16-dap-minutes.html dom 16:32:09 AnssiK has left #dap 16:34:09 jmorris has joined #dap 16:35:14 http://en.ufleku.cz/ 17:03:27 ingmar has joined #dap 17:13:46 drogersuk has joined #dap 17:19:21 alissa has joined #dap 17:32:49 shepazu has joined #dap 17:39:26 Zakim has left #dap 19:43:32 arve has joined #dap 20:45:13 shepazu has joined #dap 22:09:55 shepazu has joined #dap