Subject: Re: [hrpc] hrpc Digest, Vol 6, Issue 1

From: Corinne Cath <[email-masked]>
Date: Wed, 4 Mar 2015 15:18:56 +0000

Dear all,

Just a thought:

It's clear that there are privacy considerations w/ standards, and security
issues, of course, and those are both human rights issues even though  IT
privacy and security are not usually framed within a human rights context.
However, should we be even more specific in this document of what makes
standards development different from any other Internet/IT engineering
issues?

Users interface with software and hardware more than they do with
networking or encryption standards. Why are protocols / standards unique?
Or perhaps more relevant, how do we justify our particular focus on them.
It's a small thing - but I think it might make the document a little
stronger still if we address this issue, because I feel this might be a
point of critique brought up at the upcoming meeting.

On that same note - I recently booked my flight to Dallas and look forward
to meeting everyone who will also be attending.

Best,

Corinne

On Wed, Mar 4, 2015 at 11:00 AM, <[email-masked]> wrote:

> Send hrpc mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.ghserv.net/mailman/listinfo/hrpc
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hrpc digest..."
>
>
> Today's Topics:
>
>    1. new draft text for the ID (Niels ten Oever)
>    2. relevant UNESCO draft document (Stephen Farrell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 03 Mar 2015 14:23:34 +0100
> From: Niels ten Oever <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [hrpc] new draft text for the ID
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear all,
>
> Based on the traffic on this list, some interviews and discussions I
> drafted new text for the ID. The additions are to 2. research topic
> and 3. Proposal. I pasted the proposed text underneath, happy to discuss.
>
> The deadline for sending in the ID is the 9th, and since we will also
> need to consolidate the comments and put the ID in XML it would be
> greatly appreciated if you could comment in the coming days (before
> the 7th) so we can still integrate your comments in the ID, but of
> course also happy to discuss afterwards and in Dallas.
>
> Looking forward to your comments, questions and suggestions.
>
> Best,
>
> Niels
>
> PS The original ID can be found here:
> https://tools.ietf.org/html/draft-doria-hrpc-proposal-00
>
> 2.  Research topic
> In a manner similar to the work done for RFC 6973 [RFC6973] on Privacy
> Consideration Guidelines, the premise of this research is that some
> standards and protocols can solidify, enable or threaten human rights,
> such as freedom of expression and the right to association and
> assembly online.
>
> RFC 6973 however asserts privacy as a subset of security, and security
> aims to solely serve growth of the network and communication:
>
> Development of security mechanisms is seen as a key factor in the
> future growth of the Internet as a motor for international commerce
> and communication.[RFC1984]  and according to the Danvers Doctrine,
> there  is an overwhelming  consensus in the IETF that the best
> security  should be used and  standardized.[RFC3365]. At the same time:
>
> The  Internet Architecture Board (IAB) and the Internet Engineering
> Steering  Group (IESG), the bodies which oversee architecture and
> standards for  the Internet, are concerned by the need for increased
> protection of  international commercial transactions on the Internet,
> and by the need  to offer all Internet users an adequate degree of
> privacy. [RFC1984]
>
> This  shows that security and privacy are very high on the agenda of
> the  IETF, but a reason for this, outside of underpinning growth and
> trust of  the network, is not given. In this research it is argued
> that security and privacy are (contributing to) essential human
> rights; such as freedom of expression, the right to information, the
> right to  privacy, and the right to security.
>
> The Internet aims to be a global network of network that provides
> connectivity to all its users, just like the Universal Declaration of
> Human Rights provides rights to all citizens. This makes a clear case
> that the Internet is not only an enabler of human rights, but that
> human rights, lie at the basis of, and is ingrained in, the network.
> Furthermore  interview will be done with  the chair of the Internet
> Architecture  Board (IAB), members of the  Internet Engineering
> Steering Group (IESG)  and chairs of selected  working groups and RFC
> authors.
>
> To start addressing the issue, a mapping exercise analyzing Internet
> architecture and protocols features, vis-a-vis possible impact on
> human rights needs to be
> undertaken.
>
> [snip, leaving the examples in place]
>
> 3.  Proposal
> Mapping the relation between human rights and protocols and
> architectures is a new research challenge, which will require a good
> amount of cross organizational cooperation to develop a consistent
> methodology.  While the authors of this first draft are involved in
> both human rights advocacy and research on Internet technologies - we
> believe that bringing this work into the IRTF would facilitate and
> improve this work by bringing human rights experts together with the
> community of researchers and developers of Internet standards and
> technologies.
>
> At this point we have created a mailing list where we would like to
> encourage discussion of the issue and capture interest of the IRTF
> community.  A second step would be to create a charter and ask the
> IRTF for a Research group to further develop methodology and
> investigate Human rights Protocol considerations.
>
> Assuming that the research produces useful results, the objective
> would evolve into the creation of a set of recommended considerations
> for the protection of applicable human rights.
>
> In the  analysis of existing RFCs central design and technical
> concepts have been found which impact human rights. These concepts
> will form the lens for the analysis of RFCs and will be further
> described vis a vis their impact on human rights.
>
> The current working assumption is the following:
>
> The  combination of content agnosticism, connectivity, security (as
> defined in RFC 3365) [RFC3365] and privacy (as defined in RFC 6973)
> [RFC6973] are the technical principles that underly freedom of
> expression on the Internet.
>
> Privacy and security are defined, so here we focus on concepts that
> have not been defined as considerations that are relevant for freedom
> of expression.
>
> This is a non-exhaustive first list of concepts, which definitions
> should be improved and further aligned with existing RFCs.
>
> Connectivity
> The Internet is the tool for providing global connectivity conform
> RFC1958. Therefore all protocols and standards should aim to improve
> connectivity, and not to limit it.
>
> Distributed
> To  enable and strengthen connectivity, stability, and sustainability
> of  the network, protocols and standards should be developed in a way
> that  they can be implemented in a distributed way, if not, strong
> accountability mechanism should be in place.
>
> Inter-operable
> Standards exist to design systems that allow for other systems to
> interact freely and openly.
>
> Reliable
> Reliability ensures that a protocol will execute its function
> consistently and  error resistant as described and function without
> unexpected result, also when there is an increase or decrease of
> throughput. A system that is reliable will have a documented way to
> recover from failure.
>
> Scalable
> Any  solution should support growth of the network with more hosts,
> users and traffic. And have clear understanding of it's scope and
> ideally a proposition how it can be expanded in order to support
> greater capacity.
>
> Stateless / state-full
> If  possible protocols should be implemented stateless for reliability
> and privacy considerations. If not, they should keep as little state
> as possible.
>
> Content agnostic
> Protocols should not treat packets/datagrams differently based on
> their content.
>
> Transparent
> Protocols should be transparent in what they can do and can not do and
> how it is  done. Implementation of protocols should advertise it's
> policies on data retention for the service and which jurisdiction it
> falls under.
>
> Debugging
> A protocol should allow a user to troubleshoot and debug possible
> causes of malfunction and loss of reliability.
>
> Robust, robustness
> Protocols should be resistant to errors, involuntary legal or
> malicious attempts  to disrupt its mode of operations. Protocols
> should be developed in a  way that there is no (intransparent) kill
> switch. There should also be a clear description on how a protocol
> recovers from potential failures.
>
> End user-centric / representing  stakeholder rights
> As proposed in draft-nottingham-stakeholder-rights-00:
>
> [QUOTE]
> Protocols MUST document relevant primary stakeholders and their
> interrelationships.
>
> [..]
>
>  End-user-facing application protocols MUST prioritise their users
> higher than any other stakeholders.
> Extensions to existing protocols MUST document how they interact with
> the extended protocol's stakeholders.  If the extended protocol's
> stakeholders are not yet documented, the extension MAY estimate its
> impact, in coordination with that protocol's community and the IESG.
> The burden of this documentation need not be high; if HTML can do it
> in a paragraph, so can most protocols.  While it might be appropriate
> in a separate document (e.g., a requirements or use cases draft) or
> the protocol specification itself, documenting stakeholders in the WG
> charter has considerable benefits, since it clarifies their
> relationships up-front.
>
> [/QUOTE]
>
>
> - --
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.article19.org
>
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBAgAGBQJU9bXVAAoJEAi1oPJjbWjpeKEH/3MhfM1yFG2aJf4/8ZBWwQtA
> rlb0iVw2mCeA9RsulzgkU7cZC3dh+24PIVsX0DmiaCJtk7YJbCzI8wQtvm8b2aD0
> PnQzRbkCGHxpPKLP+GkuNr2iQCdWQ6YoY68g8up26jHco9DUaTIOw9zGFV4lApu3
> d2/9DvyrF/d2lgO17c9vFVmAoE+wWdlE1CMRV2SDGcbz9Fb9xSntnJ5/+SXkNpQ+
> 24BaCk73xK88mRqvk/HLUO3GCoDd3ytM5KuU0X4hQOoLVWOpyQaVOadtLQbLkNNX
> GB1NIalgs8ivK+8PXn4fsbKMCYLR3HcSDIzC/uiICRciznu0G82v49pZYYAVt+Y=
> =DKrF
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 03 Mar 2015 18:40:17 +0000
> From: Stephen Farrell <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [hrpc] relevant UNESCO draft document
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
>
> Hiya,
>
> I'm at a UNESCO conference at the moment [1] and they have a
> draft document for which they'd like to get more technical
> review. [2]
>
> I'm not sure to which email address they'd like comments sent
> but I'll check tomorrow and send a mail here. You'll not have
> read the 96 pages by then most likely though:-) But it's pretty
> relevant to this list I think.
>
> Cheers,
> S.
>
>
> [1] http://www.unesco.org/new/en/netconference2015
> [2]
>
> http://www.unesco.org/new/fileadmin/MULTIMEDIA/HQ/CI/CI/pdf/internet_draft_study.pdf
>
>
>
>
> ------------------------------
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://lists.ghserv.net/mailman/listinfo/hrpc
>
> End of hrpc Digest, Vol 6, Issue 1
> **********************************
>

