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

[Corinne Cath <[e-mail]>]

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, <[e-mail]> wrote:

> Send hrpc mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Subject: [hrpc] new draft text for the ID
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Subject: [hrpc] relevant UNESCO draft document
> Message-ID: <[e-mail]>
> 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
> [e-mail]
> https://lists.ghserv.net/mailman/listinfo/hrpc
>
> End of hrpc Digest, Vol 6, Issue 1
> **********************************
>



-- 



'The management of normality is hard work'