Re: [ietf-privacy] New Webiquette RFC
Hi Kate, At 11:35 AM 17-04-2022, kate_9023+...@systemli.org wrote: I'm quite new at creating RFCs. I have recently submitted a draft for a new webiquette and I am still searching a group which will take care of it. It would fit into privacy as this new webiquette is dealing with new internet technology such as deepfakes, sharing photos of 3rd parties and so on and also deleting old information on a regular basis good behavior. It's also quite short with only 9 pages and also covers cancel culture and mobbing. I think a document like this is needed and important. Anyone here who'd like to take care or helping me making an RFC out of it? Or guide me in the right direction? I took a quick look at the draft. The Introduction section is a bit short. I suggest referring to the style guide as it may contain some guidance. Some of the etiquette in the draft is not followed outside the IETF. The topic you wrote about is not ideally suited for this mailing list as the draft is focused on etiquette. It's unlikely that the memo will be published as a RFC if the editor insists on anonymity. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Accurate history
Hi Vasilenko, At 02:22 AM 07-11-2021, Vasilenko Eduard wrote: The context was about IPv6 addressing only, not the privacy on the general scope. The second half of IPv6 address bits (64 from 128) are used only for privacy now. RFC 8981. IPv6 is 64-bit addressing architecture because of this, not 128 as many believe. The host generates different pseudo-random IIDs (64-bits) and uses them to create many temporary addresses for different sessions. Keith Moore mentioned that it is privacy. Hence, the good wastage of (2^64-1)/2^64 of IPv6 address space. I was arguing that it is fake privacy. Hence, not a justification to waste so huge address space. Thanks for the clarification about the privacy comment. The address size of IPv6 is described as 128 bits in RFC 2460. I suggest looking at "wastage" [1] from an address allocation perspective [2] instead of an address space perspective. That might make discussion of other issues, e.g. privacy, less difficult. Regards, S. Moonesamy 1. There were probably some assumptions which made sense when the protocol was designed. 2. The allocation of addresses has an impact on privacy. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Accurate history
Hi Vasilenko, I moved the thread to another mailing list. At 12:55 AM 05-11-2021, Vasilenko Eduard wrote: Privacy is a myth. OTTs deliver 70% of traffic. They could correlate users by 100 parameters (including your browser window size). Just changing IID would not impact their correlation. Not at all. Your carrier has to know all your sessions for Lawful Intercept. Whom you are trying to mislead by IID changes? It just creates a heavy load on logs collection for troubleshooting, forensic, and legal intercept. The point which you made correlation is correct. Session-level information is sometimes collected for network management purposes. An external party can request access to it for investigating, for example, a crime [1]. I doubt that the external party would use information generated through correlation (using, for example, browser information) in their investigation. IIDs, as designed, did not address privacy concerns. It could be because the assumptions were incorrect. As a response to your comment about privacy, I noticed that some participants changed their identification information over the last few years. It may have been influenced about concerns about privacy. Are you trying to say that the IETF participants' expectation of privacy does not match reality? Regards, S. Moonesamy 1. It depends on the jurisdiction. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
Hi Tim, At 05:18 22-06-2016, Tim Chown wrote: We're encouraging discussion of privacy considerations in the WG. As a result, we now have a draft (see below), including an initial proposal for a solution, for which we'd welcome wider review. The draft also addresses mDNS/DNS-SD privacy within single subnet scenarios. One of the privacy issue identified in the draft (Section 2.4) is device fingerprinting. In Section 3.1, it is proposed to solve the privacy issues described in Section 2.1 by obfuscating instance names. If I had to pick one privacy threat for that I would choose "correlation". Obfuscating service names would not address that. If I understood the draft correctly, the solution "to prevent tracking over time and location, different string values would be used at different locations, or at different times". QR-codes are used to generate a shared secret and establish trust between two or more "friends". The draft identifies the problem. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Is there an official working definition for Privacy Online?
Hello, At 15:08 05-05-2016, Dave Crocker wrote: As a social term, perhaps. Social discourse uses and often needs vagueness and even ambiguity. But again: How is it possible to use a term as a technical reference, if there is not precision to its use? This being the IETF, and 'privacy' being a particularly fashionable term, the question is fundamental. That is a good question. The regulatory perspective is different from the RFC 6973 perspective. RFC 6973 mentions specific legal frameworks. I would classify privacy under social instead of technical. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Logging Recommendations for Internet-Facing Servers
Hello, At 17:48 15-06-2014, Stephen Farrell wrote: Who knows? I would agree that the intarea is probably not a hotbed of privacy activists. But its also equally true that folks on that list are probably as clueful as here, and so may well have quite a good appreciation of how privacy is more important than previously. I am picking up the above for a general comment. Currently, there isn't any IETF guidance about privacy. A person may have a good appreciation of how privacy is more important than previously. However, it may be difficult for the person to document the considerations in words which the IETF would find acceptable. There is a message at http://www.ietf.org/mail-archive/web/int-area/current/msg03948.html which highlights the other considerations which can have an impact on privacy. I would like to encourage anyone interested in privacy to comment about the topic on the INTAREA mailing list ( https://www.ietf.org/mailman/listinfo/int-area ). Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Logging Recommendations for Internet-Facing Servers
Hi Daniel, At 11:56 17-06-2014, Daniel Kahn Gillmor wrote: I'm surprised to hear you say this, given that you're thanked in the acknowledgments section of RFC 6973 (Privacy Considerations for Internet Protocols). Do you think that RFC doesn't provide useful guidance or vocabulary? RFC 6973 was published in the IAB Stream [1]. Someone could argue that it is not an IETF document. It is not possible to argue against that. I reviewed RFC 6973 before it was published as a RFC. In my opinion it contains useful guidance and vocabulary. There is the following in RFC 6973: Protecting against stored data compromise is typically outside the scope of IETF protocols. However, a number of common protocol functions -- key management, access control, or operational logging, for example -- require the storage of data about initiators of communications. When requiring or recommending that information about initiators or their communications be stored or logged by end systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize the potential for that information to be compromised and for that potential to be weighed against the benefits of data storage. Any recipient, intermediary, or enabler that stores data may be vulnerable to compromise. (Note that stored data compromise is distinct from purposeful disclosure, which is discussed in Section 5.2.4.) With hindsight I would say that I did not pay sufficient attention to the RFC 6302 reference in the above. For what it is worth my last comments about RFC 6973 was dated February 2013. Regards, S. Moonesamy 1. http://www.rfc-editor.org/info/rfc6973 ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Logging Recommendations for Internet-Facing Servers
Hi Stephen, At 17:48 15-06-2014, Stephen Farrell wrote: So I'd say give it a whirl if you've the energy to write an I-D and fwiw I'll try push forward with good work regardless of how its locally received in one or another IETF WG (no matter the relevant WG is an area-wg). But, equally, I'm not interested in helping with work on things that haven't even tried to be run by the best list of relevant/interested folks. I do get that that's not a very clear distinction (sorry:-) but I hope it helps, and regardless am happy to chat more, on and/or off list. I understood the explanation and I am okay with it. I'll post a message to INTAREA. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Logging Recommendations for Internet-Facing Servers
Hi Stephen, At 05:51 15-06-2014, Stephen Farrell wrote: Q: How will that happen? A: Someone will need to write an I-D:-) If someone does such an I-D that is reasonable and improves privacy, I'll be happy to help that progress. Ok. Not sure if the BCP's RFC would need replacing or if updating the BCP with a 2nd RFC would be right myself, so talking to the original authors and/or the intarea list would seem wise. They might also have other stuff they'd like to revise, who knows. (The draft leading to this BCP [1] was an intarea [2] draft.) In theory a (future) RFC can be added to BCP 162. In practice people won't read it or miss it. A first step might be to talk to the authors to see what they would like to do. The INTAREA working group [1] lacks the expertise to review privacy-related drafts. People with an actual interest in privacy will have to participate in the working group and review the proposed update to BCP 162. Regards, S. Moonesamy 1. https://datatracker.ietf.org/wg/intarea/ ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] CFP: The 6th International Symposium on Cyberspace Safety and Security (off-topic)
Hello, Was the message at http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00394.html approved by the ietf-privacy mailing list moderator? Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Lawful Interception (was: In case you haven't seen it yet)
Hi Fred, At 00:50 27-02-2014, Fred Baker (fred) wrote: I'm having some problems deciphering this conversation, and the traffic-peeking draft. What is being alleged, and by whom? Nothing is being alleged. I mentioned (in the draft) that It was the belief of the IETF that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described. That's the IETF angle. As to why the document was written I consider that an open explanation has been given. I mentioned conflict of interest as it can come out like I am favoring Cisco out of interest. Between appendices B and C, I'm not sure I know the difference between wiretap and lawful intercept, which is now more properly referred to lawfully authorized electronic surveillance. If you want to know what we wrote RFC 3924, it was because RFC 2804 asked us to. If you want to know why we implemented an intercept solution, it's because our customers were required by law to deploy one, and we're their vendor. If you want to know why I got involved, it's because Johann Bakker, who at the time was holding the pen on the ETSI specification, told me that it was pushing a model in which every fiber was split and one end shoved under the intelligence service's door, which could then take what it liked. I wanted there to be a warrant before the interception took place, which is consistent with US law, and I wanted audit trails. Getting them meant I needed to be involved. And the point of all of this is...? I used wiretap in the draft as I was referring to the IETF policy. The lawful intercept is more interesting. There is a need for interception as part of the work on criminal activity in most countries of the world. The draft references legislation from the United States and the European Union as that were the only public references I could use. I avoided Latin America as the material I found was in Spanish. There is very little material for Africa online. There was also the language problem for Asia and the question of which references to choose. The material (authoritative source) from Russia was not in English. The point of all this is the tussle (Clark D., Wroclawski J., Sollins K., Braden R., Tussle in cyberspace: Defining tomorrow's Internet, 2002.). There is also the matter of understanding IETF decisions which were taken many years ago. If I look at the RFC outside that context I could form an incorrect opinion [1] (speaking for myself and not saying that it should be the right conclusion). The conclusion from the draft is: The end user will usually be at the losing end of the bargain in a tussle between the end user and government when Internet traffic wiretapping is a matter of national security. That would apply to my location. As a thought experiment if everyone on this mailing list looked into that from his/her own jurisdiction, would the conclusion be different? Regards, S. Moonesamy 1. I personally do not think that you did anything wrong in publishing that RFC. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] In case you haven't seen it yet
Hi Fred, At 00:59 26-02-2014, Fred Baker (fred) wrote: http://windowsitpro.com/identity-management/richard-clarke-rsa-conference-10-observations-us-intelligence-gathering From Mr Clarke's comments: The real solution for privacy isn't data localization; the real solution is to secure the data in the cloud. Where the server sits is unimportant. In my opinion the above conflates privacy and security. Having data in the cloud obfuscates the jurisdiction aspect. From a privacy perspective, where the server sits is important if a person would like to find out which laws may be relevant. Mr Clarke also commented that: 'One of the reasons for this loss of marketing share is because non-US companies, particularly Asian companies, are using the NSA revelations as a marketing tool to say that US products are untrustworthy because they're bugged by the NSA. Clarke said The hilarious part is that they're not. But the products you can get from certain Asian manufacturers are.' It is difficult to convince people from the rest of the world that the products from certain Asian manufacturers are untrustworthy as there aren't any reports to support that claim. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
[ietf-privacy] Lawful Interception (was: In case you haven't seen it yet)
Hi Pranesh, At 18:05 26-02-2014, Pranesh Prakash wrote: But to insist that some Asian countries (namely China, via Huawei, ZTE, etc.) do it while others like USA and Sweden don't is naive at best and duplicitous propaganda at worst: To avoid any doubt about conflict of interest I'll mention that I do not work for Cisco. I am okay with any questions about that. I prefer to answer them on i...@ietf.org. Appendix C of http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-01 discusses about lawful interception. There is a sentence about the IETF perspective about the publication of RFC 3924. There was a message from Fred Baker about why he wrote the RFC. I don't recall the reference for that as it has been a while since I looked into it. I can probably find the reference if it is really important. There are multiple aspects to the text quoted above (and the link in that message). I did an (internal) analysis to try and understand the issues. I would describe them as tackling an impossible task. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Article, toward a definition of privacy (or perhaps not).
Hi Joseph, At 07:00 18-12-2013, Joseph Lorenzo Hall wrote: Many of us from academia (in my case, having recently jumped ship for civil society) that study privacy are more persuaded by Helen Nissenbaum's notion of privacy as contextual integrity. Here's the skiny in shorter-than-book-length form: I give an account of privacy in terms of expected flows of personal information, modeled with the construct of context-relative informational norms. The key parameters of informational norms are actors (subject, sender, recipient), attributes (types of information), and transmission principles (constraints under which information flows). Generally, when the flow of information adheres to entrenched norms, all is well; violations of these norms, however, often result in protest and complaint. In a health care context, for example, patients expect their physicians to keep personal medical information confidential, yet they accept that it might be shared with specialists as needed. Patients' expectations would be breached and they would likely be shocked and dismayed if they learned that their physicians had sold the information to a marketing company. In this event, we would say that informational norms for the health care context had been violated. [1] Much of the scholarship these days in privacy thinking is increasingly based on this kind of contextual definition of privacy (and in the U.S., at least, the Obama administration embraced this in a recasting of fair information principles in their Consumer Privacy Bill of Rights). At CDT, we argue that abuse or harm is an anemic framing, and that there are important privacy interests implicated after information has been fixed and collected but before any use has been made. See Brookman and Hans [2], if you're interested in reading more. Thanks for the links. I have to read the material again. The health care context is relatively easier to argue for as a patient would expect that his/her medical information would be kept secret. There is the legal context for privacy, e.g. see message from Nat Sakimura about torts. The discussion is usually around that as the body of work is focused on the legal arguments which have been made over the years. It could be said that there are several schools of thought about the topic. For example, the above (see quoted text) looks at privacy in terms of the flow of information. It may seem a better fit in the context of technology. Some people will likely look at privacy in terms of harm or abuse. It is difficult to argue against that in an IETF discussion. Privacy considerations, up to now, can be described as lacking. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] draft-moonesamy-privacy-identifiers-00
Hi Mark, At 04:37 06-09-2012, Mark Lizar wrote: Yes, this is a very interesting point. Do we have the right to revoke our consent and change our minds? That right would not be worth much if I cannot afford a good solicitor. :-) How valid are these contracts? What takes precedence privacy rights or badly informed contracts based on marginally informed consent? I'll assume that the contract is valid. Then, what? I am back to the inevitable choice. What takes precedence is the choices the person is given through the design. The alternative is to resolve the above questions. I doubt that they can be resolved easily. If a company like Google can retroactively combined my data from a whole bunch of disparate services, utilising 10 years of data aggregation about me, for the sole purpose of profit, without my consent. How valid is a Google TOU? It's a two-way exchange where I am getting a service for free and the service provider is getting something out of it. I expect that the service provider has an economic motivation. Questions about the validity of a terms of use ends up in a legal arena. It can take years to be resolved. From the above, I'd say that it in unfair bargain. Do my privacy rights take a back seat because I use google services? I don't remember clicking an I agree button to make a Google search. No (see above). This point, for me at least, brings up many questions I don't have answers too. For instance, In the context of digital identity management, (A.K.A. the use of an identifier) is Google's use of my identifiers, based on this current policy infrastructure of informed consents, legal? Is informed consent acheived for the use of my real ID that is now a requirement of Google services? I don't have the answers too. For what it is worth, the IETF does not work on digital identity management. I suggest taking a look at draft-iab-privacy-considerations-03. Is that document a good start? Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] draft-moonesamy-privacy-identifiers-00
Hi Mark, At 15:56 04-09-2012, Mark Lizar wrote: I think it would be a mistake to blame the target audience for a lack of mature understanding of the problem. In fact, I think the audience has an incredible understanding of the problems. People can understand how much privacy practices impact them physically at the moment (immediately) and respond accordingly. Is expecting more from people too much to expect? It is the integrity of the consent mechanisms at offer, their lack of continuing context or meaningfulness that might be more worthy of responsibility. The wording could have been improved but then it discourages lightweight discussion. I didn't read it as blaming the target audience. I'll put it another way. The target audience might not be that interested in a discussion about informed consent but they do have an understanding of what they would not like to see. People are expected to make a split-second decision; i.e. it should be easy for the person to make the decision. Perhaps achieving informed consent should be looked upon as an iterative process? At the moment we have a one time policy (consent) infrastructure based on (or to facilitate) contracts of adhesion (TOS, EULA etc), in which informed consent is most often no-longer informed as soon as the service (or even the service user) evolves the use of the service. (online informed consent lacks real meaning) Privacy policies usually end up as disclaimers of liability instead of policies aimed at protecting privacy. A person might not remember all the details of what he/she consented to after a while. It may be easier for the person if the consent request is contextual. That doesn't mean flooding the person with questions as it turns into an automated yes (or no). Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] draft-moonesamy-privacy-identifiers-00
Hi Robin, At 02:33 04-09-2012, Robin Wilton wrote: This is (again) an excellent airing of the issues, I think. One theme it exposes is the difficulty of balancing two factors: 1 - achieving informed consent, when the target audience doesn't have a mature understanding of the problem, or isn't motivated to act on such understanding as they have; Yes. 2 - dealing with stakeholders who react as some did to Microsoft's DNT by default decision... i.e. by saying 'if you set a privacy feature to 'on' by default, it is not reliable because it can't be interpreted as an explicit user choice (and hence as an indication if consent). Section 5 of the draft contains the following sentence: If the intention of the person is not clear, he/she may have to be asked for consent. Now, does that mean that DNT can be turned on by default (re: the above comment)? I would base the argument on the following sentence: There is a reasonable expectation that the person will be provided with a cautionary notice to which he/she must consent to if the information being disclosed may adversely affect the person. I like your point about design never being value-neutral... Wondering if there's a sense in which designers can acknowledge that and say of course not; and these privacy-enhancing design values are legitimately preferable to those privacy-eroding ones... The term comes from the Tussle paper. That question came up during a presentation within the Security Area. It was also indirectly raised during a discussion on apps-discuss. The argument I heard is: this is how we solved the technical problem; if you have a better solution, we would like to hear it. My take is that the two sides are talking past each other. Regards, S. Moonesamy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