-- 

'The management of normality is hard work'

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 04 Mar 2015 22:00:40 +0100

Hi Corinne,

Thanks for this. Great that you will be coming to Dallas!

On 03/04/2015 04:18 PM, Corinne Cath wrote:
> Dear all,
> 
> Just a thought:
> 
> It's clear that there are privacy considerations w/ standards, and 
> security issues, of course, and those are both human rights issues
> even though  IT privacy and security are not usually framed within
> a human rights context.

Not sure, what about the Human Rights Council resolution "on the
promotion, protection and enjoyment of human rights on the Internet",
the the resolution "The right to privacy in the digital age" by the UN
general assembly and the NETmundial outcome document?

> However, should we be even more specific in this document of what
> makes  standards development different from any other Internet/IT
> engineering issues?
> 
> networking or encryption standards. Why are protocols / standards 
> unique? Or perhaps more relevant, how do we justify our particular
> focus on them.

Protocols are the standards for the exchange of information. So they
ensure that systems can communicate with each other, but also shape
the way in which that is done, what is possible, and what is not. That
is the unique and important role of standards in the ecosystem. In
other words: Protocols and standards form the basis of the the
Internet, they define what the Internet is and how it works. I think
that's why we're focusing on them,

> It's a small thing - but I think it might make the document a 
> little stronger still if we address this issue, because I feel
> this might be a point of critique brought up at the upcoming
> meeting.
> 

Always happy to consider text proposals for the ID of course.

Best,

Niels