Human Rights Protocol Considerations (HRPC) Meeting 22 july 2015 Prague [ dkg taking etherpad notes ] Niels ten Oever and Avri Doria chairs https://tools.ietf.org/agenda/93/agenda-93-hrpc.html Agenda bashing Status of Proposed Research Group Avri reviews history from slides. https://www.ietf.org/proceedings/93/slides/slides-93-hrpc-3.pdf Context of research: internet as a tool of freedom of expressoin and association intentional? (see RFC 1958) scale and industry have changed the situation the proposed RG's perspective suggests that the link between protocols and rights needs to become more explicit, structured, and intentional vocabulary varies between rights folks and engineers Corinne Cath takes the mic https://www.ietf.org/proceedings/93/slides/slides-93-hrpc-2.pdf 3 strategies: list of terms map cases where protocols enable or hinder FoA and FoE apply terms to cases some examples: HTTP makes it easy to publish thoughts and ideas -- FoE (also applies to XMPP) unvalidated/unencrypted protocols weaken human rights (e.g. BGP, DNS, cleartext HTTP) Future Research Joe Hall: the two drafts don't seem fully aligned. also, what does "good enough" mean? Avri: we're not even being precise enough about "Freedom of Assembly and Association", we need to be clearer and more precise. Niels: the drafts might also be recombined later. Dan York: having been at the IETF for a while, what sort of outcomes might we get? Avri: we have to figure that out. We need to map the language; once it's mapped we can sort out what we can apply, what we can do. Stephen: how do you know it's HTTP that's relevant and not the Web or DNS? What kind of help do the authors want to be able to answer that question? corinne: i'd like use cases (e.g. turkey today, iranian government) where you can see protocols enabling or infringing on rights. Robin Wilson: Glossary deals with concepts like Identity and Anonymity. those are areas where there are many relevant protocols, and how they change, how they persist, how they're trusted, etc. that's one place where one could look at ways these are applied. Bryan Ford (EPFL): I'm curious what the scope of the RG activity is. i can see three: what are the effects, what's the terminology producing an RFC6973-like RFC that focuses on HR that hopefully someone reads, what else? Is it possible that this group might be a venue to do experimental protocol development/bashing Niels: we're currently seeing the RFC6973-like RFC as the far horizon. But we'd be happy to see any additional work as well. Right now we're trying to document what's happening, so that we have a framework for analysis. Joe Hall: I'm working on a draft that documents ways that protocols are abused to harm people -- currently a "censorship draft". i think there's a lot like that. we've been considering specifying onion routing or obfsproxy here -- maybe that would be useful? Web protocols (like web fingerprinting, etc) have a risk as well. Avri: i want to see the draft. Phil Hallam-Baker (PHB): we can prevent people from getting control points. DNSSEC as a single root of trust is an example of a serious risk. Content bypass protocols also seem relevant. Tor enabled people to get snippets of cameraphone video out of Iran, which were then rebroadcast. Tor was important for publication, but not for privacy in that context. Traffic analysis is a big problem, and we don't know how to solve it. I'm nervous about creating protocols that we claim are useful for dissidents. open standards for steganography are completely bonkers. Avri: perhaps there's an analysis that can enumerate the risks people are taking so that they're aware of what's happening. Andrew Sullivan: 3 separate dimensions: how do you implement pieces that encourage some facet of things that we think are rights. -- this doesn't go all the way to implementation, though. let someone else implement it! i'm also interested in how these things interact with one another. we tend to look at one piece at a time, but systems behave different than any of their parts individually. Can we look big picture somehow? Teasing out the separate rights and think of them in engineering terms -- this might not be fruitful, because many of them are intuitively clear, but calling them a right might not give us much. Users often want something out of the world, but might not see how these things are connected. Niels takes the mic on slide 16 ------------------------------- we need better definitions we're looking at intersection of architectural principles and human rights enabling features similar to RFC4949. Accessibility ------------- Roland Bless: maybe this is missing "freely available" as paid content on the Internet exists, too-- I assume that lots of wordsmithing is needed for all definitions Anonymity --------- Dan York: process point: is your intent here to step through everything in the glossary? because we as engineers are really good at ratholing on terminology. Joe Hall: there is an IETF glossary. we should use that at least as a starting point. Brian Trammel: RFC6973 has a great glossary you could use as a starting point. Robin: Using the IETF glossaries will take you some way, but it won't take you all the way to an HR-focused glossary. Identity and Identifier are not defined in your glossary. One meaning is authentication. but other folks see it as "singling out for different treatment" Stephane Bortzmeyer: we should not re-do 4949 or 6973. but there are terms that aren't defined anywhere in the RFCs. But there are terms that are not well-defined. 6973 talks about some things but aren't defined at all, like Avri: we should look at existing glossaries, merge them, and then look at the gaps. Stephane: Decentralized is very vague, but used very positively without common meaning. For example, is XMPP centralized? it relies on DNS, which is hierarchical. But XMPP is federated. When i try to apply the term decentralized from the definition, i can't answer anything. Dan York: again, i feel like this is a rathole -- are you trying to do technical terms in HR language, or vice versa? how do we scope the list? we could cover everything! Andrew: work from the other direction: start from the rights, and then work down to the individual terms. Avri: we started like that, but we ended up going back in both directions. Andrew: right, but start with that, because a roomful of engineers is likely to take forever Ted Hardie: i see resilience in two places. I also notice that anonymity is in security, and there are many definitions of security that don't include anoynmity. also, pseudonymity is important in a lot of contexts. how does that intersect with anonymity? I agree with Andrew that starting from the freedoms and working down to the details is the way to go, but it's important to keep the ability to nit-pick a bit. please continue to nit-pick! Avri: please help us nit-pick on the list Samuel Weiler: PETS community has a lot of terms and a glossary. ???: I don't think we need a glossary per se. what we need is this sort of relationship map, which might want a glossary. make sure the goal is visible, and not just starting it as a glossary. dkg: slides are missing some things. PHB: when we added commerce to the web, we set it up so that when you wanted to open your country to commerce, you had to open it to free speech. most of us are western types -- we have a sense of freedom of expression being an individual right. but if you're working against a totalitarian regime, it's less about an individual, and more about whether those other ideas can be circulated within the country. I'm bypassing a lot of unpleasantness for the individual. But protocols don't have to handle everyone -- they just need to be able to have enough freedom for the ideas to flow. Niels: non-discrimination is another element that wasn't included in the drafts yet. maybe non-discrimination is a subpart somewhere? these terms become interdependent, and creating a complicated graph. Travis Pryor: most of this is solved already in linguistics. they've got these relationships mapped out. I'll send something to the list. Niels: Nick Doty has some work done showing an analysis of RFCs. [ describes the graph a bit ] Dan York: this looks cool, but what are we trying to get to? what are the technological pieces that support that right at a high level? Roland Bless takes the mic for https://www.ietf.org/proceedings/93/slides/slides-93-hrpc-2.pdf defines Values and Human Rights. shows relationships of rights, including conflicts. conflict resolution strategies: enigneering choice and markets policy and regulation institutions and their values can be implemented and enforced by software [ see slides ] work from both directions: values → tech principles, and vice versa back to the mics: Andrew Sullivan: in this presentation, it's clear that some technical choices have these value propositions. this is leading us toward an idea that all technical choices have implications for social values. There are technical tools that have multiple uses, like packet capture: does it make surveillance possible or does it help us get emergency calls through first? Roland: liberal designs might be a good way to go -- sometimes allowing people to make decisions is the best choice Nalini Elkins: we need to be able to express sometihng about default values, but most folks don't have the sophistication to be able to make the complex decisions we're asking of them. Maybe we can make the default option more relevant. most people think the only way to avoid surveillance is to avoid tech entirely. Roland: Ted Hardy: the IAB's statement for default encryption is to avoid people losing trust in the Internet. back to slide 7. I used to be an anthropologist. Slide 7 is subtly wrong. the technical norms have enormous cultural expectations in the way they're put together. one of the reasons i got into this field was because i was fascinated by watching people narrow down all these options they had into sometihng that looked like what they were used to. e.g. building e-mail and talking about envelopes, etc. they built things that worked fine for a few folks, but when it scaled up, it causes a bunch of other problems. (e.g. spam or reply-all threads). I like slide 13, but you have to undersand that we at the IETF cover much more than technical norms. the cultural assumptions are pervasive. Bryan Ford: Thanks for covering conflicts between values! It's really important in concept mapping to identify where values can be translated. for example, freedom of speech can be taken down by censors or governments, or by an anonymous troll harrassing me away from a forum. Stephan Moeller(?): there's a field in ethics called value-sensitive design from the U of Washington. Roland Bless: we're aware of that, and are thinking about it. Joe to the mic -------------- Survey of worldwide censorship techniques. trying to list all cases where we've seen folks use protocols to block or impair traffic, incl. TCP RST, adversarial BGP announcements. Engineers might not care about human rights, but maybe if you care about censorship specifically, it'll help you figure out how to harden your protocols against it. maybe this work is complementary to the work going on here. Avri: this is a document, not an online tool, right? Corinne was looking for case studies. can you connect that with her? Joe: maybe i'll bring it into the hrpc? Stephen Farrell: i wouldn't put it into the IRTF, try to get broader IETF review. Avri: AOB? Robin: Andreas Pfitzmann and Marit Hansen wrote a great paper on identifiability / anonymity / linkability / observability /etc, see https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf Dan York: "thanks" for the red slides. Please think more clearly about outputs. examples for how to use the IETF protocols to support human rights; thinking about the ecosystem approach. Avri: if you don't have the bandwidth to fully-help -- does that mean that you have the bandwidth to partially help? Dan York: i will review documents Mike Alexander (VSC): Changing protocols is hard, extending them is hard, but proxies can make quick and dirty changes. maybe a quick and dirty norm-enhancing proxy is possible. Brian Ford: concepts/terminology, censorship methods, etc. can we have a fourth draft that collects/summarizes things that have been suggested as defense at the IETF. a solutions draft. Avri: if we have ways to write up connections between issues and Lars: [asks the room about support and interest ] concludes that it seems active and present.