PING meeting at TPAC2016 -- 20 Sep 2016

<tara_> FYI, I am at the Chairs' Breakfast, finishing at 8:30 and will be at the PING room shortly.

<tara_> For locals in Lisbon: room is 1.13

<tara_> We are getting the WebEx set up - bear with us!

<tara_> That did not seem to be working, sorry!

<tara_> Can you hear me at all?

<npdoty> is someone there taking minutes?

<JoeHallCDT> happy to scribe

<JoeHallCDT> npdoty: UC Berkeley I School

<JoeHallCDT> keiji: W3M contact for PING

<JoeHallCDT> Martha: from blockstream, chair of blockchain wg

<JoeHallCDT> barry leiba

<JoeHallCDT> David Singer

<JoeHallCDT> Mike O'Niell

<JoeHallCDT> mattias schunter

<Karima> I'm Karima Boudaoud from University of Nice Sophia Antipolis. Interests: User-centric Security and Privacy Management

<JoeHallCDT> moving on to first agenda item on fingerprinting guidance

<schunter> Is there a URL for the document?

<npdoty> http://w3c.github.io/fingerprinting-guidance/

<marta> Marta Piekarska, Blockstream. Security Architect & Standards, AC Rep.

<marta> ...co-chair of Blockchain CG

<JoeHallCDT> this is a guidance document, intended to be a group note

<JoeHallCDT> the idea would be to have specification authors (and implementors) read this and be able to incorporate the ideas here into their work

<JoeHallCDT> will go over the motivation and structure of the document

<JoeHallCDT> growing concern about inference and leakage based on configuration settings or other aspects of the browser

<JoeHallCDT> allows for tracking and ident. in ways that are not expected

<JoeHallCDT> e.g., you can clear cookies in your device, but there are no (or few) controls for fingerprinting

<keiji> scribe: JoeHallCDT

has a number of privacy impacts described in Section 1.2

some feel that this whole area is a bit of a lost cause

however, we do illustrate how to mitigate the privacy risks here

<keiji> : RRSagent, make minutes

we can make it difficult or at least observable so that the user can figure out when fingerprinting is going on

there is a list of 9 best practices currently in the document

section 4 on feasibility

describes various levels of success in terms of mitigations

rest of the document focuses on the mitigations, using examples as we have them

questions?

about the purpose or structure of the document

<npdoty> https://github.com/w3c/fingerprinting-guidance/issues

moving on to open issues

feedback from the TAG and from the PING list

many are currently marked "pending review"

please check those and we can try to close those out

https://github.com/w3c/fingerprinting-guidance/issues/13

<npdoty> https://github.com/w3c/fingerprinting-guidance/issues/13

<npdoty> https://github.com/w3c/fingerprinting-guidance/issues/11

ok, we are back!

<npdoty> yay technology!

11 is about providing hooks for instrumentation

make it easier for browser extensions to list the things a website is doing

it's very cumbersome process to do this kind of detection… essentially have to write your own browser

npdoty gets the impression that there is not a whole lot we can do about this in the document

<npdoty> Implementers can facilitate detectability by providing or enabling instrumentation so that users or third parties are able to calculate when fingerprinting surface is being accessed. Of particular importance for instrumentation are: access to all the different sources of fingerprinting surface; identification of the originating script; avoiding exposure that instrumentation is taking place. Beyond the minimization practice described above, these are[CUT]

<npdoty> implementation-specific (rather than Web specification) features.

dsinger asks: "wonders how I can tell when e.g. a site asks about my fonts, whether it truly cares about fonts or is ‘just’ fingerprinting me?"

npdoty: there are gross kinds of distinctions
... e.g., if a site is enumerating all fonts, not good

another big issue is actionability (issue 13)

scribe: how do we make the document more actionable… through an explicit decision tree, for example
... even with best practices in the document, how does a team figure out what they should do when?
... what we've done is asked people to attempt to use the document in their work
... that feedback is very useful
... one thing we might do is identify fingerprinting surface
... which would be helpful to figure out when a spec is increasing fingerprinting surface
... data sources that could increase fingerprinting… add a new header? look at mitigation number 1 (this is just an example)
... very unclear how to make it more actionable
... very much would like the feedback from others as to how could this document be made useful
... thoughts?

<schunter> What is the incentive for (non privacy) chairs to care about fingerprinting?

<npdoty> JoeHallCDT: we asked people to look at the privacy questionnaire for the specifications they're working on, did we do that with fingerprinting doc?

<moneill2> in best practice 8 could add that apis should be available for extensions to deal with identifiers, There are APIs to deal with cookies if identifiers are origin specific then ther should be ways to make them visible to extensions(SO THEY CAN BE MADE MORE VISIBLE AND ACTIONABLE BY USERS)

npdoty: we have had occasional people that have referenced the document
... we could ask explicitly more

