Privacy Interest Group Teleconference -- 31 Oct 2014

<trackbot> Date: 31 October 2014

<npdoty> Meeting: Privacy Interest Group f2f

Agenda overview

<npdoty> scribenick: npdoty

runnegar: overview of the agenda

http://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0005.html

runnegar: visitors from i18n to start. start with Specification Privacy Assessment

npdoty: could talk about results from the breakout sessions

Introductions

<christine> Christine Runnegar, PING co-chair

<tara> Tara Whalen, Google, PING co-chair

Nick Doty, npdoty, W3C

<olivier> Olivier Thereaux, BBC

<AndyF> introduction [way to many names to remember]

<inserted> scribenick: AndyF

Internationalization

<christine> Agenda item 2: Visits from other IGs and WGs

Richard - here to look for overlaps

<r12a> http://www.w3.org/International/track/products

<aphllip> visitors from I18N are: Addison Phillips, Richard Ishida, Dennis Tan, and Leandro Reis

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.
... uses it to track specs for other working groups. Has group look at such a list...
... A product is a grouping

<r12a> http://www.w3.org/International/track/products/2

Richard: discusses items in list they have reviewed (Internationalization Working Group)
... Goes into details of a review in tracker...

<r12a> http://www.w3.org/International/reviews/review-instructions

Richard: how doest the tracker data get used. Has URL to steps they take....
... steps through the document that describes the steps. Advises going through the document
... Asks Privacy group how they can help

Tara: In response to Richard - Privacy has done some reviews. Using a manual process of passing document around, email, phone calls, informal process

<r12a> example of what addison's saying: http://www.w3.org/International/track/issues/316

Addison: Tracker will track the emails and collect discussions. Also references IRC logs. Ties things together and keeps you up with status
... You can even link into specs.

Tara: Does this work for all size reviews

Addison: confirms. Works well when doing a lot of reviews versus the archive being unmanageable
... Some groups use Bugzilla. They can link to it.

Richard: They can handle the mess of entangled comments and responses much better with Tracker. Keep emails to one issue as a way to support this.

<Zakim> npdoty, you wanted to ask about whether these issues are by individual or by the whole group

Nick: ask about issue by issue tracking. What is the process?

<r12a> for Nick http://www.w3.org/International/reviews/review-instructions

Addison: get multiple people to read a spec. Enter comments one at a time. If time, working group will review issue by issue.
... Group keeps track of all the issues. Issues can be redrawn. Someone reads it, makes comments, trackerizes it, and then group discusses.

<aphllip> https://www.w3.org/International/wiki/Review_radar

Richard: they put comments in, group then reviews it, before sending to group owning spec.
... discusses use of shepherd to own the review....

<npdoty_> I like this "shepherd" idea too

<Zakim> olivier_, you wanted to ask about how to avoid looking like your reviews are "fire and forget"

<yrles> #help

Addison: discusses linkage usage of tracker.

<yrles> This is Frank Dawson

Olivier: Likes it that they use tracker and integrate with whatever tracking other groups use.
... How do they make sure that issues they raise are not fire and forget (followed up on).

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

<r12a> for Olivier, tracking the tracker http://www.w3.org/International/track/products lists outstanding issues

Addison: Can be a challenge. They review tracker. Other groups like organized formal comments. During last call other groups must respond.
... Int can withhold if they are not responded to.

Richard: refers to tracking link and discusses shepherd monitoring it and prompting further action

Christine: thanks other reps for coming and sharing.
... We have privacy experts, but not experts on reviews.

Richard: We know everything abut everything
... Hard to find the proper people
... Recruited a few people recently. Get them to review what is in their area of interest.

<christine> q/

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.

<aphllip> http://lists.w3.org/Archives/Public/www-international/

Richard: They have idea of what they are looking for. They then hone in on what they need.

Christine: Allows non-members to review, have public mailing list too.

Addison: Responding to request from others...

<npdoty> http://www.w3.org/International/wiki/Review_radar

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

