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