W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Draft minutes, F2F day 1, 16 March 2010 (txt and html)

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 16 Mar 2010 13:35:21 -0400
Message-Id: <F6D50E40-FA00-4D4D-8485-121A90579976@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Draft minutes, F2F day 1, 16 March 2010, with text version, html follows


regards, Frederick

Frederick Hirsch
Nokia



   [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
     _________________________________________________________

   <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.

Policy: Security, Privacy and Policy Requirements

   <fjh2> [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

   <dom> [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

   <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:
   [14]http://www.w3.org/TR/mobile-bp/

     [14] http://www.w3.org/TR/mobile-bp/

   <darobin> -> 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

   <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
   [16]http://www.w3.org/2010/03/16-dap-minutes.html#action01]

     [16] 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
   [17]http://www.w3.org/2010/03/16-dap-minutes.html#action02]

     [17] 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> [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

   <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
   [19]http://www.w3.org/2010/03/16-dap-minutes.html#action03]

     [19] 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].

Policy use cases

Threat cases

   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> [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

   <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> [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

   <dom> [23]Rich's OpenProvider

     [23] http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0136/openprovider.html

   <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> [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/

   <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
   [26]http://www.w3.org/2010/03/16-dap-minutes.html#action04]

     [26] 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
   [27]http://www.w3.org/2010/03/16-dap-minutes.html#action05]

     [27] 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> [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 <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

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

   <fjh2> [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

   <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> [30]http://www.w3.org/2009/dap/track/actions/47

     [30] http://www.w3.org/2009/dap/track/actions/47

   <dom> [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]

   <dom> [david has been volunteered]

   <scribe> 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

   <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
   [33]http://www.w3.org/2010/03/16-dap-minutes.html#action07]

     [33] 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> [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

   <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 [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

   <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
   [36]http://www.w3.org/2010/03/16-dap-minutes.html#action08]

     [36] 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
   [37]http://www.w3.org/2010/03/16-dap-minutes.html#action09]

     [37] 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> [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

   <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
   [39]http://www.w3.org/2010/03/16-dap-minutes.html#action10]

     [39] 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
   [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> 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
   [41]http://www.w3.org/2009/dap/track/issues/79/edit .

     [41] http://www.w3.org/2009/dap/track/issues/79/edit

   <fjh2> 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

   <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> [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/



Received on Tuesday, 16 March 2010 17:36:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT