idnits 2.17.1 

draft-manyfolks-hrcrfc7725-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The abstract seems to contain references ([RFC7725]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (July 15, 2017) is 2477 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Looks like a reference, but probably isn't: '1' on line 331


     Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Human Rights Protocol Considerations Research Group           S. Abraham
3	Internet-Draft                                                 CIS India
4	Intended status: Informational                               MP. Canales
5	Expires: January 16, 2018                             Derechos Digitales
6	                                                          O. Khrustaleva
7	                                                     American University
8	                                                             C. Runnegar
9	                                                                    ISOC
10	                                                           July 15, 2017

12	                Human Rights Considerations for RFC7725
13	                     draft-manyfolks-hrcrfc7725-00

15	Abstract

17	   This is draft applies the model for developing human rights protocol
18	   considerations as defined in draft-irtf-hrpc-research for [RFC7725].

20	Status of This Memo

22	   This Internet-Draft is submitted in full conformance with the
23	   provisions of BCP 78 and BCP 79.

25	   Internet-Drafts are working documents of the Internet Engineering
26	   Task Force (IETF).  Note that other groups may also distribute
27	   working documents as Internet-Drafts.  The list of current Internet-
28	   Drafts is at http://datatracker.ietf.org/drafts/current/.

30	   Internet-Drafts are draft documents valid for a maximum of six months
31	   and may be updated, replaced, or obsoleted by other documents at any
32	   time.  It is inappropriate to use Internet-Drafts as reference
33	   material or to cite them other than as "work in progress."

35	   This Internet-Draft will expire on January 16, 2018.

37	Copyright Notice

39	   Copyright (c) 2017 IETF Trust and the persons identified as the
40	   document authors.  All rights reserved.

42	   This document is subject to BCP 78 and the IETF Trust's Legal
43	   Provisions Relating to IETF Documents
44	   (http://trustee.ietf.org/license-info) in effect on the date of
45	   publication of this document.  Please review these documents
46	   carefully, as they describe your rights and restrictions with respect
47	   to this document.  Code Components extracted from this document must
48	   include Simplified BSD License text as described in Section 4.e of
49	   the Trust Legal Provisions and are provided without warranty as
50	   described in the Simplified BSD License.

52	Table of Contents

54	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
55	   2.  Connectivity  . . . . . . . . . . . . . . . . . . . . . . . .   2
56	   3.  Visibility in a browser . . . . . . . . . . . . . . . . . . .   2
57	   4.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
58	   5.  Content Agnosticism . . . . . . . . . . . . . . . . . . . . .   3
59	   6.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
60	   7.  Internationalization  . . . . . . . . . . . . . . . . . . . .   4
61	   8.  Censorship Resistance . . . . . . . . . . . . . . . . . . . .   4
62	   9.  Open Standards  . . . . . . . . . . . . . . . . . . . . . . .   4
63	   10. Heterogeneity Support . . . . . . . . . . . . . . . . . . . .   5
64	   11. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . .   5
65	   12. Accessibility . . . . . . . . . . . . . . . . . . . . . . . .   5
66	   13. Localization  . . . . . . . . . . . . . . . . . . . . . . . .   5
67	   14. Reliability . . . . . . . . . . . . . . . . . . . . . . . . .   5
68	   15. Confidentiality . . . . . . . . . . . . . . . . . . . . . . .   6
69	   16. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . .   6
70	   17. Authenticity  . . . . . . . . . . . . . . . . . . . . . . . .   6
71	   18. Adaptability  . . . . . . . . . . . . . . . . . . . . . . . .   6
72	   19. Outcome Transparency  . . . . . . . . . . . . . . . . . . . .   6
73	   20. Security Considerations . . . . . . . . . . . . . . . . . . .   7
74	   21. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
75	   22. Research Group Information  . . . . . . . . . . . . . . . . .   7
76	   23. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
77	     23.1.  Informative References . . . . . . . . . . . . . . . . .   7
78	     23.2.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   7
79	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

81	1.  Introduction

83	   This is draft applies the model for developing human rights protocol
84	   considerations as defined in draft-irtf-hrpc-research for RFC7725.

86	2.  Connectivity

88	   HTTP 451 status code response can be sent by the end nodes as well as
89	   by intermediary nodes, which makes for a potential anonymity breach
90	   possible.  However, this anonymity breach needs to be intentional.

92	3.  Visibility in a browser

94	   In the web-browsing context, the HTTP status code response might only
95	   be issued for a sub-resource (e.g. images, videos, extra HTML, CSS,
96	   or JavaScript, which are each fetched using separate requests),
97	   rather than the top-level resource seen in a browser's address bar.
98	   For example, consider a web page at https://example.net/video/ with
99	   an embedded video window implemented in html as

101	   <video><source src="movie.webm"><video>.

103	   https://example.net/video/ may return HTTP 200, but
104	   https://example.net/video/movie.webm may return HTTP 451.  Multiple
105	   subresources on a given page may return 451.

107	   This means that visibility to a browser user might be more complex
108	   than just "this web page has been blocked".

110	4.  Privacy

112	   A HTTP 451 status code response could be visible to an observer on
113	   the network.  An observer may be able to discern the blocked domain
114	   or URL the user attempted to access.  Therefore, implementers should
115	   deploy HTTP status code over HTTPS to mitigate this privacy risk.
116	   See also RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2),
117	   section 10.8 privacy considerations.  Even where HTTPS is used,
118	   metadata is still available to an observer.  That metadata could be
119	   used to identify a device, it's location and/or a user (especially
120	   when combined with other observable data).