Richard: Issue fo colliding tracker numbers between groups. Use a group specific prefix on the item number
... asks Christine to do Int reviews relative to privacy
... During TPAc the group visits other groups. Tremendous positive impact on mission.

<npdoty> r12a mentioned common issues that come up, about time zones and the like. are those written down somewhere?

Christine: later today will talk about three docs to provide guidance to w3c community.
... do you develop guidance for other groups?

Richard: describes and demonstrates examples

<r12a> http://www.w3.org/International/

<r12a> http://www.w3.org/International/technique-index

Richard: how people find it? Demonstrates how Int does this.

<r12a> http://www.w3.org/International/techniques/developing-specs-dynamic

Richard: shows heirarchical drill-down
... show recommendation for do's and don'ts
... guidance is both on paper and findable for people as they write specs. Documentation is not complete but has value.

<npdoty> this is cool.

<tara> Very nice!

Richard: Discusses interaction when reviews are not agreed to
... discusses recruiting people from other groups to serve as liasons

<npdoty> can be useful to have individuals planted in other Working Groups, who can be even more effective

Richard: offers to give further advice

Christine: welcome Int group to stay

<npdoty> thanks i18n folks, this is great.

Christine: we are ahead on agenda. Next item will be "Specification Privacy Assessment". Frank to cover his slides

Specification Privacy Assessment

Frank: Asks who attended W3C Privacy Workshop in Berkely ages ago
... Bascially same presentation....
... 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.
... Harmonic nodes in bridge caused it to be destroyed in high wind.
... 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.
... discusses ISO group and discipline of privacy engineering not being taught. It is a black art.
... it is a combination of other disciplines
... One area he worked on was PIA standard. One thing is the privacy impact statement
... Take the methodology from PIA as a methodology: impact assessment, report. He is talking about it as a process.
... anecdote about work he reused from one spec as an example of ad-hoc approach to privacy work
... 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?
... Focuses on digital and information privacy
... What would a PIA look like for specifications. In his ISO group they made this a standing document for reference

Frnak: Purpose is to take concepts of PIA and winnow down to those needed for writing specs

Frank: the outcome is what would go into specs
... concept of light PIA. Litmus test to see if there is privacy impact before doing full assessment
... Reviews 3 question flowchart for this.... [we are into his presentation now]
... What is the data? Does it impact privacy (identifies individuals)?
... discusses backtracking to identify an entity within an traffic stream
... diagram misses the chartering step. Joe [?]. Chartering needs to go through the three steps flowchart for privacy impact
... 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.

<tara> Joe Hall, CDT - suggested chartering step.

Frank: understand entries and exit to determine needed controls
... look at flows and the attack surface. Then produce inventory of data and attack surface,...other factors....
... If storing data, one set of attacks and controls, another set if crossing national boundaries. In Russia, Brazil, Vietnam, need to consider localization requirements
... we are now looking at controls. How do you put that into privacy considerations spec
... the finding could be that there is no privacy impact. That summary should be in the spec. This should be standardized.
... For device APIs, state no privacy consideration, but deployment (implementation) might have these considerations.
... demonstrates example based on Media Streams spec....

Christine: PING - two documents - what is privacy and how to do it, second is specific guidance and recommenations relative to risks and mitigations.

Frank: Email identifies spec. Then set context. Then define what is being assessed. Does this as user stories.

<christine> Frank is talking about a practical review of GetUserMedia that he did

<christine> using SPA

Frank: next step look at privacy life cycle. Start with collection and assess impact and controls.

<melinda> Life cycle?

Frank: Discusses example with video kiosk
... Discusses mobile camera - impact on shutter sound. Korea regulates this!
... 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
... ISO 15504 ref by ISO 31000 are standards for doing assessments
... 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.