christine: what are the incentives for non-privacy folks to care about fingerprinting?
... the answer is partly: we can't make all w3c specs fingerprinting proof
... but we can try to not make them worse by increasing fingerprinting surface

<schunter> Thanks!

christine: do you really need to add this thing that increases surface? and at what level of granularity do you need it?

<moneill2> How about a team of white hat fingerprinting exploiters to look at new APIs to see how they can be exploited by bad guys

<npdoty> I think the most direct incentive for any given team is: you don't want to deal much later on in the process with privacy/security teams restricting implementation of your feature because it has this substantial privacy cost

christine: detectability is an important element, especially for keeping web actors accountable (through DPA, etc. enforcement)
... asks npdoty: would you like help in terms of creating a decision tree?

mschunter: thinks the privacy questionaire is a good place to tie in the actionability

<schunter> I said: Good job!

<schunter> Great job, actually...

npdoty: we've talked a number of times about whether or not these should be two documents or one
... but this sounds like a great idea

<schunter> Example question: Does your working group define or change the user agent behavior in any way? (no -> no fingerprinting impact?).

npdoty: happy to have those questions in the questionaire or vice-versa
... would love some help. npdoty is not in the best position to do this as he's not as close to spec authors
... so think about this this week

dsinger: split section 2?
... fuzzing data to make less identifiable and vanilla response for a feature are great

npdoty: we actually prefer the "vanilla" style

<Zakim> dsinger, you wanted to ask about vanilla and fuzz

<npdoty> http://w3c.github.io/fingerprinting-guidance/#a_standardized_profile

dsinger: we should say explicitly "you must define the vanilla response for your feature"
... should we be documenting what is vanilla for older specifications?
... vanilla response = first sentence in 6.2 now: "Specifications can mitigate against fingerprintability through standardization; by defining a consistent behavior, conformant implementations won't have variations that can be used for browser fingerprinting. "

npdoty: e.g., ordering of fonts

dsinger: we could even specify what is the "lie" a browser would have to give (e.g., fake list of fonts)
... maybe here we could actually try and document what the vanilla response should be for existing specs?

npdoty: hmmm, what would the form of a vanilla response take?

dsinger: maybe just say "you should define a vanilla response"

<npdoty> dsinger, if we had a specific example of that, of what it would look for a certain spec, that would be helpful

mike: some things may not be fuzzable

mkwest: you were talking early about hooks into the browser that would allow you detect

<Zakim> mkwst, you wanted to suggest looking into WebDriver as an automation mechanism.

mkwest: might want to look into the WebDriver specification
... allows more control than what you would have in a normal browser
... you could get events back that might be useful for this
... should also talk to those folks about requirements for this kind of use case
... APIs that you have via WebDriver are going to be more powerful than via the web

npdoty: when researchers test these things, they are trying to instrument such that a headless browser gets some stuff

mkwest: I think we're on the same page… it's a bit like a debugging interface

<schunter> https://www.w3.org/TR/2013/WD-webdriver-20130117/

mattias: Web Driver won't allow you to do automatic discovery

<npdoty> npdoty to follow up with Princeton, FPDetective folks on whether WebDriver would be a useful area for them to look re instrumentation

<schunter> Mike: You can script web-driver and (if you got the script right) then it will collect sufficient information to determine whether a site tried to fingerprint you.

mike: origin-policy API, where the site can send down an arbitrary string (like cookies), could be a good place to think about fingerprinting analysis

<schunter> (= my assumption that Webdriver cannot be scripted seemed to be wrong ;-)

mkwest: cookies are not fingerprinting… very explicit tracking, under user control. much less dangerous (not dangerous) to users
... canvas, on the other hand, is more of the fingerprinting in terms of lack of discoverability

<npdoty> +1 that I'm less concerned about cookies

mkwest: more concerned about things that are outside of the user control

<npdoty> and the main things we recommend in this is just that you should treat it exactly like cookies, like clearing it at the same time

(discussion about clearing site data and media stream ID)

mkwest: >10% of users clearing cookies on a weekly basis
... ff has a "forget this site", Chrome is going to have it soon
... we can certainly look at applying this document to any and all of WebAppSec specs

<npdoty> we include "cookie-like fingerprinting" in this document largely for the "evercookie" risk identified in the past

<schunter> 3 levels of data:

mattias: the explicitness of a data source is important… cookies, super explicit. other things like media streams ID, not explicity.

<schunter> 1. Cookies (explicit, visible, deletable)

<schunter> 2. Web-site data that is stored in a user agent and that can be erased (by clearing web-site data)

<schunter> 3. Any user agent data / characteristics/ data that cannot be erased (this is the surface for fingerprinting).

<Zakim> npdoty, you wanted to comment on permanent

mkwest: it's unlikely no document will pose zero problems, but "this is like cookies" would be a good place to end

npdoty: there are things that are like cookies in terms of explicit, and there are others

