00:26:34 nvdbleek has joined #privacy 00:53:07 fjh has joined #privacy 04:57:17 nvdbleek has joined #privacy 15:39:26 RRSAgent has joined #privacy 15:39:26 logging to http://www.w3.org/2014/10/31-privacy-irc 15:39:28 RRSAgent, make logs 263 15:39:29 Zakim has joined #privacy 15:39:30 Zakim, this will be 15:39:31 I don't understand 'this will be', trackbot 15:39:31 Meeting: Privacy Interest Group Teleconference 15:39:32 Date: 31 October 2014 15:39:40 rrsagent, make logs public 15:39:46 Meeting: Privacy Interest Group f2f 15:39:54 Topic: Agenda overview 15:39:57 scribenick: npdoty 15:40:06 runnegar: overview of the agenda 15:40:09 http://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0005.html 15:40:21 AndyF has joined #privacy 15:41:22 runnegar: visitors from i18n to start. start with Specification Privacy Assessment 15:42:15 15:43:41 olivier has joined #privacy 15:44:02 npdoty: could talk about results from the breakout sessions 15:44:05 Topic: Introductions 15:44:05 Christine Runnegar, PING co-chair 15:44:10 Tara Whalen, Google, PING co-chair 15:44:20 Nick Doty, npdoty, W3C 15:45:30 Olivier Thereaux, BBC 15:46:52 aphllip has joined #privacy 15:46:55 introduction [way to many names to remember] 15:47:02 Topic: Internationalization 15:47:06 Agenda item 2: Visits from other IGs and WGs 15:47:15 Richard - here to look for overlaps 15:47:21 http://www.w3.org/International/track/products 15:47:26 visitors from I18N are: Addison Phillips, Richard Ishida, Dennis Tan, and Leandro Reis 15:48:08 Richard: discusses tracker as a way of raising issues and tracking them for a working group. It does smart things like parse emails. Most groups use for listing issues being worked. 15:48:30 Richard: uses it to track specs for other working groups. Has group look at such a list... 15:48:43 JY has joined #privacy 15:48:51 Richard: A product is a grouping 15:49:12 http://www.w3.org/International/track/products/2 15:49:17 Richard: discusses items in list they have reviewed (Internationalization Working Group) 15:49:50 Richard: Goes into details of a review in tracker... 15:50:17 http://www.w3.org/International/reviews/review-instructions 15:50:20 olivier_ has joined #privacy 15:50:40 Richard: how doest the tracker data get used. Has URL to steps they take.... 15:50:44 RRSAgent, pointer? 15:50:44 See http://www.w3.org/2014/10/31-privacy-irc#T15-50-44 15:51:14 Richard: steps through the document that describes the steps. Advises going through the document 15:51:29 Richard: Asks Privacy group how they can help 15:52:10 rrsagent, this meeting spans midnight 15:52:18 Tara: In response to Richard - Privacy has done some reviews. Using a manual process of passing document around, email, phone calls, informal process 15:52:58 example of what addison's saying: http://www.w3.org/International/track/issues/316 15:53:06 Addison: Tracker will track the emails and collect discussions. Also references IRC logs. Ties things together and keeps you up with status 15:53:22 Addison: You can even link into specs. 15:53:25 q+ 15:53:49 Tara: Does this work for all size reviews 15:54:19 Addison: confirms. Works well when doing a lot of reviews versus the archive being unmanageable 15:54:26 q+ to ask about whether these issues are by individual or by the whole group 15:54:39 fjh has joined #privacy 15:54:43 Addison: Some groups use Mozilla log. They can link to it. 15:54:44 q+ to ask about how to avoid looking like your reviews are "fire and forget" 15:55:18 yrles has joined #privacy 15:55:32 Richard: They can hancle the mess of entangled comments and responses much better with Tracker. Keep emails to one issue as a way to support this. 15:55:42 s/Mozilla log/Bugzilla/ 15:55:42 s/hancle/handle/ 15:56:42 acn npdoty 15:56:46 ack npdoty 15:56:46 npdoty, you wanted to ask about whether these issues are by individual or by the whole group 15:57:03 s/acn npdoty// 15:57:09 fjh_ has joined #privacy 15:57:11 Nick: ask about issue by issue tracking. What is the process? 15:57:29 for Nick http://www.w3.org/International/reviews/review-instructions 15:57:31 kodonog has joined #privacy 15:57:45 Addison: get multiple people to read a spec. Enter comments one at a time. If time, working group will review issue by issue. 15:58:26 Addison: Group keeps track of all the issues. Issues can be redrawn. Someone reads it, makes comments, trackerizes it, and then group discusses. 15:58:27 https://www.w3.org/International/wiki/Review_radar 15:58:56 npdoty_ has joined #privacy 15:59:02 Richard: they put comments in, group then reviews it, before sending to group owning spec. 15:59:22 Richard: discusses use of shepherd to own the review.... 15:59:30 I like this "shepherd" idea too 15:59:37 ack me 15:59:37 olivier_, you wanted to ask about how to avoid looking like your reviews are "fire and forget" 15:59:38 #help 15:59:42 Addison: discusses linkage usage of tracker. 15:59:49 keiji has joined #privacy 15:59:51 This is Frank Dawson 16:00:12 Olivier: Likes it that they use tracker and integrate with whatever tracking other groups use. 16:00:39 Olivier: How do they make sure that issues they raise are not fire and forget (followed up on). 16:01:21 Addsion: engage in whatever process other group uses. Work within their parameters so issues don't die. Also track status so Int group can followup 16:01:56 for Olivier, tracking the tracker http://www.w3.org/International/track/products lists outstanding issues 16:01:59 Addison: Can be a challenge. They review tracker. Other groups like organized formal comments. During last call other groups must respond. 16:02:17 Addison: Int can withhold if they are not responded to. 16:02:38 ack christine 16:02:39 Richard: refers to tracking link and discusses shepherd monitoring it and prompting further action 16:03:01 dka has joined #privacy 16:03:01 Christine: thanks other reps for coming and sharing. 16:03:28 Christine: We have privacy experts, but not experts on reviews. 16:03:42 Richard: We know everything abut everything 16:04:03 Richard: Hard to find the proper people 16:04:29 Richard: Recruited a few people recently. Get them to review what is in their area of interest. 16:05:22 q/ 16:05:23 Present+ Dan Appelquist 16:05:24 Addison: Usually possible to do review. But better to get someone who has expertise. Use mailing list participants to help in review, particularly last call. Get someone with foot in both camps. Not as successful as they would like but works to some degree. 16:05:24 q? 16:05:41 http://lists.w3.org/Archives/Public/www-international/ 16:06:00 Richard: They have idea of what they are looking for. They then hone in on what they need. 16:06:28 Christine: Allows non-members to review, have public mailing list too. 16:07:07 Addison: Responding to request from others... 16:07:16 http://www.w3.org/International/wiki/Review_radar 16:07:43 seems like the kind of thing I've been talking about that I should maybe have set up, as we've been talking about it for Privacy 16:07:51 Richard: Issue fo colliding tracker numbers between groups. Use a group specific prefix on the item number 16:08:15 Richard: asks Christine to do Int reviews relative to privacy 16:08:41 Richard: During TPAc the group visits other groups. Tremendous positive impact on mission. 16:08:49 dka_ has joined #privacy 16:09:15 r12a mentioned common issues that come up, about time zones and the like. are those written down somewhere? 16:09:19 Christine: later today will talk about three docs to provide guidance to w3c community. 16:09:36 Christine: do you develop guidance for other groups? 16:09:53 Richard: describes and demonstrates examples 16:10:01 http://www.w3.org/International/ 16:10:16 http://www.w3.org/International/technique-index 16:10:29 Richard: how people find it? Demonstrates how Int does this. 16:10:32 http://www.w3.org/International/techniques/developing-specs-dynamic 16:10:47 nvdbleek has joined #privacy 16:10:50 Richard: shows heirarchical drill-down 16:11:10 Richard: show recommendation for do's and don'ts 16:11:47 Richard: guidance is both on paper and findable for people as they write specs. Documentation is not complete but has value. 16:11:52 this is cool. 16:12:01 Very nice! 16:12:23 Richard: Discusses interaction when reviews are not agreed to 16:12:47 Richard: discusses recruiting people from other groups to serve as liasons 16:13:11 q? 16:13:19 can be useful to have individuals planted in other Working Groups, who can be even more effective 16:13:26 Richard: offers to give further advice 16:13:43 Christine: welcome Int group to stay 16:13:47 thanks i18n folks, this is great. 16:14:58 Christine: we are ahead on agenda. Next item will be "Specification Privacy Assessment". Frank to cover his slides 16:15:17 Topic: Specification Privacy Assessment 16:15:36 Frank: Asks who attended W3C Privacy Workshop in Berkely ages ago 16:15:54 Frank: Bascially same presentation.... 16:16:40 Frank: Concerns him: gut feeling we might be building Takoma Narrows Bridge. Needed structural engineer to review ahead of time and weatherman to advise on winds. 16:17:05 Frank: Harmonic nodes in bridge caused it to be destroyed in high wind. 16:17:58 Frank: our role is to asses attack surfaces to privacy. Then through threat analysis define threats to privacy principles. Some issues may be related to implementation, not design. 16:18:24 aphllip has left #privacy 16:18:32 Frank: discusses ISO group and discipline of privacy engineering not being taught. It is a black art. 16:18:42 Frank: it is a combination of other disciplines 16:19:08 Frank: One area he worked on was PIA standard. One thing is the privacy impact statement 16:19:57 Frank: Take the methodology from PIA as a methodology: impact assessment, report. He is talking about it as a process. 16:20:41 Frank: anecdote about work he reused from one spec as an example of ad-hoc approach to privacy work 16:21:41 Frank: List of threats and controls. Need to approach threats by understanding protocols. W3C works on a variety of protocols, formatting specs,... What do we do? 16:22:08 Frank: Focuses on digital and information privacy 16:22:50 Frank: What would a PIA look like for specifications. In his ISO group they made this a standing document for reference 16:23:14 Frnak: Purpose is to take concepts of PIA and winnow down to those needed for writing specs 16:23:23 kodonog has joined #privacy 16:23:31 Frank: the outcome is what would go into specs 16:24:05 Frank: concept of light PIA. Litmus test to see if there is privacy impact before doing full assessment 16:24:34 Frank: Reviews 3 question flowchart for this.... [we are into his presentation now] 16:25:34 Frank: What is the data? Does it impact privacy (identifies individuals)? 16:26:10 Frank: discusses backtracking to identify an entity within an traffic stream 16:26:58 Frank: diagram misses the chartering step. Joe [?]. Chartering needs to go through the three steps flowchart for privacy impact 16:27:45 Frank: W3C approach is somewhat ad-hoc. Frank - we should first ask what is the spec about. You must understand this prior to threat assessment and attack surface analysis. 16:27:57 Joe Hall, CDT - suggested chartering step. 16:28:04 Frank: understand entries and exit to determine needed controls 16:28:48 Frank: look at flows and the attack surface. Then produce inventory of data and attack surface,...other factors.... 16:29:37 Frank: If storing data, one set of attacks and controls, another set if crossing national boundaries. In Russia, Brazil, Vietnam, need to consider localization requirements 16:29:57 Frank: we are now looking at controls. How do you put that into privacy considerations spec 16:30:22 q+ 16:30:25 Frank: the finding could be that there is no privacy impact. That summary should be in the spec. This should be standardized. 16:30:59 Frank: For device APIs, state no privacy consideration, but deployment (implementation) might have these considerations. 16:31:32 Frank: demonstrates example based on Media Streams spec.... 16:31:51 ack christine 16:32:48 Christine: PING - two documents - what is privacy and how to do it, second is specific guidance and recommenations relative to risks and mitigations. 16:33:25 Frank: Email identifies spec. Then set context. Then define what is being assessed. Does this as user stories. 16:33:34 Frank is talking about a practical review of GetUserMedia that he did 16:33:41 using SPA 16:33:57 Frank: next step look at privacy life style. Start with collection and assess impact and controls. 16:34:16 Life cycle? 16:34:18 s/style/cycle/ 16:34:43 Frank: Discusses example with video kiosk 16:35:16 Frank: Discusses mobile camera - impact on shutter sound. Korea regulates this! 16:36:31 Frank: next step, process/use of the data. Then looked at user stories. Same for transfer of data. Then look at data storage - fixing errors in the data. What process for maintenance. Then data destruction issues 16:36:52 Frank: ISO 15504 ref by ISO 31000 are standards for doing assessments 16:37:40 q+ 16:37:48 Frank: net is are there any residual risks and is that acceptable. If so, how to remediate. Reviews are to understand, spec team to figure out what to do. 16:37:52 action: doty to follow up with Frank Dawson and public-privacy on state of getUserMedia 16:37:52 Created ACTION-9 - Follow up with frank dawson and public-privacy on state of getusermedia [on Nick Doty - due 2014-11-07]. 16:38:06 Frank: Presentation has link to gitHub where it is at 16:38:59 Christine: Thanks Frank! 16:39:12 +1, thanks yrles 16:39:21 https://yrlesru.github.io/SPA/ 16:39:21 http://yrlesru.github.io/SPA/ 16:39:23 Christine: appreciates the example and how Frank used his process. 16:39:37 Christine: what group needs to look at how to progress the document 16:39:53 q+ to ask about flowchart 16:40:00 q+ to ask about shepherd vs privacy champ 16:40:03 Christine: keep the doc simple. Lightweight process to help adoption and usage. 16:40:14 q+ to ask about lifecycle stages 16:40:19 q- 16:40:22 q+ to ask about boilerplate 16:40:29 Frank: Hardest part is understanding the specification. What is missing in specs is what are the use cases. 16:40:42 Frank: needed for verification 16:41:00 Frank: IETF uses formal logic as the spec. 16:41:16 Frank: W3C uses prose. This is harder. 16:41:35 sometimes use tutorials to figure out how people are actually using the spec, to infer what it's for 16:41:44 Frank: about trying to discover the use cases. Inexact process. 16:42:00 Frank: important per ISO that scope is well defined. 16:42:38 Frank: mentions Frederick Hersch as someone who helped. 16:42:44 ack npdoty 16:42:44 npdoty, you wanted to ask about flowchart and to ask about shepherd vs privacy champ and to ask about lifecycle stages and to ask about boilerplate 16:42:47 Frank: suggest use of ad-hoc sessions. 16:43:13 Nick: followup on two things Frank said. 16:43:51 Nick: about prose versus formal language. interesting trend towards more formal language. Like psuedo-code 16:44:45 Nick: Finds this difficult. Has to compile the code on scratchpad. Prose is more understandable. Has to reverse engineer purpose. Curious about others views. 16:45:16 Nick: should we identify liasons in other groups or use someone from privacy. 16:45:22 Q+ 16:45:26 Frank: like INt trakcking mechanism 16:45:53 Frank: Shepherd is agnostic. Handles open ticket resolution. 16:46:13 Frank: people to have privacy as an avocation, not formal role 16:47:07 Jari has joined #privacy 16:47:29 Frank: evaluate whether there is need to formally address privacy in spec. People on team are needed (privacy champ) to interface to privacy group. Don't use term liaison as that is too formal. 16:47:41 Q+ 16:48:15 Nick: Likes the flowchart. Wonders if order can be reversed. Every doc needs privacy review as the norm, and is exception not to have one. 16:48:39 Nick: better to just be able to tell a group they need to have a review 16:49:14 Frank: Discusses example of publication review relative to needing privacy and security review.... 16:49:53 Frank: people down in reeds may not be aware of the need to address these factors 16:50:14 Frank: need for assessment of residual risk and surface 16:50:46 Frank: the start of formal assessment is the three questions in the initial assessment flowchart 16:50:58 ack melinda 16:51:25 Melinda: IETF security considerations don't work quite as anticipated. 16:51:49 Melinda: Security review is late in process and external review catches most of the problems. 16:52:03 Frank: Later the review occurs, the more costly. 16:52:23 q+ on security considerations section template 16:52:23 Melinda: At some point external review is required. Put into process. 16:53:21 Frank: Privacy engineering and assurance is now the process. Who is verifying it all. That is the assurance part. The IETF late stage processes are really the assurance processes. Talks through the process.... 16:54:01 Frank: It is tough to go back and put this in if it is detected at the end. 16:54:28 Nick: Discusses use of template.... Having template in IETF has positive impact? 16:55:01 Melinda: discusses how IETF uses template to assure security considerations are in spec from step one. 16:55:13 Melinda: despite this, quality may not be there. 16:55:30 Frank: discusses process could start at chartering stage. 16:55:43 via melinda, xml2rfc and the upload tool both require a security considerations section, such that even uploading an author's initial draft at least requires having a section 16:55:47 Melinda: this is part of initiation. It doesn't mean result will be good. 16:56:04 Jari speaking 16:56:47 Jari: asks questions to Tag (Dan Applequist) 16:57:42 Dan: part of function of TAG is to do design review of specs. In general they focus on API design and adherence to principles such as extensibility - how high level features exposed to javascript 16:58:05 Dan: part of function of TAG is to do design review of specs. In general they focus on API design and adherence to principles such as extensibility - how high level features exposed to javascriptaG 16:58:49 Dan: Interested in how Privacy and TAG can work together. TAG is not a privacy focused center of execllence. 16:59:15 Frank: Should we incorporate SPA into formal process. 16:59:50 Christine: defer this discussion to later. Perhaps at end of the day. 17:01:00 Christine: Frank looking for feedback and what we do with his proposed concept. If there are to be updates, move spec development back to chartering. What should people do at what time in spec development. More activity specificity. 17:01:11 action: doty to follow up with comments on Specification Privacy Assessment 17:01:11 Created ACTION-10 - Follow up with comments on specification privacy assessment [on Nick Doty - due 2014-11-07]. 17:01:24 Christine: next telephone conference - work out timeline and get willing volunteers 17:02:05 Andy: coffee break starts. 17:02:43 action-10: workflow chart (apply to every spec); notes to changes to the Process; PII and personal information; boilerplate text 17:02:43 Notes added to action-10 Follow up with comments on specification privacy assessment. 17:03:07 melinda has joined #privacy 17:15:05 dka has joined #privacy 17:17:09 For discussion: Private Browsing Modes drat from the TAG: http://w3ctag.github.io/private-mode/ 17:20:15 melinda has joined #privacy 17:21:23 Topic: Private Mode 17:21:35 Dan: about private browsing. Work of Mark Nottingham. He wanted TAG to do work on privacy. Mark is co-chair of IETF HTTP working group 17:22:08 Dan: there has been a lot of focus on privacy and protecting users from pervasive monitoring in his communities 17:22:21 colin has joined #privacy 17:23:12 Dan: One of the ways we could add value is focusing on private browsing modes. The TAG occupies space between browser community, W3C community. TAG has focus on cross-technologies / cross - bodies 17:24:19 Dan: Every browser has private mode. In addition to standard features, things like fingerprinting need to have consistency? 17:24:33 miterho has joined #privacy 17:24:46 q+ 17:24:48 present+miterho Mikko Terho Huawei 17:24:51 Dan: lead to more usage of private browsing. From a spec perspective, should private browsing have a spec? 17:25:07 Jari has joined #privacy 17:25:11 Dan: Could this be part of story of how other specs address privacy 17:26:01 Dan: TAG to focus on this one area rather than boiling the ocean. Mark just wrote initial draft. It is on gitHub. Wants others to engage and wants Privacy group to review it. 17:26:02 q? 17:26:41 ack ndoty 17:26:48 Nick: Is this public. 17:26:52 ack npdoty 17:26:52 npdoty, you wanted to comment on security considerations section template 17:26:59 ack jari 17:27:09 Dan: It is pbulic. Not blogging, but available on public website. It can be talked about. 17:27:50 https://github.com/w3ctag/private-mode 17:27:58 Ncik: Concerned about a few things. Concerned about informed consent. What should end up in privacy group? 17:28:07 bhill2 has joined #privacy 17:28:26 Dan: Privacy node is not meant to solve the privacy problem. Other specs need to address it. 17:28:50 Dan: feedback to MENE group is it should be addressed. 17:29:39 Dan: Telefonica rep concerns is that there is a stigma associated with private browsing - [assuming someone has something to hide] 17:30:21 Nick: what process does W3C have for controlling scope of private browsing 17:30:43 Dan: debate about tradeoffs of functionality versus private browsing 17:31:28 Dan: Feedback from general population is why isn't it eanbled all the time. Dan explains to them the loss of functionality... 17:32:03 Christine: What Nick said will be significant. 17:32:59 Christine: observes that private browsing mode is an ambiguous mode. Some are designed to protect users against other users of same device rather than protecting against sites monitoring activity. She has problem with terminology due to this. 17:33:16 Christine: Is it meant to be a minimum set? 17:33:50 Dan: this has to be the case [in his opinion}. Other browsers will go over and above relative to the spec and each other. 17:34:20 melinda_ has joined #privacy 17:34:36 Christine: The privacy group will be reviewing the document Mark authored. 17:34:50 Dan: Is sure Mark will want to be on review call 17:35:15 Topic: Fingerprinting Guidance 17:35:26 dka has joined #privacy 17:35:27 Christine: Nick now to talk about Fingerprinting Guidance Document 17:36:01 https://w3c.github.io/fingerprinting-guidance/ 17:36:34 Nick: there is quite a bit of work on how specs impact browser fingerprintiing. Document tells spec writers how to mitigate. 17:36:40 Jari has joined #privacy 17:36:50 Nick: asks how we should review the document.... 17:37:02 Nick: will go through the document.... 17:37:22 Nick: document starts by describing what browser fingerprinting is..... 17:38:01 Nick: people want to distinguish fingerprinting versus other means of tracking 17:38:25 Nick: discusses the privacy concerns of firngerprinting.... 17:39:09 Nick: There is often no indication of fingerprinting. Contrasted relative to explicit actions like logging in to an app 17:39:58 Nick: Describes types of fingerprinting. Passive is based on just monitoring traffic. 17:40:22 Nick: stable identifiers from the http header and the IP address are trackable. 17:40:25 dka_ has joined #privacy 17:41:05 Nick: Active fingerprinting based on the execution of the code indicates information about user's device, browser,.... Allows activity correlation. 17:41:15 http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-706.pdf 17:41:51 Changes in temperature can be remotely induced through CPU load and measured by their effects on crystal clock skew. Experiments show this to be an effective attack against Tor. This side channel may also be usable for geolocation and, as a covert channel, can cross supposedly infallible air-gap security boundaries." 17:42:01 <- mind blown 17:42:12 Nick: Discusses how this has been done.... Advance ones can look at performance-related stats giving information - like graphics performance indicating info about the machine. 17:43:07 Nick: Third one is the cookie approach. Might not be fingerprinting. Problem is that if these are not cleared simultaneously, they can be regenerated. 17:43:31 Nick: One mitigation is to decrease the number of fingerprintable features. 17:44:25 Nick: Second means is to incerase anonymity. Give example of use iPhone. It was so standardized it was hard to fingerprint. 17:45:28 Nick: Third is detecting fingerprinting. Might be impossible. The function calls and code in the browser could detect fingerprinting activity and let user know. 17:45:48 Sample research (cited in fingerprinting document): http://w2spconf.com/2012/papers/w2sp12-final4.pdf 17:45:51 jin has joined #privacy 17:46:34 q+ 17:46:38 More research: https://www.cosic.esat.kuleuven.be/fpdetective/ 17:46:41 Frank:Isn't there also a theorectical means of cluttering http traffic to defeat fingerprinting. This noise would camouflage the session. 17:47:06 Frank: If you understand the fingerprinting algorithms, you can confuse them by this means 17:47:17 q+ to mention use case of web midi 17:47:37 Nick: has heard proposals in this area. Brings up "dazzle camouflage" used by ships during WWII. 17:48:26 Frank: discusses randomization a variable versus nulling a variable. Thinks attackers would be able to spot randomized. 17:48:34 s/Frank/Nick/ 17:48:58 Frank: discusses messing with message IDs as a way to confuse tracking.... 17:49:07 q? 17:49:36 Frank: Camouflage turns things on its head. 17:50:16 Melinda: works well only in some cases. Describes examples of this. It becomes an arms race. In the browser it may not work as well as in other cases. 17:50:34 q+ 17:51:31 Olivier: Use case he has used, web media API. allows enumeration of media devices. Very good way to fingerprint! 17:51:57 ack olivier 17:51:57 olivier, you wanted to mention use case of web midi 17:52:32 Olivier: They know about the problem. Just found a response to the issue "the passive fingerprinting problem is hard to solve,..... other problems higher priority" [my interpretation of quote] 17:53:43 Nick: We are familiar with the problem. Comment on this being a lost cause. The point of specifying levels of success. Making it a lost cause is not goal. Different levels of success is important. 17:54:32 Nick: don't use the another feature is so back that we should ignore it as an argument for not doing anything. Don't do fingerpointing. 17:54:50 Nick: you might still conclude [you can't solve the problem] 17:55:19 s/other problems higher priority/other APIs are worse so why bother/ 17:55:38 Brad: we need to discuss threat actors. Consider the threat actors and the varying levels of success against them. 17:55:54 ack bhill 17:56:46 Brad: Discusses how adversaries will change tactics to address circumvent mitigations.... 17:57:00 s/address // 17:57:37 Nick: Discusses impact if someone thinks they are protected when not. 17:57:54 s/web media/web MIDI/g 17:58:39 Brad: discusses how mitigation impacts user and technical approaches for mitigation - javascript 17:59:29 Christine: a part of user community is concerned about browser fingerprinting - the disabled who have adaptive settings - this being fingerprinted. 18:00:12 Christine: Franks approach questioned - is skeptical - wants research relative to effectiveness of the approach. Gives example... 18:00:35 Frank: responds - creating a big psuedo group 18:00:52 Christine: is that enough change and randomness? 18:01:50 Nick: About fingerprinting. Their suggestion to the authors.... spec must not increase surface area unless no other options 18:02:08 Nick: same for active fingerprinting... 18:02:28 Q+ 18:02:38 Nick: advice to implementers about impact of spec on fingerprinting. 18:03:10 Nick: may be a way to create APIs to minimize fingerprinting. Reduce data to server... 18:03:14 q- 18:03:44 Nick: there is advice relative to cookies... specs need to describe local state and allow it to be cleared globally 18:04:16 ack bhill 18:04:17 Nick: discusses limitations related to do not track and provides links to research... 18:04:27 gludi has joined #privacy 18:04:51 Brad: Things that people think are useful is just a subset. There are many things that are not thought of. It is a very hard problem 18:05:20 Nick: There might be things to give to authors. Perhaps common problems. Gives example. 18:05:30 q+ 18:05:47 dka has joined #privacy 18:06:19 Nick: If you API will return a set of items, you should specify the order. This defeats fingerprinting based on how a particular browser does it. 18:06:45 q+ 18:06:47 Nick: discusses further fingerprintable data - build numbers 18:07:26 Nick: discusses documents written by UAs that discuss fingerprinting mitigations. 18:08:00 Nick: There is discussion of research into detecting fingerprinting sites. Academic efforts in this area. 18:08:04 q? 18:08:33 ack keiji 18:08:33 Keiji: Is doing fingerprinting research. 18:09:41 Keiji: Discusses randomization approach. There is a way to use consistent response in private mode to avoid fingerprinting. 18:10:32 Nick: Discusses use of things we should not try to hide. User agent string as an example. It is not likely to be improved. 18:11:01 Keiji: Maybe we should describe an anonymous browser. Explains further.... 18:11:24 q+ 18:11:29 Nick: this might not work because of browser specific processing. 18:12:09 Christine: Likes idea of giving examples of problems for browsers to the rest of the W3C community. 18:12:51 Christine: Ask ? for a model - here is an example of an anonymous browsing profile. 18:12:57 q- 18:13:07 q- 18:13:44 rrsagent, make minutes 18:13:44 I have made the request to generate http://www.w3.org/2014/10/31-privacy-minutes.html olivier 18:13:52 Keiji accepts this as an action 18:14:15 Christine: request next steps 18:14:51 Christine: Nick to do next rev. Get TAG to look at it. Put it on the agenda for the next call. 18:15:11 Christine: would like to publish this year though that is ambitious 18:15:34 Christine: next agenda item is privacy consideration for web specifications 18:15:55 Christine: this is supposed to be companion to doc Frank talked about. 18:16:06 https://w3c.github.io/privacy-considerations/ 18:16:17 Christine: is to give guidance to privacy consideration..... 18:17:01 Christine: has "had a play" with the document. Inspired by work DAC did and a document the TAG did but never published. 18:17:24 Christine: intent is to work through the document now if people are willing 18:17:52 Jari_ has joined #privacy 18:18:24 Nick: provides feedback that document is "not totally wrong" [approves of document] 18:18:44 Christine: tried to cut out terminology in the document. 18:18:57 Christine: pulling up document for review.... 18:24:21 Christine: collapsing Hannes's risk definitions to ones we seem to talk about (add more as we go along ... ) 18:25:20 Christine: introduce what's here now, come back and hack it after lunch 18:26:18 Nick: it's very hard to get an exhaustive list, but one thing I'm concerned about is for unauthorized disclosure - it's commong to say you need to add permission dialogue 18:26:28 Nick: I'm not crazy about that approach 18:26:53 Nick: users ignore permissions dialogue, where there are too many they ignore them, long list of issues 18:27:03 Nick: not sure how to reflect that in the risks. 18:27:23 Christine: I think we should add something specifically about that issue 18:27:46 Christine: then the idea was to start a guidelines section 18:28:02 Christine: you have to acknowledge that there might be privacy risks 18:28:06 i/Christine: next agenda item is privacy consideration/Topic: Privacy Considerations/ 18:28:19 q? 18:28:59 Christine: Hannes made the point that when making extensions to existing architectures some design decisions have already been made 18:29:20 I like saying "it is wise to consider earlier in the process" 18:29:42 Christine: trying to give some guidance - 2119 language for normative guidelines 18:30:02 Christine: every specification MUST include a section entitled "Privacy considerations" 18:30:05 q+ 18:30:07 q 18:30:09 q+ 18:30:19 q+ 18:30:41 Christine: suggested that functionality does not necessarily jhave priority over privacy 18:30:42 q+ on functionality v. privacy 18:30:57 q+ to mention QA framework versus testing effort 18:31:04 ack AndyF 18:31:10 q+ 18:31:16 JariA has joined #privacy 18:31:18 Andy: flesh out what "as early possible" is 18:31:40 ack melinda 18:31:55 that sounds similar to Frank's point about describing particular milestones 18:32:08 Melinda: One of the lessons from IETF security reqs - having there is good, executing is challenge. 18:32:28 Melinda: descriptively describe the process of how to do the process 18:32:38 Melinda: and do it well! 18:32:56 ack olivier 18:32:56 olivier, you wanted to mention QA framework versus testing effort 18:33:03 Christine: not claiming to be the author, juped on the grenade 18:33:25 Olivier: reminds me of an effort w3c was working on 10 years ago, "QA Framework" 18:33:52 Olivier: the beginning of the document is much more worthy of focus than making it into a normative document/requirements 18:34:11 Olivier: tools and education work better than long specs with normative criteria 18:34:43 Christine: the idea was to give some basic requirements to people who don't know how to approach privacy discussion 18:34:56 The process may be much more important than the documentation 18:34:58 ack npdoty 18:34:58 npdoty, you wanted to comment on functionality v. privacy 18:35:10 Nick: comment on functionality, but also want to talk about this 18:36:01 Nick: talked about formal process requirements vs. implementation in PING calls. Sounds like Olivier thinks we should focus on practical 18:36:19 (apologies - have to run - my comment was just editorial nits that RFC2119 language isn't probably appropriate for vague and unverifiable stuff like "as early as possible") 18:36:23 q- 18:36:25 Nick: if we're going to put normative requirements, it might be that we really mean what it means for a document to have a privacy considerations section 18:36:59 q+ 18:37:06 Nick: whatever comes out, if we're not pairing it with "how do you do it?" then 18:37:33 Nick: doesn't agree that functionality is in conflict with privacy 18:37:50 Nick: functionality requires transfer of information 18:37:54 q+ 18:38:07 Nick: I don't think we have to choose one over the other 18:39:22 ack AndyF 18:39:23 Christine: it was just my intention to change our approach and give people something to talk about 18:39:30 Andy: I appreciate a formalized approach 18:39:59 Andy: sees this as an opportunity to do some evangelism around privacy 18:40:18 Christine: have been inviting working groups to have meetings about privacy 18:40:57 agree, I think we've made quite some progress with DAP, Geolocation, Web Performance and other WGs 18:41:13 ack melinda 18:42:04 melinda: the action is good. We should discuss at some point the tradeoff between functionality and privacy. Need to analyze this. Code in browser can detect this. 18:42:05 q? 18:42:41 I think melinda's point there is that functionality or behavior always has privacy implications, because of code running in the browser 18:42:58 Christine: copied most of this from other docuemnts, tried to make it broader than might ahve been for an API 18:43:21 Christine: inspired by ideas from Hannes' document, and different types of mitigations 18:44:15 Nick: makes me think about Brad's comment. Using 2119 language, it's difficult for those terms to apply to suggestions that might be hard to test 18:44:29 me: that's a great point 18:45:04 I totally agree. 18:45:04 Nick: 2119 documents things that need to be tested for conformance claims 18:45:09 q+ 18:45:28 Christine: could do it as a checklist 18:45:43 ack AndyF 18:45:43 Nick: describe them as best practices, don't need to use 2119 language 18:46:14 might actually be a question about document formatting or language, checklist-style, to make it clear to someone reading that you need to cover those when you're talking about implementation 18:46:15 Andy: Might want to address access to the device interfaces that could be fingerprinted 18:46:40 q? 18:47:03 Christine: forget the way it looks - we might do it completely differently. These are just some ideas 18:47:17 Christine: next section is about data confidentiality 18:47:27 Christine: it's pretty general 18:48:13 Christine: then there was this idea to help with the privacy problem by making it easier for users to know what's going on 18:48:37 Christine: give some guidance to help specification authors communicate to users what's going on 18:48:54 Christine: "I want this data because < ... > 18:49:05 Christine: preferences, permissions, consent, and control 18:50:00 Nick: is it useful to explain why? Would it be useful for someone who's reading to know why some mechanisms should be specified? 18:51:14 Melinda: IETF has a wiki related to voluntary privacy reviews 18:52:13 Melinda: There was a Spring workshop. Addressing privacy was in waves [within the IETF] 18:52:27 s/Spring/STRINT 18:53:17 "W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)" 18:54:23 Karen: to put a slightly more positive spin on the IETF output is that there was a working group chair training session on security 18:54:33 s/security/privacy 18:54:51 Christine:section on identifiers 18:55:31 Olivier: what kinds of identifiers are you talking about? 18:56:05 Christine: in talking with other working groups, identifiers comes up a lot. Not necessarily obvious identifiers 18:56:39 Andy: example: design pattern called a "plane ticket", put in some identifier 18:57:13 q+ 18:59:09 ack melinda 18:59:45 kodonog has joined #privacy 18:59:46 melinda: different use of "identifiers". users and identity, but also just the identifiers needed for stateless protocols 18:59:54 Christine: this is a big topic - my thinking was identifiers in a broad sense 19:00:25 Karen: pre-provisioned keys spun off into a separate specification, Mark Watson is the editor 19:00:37 Karen: it's not one of the new charter items 19:00:41 http://www.w3.org/TR/2013/WD-webcrypto-key-discovery-20130108/ 19:01:01 Christine: we should give some guidance about correlation - need more than the text that's there 19:01:12 Andy: is that actually doable? 19:01:26 Christine: we may not be able to solve all correlation problems, but we could do less 19:01:52 JariA has joined #privacy 19:02:07 Christine: one of the mitigations against correlations in the w3c is same origin policies 19:02:42 Nick: we would need to elaborate on the scope 19:02:54 Andy: people need to understand how this can occur 19:03:02 sorry... here is a better reference for the key discovery work https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html 19:03:03 Tara: do not track falls under correlation 19:03:28 Christine: section which borrows from Nick's document on fingerprinting 19:03:53 Christine: probably are other sections which should be added 19:04:17 JariA has joined #privacy 19:04:17 Andy: do you have any concern about creating policy about users' acceptable use that policy? 19:04:28 Christine: goes back to permissions 19:05:02 Andy: can the user globally specify policy once and the sites act on it 19:05:33 Christine: write that up 19:05:48 Andy: would totally change the interaction between the user and the browser, would need an API 19:06:09 Christine: there might be pieces that would be doable 19:07:35 Christine: over lunch, think about what could be done (next steps) 19:07:48 Nick: while we're all in one place, editing together could be good 19:10:10 Olivier: how would it look if you took all the points in the document and follow the same structure of problem and mitigation that Nick's fingerpriting document uses 19:10:30 http://www.w3.org/2011/07/privacy-ig-charter.html 19:10:37 Charter discussion ... 19:10:55 linked from http://www.w3.org/Privacy/ 19:11:10 Topic: Charter discussion 19:11:50 q+ 19:12:13 q- 19:12:41 Wendy: as an interest group the process is less heavyweight than for a working group 19:13:02 Wendy: we still have a charter that defines the scope of the work. End date could be extended 19:13:14 Wendy: if scope is changed, need to go out to the Advisory Group 19:13:45 Wendy: possible considerations could be if the charter says anything more specific about interactions with other groups, etc. 19:14:15 Olivier: my question was similar. Don't see anything in the current charter about reviews. Sounds like something that should be in there. 19:14:29 Olivier: other question is pedestrian: why are you extending one year at a time? 19:15:19 Christine: the kind of reviews we've been doing falls under "and advice." Putting it in the charter obliges us to do it. 19:15:38 Christine: struggling to find the volunteers to do the reviews in a timely fashion 19:16:01 Christine: we'd need to decide what the impact is of a privacy review by this group 19:16:17 q+ 19:16:18 Jari: there is language in the current charter that says we may engage. 19:17:17 Olivier: putting my AC hat on, if one of my staff comes to me and asks to participate, I don't see that their time is goimg to be spent on reviews, and that's a problem 19:17:45 Olivier: it doesn't matter where that's documented, but it needs to be somewhere 19:18:13 Wendy: another function of review by the AC is that if we get AC buy-in, that's another source of pressure on working groups to makes those reviews effective 19:18:30 Wendy: it sounds reasonable to charter it for multiple years 19:19:03 Christine: question - what's the usual practice with rotating chairs? 19:19:32 JariA has joined #privacy 19:19:34 Wendy: if chairs are doing a good job (and you both are) we're very happy to continue your leadership 19:19:52 Olivier: you don't have to wait for a rechartering to hand over chairmanship 19:20:22 Nick: rechartering will include current chairs but it's not a precommitment of 24 months 19:20:23 q- 19:20:56 Tara: not sure at what point it's reasonable to update deliverables 19:21:15 Christine: other than points Olivier made, don't see a need to update scope 19:21:30 Wendy: may want to liaison with TAG 19:22:29 Christine: in terms of external group liaisons, IEEE 802 19:22:47 Christine: we should do all of the editing for this before the 1st of December 19:22:52 Nick: we will do this 19:23:21 Nick: minor changes regarding dependencies, and scope regarding reviews 19:23:32 Nick: don't know if that would trigger AC review 19:23:44 JariA has joined #privacy 19:24:19 Keiji: virtually all groups may be affected 19:24:29 Tara: so why call out these ones? 19:25:09 Nick: even if we do call out these groups, we should try to interact with all - the groups listed in the charter are not restrictive 19:25:20 Wendy: the liaison in the other direction is more important 19:26:08 Christine: we should discuss writing security and privacy guidance together 19:27:18 http://www.w3.org/2014/privacyws/ 19:27:24 http://www.w3.org/2014/privacyws/participation.html 19:29:05 Tara: one hour for lunch 19:29:39 back at 1:30, to talk about privacy/security; next steps from breakout sessions; group-editing of the privacy considerations document 19:29:50 rrsagent, please draft the minutes 19:29:50 I have made the request to generate http://www.w3.org/2014/10/31-privacy-minutes.html npdoty 19:30:04 melinda has joined #privacy 19:30:30 chair: christine, tara 19:30:45 i/Topic: Internationalization/scribenick: AndyF/ 19:31:32 i/Christine: collapsing/scribenick: melinda/ 19:31:35 rrsagent, please draft the minutes 19:31:35 I have made the request to generate http://www.w3.org/2014/10/31-privacy-minutes.html npdoty 19:51:55 JariA has joined #privacy 20:03:12 melinda has joined #privacy 20:23:56 fjh has joined #privacy 20:27:38 melinda has joined #privacy 20:28:00 colin has joined #privacy 20:28:21 nvdbleek has joined #privacy 20:29:26 fjh has joined #privacy 20:31:34 jin has joined #privacy 20:32:57 AndyF has joined #privacy 20:33:07 keiji has joined #privacy 20:36:21 fjh has joined #privacy 20:38:11 npdoty has joined #privacy 20:38:27 christine has joined #privacy 20:38:38 melinda has left #privacy 20:38:43 melinda has joined #privacy 20:38:56 kodonog has joined #privacy 20:39:39 privacy & security combination; plenary day breakout groups 20:39:48 Christine: Discussion about merging security and privacy review 20:40:25 Tara: points are relevant from breakouts 20:40:38 Tara: is there something we should be paying attention to? 20:41:36 Nick: There was a trust and permissions breakout 20:41:39 Ryladog has joined #privacy 20:41:40 tara has joined #privacy 20:42:10 fjh_ has joined #privacy 20:42:10 Nick: The idea of permission models has been coming up across many W3C specifications 20:42:32 Nick: devices, geolocation, others 20:43:10 Nick: Dave Ragaatt (DSR) had a workshop in Paris in Sept. where this was discussed. Came up with some models for permissions 20:43:41 Nick: Things like trusted UI, ask for forgiveness, old-fashioned prompt 20:44:12 Nick: example of trusted UI would include things like a file picker 20:44:47 Nick: something you don't have to ask for permission, you have to ask for permission. Example would include full-screen API 20:45:24 Nick: the browser will put up a notice with a mechanism to revoke permission 20:45:57 Nick: example of asking permission would be geolocation APIs which prompt user for permission 20:46:40 Christine: the only other things would be that for prompts, permission-at-use is better because there's context 20:46:52 Christine: coarse-grained permissions are more easily understood by users 20:47:10 Nick: most website are using JIT permissions 20:47:47 Nick: persistent vs. one-time permissions is another distinction 20:48:10 q+ 20:48:38 q- 20:48:48 Nick: hopes that Dave Ragatt might provide a write-up. Also, this might be a write-up for the permissions section of Christine's document 20:49:09 Nick: session on secure origins and pervasive monitoring 20:49:37 Nick: response to pervasive monitoring as an attack RFC 20:50:22 Nick: access to devices and information should be limited to secure origins 20:50:26 agree with Nick to do write-up for the permissions section of the document 20:51:06 Nick: for example, websites where transport is not secure (say, not sent over TLS) would not be allowed access to devices 20:51:41 Nick: discussion was surprisingly civil 20:52:01 Nick: agreement that this was more about integrity than about confidentiality 20:52:50 Nick: more of the work there is going to be headed towards implementation and adoption questions 20:54:37 melinda has joined #privacy 20:55:14 Nick: subresource integrity has been dropped (or postponed) 20:57:31 melinda_ has joined #privacy 20:58:02 q+ 20:58:36 Nick: most promising thing here is we should really recommend that user agents not give users ability to persist permissions 20:59:54 Nick: already accepted in get media streams (?) 21:00:41 Nick: TAG wants to make some general architectural decision about this (secure origins) 21:01:05 q- 21:01:29 Nick: third breakout of interest was on privacy and openness 21:01:57 Nick: this was kind of a wide-ranging discussion 21:02:24 Christine: from our perspective the purpose was to start to socialize thinking on privacy guidance to a broader w3c community 21:02:51 Christine: and to get their ideas. The other part of the breakout session was how to reconcile privacy with the brroader model 21:03:10 Tara: structured around activities we're doing with PING 21:03:59 Tara: a lot of points were being brought up that didn't fit neatly into a framework 21:04:02 ask to Nick re secure origins breakout session - write up threat model re persistent permissions and possible solution (used in Media Streams?) for privacy guidance 21:04:41 Jeff H: has Alissa's privacy considerations RFC been brought up? Not sure you'd need any translation 21:05:38 Tara: TAG wants to have more interactions on things like private browsing modes 21:06:33 Christine: saw that as an input to the discussion today 21:07:35 Christine: the next thing we're doing this afternoon is working on the privacy guidance document 21:08:43 JeffH has joined #privacy 21:08:54 this is the current status of the Privacy Considerations document via Hannes: https://w3c.github.io/privacy-considerations/ 21:09:13 http://www.rfc-editor.org/rfc/rfc6973.txt 21:10:44 yep, that's the one 21:11:55 Christine: catching up people who weren't here this morning 21:12:31 gludi_ has joined #privacy 21:12:42 npdoty: ah ok thx 21:12:50 ptr to the doc on the screen? 21:13:07 Christine: ignore what's identified as normative or informative 21:13:34 Christine: section "Understanding privacy risks" -- looking for ideas 21:13:35 ? 21:13:39 q? 21:16:40 Christine: maybe it's not better to have the understanding privacy risks section, but combine it with guidance 21:17:22 Christine: maybe we should start with guidance and figure out what's missing around that 21:17:52 Christine: don't worry about 2119-style language 21:18:10 Christine: should we be making a recommendation that privacy considerations be mandatory? 21:18:45 Christine: just having a section is not sufficient - should we also describe what a good one looks like? 21:19:07 npdoty: gotcha 21:19:40 Nick: our goal is not just to have privacy consideration sections into documents, but the larger impact is when encourage author to make technical design decisions to support privacy 21:20:06 Christine: in the guidance we should provide design guidance 21:20:35 Christine: for example, data minimization - what does that mean in the w3c world? 21:21:10 ?: are we chartered to come up with a normative spec? 21:21:37 Christine: in my mind we publish it as a group note, and it's up to a director or the TAG to decide that it's something that should be followed 21:21:38 s/?:/katiehs:/ 21:21:43 Thanks! 21:21:50 (That was Katie's question.) 21:22:29 but this won't be a Recommendation-track document (to answer the charter / process question) 21:22:57 Andy: it's not that 2119 language should be excluded but that it's too early to specify it 21:23:43 Katie: community will want 2119 normative language 21:24:01 Christine: trying to find out what the community expectations are 21:24:43 it could be like a standard W3C document but using the "Best Practices" format, which is another not-so-uncommon style 21:25:39 Christine: presumably our discussions with the TAG and with Wendy will help resolve this 21:25:59 Christine: this is not set in stone, so what is it that we want to say about data minimization? 21:27:05 Nick: one important thing to keep in mind is that if the audience is specification, should be clarity about things like specifications and APIs not storing data 21:27:18 Katie: "enable" for probably all those 21:28:16 Nick: intent was not to criticize, but in framing requirements think about how we can encourage developers to follow a principle like data minimization 21:28:39 Christine: we can either clean up language now or someone can take it as a work item to fix it 21:28:48 I don't think we need to clean up the actual words right now, fwiw 21:30:02 Katie: in your larger front matter you'd have more explanation, but in the requirements only one sentence 21:31:09 Nick: things like how a web server stores data is not a w3c matter 21:31:17 s/server/browser/ 21:32:15 Katie: if that's an important aspect we should keep it, as a matter of future-proofness 21:32:27 I like the idea of future-proofing, but I also want to give the most relevant information to our authors for right now 21:33:05 Nick: is there a user participation section? 21:35:35 common terminology: should be consistent about information vs data 21:35:50 ... specifications vs. standards vs web protocols 21:37:19 ... and are we referring to APIs or features 21:38:02 Nick: even if "features" is right, it's not that features are requesting, but rather developers and implementers 21:39:18 my take: Specifications should be written in such a way that features make it easy for developers and implementers to request as little data as is required for the functionality. 21:40:03 Christine: "use" vs. "functionality" 21:40:36 scribenick: npdoty 21:41:21 keiji: if it's about data, it might not necessarily be about privacy, if for example it's not about personal data 21:43:05 christine: would rather not distinguish so that authors don't have to have a nuanced sense of what data is sensitive or not 21:43:09 npdoty: +1 21:44:50 npdoty: could be a distinction between minimization for UA implementers and site users (JavaScript developers, say) and what they minimize 21:46:02 katie: data rather than information. enable rather than make it easy? 21:46:10 npdoty: want to encourage, more than just make possible 21:47:50 keiji: "request" implies a subject and object. could we say "utilize" instead? 21:49:10 maybe need wordsmithing on "request" or "request from" 21:49:41 updated npdoty take: Specifications should be written in such a way that features make it easy for developers and implementers to request from the user as little data as is required for the functionality. 21:51:51 npdoty: we could note different engineering benefits (performance, extensibility, etc.) for data minimization as a general principle 21:53:18 christine: "designed in such a way that it can be deployed so that ..." 21:56:35 fjh has joined #privacy 21:58:14 christine: summarizing, data minimization recommendations at the collection point, one for how sites request and one how users can choose 21:58:29 ... but should it be relevant for other parts of the data lifecycle? 21:59:19 npdoty: should talk about security properties of both confidentiality and integrity 22:00:02 fjh has joined #privacy 22:00:02 will there be a companion from the web security side? 22:00:10 there's interest there, but not clear when/whether that will happen 22:02:22 npdoty: trend towards no new cleartext 22:02:28 keiji: what about storage? 22:02:49 melinda: should maybe refer to "protect" because we might talk about cryptographic protections that aren't encryption 22:02:57 ... like hashing and the like to protect against replay attacks 22:04:46 npdoty: focusing on communication (rather than storage), might be useful to encrypt/protect all data 22:05:18 ... but would often appropriately rely on transport layer 22:05:52 melinda: TLS is often used just to get origin authentication 22:10:53 melinda: different reasons for securing data 22:11:04 christine: could have a different call about data confidentiality 22:12:05 Topic: Next Steps 22:12:19 christine: concerns about whether a small task force (with people with limited time) is the best approach 22:12:30 ... could set aside time on our next call about recommendations 22:12:45 katie: should we talk over this on a call? 22:12:54 christine: not put online just yet, too rough still 22:13:19 karen: in order to discuss on a call, would need a draft of a document to read over 22:13:40 christine: suggesting that we could have a call where we talk about general recommendations 22:14:14 lots of agreement that most specifications start extremely rough, even though we know we don't want them to turn out that way 22:14:23 JeffH: Google Docs for real-time collaboration 22:15:03 any other business? 22:15:36 thanks to our attendees and co-chairs 22:16:31 tara: if our attendees aren't already part of the Privacy Interest Group, please feel welcome on the mailing list or our teleconferences 22:16:42 tara: getting a lot of useful feedback from people we haven't seen before 22:16:53 ... will be summarizing a lot of this, including from the related breakout sessions 22:17:07 ... and some of you will see me (or others) on other Working Groups 22:18:09 q? 22:18:23 npdoty: monthly teleconferences, often get participation from WG chairs/editors, which is great 22:18:28 thanks all 22:18:36 [adjourned] 22:18:40 rrsagent, please draft the minutes 22:18:40 I have made the request to generate http://www.w3.org/2014/10/31-privacy-minutes.html npdoty 00:27:03 fjh has joined #privacy 00:39:14 Zakim has left #privacy 00:52:39 fjh has joined #privacy 00:55:45 fjh_ has joined #privacy 00:57:45 nvdbleek has joined #privacy 02:51:46 nvdbleek has joined #privacy 03:18:13 fjh has joined #privacy 06:58:30 npdoty has joined #privacy 10:57:15 fjh has joined #privacy 11:32:32 nvdbleek has joined #privacy 12:43:12 fjh has joined #privacy 13:50:52 nvdbleek has joined #privacy 14:37:09 fjh has joined #privacy 15:21:45 nvdbleek has joined #privacy 15:22:02 fjh has joined #privacy 16:04:03 nvdbleek has joined #privacy