See also: IRC log
<trackbot> Date: 16 March 2010
<bsulliva> scribenick: bsulliva
<dom> ScribeNick: bsulliva
<dom> 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.
<fjh2> 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
<dom> Bryan's comments on policy-reqs
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
<fjh2> 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
<darobin> -> Mobile Web Best Practices: http://www.w3.org/TR/mobile-bp/
<darobin> -> WAI: 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
<fjh2> 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
<fjh2> 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
<Marcos> :D
<darobin> "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
<fjh2> IF the server keeps data, then need to be able to review, delete, modify
<fjh2> ?
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
<fjh2> 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?
<fjh2> 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
<fjh2> good example online ordering?
<fjh2> 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"
<fjh2> 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
<fjh2> 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
<fjh2> 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
<fjh2> 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
<fjh2> 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
<fjh2> 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
<fjh2> Policy with Data - access, retention, secondary use, disclosure
<fjh2> 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?
<fjh2> need proposal - concrete licenses, API implications
dom: getting a few examples and which aspects would need to be covered by the licenses
<richt> 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.
<richt> The issue here is that negotiation seems inevitable. Users don't always know what's best for them.
<scribe> ACTION: alissa to make a proposal for a license-based privacy approach [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action01]
<trackbot> Created ACTION-105 - Make a proposal for a license-based privacy approach [on Alissa Cooper - due 2010-03-23].
<richt> Although I agree users should be in a position to interaction in that negotiation.
<scribe> ACTION: robin to address how licenses could be handled by the API's [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action02]
<trackbot> Created ACTION-106 - Address how licenses could be handled by the API's [on Robin Berjon - due 2010-03-23].
<ingmar> scribenick ingmar
<ingmar> scribenick: ingmar
<RuthVazquez> hello, I'm Ruth Vazquez from Telefónica, may I join the conference via phone?
<alissa> 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
<RuthVazquez> Ruth Vazquez present+
<dom> Bryan's comments on policy-reqs
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
<fjh2> alissa notes that section 5 issue relates to explicit consent defn
bsulliva: comment about chapter 4, proposal to change wording
<fjh2> 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
<fjh2> language independent - web language
bsulliva: chapter 8.2 what does app language mean? JavaScript?
<fjh2> 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"
<bsulliva> 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"
<fjh2> 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 http://www.w3.org/2010/03/16-dap-minutes.html#action03]
<trackbot> 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].
drogersuk: will send slides to the list later
<RuthVazquez> thx
drogersuk: example 1 - premium rate abuse
<fjh2> "safe" widget sends out SMSs to premium rate numbers
drogersuk: this is a real threat, how can we defend against this scenario?
<dom> BBC article mentioned from David's slide on Premium Rate abuse
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
<fjh2> 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
<fjh2> 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
<fjh2> 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
<dom> ACTION-45?
<trackbot> ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2010-03-16 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/45
http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html
<dom> Rich's OpenProvider
<fjh2> web security context working group have had comments
<fjh2> other comments have been given on powerbox as well
darobin: the Google people working on an updated draft
<fjh2> 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
<dom> OpenProvider description document
it is related to OpenSearch http://www.opensearch.org
<dom> [there is a new element: the root element :) ]
<url> 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
<discussion about WebIDL and REST>
<fjh2> Robin notes that definition of using WebIDL to generate REST has not been designed/implemented and could be a lot of work
<fjh2> 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
<fjh2> if only having WebIDL
darobin: proposal could be to work on WebIDL and another document of how to map WebIDL to REST
<fjh2> robin notes that there might be some best practices to follow in WebIDL to enable REST
<fjh2> need to understand what limits REST implies on webidl definitinos
<fjh2> 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
<darobin> ACTION: Robin to make a proposal on WebIDL REST mapping [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action04]
<trackbot> Created ACTION-108 - Make a proposal on WebIDL REST mapping [on Robin Berjon - due 2010-03-23].
<fjh2> need to figure out technical requirements on WebIDL for REST APIs
<fjh2> scalability is concern for number of APIs, need generic mechanisms
drogersuk: question would be on how to map policies to web services
<darobin> 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 http://www.w3.org/2010/03/16-dap-minutes.html#action05]
<trackbot> 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
<dom> "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
<dom> PROPOSED RESOLUTION: the group focuses on defining WebIDL-based APIs, trying to make them REST-ful compatible
<dom> 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
<dom> ACTION-109?
<trackbot> 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
<trackbot> 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 <input> element
<fjh2> also request/response defined, not using UMP/XHR
richt: OpenProvider container has more responsibilities (enforcement point) compared to Powerbox
<dom> PROPOSED RESOLUTION: the group focuses on defining WebIDL-based APIs, trying to make them REST-ful compatible
<darobin> should we s/trying to make them/making them/ ?
<dom> PROPOSED RESOLUTION: the group is interested in seeing prototypes and explorations of discoverable API providers
<ilkka> openprovider proposal introduces unique callback address which interactive service provider calls when the call is completed.
<ilkka> If the provider is located in the network, does it mean that HTTP connection is initiated from the network side. That is problematic
<David> I propose that we also add that we still however concentrate primarily on the work as defined in the charter
<David> in order that we can deliver in a timely fashion and not get too distracted by the other things
<dom> (that's the intent of "focuses on")
RESOLUTION: the group focuses on defining WebIDL-based APIs, making them REST-ful compatible
<dom> 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
<David> OK, let's see how it goes :-)
<maxf> ScribeNick: maxf
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
<fjh2> 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
<fjh2> 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
<dom> ACTION-47?
<trackbot> ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/47
<dom> Laura's summary
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]
<dom> [david has been volunteered]
<scribe> ACTION: David to lead the merging of Bondi/Nokia policy docs [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action06]
<trackbot> 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
<fjh2> ACTION: fjh to create framework directory, and template for framework [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action07]
<trackbot> 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?
<dom> Contacts API Editors draft
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
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
<jmorris> Is there a conf. bridge or skype access?
darobin: for the specific widget situation, we don't need as many privacy-oriented features
<dom> jmorris, we're setting it up
<fjh2> 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
<richt> 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.
<fjh2> issue: contacts need management of address book, different role than contacts user
<trackbot> 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 .
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
<fjh2> access to history of usage - which sites did find results get shared with?
[reviewing the privacy considerations section]
<dom> scribenick: dom
[looking at revokation vs "access to history of usage"]
<fjh2> 3.2 paragraph 1 - should uppercase, on UA
<fjh2> 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
<scribe> 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"...
<fjh2> 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]
<fjh2> 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
<alissa> 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 http://www.w3.org/2010/03/16-dap-minutes.html#action08]
<trackbot> 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
<dom> ACTION: Dom to propose a checklist of points to verify before LC for APIs, including REST-ful, minimization, policy-binding [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action09]
<trackbot> 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.
<dom> Editors draft of Capture API
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
<jmorris> 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"
<scribe> ACTION: alissa to phrase the temporary privacy section [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action10]
<trackbot> 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
<fjh2> concern for capture EXIF data is not minimization
darobin: could be geotagged
<darobin> ISSUE: Capture has a minimisation problem with EXIF data (e.g. it could be Geotagged)
<trackbot> 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 .
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> 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
<jmorris> 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
<fjh2> creates a fingerprint of user
<fjh2> possible access control solution
<fjh2> issue: fingerprinting privacy issue related to sysinfo, need for feedback on privacy risk
<trackbot> 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 .
<fjh2> ACTION: max to add warning to sysinfo re fingerprinting privacy risk [recorded in http://www.w3.org/2010/03/16-dap-minutes.html#action11]
<trackbot> Created ACTION-115 - Add warning to sysinfo re fingerprinting privacy risk [on Max Froumentin - due 2010-03-23].
<fjh2> Traffic analysis, idle computer privacy risk for sysinfo
<fjh2> 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
<dom> ACTION-113: also: do we allow wildcard/trust-delegated access to the said API?
<trackbot> 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.
<fjh2> action-115: and traffic analysis
<trackbot> 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
<richt> 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
<David> @maxf - 'the intention would be to'
bryan: you have to assume that whoever implements the policy makes the right choice for their users
<dom> adjourned
[adjourned.]
<David> http://en.ufleku.cz/