<npdoty> http://w3c.github.io/fingerprinting-guidance/#clearing-all-local-state

npdoty: we are coming across functionality where we might need permanent or persistent identifiers
... and in the document ^^^ we say we should have no permanent or persistent identifiers

mkwest: alas, many groups want to do the exact opposite of this
... look at WebAuth and the smartcard keying stuff

<wseltzer> [Hardware-Based Secure Services: https://rawgit.com/w3c/websec/gh-pages/hbss.html ]

mkwest: those are much more persistent notions of identifiers
... agree with the sentiment, but that there are important use cases for more persistence
... orgin-locking, etc. can be recommended here

mike: origin locking is not as helpful as discoverability

<npdoty> the paragraph I currently have mentions origin-locking, user permission and user clearing, but I guess I'm asking whether this is the place to include that advice, or how amenable people would be to it

mkwest: origin locking is the foundation (doesn't make much sense to have discoverable but not locked)

npdoty: on scheduling, it would be useful to close out the things that are marked pending-review
... and get some feedback/interaction from other groups
... goal is to get this document in a note by the end of the year

tara_: thanks for joining us in Lisboa!

<npdoty> goodnight!

PING privacy questionnaire

christine: let's talk privacy questionnaire

<keiji> https://github.com/w3c/ping/blob/master/privacy-questions.html

<tara_> Privacy Questionnaire: http://htmlpreview.github.io/?https://github.com/w3c/ping/blob/master/privacy-questions.html

christine: core piece of work is to produce an annotated privacy questionnaire
... the origin of this is mkwest's TAG-adopted security questionnaire
... the idea is to have a set of questions that spec authors can work through and minimize privacy implications of their specs
... many thanks to greg norcie and CDT for curating this
... let's use the hour to walk through the document, see where it stands, and set up some homework assignments
... work on refining the questions and calibrate the level of detail for the addendum
... questions?

kepeng: we have some differing formats across questions
... 2 starts with an explanation
... we need to make the structure of each question consistent
... also 13 isn't as detailed as 11 and 12

christine: what you see before you is very much still a draft
... we have bascially put all the current thinking here in this place
... when we clean up the document, we definitely want good consistency!
... there are some WG members who need details, and there are others that just want the questions
... why is this an issue? what are ways of mitigating this issue? can we make something more detectable?
... this is very much a draft, need to work on together as a group to get in a better state

<schunter> Is there an URL for this questionaire?

christine: need to make sure that we keep this moving
... goal would be to have a working draft by the end of the year
... I don't think in our privacy guidance we should attempt to define privacy
... perhaps do it more like what IETF did… explain issues in terms that spec authors/imps can understand

<tara_> Original Security & Privacy questionnaire: https://www.w3.org/TR/security-privacy-questionnaire/

kepeng: what is the difference between this and that TAG one?

joehallcdt: we can't remember

mkwest: the TAG document has either too much detail or not enough detail
... either the questions are too detailed to give a high-level overview or not
... preference here would be to have a high-level document that points to more detailed guidance
... would love to trim down the TAG document
... we could merge the two to make a super document
... but that would make it less likely that anyone would use it
... maybe make the TAG document smaller and this one longer

kepeng: what is the security equivalent of the privacy questionairre?

mkwest: there isn't something that detailed

dsinger: why do you think two documents are useful?

mkwest: it could be different sections of the same document
... the PING document is more of a deep-dive, and we could use that for security

christine: thanks to mkwest for getting the TAG document out there
... we can ultimately decide what to do with the document
... would be good to walk through the document. What's missing? homework on existing items?

dsinger: "what do you need to think about to write the privacy considerations section of your spec?"

mkwest: there is a balance between covering everything and being usable
... from internal uses at Google, an expando-type document works well (expando: deeper heirarchy can be exposed from a high-level document)
... is important to have as much detail as possble
... practically, people get sad when they see a 30-page document

tara_: practical question: likes the expando
... or will we end up with a tiny questionairre and a very long one

<dsinger> I would like to see the meta-question added “are there privacy aspects of your specification that the preceding questions did not pull out?”

ok back!

dsinger: questions 2, 7, 8 (?) clearly need work

mattias: what do we think the process is to produce a w3c spec that has a good privacy considerations section?
... when do we want to see specs do what?
... our goal is to have specs in w3c to have good privacy considerations sections

barryleiba1: this might be difficult, what kind of guidance can we give them? Think about it as soon as possible?

dsinger: we maybe should be looking for FPWD that do not have privacy considerations
... we should explicitly say FPWD is the point in time for this
... perhaps the document could capture some of this meta conversation?
... e.g., why do you need to think about privacy considerations earlier?

<JoeHallCDT1> mkwest: the TAG document tries to go in that direction… maybe doesn't do a great job

dsinger: questions 2, 3, 7 all sound very similar, need to fix that
... and add "are there questions about your spec that we didn't ask that we should have?"

<wseltzer> [break: return at 11 Lisbon]

<keiji> : RRSagent, make minutes

<tara> We seem to have the network and WebEx back, for those who got cut off...

<tara> Okay, let's get going again...

<tara> Here is a pile of notes from my offline scribbles

<tara> Context - begins from the discussion of the Privacy & Security Questionnaire

<tara> JoeHall: those of us with security expertise could try to make a draft questionnaire Would likely not be good but would provide something to correct

<tara> Joe volunteers to do this

<tara> Kepeng also volunteers

<tara> Marta: maybe we could try some kind of flowchart model

<tara> David Singer: Q 2,3, and 7 need work

<tara> Matthias: having a checklist of questions is helpful to avoid overlooking anything

<tara> David Singer: do we expect to see Priv Considerations at some stage of the doc? Do we give people the short questionnaire for CR, or at earlier step? -- good for this group to lay out a process for this -- e.g. "can you do a CR transition if this section is not filled out"?

<tara> BarryL - going to vary depending on the context as to what would work best

<tara> DaveS: much better to do it earlier in the process -- first public working draft might be a better stage (not checkbox for last step in the process)

<tara> MikeW: experience in practice has shown that doing security & privacy late in the process has been a mistake so this was my motivation for making the original questionnaire MW: it would be nice if there were requirements to do Priv Considerations MW: first public working draft -- has "human review"; might be a good place to already have Privacy Considerations section in place, or start the discussion MW: use ReSpec or BikeShed -- will warn if you don't have se[CUT]

<tara> WendyS: we have Ralph Swick whose function is to coordinate those reviews. We can give him guidance on this process. We could recommend that this be included in first public working draft.

<tara> BarryL - IAB has discussed this. Security Considerations is required -- it's a placeholder, not always populated. IAB did not mandate Privacy Considerations (cannot mandate anything); did not define privacy, either. Community would have to have consensus to require Privacy Considerations. In practice, IESG will bring up these issues regardless.

<tara> DavidS: we did have a spec here that asked if you could even begin this work without having serious privacy implications? Would be better to find that out well before CR.

<tara> MikeW: the TAG document tried to go in this direction. Started with general threat and then go into more detail about specifics of a given threat. Note: documents are limited in their ability to support interaction. Unclear how to best structure something to make it effective.

<tara> MikeW: it's okay to have the section assert that there are "no problems."

<tara> TaraW: we should break up the document into sections to work on to make concrete progress. Also welcome suggestions for additions.

<tara> dsinger: suggests looking at 2, 3, and 7.

<tara> TaraW: ** we're breaking at 10 instead of 11 -- to deal with the wifi (and coffee)

<tara> And now we're back into the agenda

<keiji> scribe: tara

<JoeHallCDT1> scribe: joehallcdt

<JoeHallCDT1> Andrew: works for financial times, member from TAG (5% of time on standards work)

<JoeHallCDT1> … interest in privacy

<JoeHallCDT1> hadleybeeman also on the TAG

<JoeHallCDT1> … had advised the UK cabinet on privacy issues, etc.

<JoeHallCDT1> … interested in how the connections we build here impacts life outside

<JoeHallCDT1> yoshiro from GPRS, working on domain registry

<hadleybeeman> s/on privacy issues/on technology and privacy/policy issues

<JoeHallCDT1> … lots of user data, want to make sure it is informed by privacy

<JoeHallCDT1> Jeff Jaffe: needs no intro!

<JoeHallCDT1> tara_: left off with how to deal with the privacy questionairre

<JoeHallCDT1> … mkwest was here earlier

<JoeHallCDT1> … he was interested in making sure we had high-level guidance and deeper guidance that flows from that

<JoeHallCDT1> … right now our privacy document is in between

<JoeHallCDT1> … seems like we were moving towards consensus to take this document and turn it into the detailed version

<JoeHallCDT1> … and produce something more high-level from it

<JoeHallCDT1> … we would need to start carving out particular things

<JoeHallCDT1> … christine offered to shepheard that work, but we need to do that work.

<tara> Joe: how about we set up scaffolding with both security & privacy parts?

<tara> Combine TAG & PING questionnaire in one doc -- can start off with the high-level part that mkwest recommended

<tara> This could satisfy the need to have high-level guidance and also the details as required.

<tara> Need to consider limits of the usual W3C document style

<tara> JoeHall: this is in recognition of the fact that the Security part hasn't has much uptake to date

<JoeHallCDT1> jeff jaffe: thinking about privacy and security considerations. good idea!

<JoeHallCDT1> … then looked at this document that says it's important that the user can spoof

<JoeHallCDT1> … maybe great for privacy but that might be bad for security

<JoeHallCDT1> … can we work with the security folks to make sure that this isn't a problem

<JoeHallCDT1> hadleybeeman: there will be tension coming from both perspectives

<JoeHallCDT1> … and we'll need to work through that

<JoeHallCDT1> mattias: we do recognize that things like UA strings will be important to spoof

<JoeHallCDT1> jeff: was just wondering if there would be contradicting guidance here… one says "support spoofing" and the other says "don't spoof"

<JoeHallCDT1> mattias: if you reword it so that "users can make a free choice as to what to send" it would be more palatable.

<JoeHallCDT1> hadleybeeman: from a TAG perspective, we are interested in making sure spec authors are thinking about things that may not be their particular interest or focus in a spec

<JoeHallCDT1> … security and privacy are separate thought processes, have to put yourself in the position of thinking like that

<JoeHallCDT1> … one of the benefits of having something written, is not just to have an author go through a process, but to nudge them into thinking about different elements of the spec.

<JoeHallCDT1> andrew: organizations could really benefit from seeing this written down well

<JoeHallCDT1> … trying to fight against the instincts to build tech that compromises privacy is a good feature of this kind of effort

<JoeHallCDT1> keiji: the base of the web is that people are anonymous

<JoeHallCDT1> tara_: clearly we have some issues with spoofing data

<JoeHallCDT1> dsinger: can we at least decide on what "spoofing" "fuzzing" and "randomization" mean for PING?

<JoeHallCDT1> tara_: yes, there is a thing in our agenda for that after lunch

<JoeHallCDT1> dsinger: and 2, 3, 7 questions in the spec need to be closer together and likely consolidated?

<JoeHallCDT1> … one question at the end: "If you answered these questions like a lawyer, only answering what was asked, are there questions we should have asked?"

<JoeHallCDT1> … and having an introduction that set expectations of when to use this thing could work

<JoeHallCDT1> hadleybeeman: TBL talked about recently "what are the policy considerations we should consider?"

<JoeHallCDT1> … e.g., we could have included a section in the email spec that notes there could be potential problems in the future (e.g., spam)

<dsinger> I would like a section on the steps to follow that will result in a quality privacy considerations section. What do you need to do at FPWD? How do you get a privacy review? Which questions help at which stage? and so on

<tara> JoeHall: talking about issues that *others* might wish to know about that are not dealt with in the spec

<JoeHallCDT1> barrylieba: so write down, "here are things we though about and either cannot do anything about or will not do anything about"

<JoeHallCDT1> hadleybeeman: if we decided this is something to do, we'd need to make it explicit

<JoeHallCDT1> … maybe we need s privacy issues or policy issues sections of specs

<JoeHallCDT1> tara_: any volunteers interested in editing or doing something with specific sections of the document?

<christine> hi. Is webex up?

<tara> Should be. If it's not. let me know!

<barryleiba> Try calling in.

<barryleiba> We think we're dialled in.

<christine> It says host has not yet joined. Is there a new link?

<JoeHallCDT1> give one sec, Keiji needs to join as host

<christine> Seems to be fine now

<tara> Hi!

<JoeHallCDT1> tara_: anyting on questionairre for the good of the order?

<JoeHallCDT1> christine: no, will look

<JoeHallCDT1> now on Kepeng on his new document: https://www.w3.org/wiki/Privacy/Privacy_protection_principles

Privacy Protection Principles

<keiji> Privacy Protection Principles: https://www.w3.org/wiki/Privacy/Privacy_protection_principles

<JoeHallCDT1> kepeng: sent the link to the list two days ago

<JoeHallCDT1> … it's about privacy protection principles

<JoeHallCDT1> … on the list, there has been discussion about privacy principles being defined/described in a number of other places

<JoeHallCDT1> … OECD, etc.

<JoeHallCDT1> … my intent is to make this specific to the Web

<JoeHallCDT1> … I have a specification in Chinese similar to this

<JoeHallCDT1> … we can make it applicable to the w3c

<JoeHallCDT1> tara_: what was the rationale for creating the document in the first place?

<JoeHallCDT1> kepeng: I just wanted to contribute!

<JoeHallCDT1> … in China, we are defining a national standard similar to this

<JoeHallCDT1> … and it may be useful to bring it to the W3C

<JoeHallCDT1> … has 9 principles in the current document

<JoeHallCDT1> … subissues are mostly not developed as don't want to spend a lot of time on this if it gets refactored or reorganized

<JoeHallCDT1> joehallcdt1: the "agreement" principle is usually called "transparency" in other similar work

<JoeHallCDT1> agreement here seems to be notice & consent?

<JoeHallCDT1> kepeng: minimization principle (minimum usage principle)

<JoeHallCDT1> … clear communication principle is all about form of notice

<JoeHallCDT1> kepeng: this is an early effort

<JoeHallCDT1> … comments from chaals were helpful

<JoeHallCDT1> … "What if the purpose is to collect long-term information about a user?"

<JoeHallCDT1> … the website should tell the information subject before hand, and the user can reject it

<JoeHallCDT1> … "What if the purpose is to monetize information about the user to fund service?

<JoeHallCDT1> … we'll want to define some mechanism to avoid this kind of situation

<JoeHallCDT1> christine: sound quality is difficult...

<JoeHallCDT1> … thanks for sharing this work you've been doing in China, and now this English version

<JoeHallCDT1> … is this an extension of the APEC privacy principles work?

<JoeHallCDT1> … this is interesting, but

<JoeHallCDT1> … it seems to be more of a policy document than a technical document

<JoeHallCDT1> … PING might not be the best place for this

<JoeHallCDT1> … a bit wary of developing a document that is similar but different from the universe of other privacy principle efforts

<JoeHallCDT1> … Fredrik (from the WG formerly known as DAP) did http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/

<JoeHallCDT1> kepeng: I will focus on privacy questionnaire

<JoeHallCDT1> barrylieba: christine said much of what I wanted to say

<JoeHallCDT1> … most of this is not about protocols but about how site operators should act

<JoeHallCDT1> … want to be very careful about saying anonymizing information helps

<JoeHallCDT1> … i.e., enough pieces of anonymous information can be aggregated, may not be able to keep anonymious

<JoeHallCDT1> … e.g., AOL search results release

<JoeHallCDT1> (discussion about various reidentification attacks that have happened in the wild)

<JoeHallCDT1> kepeng: maybe hold off on this and pull some of this into the privacy questionnaire

<lukasz> JoeHallCDT1: I'm considering making a W3C Note on privacy, especially sensors (perhaps WoT)? We were discussing this at DAS

<tara> It is possible that there are gaps in the existing principles

<tara> Example: US revisiting FIPPs; looking at "respect for context"

<tara> So bear in mind that those external references change, too.

<JoeHallCDT1> hadleybeeman: wrt context, could talk about search history

<JoeHallCDT1> … useful to remember that the those governmental documents have political associations and baggage

<JoeHallCDT1> dsinger: context is part of what I've been talking about in terms of cultural grounding of privacy issues

<JoeHallCDT1> tara_: could be an issue to call out areas of a page/spec that might have cultural or national variance (?)

<hadleybeeman> JoeHallCDT1: In some cultures, it's a compliment to say someone is fat. It signifies prosperity. In others, it's an insult.

<JoeHallCDT1> tara_: sounds like we'll hold this and see if this can be applied (or part of it) on the questionnaire

<JoeHallCDT1> dsinger: governments have been writing laws that are way to techincal, and we've been too philosophical

<JoeHallCDT1> david rogers and paul bailey have joined the room in f2f

<JoeHallCDT1> kepeng: how do I contribute to the PING questionnaire document?

<JoeHallCDT1> tara_: we'll figure this out and get back to folks

<JoeHallCDT1> breaking for lunch, back in an hour!

<keiji> Agenda for PM:

<keiji> 5. Terminology discussion [4] (13:00-13:30)

<keiji> * Would a standardized privacy vocabulary be useful in our work? [Joe Hall]

<keiji> 6. Planning next year's work (13:30-15:00)

<keiji> * discuss IETF F2F ideas [5] [Tara Whalen, Joe Hall]

<keiji> * proposals for additional work items?

<keiji> 7. AOB/unstructured time (15:00 – 18:00)

<marta_> at some point I was suggesting we should look into using flowchart style privacy questioner

<JoeHallCDT1> we should be starting soon (for any remotes)

<tara> WebEx up for anyone who wants to call in.

<tara> Waiting for more folks to return from lunch before we jump in...

<tara> https://lists.w3.org/Archives/Public/public-privacy/2016JulSep/0038.html

<keiji> scribe: keiji

Terminology discussion

tara: Here we would like to discuss on terminology around privacy.

JoeHallCDT1: We have many words to be defined cleary e.g. soof and randmize.
... We should use certain words consistently.
... we have wiki but it may not be best way for standardization.
... e.g. spoofing has narrow meaning.
... we should have defined terms to be used in our context.

barryleiba: We should have consistent list of word for privacy.

<dsinger> +1 we should keep a list of terms (GitHub document, Wiki)

barryleiba: we even shoud have definition of privacy.

<JoeHallCDT> +1

dsinger: agrees to have list of terms with GitHub or Wiki.

<dsinger> notes that there is <http://www.w3.org/2003/glossary/> which I have never seen before…

mkwst: guidance definition of terms for standardization is helpful.

tara: list does not need to be exhaustive.

JoeHallCDT1: We should have generic definition rather than specific.

mkwst: We should have IDL to point similar term etc.

barryleiba: about spoofing randomizing fuzzing
... obfuscating may be good to represent those things.

mkwst: we can write down those possible terms.

self introduction for PM

frank:

jason: web platform from microsoft

<tara> Item: Planning next year's work

<tara> * discuss IETF F2F ideas [5] [Tara Whalen, Joe Hall]

<tara> * proposals for additional work items?

<JoeHallCDT> scribe: joehallcdt

IETF F2F ideas

<tara> work items: improve questionnaire; how to develop the process for getting review at the right stage, right considerations; glossary development

<fwagner> Frank: Working for the Group Privacy Department of Deutsche Telekom, happy to be here

moving on

to how do we structure our work for 2017

tara_: want fingerprinting guidance to be at group note stage by the end of the year

<keiji> IETF F2F ideas: https://lists.w3.org/Archives/Public/public-privacy/2016JulSep/0018.html

tara_: but there are things we might want to work on that aren't on our radar
... privacy mode/incognito mode standards?
... data gathering on techniques used to violate privacy?
... guest researchers to come to PING and talk about web privacy?

<tara> q

joehallcdt: what's the status of privacy mode standards?

mkwest: mnot has put a document together about privacy mode consideration. not sure what the state of that is.
... there is a link from TAG work somewhere to a repo that does some of this

dsinger: informally floated this a year ago at last TPAC

<tara> May need to coordinate with TAG to see what work they are pursuing in this area

dsinger: users seem to misunderstand that privacy mode is a local version of protection
... tried to motivate a conversation about a UA-based signal that says, "Hey, I'd like to be private"

jason we've been having some of those discussions at MSFT

scribe: would be very interested in this

mkwest: it's not clear that explaining to websites that a user wants to be private is a good thing, or in the interests of users
... we know that there are sites that are sniffing for incognito, and then don't show content based on that result
... don't want to minimize the use cases that came up with last year
... but it seems hard… explaining the difference between regular and private is hard enough

jason: feels like these are two separate conversations
... on is having multiple identities
... the other is privacy from some threat, local or network

mkwest: one problem is "I want to go to a website, but I want to open this again without it knowing who I am"
... there's also the notion of ephemerality… "want to visit this site but want my browser state to remain clean of that interaction"
... for example, a woman's shelter wanted to force users into incognito mode. Very interesting use case.
... but a problem is that you got to that website somehow
... and you do a disservice if they think all of an interaction was erased, when it was just the middle part of the interaction and not how you got there

dsinger: sounds like we'd want to collect use cases

mkwest: mnot's document ( https://gist.github.com/mnot/96440a5ca74fcf328d23 ) takes a first shot at considerations and controls

frank: what would the scope of a collection of uses cases be here

mkwest: we try to be very explicit in Chrome that incognito only protects the local

dsinger: we could go as far as saying "if you're in incognito, you want to be https"

mkwest: calling it privacy mode conflates a bunch of different use cases

frank: we've been working on something called a "privacy button"
... which allows forcing a new IP address

dsigner: having a discussion document about the issues and advantages of a private browsing mode

jason: something that could be useful to come out of that would be a signal for user intent about privacy desires

dsinger will instigate this conversation on the ping list

tara: the next idea: data gathering on technique for violating privacy

<keiji> ACTION: disinger to instigate conversation on incognito mode on the ping list [recorded in http://www.w3.org/2016/09/20-privacy-minutes.html#action01]

<trackbot> Error finding 'disinger'. You can review and register nicknames at <http://www.w3.org/Privacy/track/users>.

<tara> JoeHall: this was inspired by things like the Princeton (?) research on millions of websites, on fingerprinting techniques

<keiji> ACTION: dsinger to instigate conversation on incognito mode on the ping list [recorded in http://www.w3.org/2016/09/20-privacy-minutes.html#action02]

<trackbot> Created ACTION-13 - Instigate conversation on incognito mode on the ping list [on David Singer - due 2016-09-27].

<dsinger> action-113?

<trackbot> Sorry, but action-113 does not exist.

<dsinger> action-13?

<trackbot> action-13 -- David Singer to Instigate conversation on incognito mode on the ping list -- due 2016-09-27 -- OPEN

<trackbot> http://www.w3.org/Privacy/track/actions/13

<keiji> JoeHallCDT: U.S. and E.U. have different concent requirements for use of fingerprinting.

jason: one concern that I have is that the web platform is so sophisticated...
... it's so easy to fingerprint
... e.g., displays running at 60Hz may be between 58.9 and 60.2
... and have seen statistics that browsing to just 10 pages can fingerprinting you

mike: don't think fingerprinting is that big of a deal

jason: but all the big players do some notion of fingerprinting (WebGL, etc.)
... requestAnimationFrame is a good example of this… the ad is just looking if you're running exactly at 60Hz

keiji: there was a discussion in this group in the past around Web Performance WG
... they tried to define a standard that would be useful for fingerprinting
... when users try to use incognito mode, we may be able to reduce the amount of information leaked

tara: npdoty had listed a bunch of research in fingerprinting area...
... he tries to keep that up to date
... we may be able to collect that in one place
... and that may not be the kind of research we are interested in (e.g., unpublishable things about what users are actually doing)
... would be interesting to have resources about what people are doing

jason: has this group thought about making recommendations for what sites should disclose about how the world works
... e.g., fingerprinting, if sites are using that, you should disclose

mkwest: sites generally disclose this if they have a legal team
... TOS are actionable, which makes them a valuable place to put this

dsinger: maybe flip the q upside down? web site says, "to do my function, I need this data. if you give me this data, I'll make these promisses"
... e.g., "actually do need to [list your fonts/canvas timing] and here's why"
... if they don't express a legit interest, don't give the data

barryleiba: this requires a machine readable format for that, hard...
... and [did not catch the second part]

mike: in the GDPR, Article 12, calls for machine-readable indications/icons… e.g., that information imparted should be made available in a machine-readable manner

keiji: in the past there was p3p, what's the difference here?

<barryleiba> Second part was "huge incentive to lie", and third part was "who decides what's 'reasonable'?"

mike: in DNT spec there is a tracking resource status, could be a perfect place for this

hadleybeeman: [back on TAG work on standards for private browsing mode] there has been no movement in TAG since that document
... TAG was interested in it becuase 1) users care; and 2) makes it much easier for other specs to have normative references to that
... mnot was going to open it up again, but not sure
... as theme of this week and the past year
... as the web and network stack gets more complex
... with more encryption and options about what is happening in a transaction and communication
... the more ways to surface this stuff to the user would be good
... . e.g., mkwest thought about default behavior that a UA would go red when communicating over HTTP rather than HTTPS
... are there areas that the w3c should be looking at that is the next version of user notice

barryleiba: do we have any sense that real users actually understand that?

hadleybeeman: there's a lot of research that talks about that, not at my fingertips

mkwest: good person to talk to is Adrienne Porter-Felt on Chrome security team
... great work on usable security UI
... looking at the research of that team would be helpful
... also gave a great talk at the Enigma conference about treating UI as a science in security areas

<keiji> ADRIENNE PORTER FELT presentation can be seen on http://www.adrienneporterfelt.com/

(lots of discussion about UI/UX and security)

tara: how do we get close to talking about UI and still recognize this is w3c and we don't do UI?

hadleybeeman: where there are opportunities for cross-browser standardization, this group can be informative

<tara> 10-minute break

<tara> Restarting

and… we're back

joehallcdt: what about making privacy reviews more sysematic… how does TAG do it?

hadleybeeman: assigned by expertise… but bringing to the TAG varies quite a bit

tara: need to be more careful about agreeing to reviews and then not doing them

mkwest: if you want to ship a new feature in Blink, you have to have TAG review… that's increased the amount of reviews
... would be bad to have many many reviews
... would be nice to have one place to ask for reviews
... in Chrome… single bug with a bunch of tags that ask legal? security? and when all done, you can ship

hadleybeeman: TAG is trying to make itself much more scalable… so prefer the approach of WGs doing it themselves with detailed follow-up

mkwest: follow the repo for spec review… a low overhead way to keep track of what's going on in the spec

<hadleybeeman> TAG spec review repo: https://github.com/w3ctag/spec-reviews/issues/

mkwest: follow w3c tag spec review repo: https://github.com/w3ctag/spec-reviews

time for any other business (AOB)

AOB

frank: would like to remind you all that DNT will meet for tomorrow at 2p to talk about EU and DNT and consent

dsinger: the Advisory Board is interested in raising the level of activity on privacy
... so if you have any feedback on how we could increase the level of privacy activity at the w3c, please get in touch

mike: exposing more things for privacy instrumentation and notice would be great

<keiji> ACTION: JoeHallCDT and kepeng to review privacy questionnaire. [recorded in http://www.w3.org/2016/09/20-privacy-minutes.html#action03]

<trackbot> Error finding 'JoeHallCDT'. You can review and register nicknames at <http://www.w3.org/Privacy/track/users>.

<keiji> ACTION: JoeHallCDT and kepeng to review privacy questionnaire [recorded in http://www.w3.org/2016/09/20-privacy-minutes.html#action04]

<trackbot> Created ACTION-14 - And kepeng to review privacy questionnaire [on Joseph Hall - due 2016-09-27].

- DRAFT -

PING meeting at TPAC2016
20 Sep 2016

Attendees

Contents

PING privacy questionnaire

Privacy Protection Principles

Terminology discussion

self introduction for PM

IETF F2F ideas

AOB

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output

- DRAFT -

PING meeting at TPAC2016 20 Sep 2016

Attendees

Contents

PING privacy questionnaire

Privacy Protection Principles

Terminology discussion

self introduction for PM

IETF F2F ideas

AOB

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output

PING meeting at TPAC2016
20 Sep 2016