122	   Some implementations of [RFC7725] send the HTTP status code response
123	   and then re-direct to another URL [insert reference to research
124	   revealing this]. [also describe the specific redirection mechanism(s)
125	   used - javascript?  html meta refresh tag?  something else?] [insert
126	   text as to why this is a problem from a privacy perspective].
127	   Implementers should not imbed tracking elements in either web
128	   resource.

130	   [RFC7725] provides that a HTTP status code 451 is cachable by
131	   default.  Caching status code 451 on users' devices means that there
132	   will be a record of their attempt to access the blocked content
133	   stored on their devices.  If caching is used, the 451 status code
134	   response should notify users.

136	   HTTP 451 status code responses are unverified and may be fake and/or
137	   a vehicle to monitor the user and/or introduce malware.

139	5.  Content Agnosticism

141	   There may be an issue of content agnosticism if the resource
142	   returning the HTTP 451 status code is only blocked for some users
143	   (e.g. geo-blocking).  This is not a protocol issue, but rather an
144	   artefact of the blocking order.  The status code 451 is both content
145	   agnostic and content gnostic.  It is content agnostic from the
146	   perspective of the end-user when the blocking is done at the level of
147	   the resource.  However, when blocking is done at the level of the
148	   sub-resource it may not be content agnostic in all cases from the
149	   perspective of the end user.  If the sub-resource is HTML then the
150	   end user will be able to see the details of the block beyond just the
151	   status code.  But if the sub-resource is an image, audio or video -
152	   the browser will not be able to render the details of the block since
153	   the browsers currently will not render the information from the
154	   header in a manner that is scrutable to the end user.  This concern
155	   could be partially addressed by using an appropriate plugin that is
156	   able to parse the header.

158	6.  Security

160	   HTTP 451 status code responses are unverified which make them a
161	   possible vehicle to introduce malware.  The malware could be
162	   specifically implemented with the purpose to surveil the final user
163	   that is trying to access an specific type of content that has been
164	   censored.

166	7.  Internationalization

168	   The RFC does not require the use of any particular language and
169	   therefore when the standard is being implemented any language could
170	   be used.

172	8.  Censorship Resistance

174	   While HTTP 451 status code cannot prevent censorship it can help make
175	   censorship more transparent and make assessment of Internet
176	   censorship cases easier.  "Censorship is where an entity in a
177	   position of power - such as a government, organization, or individual
178	   - suppresses communication that it considers objectionable, harmful,
179	   sensitive, politically incorrect or inconvenient."  Legal means have
180	   been used for censoring content for a long time, and what HTTP 451
181	   status code does is demonstrate when legal means meet technical means
182	   online.  Blocking is still censorship, and status code 451 doesn't
183	   solve the problem, but creates a way for more transparent reporting
184	   of censorship that can be useful for the analysis and advocacy.
185	   Also, If the users are informed about why their access to a specific
186	   resource was denied they can opt to use circumvention techniques.

188	9.  Open Standards

190	   RFC 7725 is an open standard.

192	10.  Heterogeneity Support

194	   A HTTP 451 status code response can be used for any HTTP or HTTPS web
195	   resource and for any software, applications and devices that are
196	   capable of displaying HTTP header responses.

198	11.  Anonymity

200	   Possible anonymity concerns as identifiers might be introduced by the
201	   parties serving 451 status code.

203	12.  Accessibility

205	   The RFC can be currently implemented in two ways for resources.
206	   Either the server could either return a HTML file without any
207	   automatic redirect or a HTML file with an automatic redirect.  The
208	   second option could interfere with accessibility because disabled end
209	   users may not have sufficient time to use their accessibility
210	   software and hardware to read the status code and other details.
211	   Therefore it is recommended that the RFC be updated to ensure that
212	   the display of a HTTP 451 status code response should be untimed and
213	   static to provide users enough time to read and use the content.

215	13.  Localization

217	   HTTP 451 status code implies a reference to legal reasons for making
218	   a content unaccessible.  Those legal implications usually will
219	   concern a national legal framework that it will not be always easy to
220	   understand for non legal operators or users from different
221	   jurisdictions who are being affected by the lack of access for legal
222	   reasons.  When it comes to localization for language, locale etc. the
223	   RFC does not explicitly provide for internationalization of text
224	   strings but implementers of the standards can localize the text
225	   strings nevertheless.

