07:28:53 RRSAgent has joined #privacy 07:28:53 logging to http://www.w3.org/2016/09/20-privacy-irc 07:29:50 FYI, I am at the Chairs' Breakfast, finishing at 8:30 and will be at the PING room shortly. 07:31:06 Meeting: PING meeting at TPAC2016 07:31:37 JoeHallCDT has joined #privacy 07:32:19 present + 07:34:42 christine has joined #privacy 07:36:03 moneill2 has joined #privacy 07:36:53 For locals in Lisbon: room is 1.13 07:37:47 We are getting the WebEx set up - bear with us! 07:40:11 That did not seem to be working, sorry! 07:40:28 Can you hear me at all? 07:41:55 is someone there taking minutes? 07:42:07 weiler has joined #privacy 07:42:11 happy to scribe 07:42:34 barryleiba has joined #privacy 07:42:41 npdoty: UC Berkeley I School 07:42:49 schunter has joined #privacy 07:42:53 present+ npdoty 07:43:07 keiji: W3M contact for PING 07:43:08 Karima has joined #privacy 07:43:39 anssik has joined #privacy 07:43:40 Martha: from blockstream, chair of blockchain wg 07:43:46 barry leiba 07:44:22 David Singer 07:44:29 Mike O'Niell 07:44:30 present+ tara 07:44:43 mattias schunter 07:44:50 present+ 07:44:56 present+ 07:45:00 present+ Christine Runnegar 07:45:06 dsinger has joined #privacy 07:45:12 present+ 07:45:12 present+ 07:45:20 present+ 07:45:24 I'm Karima Boudaoud from University of Nice Sophia Antipolis. Interests: User-centric Security and Privacy Management 07:45:26 Gloria has joined #privacy 07:45:28 present+ 07:45:30 moving on to first agenda item on fingerprinting guidance 07:45:47 Is there a URL for the document? 07:45:49 http://w3c.github.io/fingerprinting-guidance/ 07:45:54 marta has joined #privacy 07:46:26 Marta Piekarska, Blockstream. Security Architect & Standards, AC Rep. 07:46:48 ...co-chair of Blockchain CG 07:46:48 RRSagent, make minutes 07:46:48 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 07:48:30 this is a guidance document, intended to be a group note 07:48:57 shepazu has joined #privacy 07:49:01 the idea would be to have specification authors (and implementors) read this and be able to incorporate the ideas here into their work 07:49:10 will go over the motivation and structure of the document 07:49:41 growing concern about inference and leakage based on configuration settings or other aspects of the browser 07:49:51 allows for tracking and ident. in ways that are not expected 07:50:11 e.g., you can clear cookies in your device, but there are no (or few) controls for fingerprinting 07:50:22 scribe: JoeHallCDT 07:50:24 has a number of privacy impacts described in Section 1.2 07:50:41 RRSAgent, make logs member 07:50:43 some feel that this whole area is a bit of a lost cause 07:51:00 however, we do illustrate how to mitigate the privacy risks here 07:51:13 : RRSagent, make minutes 07:51:15 we can make it difficult or at least observable so that the user can figure out when fingerprinting is going on 07:51:17 RRSagent, make minutes 07:51:17 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 07:51:26 RRSAgent, make logs team 07:51:33 there is a list of 9 best practices currently in the document 07:51:45 section 4 on feasibility 07:52:05 describes various levels of success in terms of mitigations 07:52:30 rest of the document focuses on the mitigations, using examples as we have them 07:52:59 questions? 07:53:07 about the purpose or structure of the document 07:53:18 https://github.com/w3c/fingerprinting-guidance/issues 07:53:22 moving on to open issues 07:53:40 feedback from the TAG and from the PING list 07:53:51 many are currently marked "pending review" 07:53:58 please check those and we can try to close those out 07:54:04 https://github.com/w3c/fingerprinting-guidance/issues/13 07:54:05 https://github.com/w3c/fingerprinting-guidance/issues/13 07:54:09 https://github.com/w3c/fingerprinting-guidance/issues/11 07:56:49 ok, we are back! 07:56:55 yay technology! 07:57:53 11 is about providing hooks for instrumentation 07:58:43 make it easier for browser extensions to list the things a website is doing 07:59:07 it's very cumbersome process to do this kind of detection… essentially have to write your own browser 07:59:23 npdoty gets the impression that there is not a whole lot we can do about this in the document 07:59:24 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] 07:59:25 implementation-specific (rather than Web specification) features. 08:00:11 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?" 08:00:33 npdoty: there are gross kinds of distinctions 08:00:42 … e.g., if a site is enumerating all fonts, not good 08:00:58 another big issue is actionability (issue 13) 08:01:16 … how do we make the document more actionable… through an explicit decision tree, for example 08:01:38 … even with best practices in the document, how does a team figure out what they should do when? 08:01:57 … what we've done is asked people to attempt to use the document in their work 08:02:06 … that feedback is very useful 08:02:20 … one thing we might do is identify fingerprinting surface 08:02:28 Present: keiji, tara, JoeHallCDT, npdoty, barryleiba, moneill2, schunter, dsinger 08:02:39 … which would be helpful to figure out when a spec is increasing fingerprinting surface 08:02:43 RRSagent, make minutes 08:02:43 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 08:03:11 … data sources that could increase fingerprinting… add a new header? look at mitigation number 1 (this is just an example) 08:03:20 … very unclear how to make it more actionable 08:03:27 Chair: tara 08:03:37 … very much would like the feedback from others as to how could this document be made useful 08:03:43 q+ 08:03:44 … thoughts? 08:03:50 What is the incentive for (non privacy) chairs to care about fingerprinting? 08:04:04 q- 08:04:06 ack christine 08:04:33 JoeHallCDT: we asked people to look at the privacy questionnaire for the specifications they're working on, did we do that with fingerprinting doc? 08:04:33 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) 08:05:42 npdoty: we have had occasional people that have referenced the document 08:05:46 … we could ask explicitly more 08:05:54 q+ 08:06:24 christine: what are the incentives for non-privacy folks to care about fingerprinting? 08:06:29 q- 08:06:31 q? 08:06:35 q+ to ask about vanilla and fuzz 08:06:53 … the answer is partly: we can't make all w3c specs fingerprinting proof 08:07:04 … but we can try to not make them worse by increasing fingerprinting surface 08:07:08 Thanks! 08:08:06 … do you really need to add this thing that increases surface? and at what level of granularity do you need it? 08:08:34 How about a team of white hat fingerprinting exploiters to look at new APIs to see how they can be exploited by bad guys 08:08:40 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 08:08:53 … detectability is an important element, especially for keeping web actors accountable (through DPA, etc. enforcement) 08:09:21 … asks npdoty: would you like help in terms of creating a decision tree? 08:09:39 Kepeng has joined #privacy 08:09:44 mschunter: thinks the privacy questionaire is a good place to tie in the actionability 08:09:44 I said: Good job! 08:09:50 Great job, actually... 08:10:05 chaals has joined #privacy 08:10:43 npdoty: we've talked a number of times about whether or not these should be two documents or one 08:10:50 … but this sounds like a great idea 08:10:51 q+ to suggest looking into WebDriver as an automation mechanism. 08:10:55 Example question: Does your working group define or change the user agent behavior in any way? (no -> no fingerprinting impact?). 08:11:04 … happy to have those questions in the questionaire or vice-versa 08:11:28 … would love some help. npdoty is not in the best position to do this as he's not as close to spec authors 08:11:34 … so think about this this week 08:11:48 dsinger: split section 2? 08:12:14 agenda: https://lists.w3.org/Archives/Public/public-privacy/2016JulSep/0043.html 08:12:46 … fuzzing data to make less identifiable and vanilla response for a feature are great 08:12:57 npdoty: we actually prefer the "vanilla" style 08:13:07 ack ds 08:13:07 dsinger, you wanted to ask about vanilla and fuzz 08:13:22 http://w3c.github.io/fingerprinting-guidance/#a_standardized_profile 08:13:45 dsinger: we should say explicitly "you must define the vanilla response for your feature" 08:13:57 … should we be documenting what is vanilla for older specifications? 08:14:21 … 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. " 08:14:31 npdoty: e.g., ordering of fonts 08:15:02 dsinger: we could even specify what is the "lie" a browser would have to give (e.g., fake list of fonts) 08:15:24 … maybe here we could actually try and document what the vanilla response should be for existing specs? 08:15:57 npdoty: hmmm, what would the form of a vanilla response take? 08:16:11 dsinger: maybe just say "you should define a vanilla response" 08:16:21 dsinger, if we had a specific example of that, of what it would look for a certain spec, that would be helpful 08:16:27 mike: some things may not be fuzzable 08:16:55 mkwest: you were talking early about hooks into the browser that would allow you detect 08:16:55 ack mk 08:16:55 mkwst, you wanted to suggest looking into WebDriver as an automation mechanism. 08:17:03 … might want to look into the WebDriver specification 08:17:07 present+ mkwst 08:17:16 … allows more control than what you would have in a normal browser 08:17:28 … you could get events back that might be useful for this 08:17:43 … should also talk to those folks about requirements for this kind of use case 08:17:50 yoav has joined #privacy 08:18:00 … APIs that you have via WebDriver are going to be more powerful than via the web 08:18:36 npdoty: when researchers test these things, they are trying to instrument such that a headless browser gets some stuff 08:18:52 mkwest: I think we're on the same page… it's a bit like a debugging interface 08:19:03 q? 08:19:10 https://www.w3.org/TR/2013/WD-webdriver-20130117/ 08:19:35 mattias: Web Driver won't allow you to do automatic discovery 08:21:01 npdoty to follow up with Princeton, FPDetective folks on whether WebDriver would be a useful area for them to look re instrumentation 08:21:05 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. 08:21:29 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 08:21:32 (= my assumption that Webdriver cannot be scripted seemed to be wrong ;-) 08:21:38 :) 08:22:06 mkwest: cookies are not fingerprinting… very explicit tracking, under user control. much less dangerous (not dangerous) to users 08:22:29 … canvas, on the other hand, is more of the fingerprinting in terms of lack of discoverability 08:22:45 +1 that I'm less concerned about cookies 08:22:52 … more concerned about things that are outside of the user control 08:23:00 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 08:23:34 (discussion about clearing site data and media stream ID) 08:23:53 mkwest: >10% of users clearing cookies on a weekly basis 08:24:14 … ff has a "forget this site", Chrome is going to have it soon 08:24:34 … we can certainly look at applying this document to any and all of WebAppSec specs 08:24:58 we include "cookie-like fingerprinting" in this document largely for the "evercookie" risk identified in the past 08:25:07 3 levels of data: 08:25:08 mattias: the explicitness of a data source is important… cookies, super explicit. other things like media streams ID, not explicity. 08:25:14 1. Cookies (explicit, visible, deletable) 08:25:22 q? 08:25:30 q+ on permanent 08:25:38 2. Web-site data that is stored in a user agent and that can be erased (by clearing web-site data) 08:26:04 3. Any user agent data / characteristics/ data that cannot be erased (this is the surface for fingerprinting). 08:26:24 q? 08:26:29 ack np 08:26:29 npdoty, you wanted to comment on permanent 08:26:38 mkwest: it's unlikely no document will pose zero problems, but "this is like cookies" would be a good place to end 08:27:01 npdoty: there are things that are like cookies in terms of explicit, and there are others 08:27:07 http://w3c.github.io/fingerprinting-guidance/#clearing-all-local-state 08:27:21 … we are coming across functionality where we might need permanent or persistent identifiers 08:27:44 … and in the document ^^^ we say we should have no permanent or persistent identifiers 08:28:01 mkwest: alas, many groups want to do the exact opposite of this 08:28:13 … look at WebAuth and the smartcard keying stuff 08:28:16 [Hardware-Based Secure Services: https://rawgit.com/w3c/websec/gh-pages/hbss.html ] 08:28:24 … those are much more persistent notions of identifiers 08:28:39 … agree with the sentiment, but that there are important use cases for more persistence 08:28:50 … orgin-locking, etc. can be recommended here 08:29:29 mike: origin locking is not as helpful as discoverability 08:29:39 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 08:29:46 q? 08:29:52 mkwest: origin locking is the foundation (doesn't make much sense to have discoverable but not locked) 08:30:32 npdoty: on scheduling, it would be useful to close out the things that are marked pending-review 08:30:48 … and get some feedback/interaction from other groups 08:30:56 … goal is to get this document in a note by the end of the year 08:31:13 tara_: thanks for joining us in Lisboa! 08:31:13 goodnight! 08:31:42 topic: PING privacy questionnaire 08:31:47 christine: let's talk privacy questionnaire 08:31:51 https://github.com/w3c/ping/blob/master/privacy-questions.html 08:31:53 Privacy Questionnaire: http://htmlpreview.github.io/?https://github.com/w3c/ping/blob/master/privacy-questions.html 08:32:14 christine: core piece of work is to produce an annotated privacy questionnaire 08:32:20 RRSagent, make minutes 08:32:20 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 08:32:39 … the origin of this is mkwest's TAG-adopted security questionnaire 08:32:44 moneill2 has joined #privacy 08:33:03 … the idea is to have a set of questions that spec authors can work through and minimize privacy implications of their specs 08:34:34 … many thanks to greg norcie and CDT for curating this 08:35:07 … let's use the hour to walk through the document, see where it stands, and set up some homework assignments 08:35:28 … work on refining the questions and calibrate the level of detail for the addendum 08:35:33 q+ 08:35:35 … questions? 08:35:54 ack kepeng 08:35:57 kepeng: we have some differing formats across questions 08:36:07 … 2 starts with an explanation 08:36:15 … we need to make the structure of each question consistent 08:36:30 … also 13 isn't as detailed as 11 and 12 08:36:42 christine: what you see before you is very much still a draft 08:36:53 … we have bascially put all the current thinking here in this place 08:37:17 … when we clean up the document, we definitely want good consistency! 08:37:33 … there are some WG members who need details, and there are others that just want the questions 08:37:56 … why is this an issue? what are ways of mitigating this issue? can we make something more detectable? 08:38:13 … this is very much a draft, need to work on together as a group to get in a better state 08:38:20 Is there an URL for this questionaire? 08:38:27 … need to make sure that we keep this moving 08:38:42 … goal would be to have a working draft by the end of the year 08:39:03 … I don't think in our privacy guidance we should attempt to define privacy 08:39:26 … perhaps do it more like what IETF did… explain issues in terms that spec authors/imps can understand 08:39:49 q? 08:40:32 present+ kepeng 08:40:52 Original Security & Privacy questionnaire: https://www.w3.org/TR/security-privacy-questionnaire/ 08:40:56 kepeng: what is the difference between this and that TAG one? 08:41:09 joehallcdt: we can't remember 08:41:18 weiler_ has joined #privacy 08:41:20 mkwest: the TAG document has either too much detail or not enough detail 08:41:48 … either the questions are too detailed to give a high-level overview or not 08:41:54 moneill2_ has joined #privacy 08:42:02 q+ 08:42:08 … preference here would be to have a high-level document that points to more detailed guidance 08:42:21 … would love to trim down the TAG document 08:42:36 … we could merge the two to make a super document 08:42:46 … but that would make it less likely that anyone would use it 08:43:03 … maybe make the TAG document smaller and this one longer 08:43:19 kepeng: what is the security equivalent of the privacy questionairre? 08:43:25 mkwest: there isn't something that detailed 08:43:38 dsinger: why do you think two documents are useful? 08:43:52 mkwest: it could be different sections of the same document 08:44:09 … the PING document is more of a deep-dive, and we could use that for security 08:44:39 christine: thanks to mkwest for getting the TAG document out there 08:44:41 ack chr 08:45:02 … we can ultimately decide what to do with the document 08:45:17 … would be good to walk through the document. What's missing? homework on existing items? 08:45:58 q+ on PING developing a security document too 08:46:30 dsinger: "what do you need to think about to write the privacy considerations section of your spec?" 08:46:45 mkwest: there is a balance between covering everything and being usable 08:47:29 … from internal uses at Google, an expando-type document works well (expando: deeper heirarchy can be exposed from a high-level document) 08:47:37 … is important to have as much detail as possble 08:47:53 … practically, people get sad when they see a 30-page document 08:48:11 q?? 08:48:25 tara_: practical question: likes the expando 08:48:43 … or will we end up with a tiny questionairre and a very long one 08:48:57 I would like to see the meta-question added “are there privacy aspects of your specification that the preceding questions did not pull out?” 08:49:19 q+ 08:50:43 yoav has joined #privacy 08:51:09 barryleiba1 has joined #privacy 08:54:14 keiji_ has joined #privacy 08:54:39 JoeHallCDT has joined #privacy 08:54:43 ok back! 08:55:18 dsinger: questions 2, 7, 8 (?) clearly need work 08:55:51 q+ 08:55:54 weiler_ has joined #privacy 08:55:59 mattias: what do we think the process is to produce a w3c spec that has a good privacy considerations section? 08:56:07 … when do we want to see specs do what? 08:56:24 … our goal is to have specs in w3c to have good privacy considerations sections 08:56:58 barryleiba1: this might be difficult, what kind of guidance can we give them? Think about it as soon as possible? 08:57:14 dsinger: we maybe should be looking for FPWD that do not have privacy considerations 08:57:33 … we should explicitly say FPWD is the point in time for this 08:59:40 RRSagent, make minutes 08:59:40 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji_ 09:01:06 present+ wseltzer 09:01:40 JoeHallCDT has joined #privacy 09:02:13 dsinger: perhaps the document could capture some of this meta conversation? 09:02:32 … e.g., why do you need to think about privacy considerations earlier? 09:03:42 JoeHallCDT1 has joined #privacy 09:03:50 mkwest: the TAG document tries to go in that direction… maybe doesn't do a great job 09:04:37 q? 09:05:16 schunter_ has joined #privacy 09:05:24 weiler has joined #privacy 09:05:30 ack sch 09:05:50 JoeHallCDT has joined #privacy 09:06:05 q- 09:06:26 dsinger: questions 2, 3, 7 all sound very similar, need to fix that 09:06:28 q- 09:06:47 … and add "are there questions about your spec that we didn't ask that we should have?" 09:08:14 [break: return at 11 Lisbon] 09:08:30 RRSagent, make minutes 09:08:30 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 09:13:44 schunter1 has joined #privacy 09:18:28 weiler has joined #privacy 09:21:25 yoav has joined #privacy 09:21:46 chaals has joined #privacy 09:32:52 barryleiba has joined #privacy 09:33:43 barryleiba has joined #privacy 09:33:46 chaals has joined #privacy 09:34:37 shepazu has joined #privacy 09:34:46 yoav has joined #privacy 09:35:13 JoeHallCDT has joined #privacy 09:36:49 JoeHallCDT1 has joined #privacy 09:40:48 keiji has joined #privacy 09:41:09 : RRSagent, make minutes 09:45:24 dsinger has joined #privacy 09:48:03 RRSagent, make minutes 09:48:03 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 09:49:06 present+ mattias, martha, christine 09:49:12 RRSagent, make minutes 09:49:12 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 09:57:22 tara has joined #privacy 09:57:44 We seem to have the network and WebEx back, for those who got cut off... 10:03:06 Okay, let's get going again... 10:03:15 Here is a pile of notes from my offline scribbles 10:03:39 Context - begins from the discussion of the Privacy & Security Questionnaire 10:03:53 Karima has joined #privacy 10:04:33 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 10:04:41 Joe volunteers to do this 10:04:47 Kepeng also volunteers 10:05:19 Marta: maybe we could try some kind of flowchart model 10:05:32 David Singer: Q 2,3, and 7 need work 10:05:39 Matthias: having a checklist of questions is helpful to avoid overlooking anything 10:06:05 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"? 10:06:28 BarryL - going to vary depending on the context as to what would work best 10:06:36 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) 10:06:55 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] 10:07:04 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. 10:07:11 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. 10:07:20 dsinger has joined #privacy 10:07:24 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. 10:07:32 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. 10:07:38 MikeW: it's okay to have the section assert that there are "no problems." 10:07:46 TaraW: we should break up the document into sections to work on to make concrete progress. Also welcome suggestions for additions. 10:08:02 dsinger: suggests looking at 2, 3, and 7. 10:08:10 TaraW: ** we're breaking at 10 instead of 11 -- to deal with the wifi (and coffee) 10:08:16 And now we're back into the agenda 10:09:55 scribe: tara 10:09:58 RRSagent, make minutes 10:09:58 I have made the request to generate http://www.w3.org/2016/09/20-privacy-minutes.html keiji 10:10:06 scribe: joehallcdt 10:10:21 dsinger has joined #privacy 10:11:00 Andrew: works for financial times, member from TAG (5% of time on standards work) 10:11:06 … interest in privacy 10:11:16 ??? also on the TAG 10:11:34 … had advised the UK cabinet on privacy issues, etc. 10:11:47 … interested in how the connections we build here impacts life outside 10:11:50 s/???/hadleybeeman 10:11:57 ???? from GPRS, working on domain registry 10:12:09 s/on privacy issues/on technology and privacy/policy issues 10:12:11 … lots of user data, want to make sure it is informed by privacy 10:12:14 s/????/yoshiro/ 10:12:28 Jeff Jaffe: needs no intro! 10:12:54 tara_: left off with how to deal with the privacy questionairre 10:13:00 … mkwest was here earlier 10:13:01 q+ 10:13:19 present+ andrew, hadleybeeman, yoshiro 10:13:29 … he was interested in making sure we had high-level guidance and deeper guidance that flows from that 10:13:44 … right now our privacy document is in between 10:14:01 … seems like we were moving towards consensus to take this document and turn it into the detailed version 10:14:10 … and produce something more high-level from it 10:14:22 … we would need to start carving out particular things 10:14:31 moneill2 has joined #privacy 10:14:32 present+ jeff 10:14:40 … christine offered to shepheard that work, but we need to do that work. 10:14:44 q? 10:14:45 present+ 10:14:57 present+ hadleybeeman, andrew.betts 10:15:13 jeff has joined #privacy 10:15:21 Joe: how about we set up scaffolding with both security & privacy parts? 10:15:46 q+ 10:15:53 Combine TAG & PING questionnaire in one doc -- can start off with the high-level part that mkwest recommended 10:16:31 This could satisfy the need to have high-level guidance and also the details as required. 10:16:51 Need to consider limits of the usual W3C document style 10:16:51 q+ 10:17:13 ack joe 10:17:32 ack joehallcdt 10:17:41 JoeHall: this is in recognition of the fact that the Security part hasn't has much uptake to date 10:17:51 jeff jaffe: thinking about privacy and security considerations. good idea! 10:18:05