<npdoty> ACTION: doty to follow up with Frank Dawson and public-privacy on state of getUserMedia [recorded in http://www.w3.org/2014/10/31-privacy-minutes.html#action01]

<trackbot> Created ACTION-9 - Follow up with frank dawson and public-privacy on state of getusermedia [on Nick Doty - due 2014-11-07].

Frank: Presentation has link to gitHub where it is at

Christine: Thanks Frank!

<npdoty> +1, thanks yrles

<yrles> https://yrlesru.github.io/SPA/

<tara> http://yrlesru.github.io/SPA/

Christine: appreciates the example and how Frank used his process.
... what group needs to look at how to progress the document
... keep the doc simple. Lightweight process to help adoption and usage.

Frank: Hardest part is understanding the specification. What is missing in specs is what are the use cases.
... needed for verification
... IETF uses formal logic as the spec.
... W3C uses prose. This is harder.

<npdoty> sometimes use tutorials to figure out how people are actually using the spec, to infer what it's for

Frank: about trying to discover the use cases. Inexact process.
... important per ISO that scope is well defined.
... mentions Frederick Hersch as someone who helped.

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

Frank: suggest use of ad-hoc sessions.

Nick: followup on two things Frank said.
... about prose versus formal language. interesting trend towards more formal language. Like psuedo-code
... Finds this difficult. Has to compile the code on scratchpad. Prose is more understandable. Has to reverse engineer purpose. Curious about others views.
... should we identify liasons in other groups or use someone from privacy.

Frank: like INt trakcking mechanism
... Shepherd is agnostic. Handles open ticket resolution.
... people to have privacy as an avocation, not formal role
... 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.

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.
... better to just be able to tell a group they need to have a review

Frank: Discusses example of publication review relative to needing privacy and security review....
... people down in reeds may not be aware of the need to address these factors
... need for assessment of residual risk and surface
... the start of formal assessment is the three questions in the initial assessment flowchart

Melinda: IETF security considerations don't work quite as anticipated.
... Security review is late in process and external review catches most of the problems.

Frank: Later the review occurs, the more costly.

Melinda: At some point external review is required. Put into process.

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....
... It is tough to go back and put this in if it is detected at the end.

Nick: Discusses use of template.... Having template in IETF has positive impact?

Melinda: discusses how IETF uses template to assure security considerations are in spec from step one.
... despite this, quality may not be there.

Frank: discusses process could start at chartering stage.

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

Melinda: this is part of initiation. It doesn't mean result will be good.

<tara> Jari speaking

Jari: asks questions to Tag (Dan Applequist)

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
... 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
... Interested in how Privacy and TAG can work together. TAG is not a privacy focused center of execllence.

Frank: Should we incorporate SPA into formal process.

Christine: defer this discussion to later. Perhaps at end of the day.
... 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.

<npdoty> ACTION: doty to follow up with comments on Specification Privacy Assessment [recorded in http://www.w3.org/2014/10/31-privacy-minutes.html#action02]

<trackbot> Created ACTION-10 - Follow up with comments on specification privacy assessment [on Nick Doty - due 2014-11-07].

Christine: next telephone conference - work out timeline and get willing volunteers

Andy: coffee break starts.

<npdoty> action-10: workflow chart (apply to every spec); notes to changes to the Process; PII and personal information; boilerplate text

<trackbot> Notes added to action-10 Follow up with comments on specification privacy assessment.

<dka> For discussion: Private Browsing Modes drat from the TAG: http://w3ctag.github.io/private-mode/

Private Mode

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
... there has been a lot of focus on privacy and protecting users from pervasive monitoring in his communities
... 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
... Every browser has private mode. In addition to standard features, things like fingerprinting need to have consistency?
... lead to more usage of private browsing. From a spec perspective, should private browsing have a spec?
... Could this be part of story of how other specs address privacy
... 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.

Nick: Is this public.

<Zakim> npdoty, you wanted to comment on security considerations section template

Dan: It is pbulic. Not blogging, but available on public website. It can be talked about.

<tara> https://github.com/w3ctag/private-mode

Ncik: Concerned about a few things. Concerned about informed consent. What should end up in privacy group?

Dan: Privacy node is not meant to solve the privacy problem. Other specs need to address it.
... feedback to MENE group is it should be addressed.
... Telefonica rep concerns is that there is a stigma associated with private browsing - [assuming someone has something to hide]

Nick: what process does W3C have for controlling scope of private browsing

Dan: debate about tradeoffs of functionality versus private browsing
... Feedback from general population is why isn't it eanbled all the time. Dan explains to them the loss of functionality...

Christine: What Nick said will be significant.
... 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.
... Is it meant to be a minimum set?

Dan: this has to be the case [in his opinion}. Other browsers will go over and above relative to the spec and each other.

Christine: The privacy group will be reviewing the document Mark authored.

Dan: Is sure Mark will want to be on review call

Fingerprinting Guidance

Christine: Nick now to talk about Fingerprinting Guidance Document

<tara> https://w3c.github.io/fingerprinting-guidance/

Nick: there is quite a bit of work on how specs impact browser fingerprintiing. Document tells spec writers how to mitigate.
... asks how we should review the document....
... will go through the document....
... document starts by describing what browser fingerprinting is.....
... people want to distinguish fingerprinting versus other means of tracking
... discusses the privacy concerns of firngerprinting....
... There is often no indication of fingerprinting. Contrasted relative to explicit actions like logging in to an app
... Describes types of fingerprinting. Passive is based on just monitoring traffic.
... stable identifiers from the http header and the IP address are trackable.
... Active fingerprinting based on the execution of the code indicates information about user's device, browser,.... Allows activity correlation.

<bhill2> http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-706.pdf

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

<bhill2> <- mind blown

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.
... Third one is the cookie approach. Might not be fingerprinting. Problem is that if these are not cleared simultaneously, they can be regenerated.
... One mitigation is to decrease the number of fingerprintable features.
... Second means is to incerase anonymity. Give example of use iPhone. It was so standardized it was hard to fingerprint.
... Third is detecting fingerprinting. Might be impossible. The function calls and code in the browser could detect fingerprinting activity and let user know.

<tara> Sample research (cited in fingerprinting document): http://w2spconf.com/2012/papers/w2sp12-final4.pdf

<tara> More research: https://www.cosic.esat.kuleuven.be/fpdetective/

Frank: Isn't there also a theorectical means of cluttering http traffic to defeat fingerprinting. This noise would camouflage the session.
... If you understand the fingerprinting algorithms, you can confuse them by this means

Nick: has heard proposals in this area. Brings up "dazzle camouflage" used by ships during WWII.
... discusses randomization a variable versus nulling a variable. Thinks attackers would be able to spot randomized.

Frank: discusses messing with message IDs as a way to confuse tracking....
... Camouflage turns things on its head.

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.

Olivier: Use case he has used, web MIDI API. allows enumeration of media devices. Very good way to fingerprint!

<Zakim> olivier, you wanted to mention use case of web midi

Olivier: They know about the problem. Just found a response to the issue "the passive fingerprinting problem is hard to solve,..... other APIs are worse so why bother" [my interpretation of quote]

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.
... 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.
... you might still conclude [you can't solve the problem]

Brad: we need to discuss threat actors. Consider the threat actors and the varying levels of success against them.
... Discusses how adversaries will change tactics to circumvent mitigations....

Nick: Discusses impact if someone thinks they are protected when not.

Brad: discusses how mitigation impacts user and technical approaches for mitigation - javascript

Christine: a part of user community is concerned about browser fingerprinting - the disabled who have adaptive settings - this being fingerprinted.
... Franks approach questioned - is skeptical - wants research relative to effectiveness of the approach. Gives example...

Frank: responds - creating a big psuedo group

Christine: is that enough change and randomness?

Nick: About fingerprinting. Their suggestion to the authors.... spec must not increase surface area unless no other options
... same for active fingerprinting...
... advice to implementers about impact of spec on fingerprinting.
... may be a way to create APIs to minimize fingerprinting. Reduce data to server...
... there is advice relative to cookies... specs need to describe local state and allow it to be cleared globally
... discusses limitations related to do not track and provides links to research...

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

Nick: There might be things to give to authors. Perhaps common problems. Gives example.
... 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.
... discusses further fingerprintable data - build numbers
... discusses documents written by UAs that discuss fingerprinting mitigations.
... There is discussion of research into detecting fingerprinting sites. Academic efforts in this area.

Keiji: Is doing fingerprinting research.
... Discusses randomization approach. There is a way to use consistent response in private mode to avoid fingerprinting.

Nick: Discusses use of things we should not try to hide. User agent string as an example. It is not likely to be improved.

Keiji: Maybe we should describe an anonymous browser. Explains further....

Nick: this might not work because of browser specific processing.

Christine: Likes idea of giving examples of problems for browsers to the rest of the W3C community.
... Ask ? for a model - here is an example of an anonymous browsing profile.

Keiji accepts this as an action

Christine: request next steps
... Nick to do next rev. Get TAG to look at it. Put it on the agenda for the next call.
... would like to publish this year though that is ambitious

Privacy Considerations

Christine: next agenda item is privacy consideration for web specifications
... this is supposed to be companion to doc Frank talked about.

<tara> https://w3c.github.io/privacy-considerations/

Christine: is to give guidance to privacy consideration.....
... has "had a play" with the document. Inspired by work DAC did and a document the TAG did but never published.
... intent is to work through the document now if people are willing

Nick: provides feedback that document is "not totally wrong" [approves of document]

Christine: tried to cut out terminology in the document.
... pulling up document for review....

<inserted> scribenick: melinda

Christine: collapsing Hannes's risk definitions to ones we seem to talk about (add more as we go along ... )
... introduce what's here now, come back and hack it after lunch

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
... I'm not crazy about that approach
... users ignore permissions dialogue, where there are too many they ignore them, long list of issues
... not sure how to reflect that in the risks.

Christine: I think we should add something specifically about that issue
... then the idea was to start a guidelines section
... you have to acknowledge that there might be privacy risks
... Hannes made the point that when making extensions to existing architectures some design decisions have already been made

<npdoty> I like saying "it is wise to consider earlier in the process"

Christine: trying to give some guidance - 2119 language for normative guidelines
... every specification MUST include a section entitled "Privacy considerations"

Christine: suggested that functionality does not necessarily jhave priority over privacy

Andy: flesh out what "as early possible" is

<npdoty> that sounds similar to Frank's point about describing particular milestones

<AndyF> Melinda: One of the lessons from IETF security reqs - having there is good, executing is challenge.

<AndyF> Melinda: descriptively describe the process of how to do the process

<AndyF> Melinda: and do it well!

<Zakim> olivier, you wanted to mention QA framework versus testing effort

Christine: not claiming to be the author, juped on the grenade

Olivier: reminds me of an effort w3c was working on 10 years ago, "QA Framework"
... the beginning of the document is much more worthy of focus than making it into a normative document/requirements
... tools and education work better than long specs with normative criteria

Christine: the idea was to give some basic requirements to people who don't know how to approach privacy discussion

<AndyF> The process may be much more important than the documentation

<Zakim> npdoty, you wanted to comment on functionality v. privacy

Nick: comment on functionality, but also want to talk about this
... talked about formal process requirements vs. implementation in PING calls. Sounds like Olivier thinks we should focus on practical

<bhill2> (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")

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
... whatever comes out, if we're not pairing it with "how do you do it?" then
... doesn't agree that functionality is in conflict with privacy
... functionality requires transfer of information
... I don't think we have to choose one over the other

Christine: it was just my intention to change our approach and give people something to talk about

Andy: I appreciate a formalized approach
... sees this as an opportunity to do some evangelism around privacy

Christine: have been inviting working groups to have meetings about privacy

<npdoty> agree, I think we've made quite some progress with DAP, Geolocation, Web Performance and other WGs

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

<npdoty> I think melinda's point there is that functionality or behavior always has privacy implications, because of code running in the browser

Christine: copied most of this from other docuemnts, tried to make it broader than might ahve been for an API
... inspired by ideas from Hannes' document, and different types of mitigations

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

me: that's a great point

<tara> I totally agree.

Nick: 2119 documents things that need to be tested for conformance claims

Christine: could do it as a checklist

Nick: describe them as best practices, don't need to use 2119 language

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

Andy: Might want to address access to the device interfaces that could be fingerprinted

Christine: forget the way it looks - we might do it completely differently. These are just some ideas
... next section is about data confidentiality
... it's pretty general
... then there was this idea to help with the privacy problem by making it easier for users to know what's going on
... give some guidance to help specification authors communicate to users what's going on
... "I want this data because < ... >
... preferences, permissions, consent, and control

Nick: is it useful to explain why? Would it be useful for someone who's reading to know why some mechanisms should be specified?

<AndyF> Melinda: IETF has a wiki related to voluntary privacy reviews

<AndyF> Melinda: There was a STRINT workshop. Addressing privacy was in waves [within the IETF]

<tara> "W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)"

Karen: to put a slightly more positive spin on the IETF output is that there was a working group chair training session on privacy

Christine: section on identifiers

Olivier: what kinds of identifiers are you talking about?

Christine: in talking with other working groups, identifiers comes up a lot. Not necessarily obvious identifiers

Andy: example: design pattern called a "plane ticket", put in some identifier

<npdoty> melinda: different use of "identifiers". users and identity, but also just the identifiers needed for stateless protocols

Christine: this is a big topic - my thinking was identifiers in a broad sense

Karen: pre-provisioned keys spun off into a separate specification, Mark Watson is the editor
... it's not one of the new charter items

<kodonog> http://www.w3.org/TR/2013/WD-webcrypto-key-discovery-20130108/

Christine: we should give some guidance about correlation - need more than the text that's there

Andy: is that actually doable?

Christine: we may not be able to solve all correlation problems, but we could do less
... one of the mitigations against correlations in the w3c is same origin policies

Nick: we would need to elaborate on the scope

Andy: people need to understand how this can occur

<kodonog> sorry... here is a better reference for the key discovery work https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html

Tara: do not track falls under correlation

Christine: section which borrows from Nick's document on fingerprinting
... probably are other sections which should be added

Andy: do you have any concern about creating policy about users' acceptable use that policy?

Christine: goes back to permissions

Andy: can the user globally specify policy once and the sites act on it

Christine: write that up

Andy: would totally change the interaction between the user and the browser, would need an API

Christine: there might be pieces that would be doable
... over lunch, think about what could be done (next steps)

Nick: while we're all in one place, editing together could be good

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

<npdoty> http://www.w3.org/2011/07/privacy-ig-charter.html

Charter discussion ...

<npdoty> linked from http://www.w3.org/Privacy/

Charter discussion

Wendy: as an interest group the process is less heavyweight than for a working group
... we still have a charter that defines the scope of the work. End date could be extended
... if scope is changed, need to go out to the Advisory Group
... possible considerations could be if the charter says anything more specific about interactions with other groups, etc.

Olivier: my question was similar. Don't see anything in the current charter about reviews. Sounds like something that should be in there.
... other question is pedestrian: why are you extending one year at a time?

Christine: the kind of reviews we've been doing falls under "and advice." Putting it in the charter obliges us to do it.
... struggling to find the volunteers to do the reviews in a timely fashion
... we'd need to decide what the impact is of a privacy review by this group

Jari: there is language in the current charter that says we may engage.

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
... it doesn't matter where that's documented, but it needs to be somewhere

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
... it sounds reasonable to charter it for multiple years

Christine: question - what's the usual practice with rotating chairs?

Wendy: if chairs are doing a good job (and you both are) we're very happy to continue your leadership

Olivier: you don't have to wait for a rechartering to hand over chairmanship

Nick: rechartering will include current chairs but it's not a precommitment of 24 months

Tara: not sure at what point it's reasonable to update deliverables

Christine: other than points Olivier made, don't see a need to update scope

Wendy: may want to liaison with TAG

Christine: in terms of external group liaisons, IEEE 802
... we should do all of the editing for this before the 1st of December

Nick: we will do this
... minor changes regarding dependencies, and scope regarding reviews
... don't know if that would trigger AC review

Keiji: virtually all groups may be affected

Tara: so why call out these ones?

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

Wendy: the liaison in the other direction is more important

Christine: we should discuss writing security and privacy guidance together

<npdoty> http://www.w3.org/2014/privacyws/

<wseltzer> http://www.w3.org/2014/privacyws/participation.html

Tara: one hour for lunch

<npdoty> back at 1:30, to talk about privacy/security; next steps from breakout sessions; group-editing of the privacy considerations document

<npdoty> privacy & security combination; plenary day breakout groups

Christine: Discussion about merging security and privacy review

Tara: points are relevant from breakouts
... is there something we should be paying attention to?

Nick: There was a trust and permissions breakout
... The idea of permission models has been coming up across many W3C specifications
... devices, geolocation, others
... Dave Ragaatt (DSR) had a workshop in Paris in Sept. where this was discussed. Came up with some models for permissions
... Things like trusted UI, ask for forgiveness, old-fashioned prompt
... example of trusted UI would include things like a file picker
... something you don't have to ask for permission, you have to ask for permission. Example would include full-screen API
... the browser will put up a notice with a mechanism to revoke permission
... example of asking permission would be geolocation APIs which prompt user for permission

Christine: the only other things would be that for prompts, permission-at-use is better because there's context
... coarse-grained permissions are more easily understood by users

Nick: most website are using JIT permissions
... persistent vs. one-time permissions is another distinction
... hopes that Dave Ragatt might provide a write-up. Also, this might be a write-up for the permissions section of Christine's document
... session on secure origins and pervasive monitoring
... response to pervasive monitoring as an attack RFC
... access to devices and information should be limited to secure origins

<christine> agree with Nick to do write-up for the permissions section of the document

Nick: for example, websites where transport is not secure (say, not sent over TLS) would not be allowed access to devices
... discussion was surprisingly civil
... agreement that this was more about integrity than about confidentiality
... more of the work there is going to be headed towards implementation and adoption questions
... subresource integrity has been dropped (or postponed)

<melinda_> Nick: most promising thing here is we should really recommend that user agents not give users ability to persist permissions

<melinda_> Nick: already accepted in get media streams (?)

<melinda_> Nick: TAG wants to make some general architectural decision about this (secure origins)

<melinda_> Nick: third breakout of interest was on privacy and openness

<melinda_> Nick: this was kind of a wide-ranging discussion

<melinda_> Christine: from our perspective the purpose was to start to socialize thinking on privacy guidance to a broader w3c community

<melinda_> Christine: and to get their ideas. The other part of the breakout session was how to reconcile privacy with the brroader model

<melinda_> Tara: structured around activities we're doing with PING

<melinda_> Tara: a lot of points were being brought up that didn't fit neatly into a framework

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

<melinda_> Jeff H: has Alissa's privacy considerations RFC been brought up? Not sure you'd need any translation

<melinda_> Tara: TAG wants to have more interactions on things like private browsing modes

Christine: saw that as an input to the discussion today
... the next thing we're doing this afternoon is working on the privacy guidance document

<npdoty> this is the current status of the Privacy Considerations document via Hannes: https://w3c.github.io/privacy-considerations/

<npdoty> http://www.rfc-editor.org/rfc/rfc6973.txt

<JeffH> yep, that's the one

Christine: catching up people who weren't here this morning

<JeffH> npdoty: ah ok thx

<JeffH> ptr to the doc on the screen?

Christine: ignore what's identified as normative or informative
... section "Understanding privacy risks" -- looking for ideas

<tara> ?

Christine: maybe it's not better to have the understanding privacy risks section, but combine it with guidance
... maybe we should start with guidance and figure out what's missing around that
... don't worry about 2119-style language
... should we be making a recommendation that privacy considerations be mandatory?
... just having a section is not sufficient - should we also describe what a good one looks like?

<JeffH> npdoty: gotcha

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

Christine: in the guidance we should provide design guidance
... for example, data minimization - what does that mean in the w3c world?

katiehs: are we chartered to come up with a normative spec?

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

Thanks!

<tara> (That was Katie's question.)

<npdoty> but this won't be a Recommendation-track document (to answer the charter / process question)

Andy: it's not that 2119 language should be excluded but that it's too early to specify it

Katie: community will want 2119 normative language

Christine: trying to find out what the community expectations are

<npdoty> it could be like a standard W3C document but using the "Best Practices" format, which is another not-so-uncommon style

Christine: presumably our discussions with the TAG and with Wendy will help resolve this
... this is not set in stone, so what is it that we want to say about data minimization?

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

Katie: "enable" for probably all those

Nick: intent was not to criticize, but in framing requirements think about how we can encourage developers to follow a principle like data minimization

Christine: we can either clean up language now or someone can take it as a work item to fix it

<npdoty> I don't think we need to clean up the actual words right now, fwiw

Katie: in your larger front matter you'd have more explanation, but in the requirements only one sentence

Nick: things like how a web browser stores data is not a w3c matter

Katie: if that's an important aspect we should keep it, as a matter of future-proofness

<npdoty> I like the idea of future-proofing, but I also want to give the most relevant information to our authors for right now

Nick: is there a user participation section?

<npdoty> common terminology: should be consistent about information vs data

<npdoty> ... specifications vs. standards vs web protocols

<npdoty> ... and are we referring to APIs or features

Nick: even if "features" is right, it's not that features are requesting, but rather developers and implementers

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

Christine: "use" vs. "functionality"

<npdoty> scribenick: npdoty

keiji: if it's about data, it might not necessarily be about privacy, if for example it's not about personal data

christine: would rather not distinguish so that authors don't have to have a nuanced sense of what data is sensitive or not

npdoty: +1
... could be a distinction between minimization for UA implementers and site users (JavaScript developers, say) and what they minimize

katie: data rather than information. enable rather than make it easy?

npdoty: want to encourage, more than just make possible

keiji: "request" implies a subject and object. could we say "utilize" instead?

maybe need wordsmithing on "request" or "request from"

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.

npdoty: we could note different engineering benefits (performance, extensibility, etc.) for data minimization as a general principle

christine: "designed in such a way that it can be deployed so that ..."
... summarizing, data minimization recommendations at the collection point, one for how sites request and one how users can choose
... but should it be relevant for other parts of the data lifecycle?

npdoty: should talk about security properties of both confidentiality and integrity

will there be a companion from the web security side?

there's interest there, but not clear when/whether that will happen

npdoty: trend towards no new cleartext

keiji: what about storage?

melinda: should maybe refer to "protect" because we might talk about cryptographic protections that aren't encryption
... like hashing and the like to protect against replay attacks

npdoty: focusing on communication (rather than storage), might be useful to encrypt/protect all data
... but would often appropriately rely on transport layer

melinda: TLS is often used just to get origin authentication
... different reasons for securing data

christine: could have a different call about data confidentiality

Next Steps

christine: concerns about whether a small task force (with people with limited time) is the best approach
... could set aside time on our next call about recommendations

katie: should we talk over this on a call?

christine: not put online just yet, too rough still

karen: in order to discuss on a call, would need a draft of a document to read over

christine: suggesting that we could have a call where we talk about general recommendations

lots of agreement that most specifications start extremely rough, even though we know we don't want them to turn out that way

JeffH: Google Docs for real-time collaboration

any other business?

thanks to our attendees and co-chairs

tara: if our attendees aren't already part of the Privacy Interest Group, please feel welcome on the mailing list or our teleconferences
... getting a lot of useful feedback from people we haven't seen before
... will be summarizing a lot of this, including from the related breakout sessions
... and some of you will see me (or others) on other Working Groups

npdoty: monthly teleconferences, often get participation from WG chairs/editors, which is great

thanks all

[adjourned]

- DRAFT -

Privacy Interest Group Teleconference

31 Oct 2014

Attendees

Contents