227	14.  Reliability

229	   HTTP 451 status code responses are unverified so they could be fake
230	   or mistaken.  The protocol by itself does not prevent the misuse of
231	   the status code or wrong tagging of other unavailability reasons.
232	   The informational requirement as part of the protocol address this
233	   concern in some extent, but commonly it will be difficult for the end
234	   user to verify if the code has been correctly used or if the
235	   information provided as part of it is truthful.  Additionally, many
236	   companies include in their Terms of Service prohibited types of
237	   content or activities on their networks, reserving to their
238	   discretion the interpretation of broad terms used to capture many
239	   forms of content that can be potentially blocked.

241	15.  Confidentiality

243	   HTTP 451 status code use implies sharing of information by the
244	   reporter that make it easier to identify where censorship is taking
245	   place.  It can expose to governments engaging with censorship who is
246	   more willing to collaborate blocking content making them an easier
247	   target for further actions of censorship.

249	16.  Integrity

251	   For integrity, a status code 451 should be delivered over HTTPS.

253	17.  Authenticity

255	   Implementation of the status code 451 could guarantee authenticity in
256	   most cases if the server operators implement HTTPS.  However that
257	   only guarantees authenticity during the last mile of transit between
258	   the server serving the status code and the end user.  There is no way
259	   in which the status code guarantee that the server operator is not
260	   serving false information about a particular instance of censorship.
261	   This could happen deliberately under a variety of circumstance - the
262	   server operator is masking self-censorship as government censorship
263	   or the server operator has self-interest in misrepresenting the facts
264	   about government or private censorship.  Lack of legal expertise or
265	   capacity could also result in false information being served to the
266	   user.  Many start-ups and non-profits cannot afford legal teams with
267	   the requisite expertise and many large corporation reserve their best
268	   lawyers for core business activities leaving censorship related
269	   activities to interns and junior staff.  There is no real incentive
270	   beyond good (corporate) citizenship for server operators to tell the
271	   truth and therefore this is an area for concern when it comes to
272	   implementation of the status code.

274	18.  Adaptability

276	   Status code 451 does not have any legal or technical limitations
277	   which prevents the development of other standards / protocols.

279	19.  Outcome Transparency

281	   The assumption behind the development of the status code 451 is that
282	   transparency has a chilling effect on censorship and that
283	   transparency will enable the process of justice by allowing acts of
284	   censorship to be challenged.  This is the very same assumption behind
285	   the publication of transparency reports by various Internet
286	   corporations like Google, Facebook and Twitter.  Unfortunately, this
287	   has not always been the case - in some countries the transparency
288	   reports may have contributed to competitive behavior thereby
289	   increasing censorship.  In some countries, blocks orders are unevenly
290	   implemented by ISPs either because it does not serve their bottom-
291	   lines or they are resisting censorship - governments in those
292	   countries could mandate the implementation of status code 521 which
293	   will make it easier for them to monitor the implementation of their
294	   block orders.  Finally, surveillance systems in some countries could
295	   be updated to watch out for the 521 error code on unencrypted traffic
296	   making it easier to identify those trying to access prohibited
297	   content.  Before the implementation of this standard there would be
298	   no uniformity in which websites would implement a block order
299	   increasing the number of false positives for any automated monitoring
300	   systems.

302	20.  Security Considerations

304	   As this document concerns a research document, there are no security
305	   considerations.

307	21.  IANA Considerations

309	   This document has no actions for IANA.

311	22.  Research Group Information

313	   The discussion list for the IRTF Human Rights Protocol Considerations
314	   Research Group is located at the e-mail address hrpc@ietf.org [1].
315	   Information on the group and information on how to subscribe to the
316	   list is at https://www.irtf.org/mailman/listinfo/hrpc

318	   Archives of the list can be found at: https://www.irtf.org/mail-
319	   archive/web/hrpc/current/index.html

321	23.  References

323	23.1.  Informative References

325	   [RFC7725]  Bray, T., "An HTTP Status Code to Report Legal Obstacles",
326	              RFC 7725, DOI 10.17487/RFC7725, February 2016,
327	              <http://www.rfc-editor.org/info/rfc7725>.

329	23.2.  URIs

331	   [1] mailto:hrpc@ietf.org

333	Authors' Addresses

335	   Sunil Abraham
336	   CIS India

338	   EMail: sunil@cis-india.org

340	   Maria Paz Canales
341	   Derechos Digitales

343	   EMail: mariapaz@derechosdigitales.org

345	   Olga Khrustaleva
346	   American University

348	   EMail: ok4193a@student.american.edu

350	   Christine Runnegar
351	   ISOC

353	   EMail: runnegar@isoc.org