Protocols and Human Rights: Notes
Friday, July 21, 9:30am

Minute taker:
    Alp Toker
    
Jabber scribe:
    Shane Kerr

Research group - history from 2014 to date.

Presentation with Milton Mueller: Requiem for a Dream:
    [Speaker Farzaneh Badii unable to attend due to travel difficulties]
    [See slides]
    lessig, Ridenberg, Mitchell: "code is law"
    Decisions taken at IETF may take some time to make change
    Nw IETF processes may be needed to assess HR considerations
    Yet task of addressing HR with protocol design must be approached soberly

Discussion:
    Andrew Sullivan asks: Involving standards process in / political tussles. Gentler reading of the document - getting protocol authors to think about the impact and rights enabling/disabbling consequences.
    M. replies: I wouldn't want policy makers or lawyers to have any kind of gatekeeping role. Protocols can bbe used by people whose purposes you don't know.

    Bob Hinden asks: Privacy and encryption in line with HR work. e.g. stopping middle boxes from accessing traffic. Protocols not static.

    M.: That's a balance - policy makers or no? Designers probably may know exactly what HR concerns are.


    Q: We can build in capabilities as protcol designers. Policy makers are already in the room and we can't exclude them. IETF has responsibility to include HRC and other bodies will just have to live with that.

    M: Move to the cloud is going to have policy implications that there's no way to design for. Becomes a regulatory probblem, an outcome of a series of technical decisions. When it comes to TLS, some states may try to regulate infrastructure - no guarantee more secure points will be adopted.


    Niels ten Oever: Dave Clark once said "There is a tussle" - we need to make the tussle more explicit. What are you adding to the discussion? Raven process, weaking of crypto standards have already been seen. "Affordances". You cannot predict HR impact, but that doesn't mean we shouldn't think about it or model it. Tendency toward centralisation leads to less resilient networks.

    M: Radio led the way, then became institutionalized. [more historical examples] I don't see how you're challenging my point.Tussle just a new word for and old concept.


    Allison Mankin IRTF chair: Algorithmms and regulation, media and 4th estate - comment?

    M.: No free lunch in regulating this capability. Haven't focused on algorithmic responsibility in  current research.


    Q: We see more and more monopolies because tech becomes expensive to build - big implications for HR?

    M: Tim Woo calls this the "Cycle" - early stages are small scale and free, then regulation, then perhaps later on disruption. Economic issues have as much impact as legal issues.



draft-tenoever-hrpc-anonmyity-00:
    Check room: Is anyone interested 
    
    Bortzmeyer: I offered to help but didn't do anything. Asking if anyone else wants to help?
    Tara offered to help.
    

draft-tenoever-hrpc-association-01:
    Gisela Perez de Acha [via videolink]
    Is the internet itself an association/assembly, as IETF itself is.
    Free association vs. forced association.
    DDoS could be "forced assocation" if IoT equipment hijacked
    Centralized vs. decentralized - which is better for freedom of expression and association?
    Internet access should be protected under free association.
    
Comments:
    Tara, OTF: How about the "right to be offline"? Is that a right?
    Gisela: If the internet is association, then of course you have the right to be offline otherwise it would be forced association.
    
    Steven Farrell: DDoS slide misquoted. DDoS already documented as an attack - if not clear enough, we should clarify that.
    
    
Andrew Sullivan:
    (tenoever-hrpc-political)
    On the politics of standards
    [see slides]

Comments:
    Shane Kerr: It's helpful to write things down in a structured format. No harm in publishing it as an RFC.

    Bortzmeyer: There's a lot of overlap with the HRPC draft. Hard to read - a short draft for ordinary participants could be useful. Purpose.
    
    Georg Mayer: Extending protocols from outside can be difficult - owner of a protocol often has control over it.
    A.S.: Can you give examples where IETF or author said no?
    G.M.: e.g. Circuit-switched network with SIP.
    
    Tara: Technology is not value-neutral.
    
    Victoria: Protocol police conversation is ambiguious - good to be clarifying roles.
    
    Steven P: I'm not at all sure this is useful - deploying a document like this.
    A.S.: Yes, for a lot of participantes it's opaque.
    
    NtO: We find that protocol has impact on HR - but that doesn't make it political.
    
    Steven: Maybe this paper would be better as an academic thing, not necessarily apppropriate or useful for IETF/IRTF.


Presentation with Alp Toker, Olga Khrustaleva, Shivan Kaul Sahib : Legal Content Restrictions: HTTP 451:
    [see slides]

Discussion:
    useful for transparency
    "could be dangerous" to encourage 451