Hi Jay, All your responses below look good to me and I see you created a few issues to track things in GH. Thanks, S. On 04/12/2019 19:00, Jay Daley wrote: > Hi Stephen > >> On 4/12/2019, at 11:42 PM, Stephen Farrell >> <stephen.farrell@xxxxxxxxx> wrote: 1. What is a "privacy context"? >> I'm not a GDPR specialist (thankfully:-) but have read bits about >> it and that's not a well-defined term for me. I think I do know >> what it means but want to check - if the IAB say keeps a file of >> comments received on people who've volunteered for some position, >> are we saying that data is covered by this policy or not? OR, does >> this entire policy only really apply to the public-facing IETF etc >> web sites and their logs etc? > > While the new version tries to use plain english as much as possible, > this is the one area where we need explicit legalese. A privacy > context relates to the full range of activities undertaken so > everything is covered. The NomCom comments you mention are indeed an > exception that needs to be called out. > >> >> 2. "Our Commitment to Privacy" - that subsection is only about >> transparency, suggest renaming it to "Our Commitment to >> Transparency." (That's not really a nit - there's a significant >> proportion of our industry that publishes what I believe are fake >> claims saying they are committed to privacy, so we don't want to >> smell like that at all;-) > > Yes, that was changed by the lawyers to a standard term and you’re > quite right that in our context it is inappropriate. "Our Commitment > to Transparency" works. > >> >> 3. Whose "personal data" are comments submitted to the nomcom >> feedback page? > > Agreed, that’s an exception to be listed. > >> >> 4. The list of personal data is odd. Regarding an I-D as personal >> data seems wrong in any case. I suspect there may be a lack of >> definition somewhere here but maybe it's ok to ignore that. > > The general definition of personal data is anything that can be used > to identify, through linkage, a real person. IDs are well > established as personal data unless specific precautions are taken, > and since we can’t know that we will use the safest definition. > >> >> 5. Pictures. I don't think this policy is consistent with the red >> lanyards policy at IETF meetings. The text here seems like it's >> over-riding that saying "we can do whatever we want with pictures >> from meetings." > > Agreed. This section was not changed in any detail and so that issue > has always been there, but it can be tidied up now. > >> >> 6. Sale of data. I like that bit:-) But please extend it a little >> e.g. to "We do not sell your personal data, or any data, nor do we >> monetize any data in any way, such as by "renting" or making access >> available for a fee." There have been many cases of companies >> making what seem clear statements but where it turns out that they >> do have "partners" and do end up making money from people's data >> while still claiming that they don't "sell" that. > > "nor do we monetize it in any way" works. > >> >> 7. "Our websites do not alter their behavior according to the value >> of a browser Do Not Track (DNT) setting." Is that new? (I forget >> sorry.) I don't like it anyway (even though DNT is a crap >> specification:-). If someone emits that signal we ought honour it >> unless we cannot. > > This again is a clause that has been there for a while and only > changed to make it clearer. While DNT has differing levels of > support it is a clear specification and DNT specifically only applies > to third-party tracking not first-party tracking. In other words, we > track you on our sites only as those are a single privacy context and > do not enable you to be tracked between our context and a different > context nor do we attempt to track you from another context to ours. > I do not think it appropriate to use our own custom definition, even > if we believe that’s what people expect and given that first-party > tracking can be disabled by other means. > >> >> 8. "We use services from Cloudflare to support some of their >> websites." s/their/our/? > > Noted. > >> >> 9. I'm not keen on the "go find cloudflare's policy yourself" >> statement. It'd be better if we had a pointer to that and if we >> were clear that it applies to www.ietf.org <http://www.ietf.org/> >> but not ietf.org <http://ietf.org/> or tools or datatracker etc as >> applies. CF do after all have >1 policy and tracking down which >> applies to www.ietf.org <http://www.ietf.org/> may be non-trivial. > > Ok, we can look at that. > >> >> 10. Stuff we don't share ought probably include feedback to nomcom >> and other appointing bodies (e.g. IAB/IESG). The ANRP and ANRW also >> involve reviews that some might consider sensitive. Some but not >> all of those use web based tools. Some will involve such >> feedback/comment being sent on closed mailing lists. > > I’ve had similar comments privately and these will be addressed. > >> >> 11. Not asking we fix now, but, for a future version, can we think >> about setting a policy for deleting old data? I'm not sure anyone >> needs the payment info I used for IETF35:-) If we already have such >> a policy, then saying that here would be good. > > The LLC is working on a records retention policy, which should be out > soon (couple of months?), which will cover that. > >> >> 12. Also for the future, I like warrant canaries. Not so much >> because we might need one but to set what I think is a good >> example. (Opinions vary on that though so not asking you to do it, >> just to note it down to ponder it later.) > > This would be more appropriately covered in something like an annual > transparency report. I also like warrant canaries but as you say, > that’s for a future discussion. > > Jay > >> >> Cheers, S. >> >> On 04/12/2019 00:24, IETF Executive Director wrote: >>> The IETF Administration LLC has reviewed the IETF Privacy >>> Statement [1] and proposes to introduce a new version [2]. The >>> main reasons for this are to support the introduction of web >>> analytics, to support the collection of demographic data in >>> surveys and to make the whole statement more legally compliant, >>> easier to read and clearer to understand. This new version >>> contains the following changes, which have been reviewed by our >>> privacy counsel: >>> >>> 1. Significant reordering, moving of text and changing of >>> headings, with minimal change in meaning, in order to make the >>> statement clearer and easier to understand. >>> >>> 2. The scope statement has changed from covering the >>> IETF/IRTF/IAB to identifying the specific groups that can legally >>> be considered data controllers in various data protection >>> regimes, namely the LLC, IESG, IAB, IRSG and RFC Editor, and >>> being clear that their activities form a single privacy context. >>> The scope uses “IETF†as a collective term for all these >>> groups, even though that is not structurally accurate, as >>> attempting to convey accurate structure in this statement is too >>> complex. “This statement sets out the privacy and data >>> protection policy of the following related organizations and >>> groups: the IETF Administration LLC ("LLC"); the Internet >>> Engineering Steering Group (“IESGâ€); the Internet >>> Architecture Board ("IAB"); the Internet Research Steering Group >>> ("IRSG"); and the RFC Editor (each a "Party"), which are >>> collectively referred to in this policy as the Internet >>> Engineering Task Force ("IETF") and whose activities constitute a >>> single privacy context.“ >>> >>> 3. The existing version contains a number of references to the >>> Internet Society (ISOC) given the legal structure that existed >>> before the creation of the IETF Administration LLC. Those >>> references have all been removed as data will no longer be shared >>> with ISOC and a statement added for the avoidance of doubt: >>> “For the avoidance of doubt, this policy does not apply to the >>> Internet Society (“ISOCâ€) and its activities and practices >>> constitute a separate privacy context. ISOC should be regarded as >>> a third-party for the purposes of this policy.†>>> >>> 4. Two new elements have been added to the list of data that may >>> be made public, which reflects existing practice. These are >>> “metadata related to the time and frequency of your >>> interactions with any IETF system†and “message headersâ€. >>> >>> 5. Added an additional example of personal data to be clear that >>> email message headers contain a lot of data “the IP address of >>> a message sender and details of the device or service used to >>> send the message, as found in email headersâ€. >>> >>> 6. Added a clear statement that we do not sell data "We do not >>> sell your Personal Data". >>> >>> 7. Added a new bullet on what data we collect to cover web >>> analytics and a new paragraph that covers what we intend to do >>> with that data. The bullet is “information provided when you >>> interact with any IETF website†and the paragraph is “We >>> track your usage of our websites in order to understand how our >>> websites are used and how we can improve them. We do this using >>> Javascript based tracking code, which collects a limited set of >>> technical data. If Javascript is disabled or not available in >>> your browser then this tracking will not take place and your >>> usage of our websites should not be affected.†>>> >>> 8. Section on Do Not Track (DNT) made clearer as previous >>> version required you to read the specification to understand it >>> “We do not enable or participate in any third-party tracking of >>> your website activity. As no third-party tracking is enabled on >>> our website, our websites do not alter their behavior according >>> to the value of a browser Do Not Track (DNT) setting.†>>> >>> 9. The section on the use of cookies for online transactions has >>> been made clearer “When you log into one of our websites or >>> initiate an online transaction through one of our websites then >>> we may use cookies to uniquely identify you during that session, >>> to record your preferences and to simplify the establishment of >>> new sessions. If you disable your web browser's ability to >>> accept cookies you will still be able to browse the site but >>> authenticated and transactional services may not function.†>>> >>> 10. A new section has been added to explain that if we collect >>> demographic information in a survey then that will only be >>> published in an aggregated form that does not allow individual >>> identification. This addition is not needed to enable collection >>> of demographics, we can do that anyway, it is solely to explain >>> what we do if we do collect it. “We may ask you to provide >>> demographic information (e.g. age, sex, country of residence) in >>> surveys or other information gathering activities. You are not >>> required to provide that information and your disclosure of that >>> information to us is voluntary. We do not disclose the >>> demographic information of individuals. We may publish >>> aggregated information using demographic data as one dimension, >>> in which case we will aggregate at a sufficient level to prevent >>> disaggregation or deanonymization.“ >>> >>> This email now begins a two week consultation on this revised >>> statement, closing on Wednesday 18 December. >>> >>> If you have any comments or questions then you can submit those >>> by any of the following methods: >>> >>> * Raising an issue on the Github repository >>> https://github.com/ietf-llc/ietf-privacy-statement-consultation >>> * Direct to me at exec-director@xxxxxxxx * To the ietf@xxxxxxxx >>> list >>> >>> [1] https://ietf.org/privacy-statement/ [2] >>> https://github.com/ietf-llc/ietf-privacy-statement-consultation/blob/master/DRAFT%20IETF%20Privacy%20Statement%202019.md >>> >>> >> >>> <0x5AB2FAF17B172BEA.asc> >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
