IRC log of dap on 2010-03-16

Timestamps are in UTC.

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