Internet DRAFT - draft-manyfolks-hrcrfc7725
draft-manyfolks-hrcrfc7725
Human Rights Protocol Considerations Research Group S. Abraham
Internet-Draft CIS India
Intended status: Informational MP. Canales
Expires: January 16, 2018 Derechos Digitales
O. Khrustaleva
American University
C. Runnegar
ISOC
July 15, 2017
Human Rights Considerations for RFC7725
draft-manyfolks-hrcrfc7725-00
Abstract
This is draft applies the model for developing human rights protocol
considerations as defined in draft-irtf-hrpc-research for [RFC7725].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Abraham, et al. Expires January 16, 2018 [Page 1]
Internet-Draft hrcRFC775 July 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Visibility in a browser . . . . . . . . . . . . . . . . . . . 2
4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Content Agnosticism . . . . . . . . . . . . . . . . . . . . . 3
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Internationalization . . . . . . . . . . . . . . . . . . . . 4
8. Censorship Resistance . . . . . . . . . . . . . . . . . . . . 4
9. Open Standards . . . . . . . . . . . . . . . . . . . . . . . 4
10. Heterogeneity Support . . . . . . . . . . . . . . . . . . . . 5
11. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . 5
12. Accessibility . . . . . . . . . . . . . . . . . . . . . . . . 5
13. Localization . . . . . . . . . . . . . . . . . . . . . . . . 5
14. Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 5
15. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 6
16. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 6
17. Authenticity . . . . . . . . . . . . . . . . . . . . . . . . 6
18. Adaptability . . . . . . . . . . . . . . . . . . . . . . . . 6
19. Outcome Transparency . . . . . . . . . . . . . . . . . . . . 6
20. Security Considerations . . . . . . . . . . . . . . . . . . . 7
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
22. Research Group Information . . . . . . . . . . . . . . . . . 7
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
23.1. Informative References . . . . . . . . . . . . . . . . . 7
23.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This is draft applies the model for developing human rights protocol
considerations as defined in draft-irtf-hrpc-research for RFC7725.
2. Connectivity
HTTP 451 status code response can be sent by the end nodes as well as
by intermediary nodes, which makes for a potential anonymity breach
possible. However, this anonymity breach needs to be intentional.
3. Visibility in a browser
In the web-browsing context, the HTTP status code response might only
be issued for a sub-resource (e.g. images, videos, extra HTML, CSS,
or JavaScript, which are each fetched using separate requests),
Abraham, et al. Expires January 16, 2018 [Page 2]
Internet-Draft hrcRFC775 July 2017
rather than the top-level resource seen in a browser's address bar.
For example, consider a web page at https://example.net/video/ with
an embedded video window implemented in html as
<video><source src="movie.webm"><video>.
https://example.net/video/ may return HTTP 200, but
https://example.net/video/movie.webm may return HTTP 451. Multiple
subresources on a given page may return 451.
This means that visibility to a browser user might be more complex
than just "this web page has been blocked".
4. Privacy
A HTTP 451 status code response could be visible to an observer on
the network. An observer may be able to discern the blocked domain
or URL the user attempted to access. Therefore, implementers should
deploy HTTP status code over HTTPS to mitigate this privacy risk.
See also RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2),
section 10.8 privacy considerations. Even where HTTPS is used,
metadata is still available to an observer. That metadata could be
used to identify a device, it's location and/or a user (especially
when combined with other observable data).
Some implementations of [RFC7725] send the HTTP status code response
and then re-direct to another URL [insert reference to research
revealing this]. [also describe the specific redirection mechanism(s)
used - javascript? html meta refresh tag? something else?] [insert
text as to why this is a problem from a privacy perspective].
Implementers should not imbed tracking elements in either web
resource.
[RFC7725] provides that a HTTP status code 451 is cachable by
default. Caching status code 451 on users' devices means that there
will be a record of their attempt to access the blocked content
stored on their devices. If caching is used, the 451 status code
response should notify users.
HTTP 451 status code responses are unverified and may be fake and/or
a vehicle to monitor the user and/or introduce malware.
5. Content Agnosticism
There may be an issue of content agnosticism if the resource
returning the HTTP 451 status code is only blocked for some users
(e.g. geo-blocking). This is not a protocol issue, but rather an
artefact of the blocking order. The status code 451 is both content
Abraham, et al. Expires January 16, 2018 [Page 3]
Internet-Draft hrcRFC775 July 2017
agnostic and content gnostic. It is content agnostic from the
perspective of the end-user when the blocking is done at the level of
the resource. However, when blocking is done at the level of the
sub-resource it may not be content agnostic in all cases from the
perspective of the end user. If the sub-resource is HTML then the
end user will be able to see the details of the block beyond just the
status code. But if the sub-resource is an image, audio or video -
the browser will not be able to render the details of the block since
the browsers currently will not render the information from the
header in a manner that is scrutable to the end user. This concern
could be partially addressed by using an appropriate plugin that is
able to parse the header.
6. Security
HTTP 451 status code responses are unverified which make them a
possible vehicle to introduce malware. The malware could be
specifically implemented with the purpose to surveil the final user
that is trying to access an specific type of content that has been
censored.
7. Internationalization
The RFC does not require the use of any particular language and
therefore when the standard is being implemented any language could
be used.
8. Censorship Resistance
While HTTP 451 status code cannot prevent censorship it can help make
censorship more transparent and make assessment of Internet
censorship cases easier. "Censorship is where an entity in a
position of power - such as a government, organization, or individual
- suppresses communication that it considers objectionable, harmful,
sensitive, politically incorrect or inconvenient." Legal means have
been used for censoring content for a long time, and what HTTP 451
status code does is demonstrate when legal means meet technical means
online. Blocking is still censorship, and status code 451 doesn't
solve the problem, but creates a way for more transparent reporting
of censorship that can be useful for the analysis and advocacy.
Also, If the users are informed about why their access to a specific
resource was denied they can opt to use circumvention techniques.
9. Open Standards
RFC 7725 is an open standard.
Abraham, et al. Expires January 16, 2018 [Page 4]
Internet-Draft hrcRFC775 July 2017
10. Heterogeneity Support
A HTTP 451 status code response can be used for any HTTP or HTTPS web
resource and for any software, applications and devices that are
capable of displaying HTTP header responses.
11. Anonymity
Possible anonymity concerns as identifiers might be introduced by the
parties serving 451 status code.
12. Accessibility
The RFC can be currently implemented in two ways for resources.
Either the server could either return a HTML file without any
automatic redirect or a HTML file with an automatic redirect. The
second option could interfere with accessibility because disabled end
users may not have sufficient time to use their accessibility
software and hardware to read the status code and other details.
Therefore it is recommended that the RFC be updated to ensure that
the display of a HTTP 451 status code response should be untimed and
static to provide users enough time to read and use the content.
13. Localization
HTTP 451 status code implies a reference to legal reasons for making
a content unaccessible. Those legal implications usually will
concern a national legal framework that it will not be always easy to
understand for non legal operators or users from different
jurisdictions who are being affected by the lack of access for legal
reasons. When it comes to localization for language, locale etc. the
RFC does not explicitly provide for internationalization of text
strings but implementers of the standards can localize the text
strings nevertheless.
14. Reliability
HTTP 451 status code responses are unverified so they could be fake
or mistaken. The protocol by itself does not prevent the misuse of
the status code or wrong tagging of other unavailability reasons.
The informational requirement as part of the protocol address this
concern in some extent, but commonly it will be difficult for the end
user to verify if the code has been correctly used or if the
information provided as part of it is truthful. Additionally, many
companies include in their Terms of Service prohibited types of
content or activities on their networks, reserving to their
discretion the interpretation of broad terms used to capture many
forms of content that can be potentially blocked.
Abraham, et al. Expires January 16, 2018 [Page 5]
Internet-Draft hrcRFC775 July 2017
15. Confidentiality
HTTP 451 status code use implies sharing of information by the
reporter that make it easier to identify where censorship is taking
place. It can expose to governments engaging with censorship who is
more willing to collaborate blocking content making them an easier
target for further actions of censorship.
16. Integrity
For integrity, a status code 451 should be delivered over HTTPS.
17. Authenticity
Implementation of the status code 451 could guarantee authenticity in
most cases if the server operators implement HTTPS. However that
only guarantees authenticity during the last mile of transit between
the server serving the status code and the end user. There is no way
in which the status code guarantee that the server operator is not
serving false information about a particular instance of censorship.
This could happen deliberately under a variety of circumstance - the
server operator is masking self-censorship as government censorship
or the server operator has self-interest in misrepresenting the facts
about government or private censorship. Lack of legal expertise or
capacity could also result in false information being served to the
user. Many start-ups and non-profits cannot afford legal teams with
the requisite expertise and many large corporation reserve their best
lawyers for core business activities leaving censorship related
activities to interns and junior staff. There is no real incentive
beyond good (corporate) citizenship for server operators to tell the
truth and therefore this is an area for concern when it comes to
implementation of the status code.
18. Adaptability
Status code 451 does not have any legal or technical limitations
which prevents the development of other standards / protocols.
19. Outcome Transparency
The assumption behind the development of the status code 451 is that
transparency has a chilling effect on censorship and that
transparency will enable the process of justice by allowing acts of
censorship to be challenged. This is the very same assumption behind
the publication of transparency reports by various Internet
corporations like Google, Facebook and Twitter. Unfortunately, this
has not always been the case - in some countries the transparency
reports may have contributed to competitive behavior thereby
Abraham, et al. Expires January 16, 2018 [Page 6]
Internet-Draft hrcRFC775 July 2017
increasing censorship. In some countries, blocks orders are unevenly
implemented by ISPs either because it does not serve their bottom-
lines or they are resisting censorship - governments in those
countries could mandate the implementation of status code 521 which
will make it easier for them to monitor the implementation of their
block orders. Finally, surveillance systems in some countries could
be updated to watch out for the 521 error code on unencrypted traffic
making it easier to identify those trying to access prohibited
content. Before the implementation of this standard there would be
no uniformity in which websites would implement a block order
increasing the number of false positives for any automated monitoring
systems.
20. Security Considerations
As this document concerns a research document, there are no security
considerations.
21. IANA Considerations
This document has no actions for IANA.
22. Research Group Information
The discussion list for the IRTF Human Rights Protocol Considerations
Research Group is located at the e-mail address hrpc@ietf.org [1].
Information on the group and information on how to subscribe to the
list is at https://www.irtf.org/mailman/listinfo/hrpc
Archives of the list can be found at: https://www.irtf.org/mail-
archive/web/hrpc/current/index.html
23. References
23.1. Informative References
[RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles",
RFC 7725, DOI 10.17487/RFC7725, February 2016,
<http://www.rfc-editor.org/info/rfc7725>.
23.2. URIs
[1] mailto:hrpc@ietf.org
Abraham, et al. Expires January 16, 2018 [Page 7]
Internet-Draft hrcRFC775 July 2017
Authors' Addresses
Sunil Abraham
CIS India
EMail: sunil@cis-india.org
Maria Paz Canales
Derechos Digitales
EMail: mariapaz@derechosdigitales.org
Olga Khrustaleva
American University
EMail: ok4193a@student.american.edu
Christine Runnegar
ISOC
EMail: runnegar@isoc.org
Abraham, et al. Expires January 16, 2018 [Page 8]
