Re: [hrpc] Late Review of draft-irtf-hrpc-guidelines-16

On Tue, Mar 14, 2023 at 9:42 AM Niels ten Oever <mail@nielstenoever.net>
wrote:

> It has been roughly a month since this response was posted. I want to make
> sure this addressed all issues and we can move forward with this draft?
>

Thanks for the reminder. No, I do not believe it addressed all issues. I've
replied in detail separately.

-Ekr

> Best,
>
> Niels
>
> On 21-02-2023 12:22, Gurshabad Grover wrote:
> > Thank you for your review. v -17 of the draft is up now, which addresses
> your comments. Please see in-line for responses.
> >
> > On 12/26/2022 10:58 PM, Eric Rescorla wrote:
> >>
> >> FRAMING
> >> The framing of this document centers the conduct of a "human rights
> >> review" (Section 3) and the document talks about a Human Rights Review
> >> Team. The implication is that there is some body (HRPC?) that stands
> >> outside the ordinary IETF protocol design and development process and
> >> somehow reviews protocols for their impact on human rights. It seems
> >> to me that the available evidence is that this is not a great model,
> >> ranging from the social (nobody likes outsiders coming in and telling
> >> you you're doing it wrong) to practical (it fosters a shallow form of
> >> engagement that is insufficient to address complex technical
> >> problems.) My one experience with application of the methodology in
> >> this document
> >> (https://datatracker.ietf.org/doc/html/draft-martini-hrpc-quichr-00 <
> https://datatracker.ietf.org/doc/html/draft-martini-hrpc-quichr-00>),
> >> seemed to me to follow this pattern.
> >>
> >> As a comparison point, I think it's useful to consider security review
> >> and the methodology described in RFC 3552. At the time of the writing
> >> of 3552, there was already broad consensus that Security
> >> Considerations needed to be part of protocol development and
> >> documentation and fairly broad agreement on how to do that analysis
> >> (what threats should be considered, available technologies, etc.), as
> >> well as an entity (the Security ADs) who was specifically empowered to
> >> enforce security requirements. Despite that, there have been
> >> persistent tensions due to differing views of what security tradeoffs
> >> were appropriate between participants in different IETF areas. I think
> >> experience clearly indicates that reviews of nearly finished protocols
> >> are of limited usefulness here; what has worked much better is where
> >> security expertise is baked into the process early, as with QUIC.
> >>
> >
> > Section 3 aims to describe the methods of conducting a review based on
> the guidelines (as a work-in-progress) or in conjunction with them. The
> "human rights review team" is/was a small informal team that worked on
> applying these guidelines and improving this document. Personally, I see no
> implication of the text (as you point out) that there is some body "that
> stands outside the ordinary IETF protocol design and development process
> and somehow reviews protocols for their impact on human rights."
> >
> > I think the document is quite clear in saying:
> >
> > "Human rights reviews can be done by any participant, and can take place
> at different stages of the development process of an Internet-Draft.
> Generally speaking, it is easier to influence the development of a
> technology at earlier stages than at later stages. This does not mean that
> reviews at last-call are not relevant, but they are less likely to result
> in significant changes in the reviewed document."
> >
> > Which to me is exactly what you are saying: that ideally, participants
> should be involved as early as possible in the working group.
> >
> > As a separate point: While it's not possible for me here to summarise
> every review that has been done in the past, there are some reviews you can
> read in a github repo. [0] In my experience, reviews have successfully
> resulted in some sort of change to Internet Drafts (and have been
> appreciated by authors/some of the working group participants).
> >
> >> It seems to me that there are at least two reasons why protocols might
> >> have human rights properties that are less good than we might like:
> >>
> >> 1. Protocol designers don't care as much about human rights issues
> >>     as one might want.
> >> 2. Protocol design is a matter of compromise and so we
> >>     end up with designs which try to balance those and so
> >>     necessarily have suboptimal properties.
> >>
> >> The majority of the text here seems to be devoted to justifying why
> >> various technical features are necessary for human rights, which
> >> implies that the problem is (1) but in my experience, (2) is much more
> >> common. It's of course true that people have different judgements
> >> about what's important, but in many cases it's simply a hard problem
> >> to provide privacy, censorship resistance, etc.
> >>
> >
> > Thanks for framing it like this. Based on my experience in some working
> groups and my reading of some ietf discussions, I think that (1) and (2)
> co-exist. For our purposes, I don't think it matters what is more
> prevalent, because the document has both goals.
> >
> > That is, I actually think it is quite okay to me if the document seems
> "devoted to justifying why various technical features are necessary for
> human rights", because that is one of the goals of the document and the RG.
> >
> > The other goal is to provide practical guidance to reviewers/protocol
> designers. More on that below.
> >
> >> I found much of the material here very abstract and not of much use to
> >> a working protocol designer. Let's take the discussion of anonymity
> >> and pseudonymity in S 4.14 and S 4.15 (see more below as well.)  The
> >> basic problem from a designer's perspective is that there are many
> >> reasons that protocols need various kinds of identifiers and yet those
> >> degrade privacy. So, the question is what technologies are available
> >> to improve privacy while also providing the necessary protocol
> >> functionality. This section is of little help in addressing that
> problem.
> >>
> >> Second, much of the content in this document seems to be just about
> generic
> >> properties that I think there is broad consensus protocols should
> >> strive for (e.g., connectivity, reliability, etc.) that have been
> >> labelled here as important for human rights. I'm not saying that that
> >> isn't true, but in the context of this document, I don't think it's
> >> very helpful, for three reasons:
> >>
> >> 1. As I said, these are properties that we generally aim for in
> >>     any case, and so are likely to be covered by others.
> >>
> >> 2. The discussion here is fairly shallow and not really of much
> >>     help in achieving these properties.
> >>
> >> 3. It distracts from the properties that are more distinctively
> >>     about human rights and might not otherwise be considered.
> >>
> >> IMO this document would be improved by focusing specifically on those
> >> distinctive human rights properties and providing a much more in-depth
> >> treatment. To return to the discussion of anonymity and pseudonymity,
> >> it would be very useful to provide a discussion of the problem of IP
> >> identifiers in protocols and of various ways to address the associated
> >> privacy issues in different contexts. For instance, if you wanted to
> >> talk about DNS, this could include material on proxying, caching, PIR,
> >> etc.  (as well as a discussion of the tension between the privacy
> >> afforded by caching and the tension with the recursive seeing your
> >> query). This would be far more useful to protocol designers than
> >> what is currently there.
> >>
> >
> > The HRPC RG does have documents dedicated to specific rights, and their
> aim is exactly what you describe.
> >
> > In this document, while we have aimed to provide practical guidance on
> how to make trade-offs, some abstract guidance was inevitable because
> application of these principles is quite contextual. Based on your other
> comments (below), will try to improve the specifics.
> >
> >>
> >> DETAILED COMMENTS
> >> S 4.1.
> >>     Question(s): Does your protocol add application-specific functions
> to
> >>     intermediary nodes?  Could this functionality be added to end nodes
> >>     instead of intermediary nodes?
> >>
> >> There are plenty of functions which *can* be performed at end nodes
> >> but which are much better performed at what one might consider
> >> intermediaries. The question is where the function is best performed.
> >>
> >
> > To me, the questions here are simply pointing towards the end-to-end
> principle. Note also the use of "application-specific" in the question.
> >
> > When you say that the question is "where the function is best
> performed", it is not clear to me what the parameters of determining what
> the "best" is. Is it efficiency? Is it security?
> >
> >>     Is your protocol optimized for low bandwidth and high latency
> >>     connections?  Could your protocol also be developed in a stateless
> >>     manner?
> >>
> >>     Explanation: The end-to-end principle [Saltzer] holds that certain
> >>     functions can and should be performed at 'ends' of the network.
> >>     [RFC1958] states "that in very general terms, the community believes
> >>     that the goal is connectivity [...] and the intelligence is end to
> >>     end rather than hidden in the network."  Generally speaking, it is
> >>     easier to attain reliability of data transmissions with computation
> >>     at endpoints rather than at intermediary nodes.
> >>
> >> A few points here:
> >>
> >> 1. I don't see that the E2E principle has a lot to do with connectivity
> >> and low bandwidth, so perhaps you need some rewrite here.
> >>
> >
> > I think the E2E principle is quite relevant to the first question under
> the same subheading, not to the latter. The second paragraph of the
> explanation relates to connectivity and low bandwidth.
> >
> >> 2. ISTM that the statement that opens this paragraphs is kind of
> >> overgeneralizing the E2E argument. There are plenty of cases where
> >> end-to-end systems are possible but behave much worse. To take one
> >> example, P2P delivery systems have much worse reliability and
> >> performance problems than centralized CDN-type systems.
> >>
> >
> > Not sure what the over-generalization is, we are not talking about
> decentralised or end-to-end "systems" in the text you are referring to. I
> think the question and associated statement are about network protocols and
> where to place "application-specific" functions. So, in fact, it is a
> narrow reading of the E2E principle. For instance, one could argue that
> many protocols that respect the E2E principle can (and do) operate in a
> centralized CDN-stype environment. However (un)desirable the system itself
> is not something we aim to touch upon here.
> >
> >>     Example: Encrypting connections, like done with HTTPS, can add a
> >>     significant network overhead and consequently make web resources
> less
> >>     accessible to those with low bandwidth and/or high latency
> >>     connections.  [HTTPS-REL] Encrypting traffic is a net positive for
> >>     privacy and security, and thus protocol designers can acknowledge
> the
> >>     tradeoffs of connectivity made by such decisions.
> >>
> >> HTTPS actually does not really add significant network overhead for
> >> most traffic. What it does--and what this citation says--is prevent
> >> caching by intermediaries (which, incidentally, makes it an odd
> >> example to provide in the context of this section). You should rewrite
> >> this text. It would also be nice to provide a better reference than a
> >> blog post, e.g., one that provided at-scale measurements and not
> >> just anecdotes.
> >>
> >
> > The example was to say precisely that: that while caching by
> intermediaries may be beneficial, encrypting connections is a "net
> positive" because of other considerations. I've removed that reference.
> Here's what it reads like now, and I hope it's fine:
> >
> > "Encrypting connections, like done with HTTPS, can prevent caching by
> intermediaries and possibly add a network overhead, making web resources
> less accessible to those with low bandwidth and/or high latency
> connections. However, encrypting traffic is a net positive for privacy and
> security, and thus protocol designers can acknowledge the tradeoffs of
> connectivity made by such decisions."
> >
> >>
> >> S 4.2.
> >>     It is important here to draw a distinction between random
> degradation
> >>     and malicious degradation.  Many current attacks against TLS
> >>     [RFC8446], for example, exploit TLS' ability to gracefully downgrade
> >>     to non-secure cipher suites -- from a functional perspective, this
> is
> >>     useful; from a security perspective, this can be disastrous.  As
> with
> >>
> >> I'm not sure what paragraph this is referring to. Are you saying that
> >> there are a lot of current attacks on cipher suite negotiation in the
> >> wild? If so, that seems like a surprising result, and I would expect
> >> to see a citation to it.
> >>
> >> Alternately, perhaps you're referring to attacks like FREAK or Logjam,
> >> and "many current" means "a number of papers have been recently
> >> published". If that's what you mean, then this is pretty confusing
> >> because (1) those papers are now fairly old and (2) your citation to
> >> TLS 1.3 which is designed to resist those attacks and (3) many
> >> implementations removed the offending cipher suites because of this
> >> work.
> >>
> >> In either case, this text really needs a rewrite.
> >>
> >
> > Thanks, you're right, re-wrote this part.
> >
> >>
> >>     useful; from a security perspective, this can be disastrous.  As
> with
> >>     confidentiality, the growth of the Internet and fostering innovation
> >>     in services depends on users having confidence and trust [RFC3724]
> in
> >>     the network.
> >>
> >> It's not clear to me that this is true, given that we know that the
> >> Internet grew very quickly in a setting where there was very little
> >> encryption (recall that HTTPS usage was well under 50% in 2014). Do
> >> you have a citation for this claim?
> >>
> >
> > Right, that claim wasn't necessary there. Removed it.
> >
> >>     Example: In the modern IP stack structure, a reliable transport
> layer
> >>     requires an indication that transport processing has successfully
> >>     completed, such as given by TCP's ACK message [RFC0793], and not
> >>     simply an indication from the IP layer that the packet arrived.
> >>
> >> This is kind of an odd sentence. I mean, it's true that this is how
> >> TCP is architected, but actually one could imagine having a system
> >> which just acknowledged the IP packet which would probably work
> >> almost as well. I agree that the E2E argument suggests that this
> >> is not as good, but then that's not what this section is about.
> >>
> >
> > Agreed, removed the reference to the IP packet.
> >
> >>
> >> S 4.3.
> >>
> >>     Question(s): If your protocol impacts packet handling, does it use
> >>     user data (packet data that is not included in the header)?  Is it
> >>     making decisions based on the payload of the packet?  Does your
> >>     protocol prioritize certain content or services over others in the
> >>     routing process?  Is the protocol transparent about the
> >>     prioritization that is made (if any)?
> >>
> >>     Explanation: Content agnosticism refers to the notion that network
> >>     traffic is treated identically regardless of payload, with some
> >>     exceptions where it comes to effective traffic handling, for
> instance
> >>     where it comes to delay-tolerant or delay-sensitive packets, based
> on
> >>     the header.  If there is any prioritization based on the content or
> >>     metadata of the protocol, the protocol should be transparent about
> >>     such information and reasons thereof.
> >>
> >>
> >> I don't think that this is a very helpful framing around content
> >> agnosticism, for a nunmber of reasons.
> >>
> >> 1. It's possible to do traffic class discrimination based on data
> >>     that is solely in the headers, and as more traffic is encrypted,
> >>     increasingly this will be the main way in which people do it,
> >>     focusing on the payload doesn't help much.
> >>
> >> 2. There are at least arguably valid reasons for providing
> >>     differential treatment for different traffic classes. This is
> >>     handled here in a sort of brief aside around "delay-tolerant", but
> >>     that's of course not the only reason (e.g., DoS). I'm not as
> >>     sympathetic to these areguments as some others, but I think they
> >>     deserves a more thorough treatment than provided in this section.
> >>
> >> 3. In general, it's not really the *protocol* which provides
> >>     differential treatment. It's an operational practice. The
> >>     protocol can either enable or prevent it.
> >>
> >>
> >
> > All your points are valid. If the protocol enables traffic
> differentiation, the document asks for transparency for it. That's it.
> Slightly changed the language here based on point 3, but not sure what
> other changes you'd like to see.
> >
> >>     Example: Content agnosticism prevents payload-based discrimination
> >>     against packets.  This is important because changes to this
> principle
> >>     can lead to a two-tiered Internet, where certain packets are
> >>     prioritized over others on the basis of their content.  Effectively
> >>     this would mean that although all users are entitled to receive
> their
> >>     packets at a certain speed, some users become more equal than
> others.
> >>
> >> I think it's important to distinguish between user identity and user
> >> behavior. If, for instance, a carrier prioritizes traffic to their
> >> own video service over some other service, it's not that they
> >> are giving Alice more bandwidth than Bob based on their status.
> >> This might or might not be objectionable, but it's not as simple as
> >> "some users become more equal than others".
> >>
> >> I suppose you could say that they are delivering their own packets
> >> at a certain speed but not the other video service, but those
> >> entities are not what people typically think of when they think
> >> of "users" and of course in that case the video service is not
> >> a customer of the carrier, so the relationships are complicated.
> >>
> >
> > Sure, users can be individuals, groups, or categories of users. Not sure
> this goes against the existing text.
> >
> >>
> >> S 4.4.
> >>
> >>     In the current IETF policy [RFC2277], internationalization is aimed
> >>     at user-facing strings, not protocol elements, such as the verbs
> used
> >>     by some text-based protocols.  (Do note that some strings are both
> >>     content and protocol elements, such as identifiers.)  Given the
> >>     IETF's mission to make the Internet a global network of networks,
> >>     [RFC3935] developers should ensure that protocols work with
> languages
> >>     apart from English and character sets apart from Latin characters.
> >>     It is therefore crucial that at the very least, the content carried
> >>     by the protocol can be in any script, and that all scripts are
> >>     treated equally.
> >>
> >> This text (and in particular "at the very least") seems to imply that
> >> it's the opinion of this draft (and hence HRPC) that identifiers
> >> should in fact be internationalized, but that that's not IETF
> >> practice, but it doesn't actually say that. I don't think that that
> >> form of I18N is a particularly good idea, but in any case, this text
> >> should be clearer about whether it's disagreeing with that policy.
> >>
> >
> > Thanks, simplified the language here.
> >
> >>
> >> S 4.7.
> >>
> >>     Question(s): Does your protocol support heterogeneity by design?
> >>     Does your protocol allow for multiple types of hardware?  Does your
> >>     protocol allow for multiple types of application protocols?  Is your
> >>     protocol liberal in what it receives and handles?
> >>
> >> See here:
> https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-10.html <
> https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-10.html>
> >>
> >>
> >>     Example: Heterogeneity is inevitable and needs be supported by
> >>     design.  Multiple types of hardware must be allowed for (e.g.,
> >>     transmission speeds differing by at least 7 orders of magnitude,
> >>     various computer word lengths, and hosts ranging from memory-starved
> >>     microprocessors up to massively parallel supercomputers).
> >>
> >> This graf seems either trivial or wrong. Yes, the Internet needs to
> >> work over a wide range of hardware scenarios (trivial) but we
> >> routinely design protocols that are intended to work only in
> >> relatively modern computing environments, so the implication here that
> >> everything we do has to work on every kind of computer is just
> >> wrong. Indeed, that's why we see WGs/protocols that are targeted
> >> specifically for resource-constrained environments.
> >>
> >
> > Don't think the intention here is to document current practice, but
> point taken and guidance relaxed a bit.
> >
> >>
> >>     Example: WebRTC generates audio and/or video data.  In order to
> >>     ensure that WebRTC can be used in different locations by different
> >>     parties, it is important that standard Javascript application
> >>     programming interfaces (APIs) are developed to support applications
> >>     from different voice service providers.  Multiple parties will have
> >>     similar capabilities, in order to ensure that all parties can build
> >>     upon existing standards these need to be adaptable, and allow for
> >>     permissionless innovation.
> >>
> >> I have no idea what this paragraph means. WebRTC *consists of*
> >> standardized APIs. Are you just stating that fact? Arguing for
> >> something new?
> >>
> >
> > It is indeed an example. Edited the langauge for clarity.
> >
> >>     Alice wants to communicate with Bob.  Alice sends data to Bob.
> >>     Corinne intercepts the data sent to Bob.  Corinne reads and alters
> >>     the message to Bob.  Bob can see that the data did not come from
> >>     Alice.
> >>
> >> This is not quite correct. What Bob can see is that he is unable
> >> to verify that the data came from Alice, not that it did not come
> >> from her. Consider, for instance, the case where you do a DNS
> >> resolution and some intermediary strips the RRSIG. The data is
> >> still authentic, just not verifiable.
> >>
> >
> > Right, corrected.
> >
> >>
> >> S 4.11.
> >> This section seems to conflate two different questions:
> >>
> >> - Technical: does the protocol provide confidentiality
> >>    (i.e., is it encrypted)
> >>
> >> - Policy: are there mechanisms to address sharing by
> >>    entities which can see the data
> >>
> >> For good or bad, IETF protocols typically treat these policy questions
> >> as out of scope. I think this section would be a lot clearer if you
> >> focused on the technical questions.
> >>
> >
> > While it discusses aspects of both, I think the section is quite clear
> in delineating between them. For instance: "If no such mechanisms or
> controls are specified, is it expected that control and consent will be
> handled outside of the protocol?"
> >
> >>
> >> S 4.14/S 4.15
> >> I don't think separating out pseudonymity from anonymity is useful in
> >> this context. For instance, it's weird to talk about ODoH in the
> >> context of pseudonymity, when it's actually about providing anonymous
> >> access (there's no pseudonymous identifier).
> >>
> >> Protocols can contain identifying information that varies along at
> >> least two axes:
> >>
> >> - Resolution (e.g., k in k-anonymity)
> >> - Temporal stability
> >>
> >> At one extreme, we have complete anonymity in a system like a mixnet,
> >> and at the other we have a system with permanent identifiers that are
> >> scoped to a single person (e.g., something like social security
> >> numbers). In the middle, we have a pile of different types of
> >> identifying information with different properties, e.g.,
> >>
> >> - IP addresses (low k, fairly stable)
> >> - Fingerprinting (low to high k, somewhat stable)
> >> - QUIC connection identifiers (k=1, not that stable)
> >>
> >> Trying to cram this into a pseudonymity vs. anonymity framework
> >> doesn't seem that useful. For instance, is a QUIC CID a pseudonym?
> >>
> >> I would rewrite these sections something like as follows:
> >>
> >> - Talk about the various threats and forms of leakage, including:
> >>    identication, linkage, and reidentification
> >>
> >> - Describe the protocol situations where some form of persistent
> >>    identity is required and at which time scales, e.g., connection
> >>    identifiers, user continuity identifiers, communication addresses,
> >>    etc.
> >>
> >> - Describe technical mechanisms for providing privacy against
> >>    the backdrop of those protocol mechanisms. For instance:
> >>
> >>    + TLS 1.3 encrypts the PSK identity to avoid allowing outsiders
> >>      to link multiple connections to the same user
> >>
> >>    + ODoH provides privacy in the face of the fact that the IP
> >>      address (needed for communication) is identifying
> >>
> >>    + Cookie isolation mechanisms prevent third party tracking via
> >>      what is otherwise an identifier (the cookie)
> >>
> >> I think this will be a lot clearer.
> >>
> >
> > While I'm not sure I agree with everything here, I think your comment
> points to the fact that pseudonymity and anonymity perhaps deserve their
> own detailed treatment in another I-D. I'm happy to collaborate on such an
> exercise. At this stage, I don't think we can make such large edits (and
> try to re-establish consensus in the RG).
> >
> >>
> >> S 4.16
> >> I don't think that the discussion of new user-level identifiers is that
> >> useful in the context of censorship resistance. It's of course true
> >> that user identifiers can be used to target people visiting certain
> >> sites but this is more about anonymity (see above) than censorship.
> >>
> >>     Example: Identifiers of content exposed within a protocol might be
> >>     used to facilitate censorship, as in the case of Application Layer
> >>     based censorship, which affects protocols like HTTP.  In HTTP,
> denial
> >>     or restriction of access can be made apparent by the use of status
> >>     code 451, which allows server operators to operate with greater
> >>     transparency in circumstances where issues of law or public policy
> >>     affect their operation [RFC7725].
> >>
> >>     If a protocol potentially enables censorship, protocol designers
> >>     should strive towards creating error codes that capture different
> >>     scenarios (blocked due to administrative policy, unavailable because
> >>     of legal requirements, etc.) to minimize ambiguity for end-users.
> >>
> >> This set of paragraphs seems pretty confusing. Specifically, I don't
> >> think it's really the case that HTTP "facilitates" censorship. HTTP is
> >> a fairly typical client/server protocol, and the censorship in this
> >> case consists of governments telling the servers not to serve a given
> >> piece of content, so there's nothing specific about HTTP which really
> >> "enables" or "facilitates" censorship (it's of course true that if
> >> it's in the clear then censorship is easy, but 451 is designed to
> >> operate in cases where the data is encrypted over HTTPS).
> >>
> >
> > Don't think it's unfair to say that elements in the HTTP protocol
> "facilitate" censorship.
> >
> > Not sure how your point about 451 leads to different text here, but I
> disagree with it in any case. RFC7725 specifically says that the "server in
> question [returning the 451] might not be an origin server.", because legal
> orders "typically most directly affects the operations of ISPs and search
> engines." If the requests were in plaintext, one could also an imagine an
> ISP intercepting the requesting and injecting a 451 response and page.
> >
> >> It's of course true that there are P2P protocols which are more
> >> resistant to this kind of blocking at a particular server, but given
> >> that they have very little deployment, it's not clear that they in
> >> practice have better censorship properties; in fact, due to their bad
> >> privacy properties, it's possible they have much worse properties for
> >> targeting people who try to retrieve disfavored content.
> >>
> >> It's a serious omission that this section doesn't talk about the
> >> primary forms of censorship we see now, which are focused on various
> >> kinds of blocking, either of DNS or of connections to specific
> >> servers. You should add discussions of these techniques as well as
> >> countermeasures such as Tor, ECH, DoH, etc.
> >>
> >
> > There is a reference to an ID <
> https://tools.ietf.org/html/draft-irtf-pearg-censorship> which describes
> censorship techniques in much clearer detail. We did not find it necessary
> to repeat that here.
> >
> >>
> >> S 4.20.
> >> I agree that you're identifying a useful tension here between
> >> anonymity and addressing misbehavior, but the discussion here just
> >> says "yeah, there's a tension", which seems unhelpful.  Do you have
> >> any guidance for how protocols could be designed to address both of
> >> these cases? Examples seem pretty thin on the ground, but I would at
> >> least cite message franking as implemented in Facebook Messenger.
> >>
> >
> > I think we've had multiple threads to fine-tune this text so that it
> represents some consensus in this RG, so I'm hesitant to change it. I
> disagree that it does not offer an opinion, it is saying that in the
> general case, adding identifiers just to provide avenues or remedy probably
> inconsistent with human rights (because of its effect on other rights).
> >
> > I agree that citing some more examples would be useful here. I've added
> message franking and a recent paper on this as examples.
> >
> > Thank you.
> > -Gurshabad and Niels
> >
> > _______________________________________________
> > hrpc mailing list
> > hrpc@irtf.org
> > https://www.irtf.org/mailman/listinfo/hrpc
>
> --
> Niels ten Oever, PhD
> Co-Principal Investigator - critical infrastructure lab - University of
> Amsterdam
>
> W: https://criticalinfralab.net
> W: https://nielstenoever.net
> PGP: 4254 ECD5 D4CF F6AF 8B91 0D9F EFAD 2E49 CC90 C10C
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>