RFC 8280 | Исследования по вопросам протокола о правах человека (HRPC)

Аннотация

Этот документ призван предложить руководящие принципы по соображениям прав человека, аналогичные работе, проделанной над руководящими принципами по вопросам конфиденциальности (RFC 6973). Другие части этого документа объясняют предысторию руководящих принципов и то, как они были разработаны.

Этот документ является первым этапом долгосрочных исследований. Он был рассмотрен Исследовательской группой по рассмотрению протоколов о правах человека (Human Rights Protocol Considerations (HRPC)), а также лицами, не входящими в исследовательскую группу.

Скачать оригинальный документ на английском языке RFC 8280 PDF

 

Оглавление

1. Введение
2. Используемый словарь
3. Вопросы исследования
4. Обзор литературы и дискуссий
5. Методология
5.1. Источники данных
5.1.1. Дискурс-анализ RFC
5.1.2. Интервью с членами сообщества IETF
5.1.3. Наблюдение за участниками в рабочих группах
5.2. Стратегии анализа данных
5.2.1. Определение качеств технических понятий, связанных с правами человека
5.2.1.1. Составление карт протоколов и стандартов по правам человека
5.2.1.2. Извлечение концепций из выбранных RFC
5.2.1.3. Создание общего словаря технических понятий, влияющих на права человека
5.2.1.4. Перевод концепций прав человека в технические определения
5.2.1.5. Список технических терминов, которые при частичном сочетании могут создать благоприятную среду для прав человека
5.2.2. Отношение прав человека к техническим концепциям
5.2.3. Картирование случаев протоколов, реализаций и сетевых парадигм, которые негативно влияют на права человека или являются их стимулами
5.2.3.1. IPv4
5.2.3.1.1. Видимость сети источника и назначения
5.2.3.1.2. Трансляция адресов и мобильность
5.2.3.2. DNS
5.2.3.2.1. Удаление записей
5.2.3.2.2. Искажение записей
5.2.3.2.3. Инъекция записей
5.2.3.3. HTTP
5.2.3.3.1. Перехват трафика
5.2.3.3.2. Управление трафиком
5.2.3.4. XMPP
5.2.3.4.1. Идентификация пользователя
5.2.3.4.2. Наблюдение за связью
5.2.3.4.3. Ограничения группового чата
5.2.3.5. Пиринговый
5.2.3.5.1. Сетевое отравление
5.2.3.5.2. Дроссельный
5.2.3.5.3. Отслеживание и идентификация
5.2.3.5.4. Предсказания атак
5.2.3.6. Виртуальные частные сети
5.2.3.6.1. Нет анонимности в отношении провайдеров VPN
5.2.3.6.2. Логирование
5.2.3.6.3. Сторонний хостинг
5.2.3.6.4. IPv6 Утечка
5.2.3.6.5. Утечка DNS
5.2.3.6.6. Корреляция трафика
5.2.3.7. Код состояния HTTP 451
5.2.3.8. DDoS-атаки
6. Модель разработки соображений по протоколу о правах человека
6.1. Угрозы прав человека
6.2. Руководство по правам человека
6.2.1. Связь
6.2.2. Конфиденциальность
6.2.3. Содержание Агностицизма
6.2.4. Безопасность
6.2.5. Интернационализация
6.2.6. Сопротивление цензуре
6.2.7. Открытые стандарты
6.2.8. Поддержка неоднородности
6.2.9. Анонимность
6.2.10. Псевдонимность
6.2.11. Доступность
6.2.12. Локализация
6.2.13. Децентрализация
6.2.14. Надежность
6.2.15. Конфиденциальность
6.2.16. Целостность
6.2.17. Аутентичность
6.2.18. Адаптируемость
6.2.19. Прозрачность результатов
7. Вопросы безопасности
8. Соображения IANA
9. Информация исследовательской группы
10. Информационные ссылки
Благодарности
Адреса авторов

 

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Исследовательской группы по Интернету (IRTF). IRTF публикует результаты интернет-исследований и разработок. Эти результаты могут не подходить для развертывания. Этот RFC представляет консенсус Исследовательской группы по рассмотрению протоколов в области прав человека Целевой группы по исследованию интернета (IRTF). Документы, одобренные для публикации IRSG, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8280.

 

Уведомление об авторских правах

Copyright (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

 

1. Введение

«В Интернете есть свобода: пока мы принимаем правила отправки пакетов, мы можем отправлять пакеты, содержащие что угодно, куда угодно». [Бернерс-Ли]

«Интернет не является нейтральным по отношению к ценностям, как и IETF». [RFC3935]

Постоянно растущая взаимосвязь между Интернетом и обществом увеличивает влияние Интернета на жизнь людей. Из-за этого проектирование и развитие инфраструктуры Интернета также оказывают растущее влияние на общество. Это привело к широкому признанию того, что права человека [UDHR] [ICCPR] [ICESCR] играют роль в развитии и управлении Интернетом [UNGA2013] [NETmundial]. Также утверждалось, что Интернет должен быть укреплен как благоприятная среда для прав человека [Brown].

Этот документ нацелен на (1) раскрытие взаимосвязи между протоколами и правами человека, (2) предложение возможных руководящих принципов для защиты Интернета в качестве благоприятной среды для прав человека при разработке будущих протоколов, аналогично работе, проделанной в целях обеспечения конфиденциальности [RFC6973], и (3) повысить осведомленность как правозащитного сообщества, так и технического сообщества о важности технической работы Интернета и ее влиянии на права человека.

Авторы документов, которые хотят применить эту работу самостоятельно, могут перейти непосредственно к разделу 6 этого документа.

Открытое, безопасное и надежное соединение необходимо (хотя и недостаточно) для осуществления прав человека, таких как свобода выражения мнений и свобода ассоциаций [FOC], как они определены во Всеобщей декларации прав человека [UDHR]. Целью Интернета является создание глобальной сети сетей, которая обеспечивает беспрепятственное подключение для всех пользователей и для любого контента [RFC1958]. Эта цель стимулирования глобальной связи способствует роли Интернета в качестве правозащитника. Интернет дал людям платформу для обмена мнениями и сбора информации; это позволило людям разных слоев и полов участвовать в общественных дебатах; это также позволило людям собираться и организовываться. Кроме того, сильная приверженность безопасности [RFC1984] [RFC3365] и конфиденциальности [RFC6973] [RFC7258] в архитектурном дизайне Интернета способствует укреплению Интернета как благоприятной среды для прав человека.

Можно даже утверждать, что Интернет является не только средством обеспечения прав человека, но и что права человека лежат в основе архитектуры сетей, составляющих Интернет, и являются ее неотъемлемой частью. Подключение к Интернету расширяет возможности отдельных лиц по осуществлению своих прав; поэтому ядро Интернета — его архитектурный дизайн — тесно переплетено с правозащитной структурой [CathFloridi]. Многие утверждают, что наиболее существенной является связь между инфраструктурой Интернета и правами человека. [Bless1], например, утверждает, что «в определенной степени Интернет и его протоколы уже способствовали реализации прав человека, например свободы собраний и выражения мнений. Напротив, меры цензуры и повсеместного наблюдения нарушают фундаментальные права человека. права «. [DeNardis15] утверждает, что «с момента первых намеков на коммерциализацию и интернационализацию Интернета IETF поддерживает строгую безопасность при разработке протоколов и иногда служит в качестве силы, противостоящей функциям наблюдения с поддержкой протоколов» Таким образом, IETF позволил проявить право на неприкосновенность частной жизни через инфраструктуру Интернета. Кроме того, доступ к свободно доступной информации дает людям доступ к знаниям, которые позволяют им помогать соблюдать другие права человека; Интернет как таковой все больше становится предпосылкой прав человека, а не дополнением.

Права человека могут противоречить друг другу, такие как право на свободу выражения мнений и право на неприкосновенность частной жизни. В таких случаях различные затронутые права должны быть сбалансированы. Для этого крайне важно, чтобы воздействия на права были четко задокументированы, чтобы уменьшить потенциальный вред. Это исследование направлено на то, чтобы в конечном итоге сделать этот процесс осязаемым и практичным для разработчиков протоколов. Технология никогда не может быть полностью приравнена к праву человека. Принимая во внимание, что конкретная технология может быть мощным стимулятором конкретного права человека, она может оказать неблагоприятное воздействие на другое право человека. В этом случае решения о проектировании и развертывании должны принимать это во внимание.

Открытый характер первоначального технического проекта и его открытых стандартов, а также такие разработки, как открытый исходный код, способствовали свободе общения. В результате возникла сеть сетей, в которой каждый мог подключаться и обмениваться данными, информацией и кодом. Для многих включение таких соединений стало основной ценностью. Однако по мере роста масштабов и коммерциализации Интернета такие темы, как доступ, права и связь, были вынуждены конкурировать с другими ценностями. Следовательно, важные характеристики Интернета, которые обеспечивают права человека, могут быть ухудшены, если они не будут должным образом определены, описаны и защищены как таковые. И наоборот, отсутствие защиты характеристик, обеспечивающих права человека, может также привести к (частичной) потере функциональности и возможности подключения, наряду с другими неотъемлемыми частями архитектуры сетей Интернета. Новые протоколы, особенно те, которые модернизируют базовую инфраструктуру сети, должны быть разработаны таким образом, чтобы продолжать обеспечивать основные права человека.

IETF разработал руководящие принципы и процедуры для обеспечения и обеспечения конфиденциальности личности и безопасности сети при разработке протокола. Этот документ направлен на изучение возможности разработки аналогичных процедур для руководящих принципов, касающихся прав человека, для обеспечения того, чтобы протоколы, разработанные в IETF, не оказывали неблагоприятного воздействия на реализацию прав человека в Интернете. Тщательно продумав ответы на вопросы, поставленные в разделе 6 настоящего документа, авторы документа должны (1) иметь возможность провести всесторонний анализ, который может послужить основой для обсуждения вопроса о том, адекватно ли протокол защищает от конкретных угроз в области прав человека, и ( 2) потенциально стимулировать думать об альтернативных вариантах дизайна.

Этот документ был разработан в рамках исследовательской группы по рассмотрению протоколов о правах человека (HRPC) на основе обсуждений в списке рассылки HRPC (раздел 9); этот документ также широко обсуждался на заседаниях HRPC. Этот документ получил одиннадцать подробных обзоров в списке рассылки, и он получил много комментариев как внутри, так и вне сообществ IRTF и IETF.

 

2. Используемый словарь

В обсуждении прав человека и архитектуры Интернета концепции, разработанные в области компьютерных наук, сетей, права, разработки политики и адвокации, собираются вместе [Даттон], Кей, Франклин, RFC1958. Те же самые понятия могут иметь совсем другое значение и последствия в других областях знаний. Чтобы стимулировать конструктивные междисциплинарные дебаты и минимизировать различия в толковании, предоставляется следующий глоссарий. Он максимально основан на существующих определениях; когда определения не были доступны в документах IETF, определения были взяты из других организаций по разработке стандартов (SDO) или академической литературы.

 

Accessibility (Доступность)

«Полное подключение к Интернету», как описано в [RFC4084], для обеспечения беспрепятственного доступа в Интернет.

Разработка протоколов, сервисов или реализаций, обеспечивающих благоприятную среду для людей с ограниченными возможностями.

Возможность получения информации доступна в интернете.

Anonymity (Анонимность)

Состояние личности неизвестно или скрыто [RFC4949].

Anonymous (Аноним)

Состояние лица, в котором наблюдатель или злоумышленник не может идентифицировать человека в группе других лиц (набор анонимности) [RFC6973].

Authenticity (Подлинность)

Свойство быть подлинным и иметь возможность быть проверенным и заслуживающим доверия [RFC4949].

Blocking (Блокировка)

Практика предотвращения доступа к ресурсам в совокупности [RFC7754]. Как блокирование, так и фильтрация могут быть реализованы на уровне «услуг» (например, веб-хостинг или потоковое видео) или на уровне определенного «контента» [RFC7754].

Censorship (Цензура)

Технические механизмы, включая как блокирование, так и фильтрацию, которые определенные политические или частные субъекты во всем мире используют для блокирования или деградации интернет-трафика. Для получения дополнительной информации о различных элементах интернет-цензуры см. [Hall].

Censorship resistance (Сопротивление цензуре)

Методы и меры по смягчению цензуры в Интернете.

Confidentiality (Конфиденциальность)

Свойство, при котором данные не передаются системным объектам, если только им не разрешено знать данные [RFC4949].

Connectivity (Возможность подключения)

Степень, в которой устройство или сеть могут обращаться к другим устройствам или сетям для обмена данными. Интернет является инструментом для обеспечения глобальной связи [RFC1958]. Различные типы подключения дополнительно определены в [RFC4084].

Комплексный принцип, функциональная совместимость, распределенная архитектура, устойчивость, надежность и надежность в сочетании представляют собой факторы, способствующие подключению к Интернету и включению в него.

Content agnosticism (Агностицизм контента)

Одинаково относиться к сетевому трафику независимо от контента.

Decentralized (Децентрализованный)

Внедрение или развертывание стандартов, протоколов или систем без единой точки контроля.

End-to-end principle (Сквозной принцип)

Принцип, согласно которому специфичные для приложения функции не должны быть встроены в сеть и, таким образом, оставаться на конечных точках. Во многих случаях, особенно при работе со сбоями, правильные решения могут быть приняты только с соответствующими знаниями конкретного приложения, которые доступны на конечных точках, не входящих в сеть.

Сквозной принцип является одним из ключевых архитектурных принципов Интернета. Аргумент в пользу комплексного подхода к проектированию системы изложен в фундаментальных статьях Солтцера, Рида и Кларка [Saltzer] [Кларк]. В этих работах авторы приводят доводы в пользу радикального упрощения: разработчики систем должны встраивать в сеть только основные и общие функции, поскольку большинство функций могут быть реализованы только на конечных точках сети. Встраивание функций в сеть для определенных приложений будет осуществляться за счет других. Таким образом, в целом разработчики систем должны стараться избегать встраивания в сеть чего-либо, что не является обязательной необходимостью для ее функционирования. Следование сквозному принципу имеет решающее значение для инноваций, так как оно делает возможными инновации без необходимости вносить изменения в сеть и защищает надежность сети. В [RFC2775] более подробно рассматриваются различные аспекты сквозного подключения.

 

Federation (Федерация)

Возможность соединения автономных и, возможно, централизованных систем в единую систему без центрального органа.

Filtering (Фильтрация)

Практика предотвращения доступа к определенным ресурсам в совокупности [RFC7754].

Heterogeneity (Неоднородность)

«Интернет характеризуется неоднородностью на многих уровнях: устройства и узлы, алгоритмы планирования маршрутизаторов и механизмы управления очередями, протоколы маршрутизации, уровни мультиплексирования, версии и реализации протоколов, базовые уровни каналов (например, точка-точка, несколько -связи доступа, беспроводная связь, FDDI и т. д.), в структуре трафика и на уровнях перегрузки в разное время и в разных местах. Кроме того, поскольку Интернет состоит из автономных организаций и поставщиков интернет-услуг, каждая из которых имеет свои собственные политические интересы , существует большая неоднородность административных доменов и ценовых структур». [FIArch]

В результате, согласно [FIArch], принцип гетерогенности, предложенный в [RFC1958], должен быть поддержан проектом.

Human rights (Права человека)

Принципы и нормы, которые являются неделимыми, взаимосвязанными, неотъемлемыми, универсальными и взаимоподкрепляющими. Права человека были кодифицированы в национальных и международных правовых органах. Всеобщая декларация прав человека [UDHR] является наиболее известным документом в истории прав человека. Устремления [UDHR] впоследствии были кодифицированы в такие договоры, как Международный пакт о гражданских и политических правах [ICCPR] и Международный пакт об экономических, социальных и культурных правах [ICESCR], после чего подписавшие страны были обязаны отразить их в своих национальные органы права. Существует также широкое признание того, что не только государства имеют обязательства по отношению к правам человека, но и негосударственные субъекты.

Integrity (Целостность)

Свойство, при котором данные не были изменены, уничтожены или утеряны несанкционированным или случайным образом [RFC4949].

Internationalization (Интернационализация (i18n))

Практика создания протоколов, стандартов и реализаций, используемых на разных языках и в различных сценариях (см. Раздел 6.2.12 («Локализация»)).

«В IETF« интернационализация »означает добавление или улучшение обработки текста, не относящегося к ASCII, в протоколе» [RFC6365].

Другая точка зрения, более подходящая для протоколов, которые с самого начала предназначены для глобального использования, — это определение, используемое Консорциумом World Wide Web (W3C) [W3Ci18nDef]: «Интернационализация — это проектирование и разработка продукта, приложения или содержимого документа. это позволяет легко локализовать целевую аудиторию, различную по культуре, региону или языку».

Многие протоколы, которые обрабатывают текст, обрабатывают только одну кодировку (US-ASCII), или они оставляют вопрос кодирования до локальных догадок (что, конечно, приводит к проблемам совместимости) [RFC3536]. Если разрешено несколько кодировок, они должны быть явно идентифицированы [RFC2277]. Добавление не-ASCII текста в протокол позволяет протоколу обрабатывать больше сценариев, возможно, все сценарии, используемые в мире. В современном мире это обычно лучше всего достигается, если разрешить кодировку Unicode только в UTF-8, что устраняет проблемы с преобразованием из специальных вариантов.

Interoperable (Совместимость)

Свойство документированного стандарта или протокола, которое позволяет различным независимым реализациям работать друг с другом без каких-либо ограничений функциональности.

Localization (Локализация (l10n))

Практика перевода реализации, чтобы сделать ее функциональной на определенном языке или для пользователей в определенной локали (см. Раздел 6.2.5 («Интернационализация»)).

(см. [RFC6365]): процесс адаптации интернационализированной прикладной платформы или приложения к конкретной культурной среде. При локализации сохраняется та же семантика, в то время как синтаксис может быть изменен [FRAMEWORK].

Локализация — это процесс настройки приложения для другого языка, сценария или культуры. Некоторые интернационализированные приложения могут работать с различными языками. Обычные пользователи понимают только небольшое количество языков, поэтому программа должна быть адаптирована для взаимодействия с пользователями только на тех языках, которые они знают. Основная работа по локализации — перевод пользовательского интерфейса и документации. Локализация включает в себя не только изменение языкового взаимодействия, но и другие соответствующие изменения, такие как отображение чисел, дат, валюты и так далее. Чем лучше интернационализировано приложение, тем легче его локализовать для конкретного языка и схемы кодировки символов.

Open standards (Открытые стандарты)

Соответствуют [RFC2026], в котором говорится следующее: «Различные национальные и международные органы по стандартизации, такие как ANSI, ISO, IEEE и ITU-T, разрабатывают различные спецификации протокола и услуг, которые аналогичны определенным техническим спецификациям здесь. Национальные и международные группы также публикуют «соглашения исполнителей», которые аналогичны заявлениям о применимости, фиксируя совокупность конкретных деталей реализации, связанных с практическим применением их стандартов. Все они считаются «открытыми внешними стандартами» для целей процесса интернет-стандартов «.

Openness (Открытость)

Отсутствие централизованных точек контроля — «функция, которая, как предполагается, облегчает присоединение новых пользователей и развертывание новых применений» [Brown].

Permissionless innovation (Бесполезные инновации)

Свобода и возможность свободно создавать и развертывать новые протоколы поверх существующих в настоящее время коммуникационных конструкций.

Privacy (Конфиденциальность)

Право субъекта (обычно лица), действующего от своего имени, определять степень, в которой он будет взаимодействовать со своей средой, включая степень, в которой субъект готов поделиться своей личной информацией с другими [RFC4949].

Право отдельных лиц контролировать или влиять на то, какая информация, связанная с ними, может собираться и храниться, а также кем и кому эта информация может быть раскрыта.

Конфиденциальность — это широкое понятие, касающееся защиты индивидуальной или групповой автономии и отношений между отдельным лицом или группой и обществом, включая правительство, компании и частных лиц. Его часто называют «право быть оставленным в покое», но он включает в себя широкий спектр прав, включая защиту от вторжений в семейную и семейную жизнь, контроль над сексуальными и репродуктивными правами и секретность общения. Это широко признано в качестве основного права, которое поддерживает человеческое достоинство и другие ценности, такие как свобода ассоциаций и свобода слова.

Право на неприкосновенность частной жизни также признается почти в каждой национальной конституции и в большинстве международных договоров по правам человека. Он был рассмотрен как международными, так и региональными органами. Право на неприкосновенность частной жизни также защищено законом на национальном уровне посредством положений в гражданском и / или уголовном кодексах.

 

Reliability (Надежность)

Гарантирует, что протокол будет выполнять свою функцию последовательно, как описано, и функционирует без неожиданных результатов. Надежная система изящно вырождается и будет иметь документированный способ объявить о деградации. Он также имеет механизмы, позволяющие корректно восстанавливаться после сбоя и, если применимо, допускает частичное лечение [dict].

Resilience (Устойчивость)

Поддержание надежности и производительности перед лицом непредвиденных изменений и обстоятельств [Meyer].

Robustness (Прочность)

Устойчивость протоколов и их реализаций к ошибкам и устойчивость к недобровольным, законным или злонамеренным попыткам нарушить режимы их работы [RFC760] [RFC791] [RFC793] [RFC1122]. Или, если сформулировать более позитивно, система может предоставлять функциональность последовательно и без ошибок, несмотря на недобровольные, законные или злонамеренные попытки нарушить свой режим работы.

Scalability (Масштабируемость)

Способность обрабатывать увеличенные или уменьшенные системные параметры (число конечных систем, пользователей, потоки данных, записи маршрутизации и т. Д.) Предсказуемо в рамках определенных ожиданий. Должно быть четкое определение его объема и применимости. Должны быть определены пределы масштабируемости системы. Рост или сжатие этих параметров обычно учитывается на порядки.

Strong encryption / cryptography (Сильное шифрование/криптография)

Используется для описания криптографического алгоритма, который потребует большого количества вычислительной мощности, чтобы победить его [RFC4949]. В современном использовании определения «сильное шифрование» это относится к количеству вычислительной мощности, в настоящее время недоступной, даже для основных действующих лиц на государственном уровне.

Transparency (Прозрачность)

В этом контексте связана с понятностью протокола относительно выбора, который он делает для пользователей, разработчиков и исполнителей протокола, и с его результатами.

Прозрачность результатов связана с понятностью эффектов протокола в отношении выбора, который он делает для пользователей, разработчиков протоколов и разработчиков, в том числе с пониманием возможных непреднамеренных последствий выбора протокола (например, отсутствие аутентичности может привести к отсутствию целостность и негативные внешние эффекты).

3. Вопросы исследования

Исследовательская группа по соображениям протокола о правах человека (HRPC) в Целевой группе по исследованиям в Интернете (IRTF) приступила к выполнению своей задачи, чтобы ответить на следующие два вопроса, которые также являются основными двумя вопросами, на которые этот документ стремится ответить:

1. Каким образом интернет-протоколы и стандарты могут влиять на права человека путем их включения или создания ограничительной среды?
2. Можно ли разработать руководящие принципы для улучшения информированного и прозрачного принятия решений о потенциальном воздействии протоколов на права человека?

4. Обзор литературы и дискуссий

Протоколы и стандарты регулярно рассматриваются как просто выполняющие технические функции. Однако эти протоколы и стандарты не существуют вне их технического контекста и не существуют вне их политического, исторического, экономического, правового или культурного контекста. Это лучше всего иллюстрирует то, как некоторые интернет-процессы и протоколы стали неотъемлемой частью политических процессов и государственных политик: нужно только взглянуть на передачу IANA, [RFC7258] («Всепроникающий мониторинг — это атака»), или глобальная инновационная политика, на конкретных примерах [DeNardis15]. Согласно [Abbate], «протоколы — это политика другими способами». Это заявление, вероятно, не получит консенсуса IETF, но тем не менее показывает, что протоколы основаны на принятии решений, чаще всего людьми. В этом процессе ценности и идеи о роли, которую конкретная технология должна играть в обществе, внедряются в дизайн. Часто эти дизайнерские решения являются частично «чисто техническими» и частично основаны на определенном мировоззрении о том, как должны функционировать технологии, которое основано на личных, корпоративных и политических взглядах. В сообществе участников IETF существует сильное желание решить технические проблемы и минимизировать участие в политических процессах и не связанных с протоколом политических проблемах.

С конца 1990-х годов растущая группа ученых и практиков исследовала вопросы, касающиеся воздействия протоколов на общество, а также политики протоколов. Эти исследования различаются по своей направленности и охвату: некоторые фокусируются на конкретных стандартах [Davidson-etal] [Musiani]; другие изучают политическое, юридическое, коммерческое или социальное влияние протоколов [BrownMarsden] [Lessig] [Mueller]; а другие смотрят на то, как личный набор ценностей инженеров воплощается в технологии [Abbate] [CathFloridi] [DeNardis15] [WynsbergheMoura].

Коммерческое и политическое влияние на управление инфраструктурой Интернета хорошо документировано в научной литературе и поэтому здесь обсуждаться не будет; см. [Benkler], [Brown-etal], [DeNardis15], [Lessig], [Mueller] и [Zittrain]. Достаточно сказать, что сообщество IETF последовательно пытается оттолкнуться от стандартизации надзора и некоторых других проблем, которые негативно влияют на опыт конечного пользователя в Интернете и доверие к нему [DeNardis14]. Роль, которую права человека играют в проектировании, обслуживании инфраструктуры и разработке протоколов, гораздо менее ясна.

Очень важно понимать, как протоколы и стандарты влияют на права человека, в частности, потому что SDO все чаще становятся площадками, где обсуждаются социальные ценности (например, права человека), хотя часто с технической точки зрения. Эти SDO становятся новым координационным центром для дискуссий о «ценностях по замыслу» и роли технических инженеров в защите или поддержке прав человека.

Коммерческое и политическое влияние на управление инфраструктурой Интернета хорошо документировано в научной литературе и поэтому здесь обсуждаться не будет; см. [Benkler], [Brown-etal], [DeNardis15], [Lessig], [Mueller] и [Zittrain]. Достаточно сказать, что сообщество IETF последовательно пытается оттолкнуться от стандартизации надзора и некоторых других проблем, которые негативно влияют на опыт конечного пользователя в Интернете и доверие к нему [DeNardis14]. Роль, которую права человека играют в проектировании, обслуживании инфраструктуры и разработке протоколов, гораздо менее ясна.

Очень важно понимать, как протоколы и стандарты влияют на права человека, в частности, потому что SDO все чаще становятся площадками, где обсуждаются социальные ценности (например, права человека), хотя часто с технической точки зрения. Эти SDO становятся новым координационным центром для дискуссий о «ценностях по замыслу» и роли технических инженеров в защите или поддержке прав человека [Brown-etal] [Clark-etal] [DeNardis14] [CathFloridi] [Lessig] [Rachovitsa].

В научной литературе можно выделить пять четких позиций в отношении роли прав человека в разработке протоколов и способов учета этих прав человека при разработке протоколов: Clark et al. [Clark-etal] утверждают, что существует необходимость в разработке «для изменения результата — так, чтобы результат мог быть различным в разных местах, и драка происходит в рамках проекта (…)» [as] «Жесткий проекты будут разрушены; проекты, которые допускают изменения, будут изгибаться под давлением и выживать «. Они считают, что права человека не должны быть жестко закодированы в протоколах по трем причинам: во-первых, права в UDHR не являются абсолютными. Во-вторых, технология — не единственный инструмент борьбы за права человека. И последнее, но не менее важное: опасно давать обещания, которые не могут быть выполнены. Они утверждают, что открытая природа Интернета никогда не будет достаточной для полной защиты прав человека.

Наоборот, Браун и соавт. [Brown-etal] заявляет, что «некоторые ключевые универсальные ценности, из которых UDHR является наиболее законным выражением, должны быть включены в архитектуру во время разработки». Они утверждают, что выбор дизайна имеет офлайновые последствия и способен формировать властные позиции групп или отдельных лиц в обществе. Как таковые, лица, принимающие эти технические решения, несут моральное обязательство учитывать влияние своих решений на общество и, соответственно, права человека. Браун и соавт. признать, что ценности и реализация прав человека варьируются по всему миру. Тем не менее они утверждают, что все члены Организации Объединенных Наций пришли к «общему согласию в отношении ценностей, провозглашенных во Всеобщей декларации прав человека». В поисках наиболее законного набора глобальных ценностей, которые можно было бы внедрить в будущие интернет-архитектуры, UDHR имеет демократическое согласие значительной части населения планеты через своих избранных представителей «.

Основное различие между этими двумя академическими позициями заключается главным образом в вопросе о том, (1) должна ли конкретная система ценностей быть встроена в архитектуры Интернета или (2) архитектуры должны учитывать изменяющийся набор ценностей.

Третью позицию, аналогичную позиции Брауна и др., Занимает [Broeders], в которой Бродерс утверждает, что «мы должны найти способы и впредь гарантировать целостность и функциональность общедоступного ядра Интернета». Он утверждает, что лучший способ сделать это — объявить магистраль Интернета, которая включает набор протоколов TCP / IP, многочисленные стандарты, систему доменных имен (DNS) и протоколы маршрутизации, что является общим общественным благом. Этот подход отличается от подходов [Clark-etal] и [Brown-etal], поскольку Бродерс не предполагает, что социальные ценности должны (или не должны) явно кодироваться в Интернете, а существующая инфраструктура должна рассматриваться как субъект общественной ценности.

Bless и Orwat [Bless2] представляют четвертую позицию. Они утверждают, что еще рано делать какие-либо окончательные заявления, но что существует необходимость в более тщательном анализе влияния выбора дизайна протокола на права человека. Они также утверждают, что важно искать решения, которые «повышают осведомленность технического сообщества о влиянии выбора дизайна на социальные ценности» и «разрабатывают методологию совместного проектирования технических и институциональных систем».

Бернерс-Ли и Хэлпин [BernersLeeHalpin] представляют пятую позицию. Они утверждают, что Интернет может привести к еще более новым возможностям, и эти возможности могут со временем рассматриваться как новые виды прав. Например, доступ к Интернету может рассматриваться как право человека само по себе, если он считается предварительным условием для других прав, даже если он не мог быть предсказан во время написания UDHR (после окончания Война II).

Важно контекстуализировать техническую дискуссию с академической дискуссией по этому вопросу. Академические дискуссии также важны для документирования, поскольку они отражают позицию авторов этого документа. Позиция исследовательской группы заключается в том, что жесткое кодирование прав человека в протоколы является сложным и меняется в зависимости от контекста. На данный момент трудно сказать, является ли жесткое кодирование прав человека в протоколах разумным или целесообразным. Кроме того, существует много прав человека, но не все они имеют отношение к информационным и коммуникационным технологиям (ICTs). Частичный каталог (со ссылками на источники) прав человека, связанных с ICTs, можно найти в [Hill2014]. Однако важно принимать осознанные и четкие проектные решения, которые учитывают руководящие принципы, касающиеся протоколов в области прав человека, разработанные ниже. Это будет способствовать пониманию влияния протоколов на права человека как для разработчиков, так и для пользователей. Кроме того, это способствует (1) тщательному рассмотрению воздействия, которое конкретный протокол может оказать на права человека, и (2) распространению практики документирования решений по разработке протоколов, касающихся прав человека.

В соответствии с принципом постоянных изменений, поскольку функция и сфера действия Интернета меняются, возрастает и роль IETF в разработке стандартов. Стандарты Интернета принимаются на основе ряда критериев, включая высокое техническое качество, поддержку со стороны сообщества и их общую пользу для Интернета. Последнее требует оценки интересов всех затрагиваемых сторон и влияния спецификаций на пользователей Интернета. В этом отношении эффективное осуществление прав человека пользователей Интернета является важным соображением, которое необходимо учитывать в процессе стандартизации, поскольку оно напрямую связано с надежностью и основными ценностями Интернета [RFC1958] [RFC2775] [ RFC3439] [RFC3724].

В этом документе подробно описываются шаги, предпринятые исследовательской группой HRPC для изучения протокола о правах человека, чтобы прояснить взаимосвязь между техническими концепциями, используемыми в IETF, и правами человека. В этом документе изложены некоторые предварительные шаги и соображения, которые инженеры должны учитывать при разработке стандартов и протоколов.

 

5. Методология

Отображение взаимосвязи между правами человека, протоколами и архитектурами является новой исследовательской задачей, которая требует значительного междисциплинарного и межорганизационного сотрудничества для разработки последовательной методологии.

Методологический выбор, сделанный в этом документе, основан на политологическом методе дискурс-анализа и этнографических исследованиях [Cath]. Эта работа отходит от предположения, что язык отражает понимание концепций. Или, как считает [Jabri], программные документы — это «социальные отношения, представленные в текстах, где язык, содержащийся в этих текстах, используется для конструирования значения и представления». Этот процесс происходит в обществе [Denzin] и проявляется в учреждениях и организациях [King], раскрытых с использованием этнографических методов полуструктурированных интервью и наблюдения за участниками. Или, если говорить не на академическом языке, то, как язык в документах IETF/IRTF описывает и подходит к проблемам, которые они пытаются решить, указывает на основные социальные предположения и отношения инженеров к их разработке. Читая и анализируя эти документы, а также проводя собеседования с инженерами и участвуя в рабочих группах IETF/IRTF, можно выявить взаимосвязь между правами человека, протоколами и инфраструктурой Интернета, поскольку она имеет отношение к работе IETF.

Дискурс-анализ проводился с использованием качественных и количественных средств. Первым шагом, предпринятым авторами и участниками, было чтение RFC и других официальных документов IETF. Вторым этапом было использование анализатора на основе Python с использованием инструмента «Bigbang», адаптированного Ником Доти [Doty], для сканирования концепций, которые были определены как важные архитектурные принципы (взятые из первоначального чтения и дополненные интервью и наблюдение за участниками). Такой количественный метод очень точен и ускоряет исследовательский процесс [Ritchie]. Но этот инструмент не в состоянии понять «скрытое значение» [Denzin]. Чтобы смягчить эти проблемы автоматизированных основанных на частоте слов подходов и получить представление о «толстом значении» [Geertz] данных, был проведен второй качественный анализ набора данных. Эти различные раунды анализа дискурса были использованы для информирования интервью и дальнейшего анализа данных. Таким образом, первые раунды количественного дискурсивного анализа были использованы для информирования о вторых раундах качественного анализа. Результаты качественных интервью снова использовались для подачи новых концепций в количественный анализ дискурса. Таким образом, эти два метода продолжали поддерживать и обогащать друг друга.

Этнографические методы сбора и обработки данных позволили исследовательской группе получить данные, необходимые для «обеспечения целостного понимания взглядов и действий участников исследования» [Denzin], в которых освещались текущие проблемы и тематические исследования, в которых протоколы влияют на права человека. Участники интервью были отобраны с помощью целенаправленной выборки [Babbie], поскольку исследовательская группа была заинтересована в получении широкого разнообразия мнений о роли прав человека в разработке протоколов. Этот метод выборки также гарантировал, что люди с большим опытом работы в IETF в различных ролях были мишенью. В число опрошенных входили лица, занимающие руководящие должности (председатели рабочих групп (WG), региональные директора (AD)), «постоянные участники», а также лица, работающие на конкретные организации (корпоративные, гражданское общество, политические, академические) и представляющие различные фоны, национальности, и гендеры.

 

5.1. Источники данных

Чтобы составить карту потенциальной взаимосвязи между правами человека и протоколами, Исследовательская группа HRPC собрала данные из трех конкретных источников:

5.1.1. Дискурс-анализ RFC

Чтобы приступить к решению проблемы, была проведена картографическая работа с анализом инфраструктуры Интернета и протокольных функций с точки зрения их возможного воздействия на права человека. Поэтому было проведено исследование (1) языка, используемого в текущих и исторических RFC, и (2) информации, собранной в ходе обсуждений в списке рассылки, с целью раскрытия основных архитектурных принципов, языка и обсуждения прав человека тех, кого затрагивает сеть.

5.1.2. Интервью с членами сообщества IETF

На собрании IETF 92 в Далласе было проведено более 30 интервью с нынешними и бывшими членами Совета по архитектуре Интернета (IAB), нынешними и бывшими членами Руководящей группы по инженерным вопросам интернета (IESG), председателями отдельных рабочих групп и авторами RFC. в марте 2015 года, чтобы узнать, как они видят отношения (если таковые имеются) между правами человека и протоколами, и как эти отношения влияют на их работу. Несколько участников решили остаться анонимными. Если вы заинтересованы в этом наборе данных, пожалуйста, свяжитесь с авторами этого документа.

5.1.3. Наблюдение за участниками в рабочих группах

Благодаря участию в различных рабочих группах, лично на собраниях IETF и в списках рассылки, была собрана информация о повседневной работе IETF, из которой были извлечены общие темы, технические концепции и примеры использования прав человека и протоколов. Этот процесс начался на собрании IETF 91 в Гонолулу и продолжается сегодня.

5.2. Стратегии анализа данных

Приведенные выше данные были обработаны с использованием трех последовательных стратегий: составление карт протоколов, связанных с правами человека, извлечение концепций из этих протоколов и создание общего глоссария (подробно описано в разделе 2). Прежде чем перейти к рассмотрению этих стратегий, необходимо провести некоторую разработку процесса определения технических концепций, связанных с правами человека:

5.2.1. Определение качеств технических понятий, связанных с правами человека

5.2.1.1. Составление карт протоколов и стандартов по правам человека

Комбинируя данные из трех названных выше источников данных, был создан обширный список протоколов и стандартов, которые потенциально позволяют использовать Интернет в качестве инструмента свободы выражения мнений и ассоциации. Для того чтобы определить стимулирующие (или запрещающие) функции, мы полагались на прямые ссылки в RFC, связанные с такими воздействиями, а также на вклад сообщества. На основе этого анализа был составлен список RFC, которые описывают стандарты и протоколы, которые потенциально тесно связаны с правами человека.

5.2.1.2. Извлечение концепций из выбранных RFC

Первым шагом было определение протоколов и стандартов, связанных с правами человека, и создание среды, обеспечивающей права человека. Для этого нам нужно было сосредоточиться на конкретных технических концепциях, лежащих в основе этих протоколов и стандартов. Основываясь на этом списке, ряд технических понятий, которые часто появлялись, были извлечены и использованы для создания второго списка технических терминов, которые, при объединении и применении в различных обстоятельствах, создают благоприятную среду для осуществления прав человека в Интернете.

5.2.1.3. Создание общего словаря технических понятий, влияющих на права человека

При опросе экспертов, расследовании RFC и составлении технических определений было выявлено несколько концепций конвергенции и расхождения. Чтобы обсуждение было основано на общем понимании терминов и словарного запаса, был создан список определений. Определения основаны на формулировке, найденной в различных документах IETF; если определения там отсутствовали, определения были взяты из других SDO или академической литературы, как указано в Разделе 2.

5.2.1.4. Перевод концепций прав человека в технические определения

Предыдущие шаги позволили уточнить взаимосвязи между правами человека и техническими концепциями. Предпринятые шаги показывают, как «масштабируется» процесс исследования, начиная от составления широкого списка протоколов и стандартов, касающихся прав человека, и заканчивая извлечением точных технических концепций, составляющих эти протоколы и стандарты, чтобы понять взаимосвязь между этими двумя , В этом подразделе представлен следующий шаг: преобразование прав человека в технические концепции путем сопоставления отдельных компонентов прав с сопровождающими техническими концепциями, что позволяет создать список технических концепций, которые при частичном объединении могут создать благоприятную среду для прав человека.

5.2.1.5. Список технических терминов, которые при частичном сочетании могут создать благоприятную среду для прав человека

На основе предыдущих шагов был составлен следующий список технических терминов. При частичном объединении этот список может создать благоприятную среду для прав человека, такую как свобода выражения мнений и свобода ассоциаций.

5.2.2. Отношение прав человека к техническим концепциям

Технические концепции, перечисленные в вышеперечисленных шагах, были сгруппированы в соответствии с их влиянием на конкретные права, как упоминалось в интервью, проведенных на IETF 92, а также в исследовании литературы (см. Раздел 4 («Обзор литературы и дискуссий») выше).

Этот анализ направлен на то, чтобы помочь разработчикам протоколов лучше понять роли, которые играют конкретные технические концепции в отношении их вклада в благоприятную среду, в которой люди могут осуществлять свои права человека.

Этот анализ не претендует на то, чтобы быть полным или исчерпывающим отображением всех возможных способов, которыми протоколы могут потенциально повлиять на права человека, но он представляет собой отображение первоначальных концепций, основанных на интервью, обсуждении и обзоре литературы.

5.2.3. Картирование случаев протоколов, реализаций и сетевых парадигм, которые негативно влияют на права человека или являются их стимулами

Учитывая приведенную выше информацию, был сформирован следующий список случаев протоколов, реализаций и сетевых парадигм, которые либо негативно влияют, либо способствуют правам человека.

Важно отметить, что оценка здесь не является общим суждением по этим протоколам и не является исчерпывающим списком всех потенциальных негативных или позитивных воздействий на права человека, которые могут иметь эти протоколы. Когда эти протоколы были задуманы, было много критериев, которые нужно было принять во внимание. Например, полагаться на централизованную услугу может быть плохо для свободы слова (это создает еще одну контрольную точку, где может применяться цензура), но это может быть необходимо, если конечные точки не подключены и доступны постоянно. Итак, когда мы говорим, что «протокол X имеет особенность Y, которая может поставить под угрозу свободу слова», это не означает, что протокол X плохой, тем более что его авторы были злыми. Цель здесь — показать на реальных примерах, что разработка протоколов имеет практические последствия для некоторых прав человека и что эти последствия необходимо учитывать на этапе разработки.

5.2.3.1. IPv4

Интернет-протокол версии 4 (IPv4), также известный как «Уровень 3» Интернета и указанный с общим заголовком инкапсуляции и протокола, определен в [RFC791]. Эволюция интернет-коммуникаций привела к дальнейшему развитию в этой области, «инкапсулированной» в разработку версии 6 (IPv6) протокола [RFC8200]. Несмотря на этот обновленный протокол, мы обнаруживаем, что через 23 года после спецификации IPv6 на более старый стандарт IPv4 по-прежнему приходится значительная часть интернет-трафика. Большинство обсуждаемых здесь проблем (преобразователи сетевых адресов (NAT) являются основным исключением; см. Раздел 5.2.3.1.2 («Преобразование адресов и мобильность»)) действительны как для IPv4, так и для IPv6.

Интернет был задуман как платформа для свободного и открытого общения, особенно кодируемого в сквозном принципе, и эта философия также присутствует в технической реализации IP [RFC3724]. Несмотря на то, что протокол был разработан для существования в среде, где на конечных хостах находятся сведения, он доказал, что предоставляет достаточно информации, чтобы более интеллектуальное сетевое ядро ​​могло принимать политические решения и обеспечивать формирование трафика на основе политик, тем самым ограничивая связь конечных хостов , Эти возможности для управления сетью и ограничения свободы выражения конечными хостами можно проследить до дизайна IPv4, что помогает нам понять, какие решения по техническим протоколам привели к ущемлению этого права человека. Функцией, которая может нанести вред свободе выражения, а также праву на неприкосновенность частной жизни через злоупотребление IP, является использование общедоступной видимости пар узлов для всех коммуникаций и соответствующей способности дифференцировать и блокировать трафик в результате этих метаданных.

5.2.3.1.1. Видимость сети источника и назначения

Заголовок протокола IPv4 содержит фиксированные поля расположения как для IP-адреса источника, так и для IP-адреса назначения [RFC791]. Эти адреса идентифицируют как отправляющего хоста, так и принимающего каждое сообщение; они также позволяют базовой сети понимать, кто с кем разговаривает, и практически ограничивать связь между парами хостов. Блокирование коммуникации на основе пары источника и назначения является одним из наиболее распространенных ограничений на способность людей общаться сегодня [CAIDA] и может рассматриваться как ограничение способности людей собираться или выражать свое мнение по своему усмотрению.

Включение идентифицируемого в Интернете источника в заголовок IP — не единственная возможная схема, тем более что протокол чаще всего реализуется в сетях Ethernet, в которых используются только идентификаторы локальной линии [RFC894].

Существуют различные альтернативные варианты, такие как учетный и частный интернет-протокол [APIP] и высокоскоростная луковичная маршрутизация на сетевом уровне (HORNET) [HORNET], а также маршрутизация от источника. Последнее позволило бы отправителю выбрать предопределенный (безопасный) маршрут и подделку IP-адреса источника, которые технически поддерживаются IPv4, но ни один из них не считается хорошей практикой в ​​Интернете [Farrow]. Хотя проекты, такие как [TorProject], обеспечивают альтернативную реализацию анонимности в соединениях, они были разработаны, несмотря на дизайн протокола IPv4.

5.2.3.1.2. Трансляция адресов и мобильность

Основным структурным сдвигом в Интернете, который подорвал дизайн протокола IPv4 и значительно сократил свободу конечных пользователей для общения и сборки, стало введение трансляции сетевых адресов [RFC3022]. Трансляция сетевых адресов — это процесс, при котором организации и автономные системы соединяют две сети путем преобразования адресов источника и назначения IPv4 между ними. Этот процесс ставит маршрутизатор, выполняющий трансляцию, в привилегированное положение, где заранее определено, какое подмножество сообщений будет транслироваться.

Этот процесс перевода получил широкое распространение, несмотря на продвижение процесса, который идет вразрез с заявленным сквозным процессом базового протокола [NATusage]. Напротив, предложенный механизм для обеспечения поддержки мобильности и пересылки клиентам, которые могут перемещаться — вместо этого кодируется в качестве опции в IP [RFC5944] — не смог набрать силу. В этой ситуации компромисс, достигнутый при разработке протокола, привел к созданию технологии, которая не соответствует сквозным принципам и, таким образом, создает дополнительное возможное препятствие для свободы выражения при его разработке, даже если существует жизнеспособная альтернатива , Существует конкретная проблема, связанная с NAT и виртуальными частными сетями (VPN) (а также с другими соединениями, используемыми в целях конфиденциальности), поскольку NAT иногда приводит к тому, что VPN не работают.

5.2.3.2. DNS

Система доменных имен (DNS) [RFC1035] предоставляет возможности обнаружения услуг и предоставляет механизм для связи удобочитаемых имен с сервисами. DNS организован вокруг набора независимо управляемых «корневых серверов», управляемых организациями, которые функционируют в соответствии с политикой ICANN, отвечая на запросы, для которых были делегированы организации для управления регистрацией в каждом домене верхнего уровня (TLD). DNS организован в виде корневого дерева, и это поднимает политические и социальные проблемы контроля. TLDs поддерживаются и определяются ICANN. Эти пространства имен охватывают несколько классов услуг. Первоначальные пространства имен, в том числе «.com» и «.net», предоставляют общие пространства для выражения идей, хотя их политика определяется американскими компаниями. Другие пространства имен делегируются конкретным национальностям и могут налагать ограничения, предназначенные для того, чтобы сосредоточить речь на этих форумах, чтобы (1) продвигать речь от этой национальности и (2) соблюдать местные ограничения на выражение и социальные нормы. Наконец, система была недавно расширена за счет дополнительных общих и спонсируемых пространств имен — например, «.travel» и «.ninja» — которые управляются рядом организаций, которые могут самостоятельно определять свои политики регистрации. Это новое развитие имеет как положительные, так и отрицательные последствия с точки зрения обеспечения прав человека. Некоторые люди утверждают, что это подрывает право на свободу выражения мнений, поскольку некоторые из этих новых родовых TLDs имеют ограниченную политику регистрации и особые правила в отношении содержания разжигания ненависти. Другие утверждают, что именно эти свойства являются положительными, поскольку они позволяют определенным (в основном меньшинствам) общинам создавать более безопасные пространства для ассоциации, тем самым обеспечивая их право на свободу ассоциации. Часто упоминаемый пример — это приложение типа .gay [CoE].

Как обсуждалось в [RFC7626], DNS имеет значительные проблемы с конфиденциальностью. Наиболее примечательным является отсутствие шифрования для ограничения видимости запросов на разрешение домена от посредников и ограниченное развертывание DNSSEC для обеспечения аутентификации, что позволяет клиенту знать, что он получил правильный, «авторитетный» ответ на запрос. В ответ на вопросы конфиденциальности рабочая группа IETF DNS Private Exchange (DPRIVE) разрабатывает механизмы обеспечения конфиденциальности транзакций DNS для решения проблем, связанных с повсеместным мониторингом [RFC7258].

Аутентификация через DNSSEC создает путь проверки для записей. Эта аутентификация защищает от поддельных или манипулированных данных DNS. Таким образом, DNSSEC защищает поиск в каталогах и усложняет захват сеанса. Это важно, потому что вмешательство в работу DNS в настоящее время становится одним из центральных механизмов, используемых для блокировки доступа к веб-сайтам. Это вмешательство ограничивает как свободу слова издателя предлагать свой контент, так и свободу собраний для клиентов, которые собираются в общем виртуальном пространстве. Несмотря на то, что DNSSEC не предотвращает цензуру, она дает понять, что возвращаемая информация не является запрашиваемой информацией; это способствует праву на безопасность и повышает доверие к сети. Однако важно отметить, что DNSSEC в настоящее время широко не поддерживается или не используется регистраторами доменных имен, что затрудняет аутентификацию и правильное использование.

5.2.3.2.1. Удаление записей

Был ряд случаев, когда записи для домена были удалены из системы имен из-за политических событий. Примеры этого удаления включают «захват» wikileaks [BBC-wikileaks] и названия незаконно действующих операций азартных игр подразделением по иммиграции и таможенному правоприменению (ICE) США. В первом случае суд США обязал регистратора закрыть домен. Во-вторых, ICE вынудил регистрацию в США, отвечающую за домен .com, передать право собственности на эти домены правительству США. Тот же метод был использован в Ливии, чтобы удалить сайты в нарушение «Закона нашей страны и нравственности (которые) не допускают каких-либо порнографии или его продвижение.» [Techyum]

На уровне протокола не проводится технический аудит владения именами, как в альтернативных системах, таких как Namecoin [Namecoin]. В результате пользователи не могут отличить конфискацию от законной передачи права собственности на имя, что является чисто политическим решением, принятым регистраторами. В то время как DNSSEC обращается к событиям искажения сети, описанным ниже, это не решает эту проблему.

(Хотя мы упоминаем альтернативные методы, это не сравнение DNS с Namecoin: у последнего есть свои проблемы и ограничения. Идея здесь состоит в том, чтобы показать, что существует несколько возможных вариантов, и они имеют последствия для прав человека.)

5.2.3.2.2. Искажение записей

Наиболее распространенным механизмом, с помощью которого DNS используется для ограничения свободы выражения, является манипулирование сетевыми сообщениями протокола. Одна форма возникает на уровне организации, где клиентские компьютеры получают инструкции использовать локальный преобразователь DNS, контролируемый организацией. DNS-распознаватель будет затем выборочно искажать ответы, а не запрашивать авторитетный поиск в вышестоящей системе. Вторая форма возникает при использовании Deep Packet Inspection (DPI), где все сообщения протокола DNS проверяются сетью, а нежелательный контент искажается, что можно наблюдать в китайских сетях.

Заметный случай искажения произошел в Греции [Ververis], где в ходе исследования были обнаружены доказательства (1) DPI для искажения ответов DNS и (2) более чрезмерной блокировки контента, чем требовалось или требовалось по закону (также известной как «перегрузка») , Интернет-провайдеры (ISP), подчиняясь правительственному распоряжению, не давали клиентам разрешать имена доменов, тем самым вызывая именно эту блокировку систем.

На уровне протокола эффективность этих атак становится возможной благодаря отсутствию аутентификации в протоколе DNS. DNSSEC предоставляет возможность определять подлинность ответов при их использовании, но они не регулярно проверяются распознавателями. DNSSEC не эффективен, когда локальный распознаватель для сети является соучастником искажения — например, когда преобразователь, назначенный для использования поставщиком услуг Интернета, является источником инъекции. Избирательное искажение записей также стало возможным благодаря предсказуемой структуре DNS-сообщений, которая позволяет вычислительному устройству легко просматривать все проходящие сообщения даже на высоких скоростях, а также отсутствию шифрования, которое позволяет сети искажать только нежелательные сообщения. подмножество протокольных сообщений. Конкретные механизмы искажения обсуждаются далее в [Зале].

Пользователи могут переключаться на другой распознаватель — например, общедоступный распознаватель. Затем искажающее устройство может попытаться заблокировать или захватить соединение с этим распознавателем. Это может привести к гонке вооружений, когда пользователь переключится на защищенные соединения с этим альтернативным распознавателем [RFC7858], а затем искажатель попытается найти более изощренные способы блокирования или захвата соединения. В некоторых случаях этот поиск альтернативного, не нарушающего работу распознавателя может привести к большей централизации, поскольку многие люди переходят на несколько крупных коммерческих общедоступных распознавателей.

5.2.3.2.3. Инъекция записей

Неправильный ответ на запросы о поиске имен является наиболее распространенным механизмом, который используют сетевые устройства для ограничения возможности конечных пользователей обнаруживать службы. Отклонение, которое выполняет аналогичную задачу и может рассматриваться как отличное от перспективы «свободы выражения», — это введение неверных ответов на запросы. Наиболее яркий пример такого поведения наблюдается в Китае, где запросы на поиск сайтов, которые считаются неуместными, заставят сеть вернуть ложный ответ, в результате чего клиент будет игнорировать реальный ответ при его последующем получении [greatfirewall]. В отличие от других сетевых парадигм, обсужденных выше, внедрение не ограничивает способность сервера сообщать свое имя; вместо этого он дает другой голос, который отвечает раньше. Это эффективно, потому что без DNSSEC протокол будет отвечать на любой ответ, полученный первым, без прослушивания последующих ответов.

5.2.3.3. HTTP

Протокол передачи гипертекста (HTTP) версии 1.1 [RFC7230] [RFC7231] [RFC7232 #] [RFC7233] [RFC7234] [RFC7235] [RFC7236] [RFC7236] является протоколом приложения запроса-ответа, разработанным на протяжении 1990-х годов. HTTP фактически способствовал экспоненциальному росту Интернета и взаимосвязям между людьми по всему миру. Его простая конструкция внесла значительный вклад в то, что HTTP стал основой большинства современных интернет-платформ и систем связи, от веб-сайтов до систем чата и компьютер-компьютерных приложений. В своем проявлении во Всемирной паутине HTTP радикально изменил ход технологического развития и способы взаимодействия людей с онлайн-контентом и друг с другом.

Однако HTTP также является принципиально небезопасным протоколом, который изначально не обеспечивает свойства шифрования. Хотя определение Secure Sockets Layer (SSL) [RFC6101], а затем и Transport Layer Security (TLS) [RFC5246] также произошло в 1990-х годах, тот факт, что HTTP не предписывает использование таких уровней шифрования разработчиками и поставщики услуг были одной из причин очень позднего принятия шифрования. Только в середине 2000-х годов мы наблюдали, как крупные интернет-провайдеры, такие как Google, начали предоставлять зашифрованный доступ к своим веб-сервисам.

Отсутствие чувствительности и понимания критической важности обеспечения безопасности веб-трафика стимулировало некоторых (оскорбительных) участников к разработке, развертыванию и использованию систем перехвата в целом и последующему запуску активных инъекционных атак, чтобы проводить большие объемы данных и подвергать риску Интернет устройства. Коммерческая доступность систем и инструментов для проведения подобных атак также привела к ряду нарушений прав человека, которые были обнаружены и о которых сообщалось на протяжении многих лет.

Как правило, мы можем идентифицировать перехват трафика (раздел 5.2.3.3.1) и манипулирование трафиком (раздел 5.2.3.3.2) как две наиболее проблемные атаки, которые могут быть выполнены против приложений, использующих транспортный уровень HTTP с открытым текстом. При этом IETF предпринимает последовательные шаги для перехода на зашифрованную версию HTTP, HTTP Secure (HTTPS).

Хотя это похвально, мы не должны упускать из виду тот факт, что различные протоколы, реализации, конфигурации и сетевые парадигмы могут пересекаться так, что они (могут использоваться) негативно влияют на права человека. Например, чтобы облегчить наблюдение, некоторые страны будут ограничивать HTTPS-соединения, заставляя пользователей переключаться на (не регулируемый) HTTP [Aryan-etal].

5.2.3.3.1. Перехват трафика

Хотя в последние пару лет мы наблюдаем растущую тенденцию использовать SSL / TLS в качестве безопасного уровня трафика для приложений на основе HTTP, мы все еще далеки от того, чтобы повсеместно использовать повсеместное использование шифрования. Важно учитывать, что принятие SSL / TLS также является относительно недавним явлением.

Поставщики электронной почты, такие как riseup.net, первыми включили SSL по умолчанию. Google не предоставлял опцию своим пользователям Gmail для навигации по SSL до 2008 года [Rideout] и позже включил TLS по умолчанию, в 2010 году [Schillace]. Потребовалось все больше нарушений безопасности и откровений о глобальном наблюдении от Эдварда Сноудена, прежде чем другие поставщики почтовых услуг последовали их примеру. Например, Yahoo не включала SSL / TLS по умолчанию в своих службах веб-почты до начала 2014 года [Петерсон].

Сам TLS подвергался многим атакам и ошибкам; Эта ситуация может быть объяснена некоторыми фундаментальными недостатками дизайна, такими как отсутствие конечного автомата (который открывает уязвимость для атак тройного рукопожатия) и недостатки, вызванные ранними ограничениями правительства США на криптографию, что приводит к атакам с понижением качества комплекта шифров (атаки Logjam) , Эти уязвимости исправляются в TLS 1.3 [Бхаргаван] [Адриан].

Обновление HTTP до HTTPS также уязвимо, так как злоумышленник удаляет «s» в любых ссылках на URI HTTPS со страницы, передаваемой в незашифрованном виде по HTTP — атака, называемая «SSL Stripping» [sslstrip]. Таким образом, для использования HTTPS с высоким уровнем безопасности следует использовать стандарты IETF, такие как HTTP Strict Transport Security (HSTS) [RFC6797], закрепление сертификата [RFC7469] и / или аутентификация именованных объектов на основе DNS (DANE) [RFC6698].

Как мы узнали из откровений Сноудена, спецслужбы много лет перехватывали и собирали незашифрованный трафик. Имеются документально подтвержденные примеры таких программ массового наблюдения с Tempora [WP-Tempora] из Центрального штаба связи (GCHQ) и XKeyscore [Гринвальд] из Агентства национальной безопасности (NSA). Благодаря этим программам АНБ и GCHQ смогли провести большие объемы данных, включая электронную почту и обмен мгновенными сообщениями, которые годами передавались в открытом виде поставщиками, не подозревающими о распространенности и масштабах усилий правительств и инвестиций в глобальные возможности массового наблюдения.

Однако в некоторых демократических странах аналогичный массовый перехват незашифрованных HTTP-коммуникаций также часто используется на национальном уровне путем осуществления контроля над государственными интернет-провайдерами и использования коммерчески доступного оборудования для мониторинга, сбора и цензуры. За последние несколько лет общественности стало известно много информации о роли и масштабах индустрии наблюдения, занимающейся разработкой различных типов устройств перехвата, использующих известные и неизвестные недостатки существующих протоколов [RFC7258]. У нас есть несколько записей о том, что такое оборудование продавалось и использовалось некоторыми режимами для мониторинга целых слоев населения, особенно в периоды социальных и политических бедствий, что позволяет выявить массовые нарушения прав человека. Например, в 2013 году группа Telecomix раскрыла, что сирийский режим использует продукты Blue Coat для перехвата открытого текста, а также для обеспечения цензуры нежелательного контента [RSF]. Аналогичным образом, в 2011 году было установлено, что французская технологическая фирма Amesys предоставила правительству Каддафи оборудование, способное перехватывать электронную почту, трафик Facebook и сообщения чата на уровне всей страны [WSJ]. Использование таких систем, особенно в контексте «арабской весны» и гражданских восстаний против диктатур, вызвало серьезную обеспокоенность в связи с серьезными нарушениями прав человека в Ливии.

5.2.3.3.2. Управление движением

Отсутствие безопасного транспортного уровня в HTTP-соединениях не только подвергает пользователей перехвату содержимого их сообщений, но и все чаще используется как средство для активной компрометации компьютеров и мобильных устройств. Если сеанс HTTP проходит в открытом виде по сети, любой узел, расположенный в любой точке сети, может выполнять атаки «человек посередине»; узел может наблюдать за сеансом, манипулировать им и перехватывать его и может изменять содержимое сообщения, чтобы вызвать непредвиденное поведение приложения, генерирующего трафик. Например, в случае браузера злоумышленник сможет внедрить вредоносный код для использования уязвимостей в браузере или любом из его плагинов. Аналогично, злоумышленник сможет перехватывать, добавлять вредоносные программы и перепаковывать двоичные обновления программного обеспечения, которые очень часто загружаются в открытом виде приложениями, такими как текстовые процессоры и медиаплееры. Если бы сеанс HTTP был зашифрован, подделка контента была бы невозможна, и эти атаки с использованием сетевых инъекций не были бы успешными.

Хотя атаки с манипулированием трафиком давно известны, задокументированы и созданы прототипами, особенно в контексте сетей Wi-Fi и LAN, в последние несколько лет мы наблюдаем рост инвестиций в производство и продажу оборудования для инъекций в сеть, которое является коммерческим доступны и развернуты в масштабе спецслужбами.

Например, мы узнали из некоторых документов, предоставленных Эдвардом Сноуденом для прессы, что АНБ построило глобальную инфраструктуру сетевой инъекции, названную «QUANTUM», способную использовать массовое наблюдение для выявления целей, представляющих интерес, и впоследствии для управления задачами. локальные атаки, которые в конечном итоге скомпрометируют выбранное устройство. Среди других атак, NSA использует атаку под названием «QUANTUMINSERT» [Haagsma], которая перехватывает и перехватывает незашифрованные HTTP-сообщения и заставляет запрашивающий браузер перенаправлять на хост, контролируемый NSA, вместо намеченного веб-сайта. Обычно новым местом назначения будет служба эксплуатации, называемая в документах Сноудена «FOXACID», которая будет пытаться выполнить вредоносный код в контексте браузера цели. В 2013 году The Guardian сообщила, что АНБ, например, использует эти методы для нацеливания на пользователей популярного сервиса анонимности Tor [Schneier]. Немецкий Norddeutscher Rundfunk (NDR) сообщил в 2014 году, что АНБ также использует свои возможности массового наблюдения для идентификации пользователей Tor в целом [Аппельбаум].

Недавно о подобных возможностях, использованных китайскими властями, также сообщалось в так называемом «Великом орудии» [Marcak], которое вызывало многочисленные опасения по поводу потенциального ограничения прав человека и свободы слова из-за все более жесткого контроля над Китайские интернет-коммуникации и доступ к информации.

Атаки по сети также становятся широко доступными для государственных субъектов во всем мире благодаря коммерциализации аналогичного оборудования меньшего масштаба, которое можно легко приобрести и развернуть на уровне всей страны. Известно, что некоторые компании имеют сетевые инъекционные устройства в своем ассортименте продукции [Marquis-Boire]. Технология, разработанная и созданная некоторыми из них для выполнения атак манипулирования сетевым трафиком по HTTP-коммуникациям, даже является предметом патентной заявки в Соединенных Штатах [Googlepatent]. Доступ к оскорбительным технологиям, доступным на коммерческом рынке законного перехвата, привел к нарушениям прав человека и незаконному наблюдению за журналистами, правозащитниками и политическими активистами во многих странах мира [Коллинз]. Хотя атаки с использованием сетевых инъекций не были предметом пристального внимания, они позволяют даже неквалифицированным злоумышленникам совершать бесшумные и очень устойчивые компромиссы, а незашифрованный HTTP остается одним из основных средств.

Существует новая версия HTTP, называемая «HTTP / 2» [RFC7540], которая стремится быть в значительной степени обратно совместимой, а также предлагает новые параметры, такие как сжатие данных заголовков HTTP, конвейеризация запросов и мультиплексирование нескольких запросов по одному TCP подключение. Помимо уменьшения задержки для повышения скорости загрузки страниц, это также способствует более эффективному использованию возможностей подключения в средах с низкой пропускной способностью, что, в свою очередь, обеспечивает свободу выражения; право на собрание; право на участие в политической жизни; и право участвовать в культурной жизни, искусстве и науке. [RFC7540] не требует TLS или любой другой формы шифрования, а также не поддерживает оппортунистическое шифрование, даже несмотря на то, что оппортунистическое шифрование теперь рассматривается в [RFC8164].

5.2.3.4. XMPP

Расширяемый протокол обмена сообщениями и присутствия (XMPP), указанный в [RFC6120], обеспечивает стандарт для обмена сообщениями в интерактивном чате и развивается, чтобы охватить совместимый текстовый, голосовой и видеочат. Протокол структурирован как объединенная сеть серверов, аналогичная электронной почте, где пользователи регистрируются на локальном сервере, который действует от их имени для кэширования и ретрансляции сообщений. Такая конструкция протокола имеет много преимуществ, позволяя серверам защищать клиентов от отказа в обслуживании и других форм возмездия за их выражение; это также разработано, чтобы избежать центральных объектов, которые могли управлять способностью общаться или собираться, используя протокол.

Тем не менее, существует множество аспектов разработки протокола XMPP, которые формируют возможность для пользователей свободно общаться и собираться через протокол.

5.2.3.4.1. Идентификация пользователя

Спецификация XMPP [RFC6120] требует, чтобы клиенты идентифицировались с помощью ресурса (<узел @ домен / дом> / <узел @ домен / работа>), чтобы различать разговоры с конкретными устройствами. Хотя в протоколе не указано, что клиентский сервер должен предоставлять этот ресурс удаленным пользователям, на практике это стало поведением по умолчанию. При этом пользователи могут отслеживать удаленных друзей и их серверы, которые могут отслеживать присутствие не только пользователя, но и каждого отдельного устройства, с которым пользователь входит в систему. Это оказалось обманчивым для многих пользователей [Pidgin], так как многие клиенты предоставляют информацию только на уровне пользователя, а не на уровне устройства. Аналогичным образом, невидимость пользователя, так что связь может происходить, когда пользователи не уведомляют всех друзей и другие серверы о своей доступности, не является частью формального протокола и была добавлена только как расширение в потоке XML, а не принудительно применена протоколом.

5.2.3.4.2. Наблюдение за связью

XMPP определяет стандарт, с помощью которого каналы связи могут быть зашифрованы, но он не обеспечивает видимость для клиентов относительно того, зашифрованы ли их сообщения по каждой ссылке. В частности, даже когда оба клиента гарантируют, что у них есть зашифрованное соединение с их сервером XMPP, чтобы гарантировать, что их локальная сеть не может читать или прерывать отправляемые ими сообщения, протокол не обеспечивает видимость состояния шифрования между двумя серверами. Таким образом, клиенты могут подвергаться избирательному прерыванию связи через промежуточную сеть, которая прерывает связь на основе ключевых слов, найденных через DPI. Хотя многие операторы взяли на себя обязательство устанавливать только зашифрованные ссылки со своих серверов в знак признания этой уязвимости, пользователи по-прежнему не могут проверить это поведение, и зашифрованные соединения не требуются самим протоколом [XMPP-Manifesto].

В частности, в разделе 13.14 спецификации XMPP [RFC6120] явным образом признается существование атаки с понижением рейтинга, когда злоумышленник, управляющий промежуточной сетью, может заставить междоменную федерацию между серверами вернуться к незашифрованному протоколу, где затем могут быть выбраны отдельные сообщения. нарушена.

5.2.3.4.3. Ограничения группового чата

Групповой чат в XMPP определяется как расширение в спецификации XML XMPP (https://xmpp.org/extensions/xep-0045.html). Тем не менее, он не кодируется или не требуется на уровне протокола и не применяется клиентами единообразно.

Конструкция многопользовательского чата в XMPP страдает от расширения протокола, который не был разработан с учетом множества пользователей. В частности, в федеративном протоколе, предоставляемом XMPP, многопользовательские сообщества реализованы с выдающимся «владельцем», которому предоставляется контроль над участниками и структурой диалога.

Многопользовательские чаты идентифицируются по имени, указанному на конкретном сервере, поэтому, хотя общий протокол может быть объединен, возможность пользователей собираться в данном сообществе модерируется одним сервером. Этот сервер может блокировать помещение и предотвращать сборку в одностороннем порядке, даже между двумя пользователями, ни один из которых не доверяет или не использует этот сервер напрямую.

5.2.3.5. Пиринговый

Peer-to-Peer (P2P) — это архитектура распределенной сети [RFC5694], в которой все узлы-участники могут отвечать за хранение и распространение информации от любого другого узла (см. [RFC7574], стандарт IETF, в котором обсуждается архитектура P2P. называется «Протокол одноранговой потоковой передачи» (PPSPP)). P2P-сеть — это логическое наложение, которое живет поверх физической сети и позволяет участвующим в ней узлам (или «равноправным узлам») устанавливать контакты и обмениваться информацией напрямую друг с другом. Реализация P2P-сети может широко варьироваться: она может быть структурированной или неструктурированной, и она может реализовывать более сильные или более слабые криптографические и анонимные свойства. Хотя его наиболее распространенным приложением традиционно является совместное использование файлов (и других типов систем доставки контента), P2P является популярной архитектурой для сетей и приложений, которые требуют (или поощряют) децентрализацию. Яркими примерами являются биткойны и другие проприетарные мультимедийные приложения.

Во времена сильно централизованных онлайн-сервисов P2P регулярно описывается как альтернативный, более демократичный и устойчивый вариант, который смещает структуры контроля над данными и коммуникациями и делегирует всем пирам равную ответственность за функционирование, целостность и безопасность данные. Хотя в принципе P2P остается важным для проектирования и разработки будущих систем распространения контента, обмена сообщениями и публикации, он создает многочисленные проблемы безопасности и конфиденциальности, которые в основном делегируются отдельным разработчикам для распознавания, анализа и решения в каждой реализации данного P2P. сеть.

5.2.3.5.1. Сетевое отравление

Поскольку контент, а иногда и списки пиров, защищены и распространяются их членами, P2P-сети подвержены тому, что обычно определяется как «атаки отравления». Атаки отравления могут быть направлены непосредственно на данные, которые распространяются, например, (1) путем преднамеренного повреждения данных, (2) в индексных таблицах, используемых для указания узлам, где следует получать данные, или (3) при маршрутизации таблиц, с попыткой предоставить соединяющимся одноранговым узлам списки мошеннических или несуществующих одноранговых узлов с намерением эффективно вызвать отказ в обслуживании в сети.

5.2.3.5.2. Дроссельный

P2P-трафик (и, в частности, BitTorrent) представляет значительный процент глобального интернет-трафика [Sandvine], и для интернет-провайдеров становится все более популярным выполнять регулирование линий клиентов, чтобы ограничить использование полосы пропускания [torrentfreak1] и, иногда, вероятно, как эффект продолжающегося конфликта между правообладателями и сообществами обмена файлами [wikileaks]. Такое регулирование подрывает сквозной принцип.

Регулирование трафика P2P делает некоторые виды использования сетей P2P неэффективными; это ограничение может быть связано с более строгой проверкой интернет-трафика пользователей с помощью методов DPI, что может создавать дополнительные риски для безопасности и конфиденциальности.

5.2.3.5.3. Отслеживание и идентификация

Одна из фундаментальных и наиболее проблемных проблем традиционных сетей P2P — полное отсутствие анонимности их пользователей. Например, в случае BitTorrent, IP-адреса всех пиров открыто доступны для других пиров. Это привело к постоянно растущему отслеживанию пользователей P2P и файлообменников [ars]. Поскольку географическое местоположение пользователя напрямую отображается, как и его личность, пользователь может стать объектом дополнительных преследований и атак физического или юридического характера. Например, известно, что в Германии юридические фирмы широко используют системы отслеживания P2P и совместного использования файлов, чтобы выявлять загрузчиков и инициировать юридические действия в поисках компенсаций [torrentfreak2].

Стоит отметить, что существует несколько разновидностей P2P-сетей, которые реализуют методы криптографии и вводят анонимность своих пользователей. Такие реализации могут оказаться успешными в противостоянии цензуре контента и отслеживанию сетевых пиров. Ярким примером является Freenet [freenet1], бесплатное программное приложение, которое (1) разработано для того, чтобы значительно усложнить идентификацию пользователей и контента, и (2) предназначено для содействия свободе слова в Интернете [freenet2].

5.2.3.5.4. Сибил Атаки

В P2P-сетях с открытым членством один злоумышленник может притвориться множеством участников, обычно путем создания нескольких поддельных идентификаторов любого вида, который сеть P2P использует [Douceur]. Злоумышленники могут использовать атаки Sybil для смещения выбора, который сеть P2P делает коллективно для преимущества злоумышленника, например, повышая вероятность того, что конкретный элемент данных (или некоторый порог реплик или общих частей данных) будет назначен злоумышленнику. контролируемые участники. Если в P2P-сети реализованы какие-либо функции голосования, модерации или рецензирования, атаки Sybil могут быть использованы для «заполнения бюллетеней», что принесет пользу злоумышленнику. Компании и правительства могут использовать атаки Сибил на P2P-системы, ориентированные на обсуждение, для «астротурфинга» или создания массового массового поддержки для какой-либо позиции, которой на самом деле нет. Важно знать, что не существует известных законченных, экологически устойчивых и полностью распределенных решений для атак Sybil, а маршрутизация через «друзей» позволяет анонимно анонимизировать пользователей через их социальный граф. Важно отметить, что атаки Сибил в этом контексте (например, астротурфинг) имеют отношение не только к протоколам P2P; они также распространены в сетевых системах и эксплуатируются правительствами и коммерческими организациями.

Зашифрованные P2P и анонимные P2P сети уже появились. Они предоставляют жизнеспособные платформы для обмена материалами [Tribler], публикации контента анонимно и безопасного общения [Bitmessage]. Эти платформы не идеальны, и необходимо провести дополнительные исследования. В случае принятия в больших, хорошо спроектированных и устойчивых P2P-сетях, они могут представлять собой критически важный компонент будущего безопасного и распределенного Интернета, обеспечивая свободу слова и свободу информации в масштабе.

5.2.3.6. Виртуальные частные сети

Обсуждаемые здесь VPN-соединения представляют собой двухточечные соединения, которые позволяют двум компьютерам обмениваться данными через зашифрованный туннель. Существует несколько реализаций и протоколов, используемых при развертывании VPN, и они обычно диверсифицируются с помощью протокола шифрования или определенных требований, чаще всего в проприетарных и корпоративных решениях. VPN обычно используются для (1) предоставления возможности некоторым устройствам обмениваться данными через особые конфигурации сети, (2) использовать некоторые свойства конфиденциальности и безопасности для защиты трафика, генерируемого конечным пользователем, или обоих. VPN также стали очень популярной технологией среди правозащитников, диссидентов и журналистов во всем мире, чтобы избежать локального мониторинга и, в конечном итоге, обойти цензуру. VPN часто обсуждаются среди правозащитников как потенциальная альтернатива Tor или другим анонимным сетям. Такие сравнения вводят в заблуждение, так как некоторые свойства конфиденциальности и безопасности VPN часто неправильно понимаются менее опытными пользователями и могут в конечном итоге привести к непреднамеренным проблемам.

По мере того как популярность VPN растет, коммерческие провайдеры VPN начинают расти как предприятия, и их очень часто выбирают правозащитники и люди, которым грозит риск, поскольку они, как правило, предоставляют простой в использовании сервис, а иногда даже пользовательские приложения для установить VPN-туннель Невозможно контролировать конфигурацию сети, не говоря уже о безопасности приложения, оценить общую частную жизнь и состояние безопасности обычных VPN очень сложно. Такие службы часто обнаруживают утечку информации, а их пользовательские приложения были признаны ошибочными. Несмотря на то, что Tor и подобные сети подвергаются тщательному анализу со стороны общественности и академического сообщества, коммерческие или некоммерческие виртуальные частные сети гораздо меньше анализируются и понимаются [Insinuator] [Alshalan-etal], и может оказаться полезным установить некоторые стандарты, чтобы гарантировать минимальный уровень конфиденциальности и безопасности для тех, кто в них нуждается больше всего.

5.2.3.6.1. Нет анонимности в отношении провайдеров VPN

Одним из распространенных заблуждений среди пользователей VPN является уровень анонимности, который может обеспечить VPN. Это чувство анонимности может быть обмануто множеством атак или неправильной настройки VPN-провайдера. Важно помнить, что, в отличие от Tor и аналогичных систем, VPN не предназначены для обеспечения свойств анонимности. С технической точки зрения VPN может привести к утечке идентифицируемой информации или может стать объектом корреляционных атак, которые могут раскрыть исходный адрес подключающегося пользователя. Что наиболее важно, важно понимать, что коммерческие и некоммерческие провайдеры VPN связаны законодательством юрисдикции, в которой они проживают или в которой находится их инфраструктура, и они могут по закону быть вынуждены передавать данные конкретных пользователей, если судебные расследования или требования разведки диктуют это. В таких случаях, если провайдеры VPN сохраняют журналы, возможно, что информация пользователя может быть предоставлена ​​противнику пользователя и привести к его или ее идентификации.

5.2.3.6.2. Логирование

Поскольку виртуальные частные сети являются соединениями типа «точка-точка», поставщики услуг фактически могут наблюдать исходное местоположение подключающихся пользователей, и они могут отслеживать, в какое время они начали свой сеанс и, в конечном итоге, также к каким адресатам они относятся. пытаюсь подключиться. Если провайдеры VPN хранят журналы в течение достаточно долгого времени, они могут быть вынуждены перевернуть соответствующие данные, или они могут быть скомпрометированы иным образом, что приведет к тому, что те же данные будут доступны. Можно применять четкую политику хранения журналов, но, учитывая, что страны применяют разные уровни политик хранения данных, поставщики VPN должны по крайней мере быть прозрачными в отношении того, какую информацию они хранят и как долго она хранится.

5.2.3.6.3. Сторонний хостинг

Провайдеры VPN очень часто полагаются на третьих лиц для предоставления инфраструктуры, которая впоследствии будет использоваться для запуска конечных точек VPN. Например, они могут полагаться на поставщиков внешних выделенных серверов или поставщиков восходящей линии связи. В этих случаях, даже если сам VPN-провайдер не хранит какие-либо важные журналы, информация о подключении пользователей может быть сохранена этими третьими сторонами, что создает дополнительную точку сбора для злоумышленника.

5.2.3.6.4. IPv6 Утечка

Некоторые исследования показали, что некоторые коммерческие провайдеры и приложения VPN страдают от критической утечки информации через IPv6 из-за неправильной поддержки и конфигурации [PETS2015VPN]. Обычно это вызвано отсутствием надлежащей конфигурации клиентских таблиц маршрутизации IPv6. Учитывая, что большинство популярных браузеров и аналогичных приложений по умолчанию поддерживают IPv6, если хосту предоставляется функциональная конфигурация IPv6, генерируемый трафик может быть пропущен, если приложение VPN не предназначено для правильной обработки такого трафика.

5.2.3.6.5. Утечка DNS

Аналогично, VPN-сервисы, которые не обрабатывают DNS-запросы и не используют свои собственные DNS-серверы, могут быть подвержены утечке DNS, что может не только раскрыть конфиденциальную информацию о деятельности пользователя, но также потенциально может привести к атакам по захвату DNS и последующие компромиссы.

5.2.3.6.6. Корреляция трафика

Некоторые реализации VPN, по-видимому, особенно уязвимы для идентификации и сбора обмена ключами, которые, как показали некоторые документы Сноудена, систематически собираются и хранятся для дальнейшего использования. Способность злоумышленника контролировать сетевые соединения во многих различных точках через Интернет может позволить им выполнять атаки по корреляции трафика и определять источник определенного VPN-трафика путем перекрестной ссылки времени соединения пользователя с конечной точкой и времени соединения конечная точка до конечного пункта назначения. Эти типы атак, хотя и очень дорогие и обычно выполняются только находчивыми противниками, были задокументированы [SPIEGEL], чтобы уже практиковаться, и они могли бы полностью аннулировать использование VPN и в конечном итоге разоблачить активность и личность пользователя. рискованно.

5.2.3.7. Код состояния HTTP 451

«Каждый пользователь Интернета сталкивался с кодом состояния« HTTP-протокол 404 Not Found »по протоколу гипертекстовой передачи (HTTP) при попытке получить доступ к определенному веб-сайту и при сбое». [Cath]. Это статус ответа, который сервер отправляет браузеру, когда сервер не может найти URL. «403 Forbidden» является еще одним примером этого класса кодовых сигналов, который дает пользователям информацию о том, что происходит. В случае «403» сервер может быть подключен, но блокирует запрос, потому что пользователь пытается получить доступ к контенту, запрещенному для него, обычно потому, что некоторый контент предназначен только для идентифицированных пользователей, на основании оплаты или особого статуса в организации. , Большую часть времени 403 отправляется исходным сервером, а не посредником. Если брандмауэр предотвращает государственного служащего от доступа к порнографии на рабочем компьютере, он не использует 403.

По мере того, как надзор и цензура в Интернете становятся все более распространенным явлением, в IETF прозвучали голоса, чтобы ввести новый код статуса, который указывает, когда что-то недоступно по «юридическим причинам» (например, цензура):

Код состояния 451 позволит операторам серверов работать с большей прозрачностью в условиях, когда вопросы права или государственной политики влияют на их работу. Эта прозрачность может быть полезна как для (1) этих операторов, так и (2) конечных пользователей [RFC7725].

Код состояния назван «451» по отношению к известному роману Брэдбери «451 по Фаренгейту» и к 451 градусу по Фаренгейту (температура, при которой некоторые утверждают, что самовоспламеняющиеся бумажные книги).

Во время встречи IETF 92 в Далласе обсуждалась полезность 451. Основное напряжение возникло из-за отсутствия очевидного машиночитаемого технического использования информации. Степень, в которой 451 является просто «политическим театром» или имеет ли он конкретное техническое применение, была горячо обсуждена. Некоторые утверждали, что «код состояния 451 — это просто код состояния с телом ответа»; другие сказали, что это было проблематично, потому что «это приносит закон в картину». Третьи утверждали, что было бы полезно для отдельных лиц или для организаций, таких как проект «Эффект охлаждения», которые сканируют Интернет, чтобы получить указание на цензуру (обсуждение IETF по 451 — полевые заметки автора, март 2015 г.). На встрече в Далласе не было никаких явных возражений против продвижения по коду статуса 451, и 18 декабря 2015 года IESG утвердил «Код статуса HTTP для сообщения о юридических препятствиях» (теперь [RFC7725]) для публикации. Код состояния HTTP 451 теперь является одобренным IETF кодом состояния HTTP, который сигнализирует, когда доступ к ресурсам запрещен вследствие юридических требований.

Что интересно в этом конкретном случае, так это то, что не только технические аргументы, но и прямое потенциальное политическое использование кодекса статуса для гражданского общества сыграли существенную роль в формировании дискуссии и решении двигаться дальше с этой технологией.

Тем не менее важно отметить, что код состояния HTTP 451 не является решением для обнаружения всех случаев цензуры. Большая доля интернет-фильтрации происходит в сети на более низком уровне, чем HTTP, а не на самом сервере. Для этих форм цензуры 451 играет ограниченную роль, поскольку типичные посредники цензуры не будут ее генерировать. Помимо технических причин, такие режимы фильтрации вряд ли добровольно введут код состояния 451. Использование 451, скорее всего, будет применяться в случае кооперативных, законных версий удаления контента в результате запросов к поставщикам. Можно вспомнить контент, который удален или заблокирован по юридическим причинам, таким как нарушение авторских прав, законы об азартных играх, жестокое обращение с детьми и т. Д. Крупные интернет-компании и поисковые системы постоянно просят подвергать цензуре контент в различных юрисдикциях. 451 позволяет легко это обнаружить, например, с помощью таких инициатив, как база данных Lumen.

В целом, сила 451 заключается в ее способности обеспечить прозрачность, указав причину блокировки и предоставив конечному пользователю возможность подать жалобу. Это позволяет организациям легко измерять цензуру в автоматическом режиме и предлагает пользователю получить доступ к контенту по другому пути (например, Tor, VPN), когда он (-ы) встречает код состояния 451.

Код статуса 451 влияет на права человека, делая цензуру более прозрачной и измеримой. Это повышает прозрачность, сигнализируя о существовании цензуры (вместо гораздо более широкого сообщения об ошибках HTTP, такого как код состояния HTTP 404), а также предоставляя подробную информацию о правовом ограничении, какие правовые полномочия налагают его и к какому классу ресурсов оно применяется , Это дает пользователю возможность искать возмещение.

 

5.2.3.8. DDoS-атаки

Многие люди, в том числе инженеры IETF, утверждают, что DDoS-атаки принципиально против свободы слова. Технически, DDoS-атаки — это атаки, когда один хост или несколько хостов перегружают полосу пропускания или ресурсы другого хоста, заполняя его трафиком или делая ресурсоемкие запросы, в результате чего он временно перестает быть доступным для пользователей. Можно примерно дифференцировать три типа DDoS-атак:

1. Атаки на основе тома (которые направлены на то, чтобы сделать хост недоступным за счет использования всей его полосы пропускания; часто используемыми методами являются наводнения UDP и ICMP)
2. Протокольные атаки (целью которых является использование фактических ресурсов сервера; часто используемыми методами являются потоки SYN, атаки фрагментированных пакетов и «пинг смерти» [RFC4949])
3. Атаки на уровне приложений (целью которых является отключение сервера, такого как веб-сервер).

Таким образом, DDoS-атаки могут подавлять свободу выражения мнений и усложнять способность независимых средств массовой информации и правозащитных организаций осуществлять свое право на (онлайн) свободу ассоциации, одновременно способствуя способности правительств подвергать цензуре инакомыслие. Когда дело доходит до сравнения DDoS-атак с протестами в автономном режиме, важно помнить, что только ограниченное количество DDoS-атак вовлекало только добровольных участников. В подавляющем большинстве случаев клиенты являются взломанными хостами несвязанных сторон, которые не дали согласия на участие в DDoS (исключения см. В разделе «Операция Ababil [Ababil]» или кампания «DDoS» Иранского зеленого движения во время выборов [GreenMovement]). Кроме того, DDoS-атаки все чаще используются в качестве тактики вымогательства.

Кажется, что все эти проблемы предполагают, что IETF должен попытаться гарантировать, что их протоколы не могут быть использованы для DDoS-атак; это согласуется с давним консенсусом IETF о том, что DDoS — это атака, которую протоколы должны смягчать, насколько это возможно [BCP72]. Уменьшение количества уязвимостей в протоколах и (за пределами IETF) количества ошибок в сетевых стеках маршрутизаторов или компьютеров может решить эту проблему. IETF может сыграть определенную роль в достижении некоторых из этих изменений, но нельзя ожидать, что IETF займет положительную позицию в отношении (специфических) DDoS-атак или создаст протоколы, которые разрешают одни атаки и препятствуют другим. Что может сделать IETF, так это критически отразиться на его роли в развитии Интернета и на том, как это влияет на способность людей осуществлять свои права человека, такие как свобода выражения мнений.

6. Модель разработки соображений по протоколу о правах человека

В этом разделе изложен ряд соображений по поводу правозащитных протоколов для разработчиков протоколов. В нем содержатся вопросы, которые инженеры должны задать себе при разработке или улучшении протоколов, если они хотят понять их влияние на права человека. Следует, однако, отметить, что влияние протокола не может быть выведено исключительно из его структуры; его использование и осуществление также должны быть изучены, чтобы сформировать полную оценку воздействия протокола на права человека.

Вопросы основаны на исследовании, проведенном исследовательской группой HRPC. Это исследование было задокументировано до написания этих соображений. Исследование устанавливает, что права человека связаны со стандартами и протоколами; он также предлагает общий словарь технических концепций, влияющих на права человека, и способы объединения этих технических концепций для обеспечения того, чтобы Интернет оставался благоприятной средой для прав человека. Благодаря этому сформировалась модель для разработки протокольных соображений.

6.1. Угрозы прав человека

Угрозы правам человека в Интернете принимают множество форм. Протоколы и стандарты могут либо навредить, либо обеспечить право на свободу выражения мнений; право на недискриминацию; право на равную защиту; право на участие в культурной жизни, искусстве и науке; право на свободу собраний и ассоциаций; и право на безопасность. Конечный пользователь, которому отказано в доступе к определенным услугам, данным или веб-сайтам, может быть не в состоянии раскрыть важную информацию о злоупотреблениях со стороны правительства или другого органа. Лицо, чьи сообщения контролируются, может быть лишено возможности реализовать свое право на свободу ассоциации или участие в политических процессах [Penney]. В худшем случае протоколы, которые пропускают информацию, могут привести к физической опасности. Реалистичным примером для рассмотрения является случай, когда на основании информации, собранной государственными органами посредством утечки информации в протоколах, лица, воспринимаемые как угрозы государству, подвергаются пыткам, внесудебным убийствам или задержанию.

В этом разделе подробно описываются несколько «распространенных» угроз правам человека, и указывается, как каждая из них может привести к нанесению вреда или нарушению прав человека. В нем также представлено несколько примеров того, как эти угрозы правам человека материализуются в Интернете. Это моделирование угроз основано на документе [RFC6973] («Вопросы конфиденциальности для интернет-протоколов»), который основан на анализе угроз безопасности. Этот метод ни в коем случае не является идеальным решением для оценки рисков для прав человека в интернет-протоколах и системах; это, однако, лучший подход в настоящее время. Определенные конкретные угрозы прав человека косвенно рассматриваются в интернет-протоколах как часть их соображений безопасности [BCP72], но руководящие принципы или обзоры конфиденциальности [RFC6973], не говоря уже об оценке воздействия протоколов на права человека, не стандартизированы и не применяются.

Многие угрозы, факторы и риски связаны с различными правами. Это неудивительно, если принять во внимание, что права человека взаимосвязаны, взаимозависимы и неделимы. Здесь, однако, мы не обсуждаем все права человека, потому что не все права человека имеют отношение к ИКТ в целом и к протоколам и стандартам в частности [Bless1]:

• Основным источником ценностей прав человека является Международный билль о правах человека, который состоит из Всеобщей декларации прав человека [UDHR] вместе с Международным пактом о гражданских и политических правах [ICCPR] и Международным пактом об экономических, социальных и социальных правах. и культурные права [ICESCR]. В свете нескольких случаев цензуры в Интернете в 2012 году [UNHRC2016] была принята Резолюция Совета по правам человека 20/8, в которой было подтверждено «… что те же права, которые люди имеют в автономном режиме, также должны быть защищены в Интернете …» В 2015 году Хартия прав человека и принципов для Интернета [IRP] была разработана и выпущена. Согласно этим документам, некоторыми примерами прав человека, имеющих отношение к системам IRP, являются человеческое достоинство (статья 1 UDHR), недискриминация (статья 2), права на жизнь, свободу и безопасность (статья 3), свобода мнений и выражение (ст. 19), свобода собраний и ассоциаций (ст. 20), права на равную защиту, средства правовой защиты, справедливое судебное разбирательство, надлежащее судебное разбирательство, предполагаемый невиновность (ст. 7-11), соответствующий социальный и международный порядок (ст. 28) участие в общественных делах (ст. 21), участие в культурной жизни, защита интеллектуальной собственности (ст. 27) и неприкосновенность частной жизни (ст. 12).

Частичный каталог прав человека, связанных с ИКТ, включая экономические права, можно найти в [Hill2014].

Это ни в коем случае не попытка исключить определенные права или расставить приоритеты одних прав над другими. Если другие права представляются актуальными, пожалуйста, свяжитесь с авторами этого документа.

6.2. Руководство по правам человека

Этот раздел содержит рекомендации для авторов документов в форме вопросника о протоколах и их (потенциальном) воздействии. Анкета может быть полезна на любом этапе процесса проектирования, особенно после того, как авторы документа разработали модель протокола высокого уровня, как описано в [RFC4101]. Эти руководящие принципы не стремятся заменить какие-либо существующие ссылочные спецификации; скорее, они способствуют им и смотрят на процесс проектирования с точки зрения прав человека.

Протоколы и Интернет-стандарты могут выиграть от документированного обсуждения потенциальных рисков для прав человека, возникающих в результате возможного неправильного применения протокола или технологии, описанных в данном RFC. Это может быть связано с Заявлением о применимости для этого RFC.

Обратите внимание, что руководство, представленное в этом разделе, не рекомендует конкретные практики. Диапазон протоколов, разработанных в IETF, слишком широк, чтобы давать рекомендации относительно конкретного использования данных или того, как права человека могут быть сбалансированы с другими целями разработки. Однако, тщательно продумав ответы на следующие вопросы, авторы документов должны иметь возможность провести всесторонний анализ, который может послужить основой для обсуждения вопроса о том, адекватно ли протокол учитывает конкретные угрозы в области прав человека. Это руководство предназначено, чтобы помочь мыслительному процессу анализа прав человека; в нем не дается конкретных указаний о том, как написать раздел, посвященный протоколам о правах человека (следуя примеру, установленному в [RFC6973]), и добавление раздела, посвященного протоколам о правах человека, также еще не предлагалось. При рассмотрении этих вопросов авторам необходимо знать о возможном техническом прогрессе или о времени, которое может подорвать защиту. В общем, соображения о правах, вероятно, будут более эффективными, если их рассматривать с учетом цели и конкретных случаев использования, а не как абстрактные абсолютные цели.

6.2.1. Связь

Вопросы:

• Добавляет ли ваш протокол функции приложений для промежуточных узлов?
• Может ли эта функциональность быть добавлена ​​к конечным узлам вместо промежуточных узлов?
• Оптимизирован ли ваш протокол для соединений с низкой пропускной способностью и высокой задержкой?
• Может ли ваш протокол также быть разработан без учета состояния?

Объяснение: Принцип сквозного действия [Солтцер] гласит, что «интеллект является сквозным, а не скрытым в сети» [RFC1958]. Комплексный принцип важен для надежности сети и инноваций. Такая надежность сети имеет решающее значение для обеспечения прав человека, таких как свобода выражения мнений.

Пример: промежуточные ящики (которые могут быть сетями доставки контента, межсетевыми экранами, NAT или другими промежуточными узлами, которые предоставляют «услуги», отличные от маршрутизации), служат многим законным целям.

Но руководящие ими протоколы могут влиять на способность людей свободно и конфиденциально общаться в Интернете. Возможны злоупотребления, преднамеренная и непреднамеренная цензура и ограничение неразрешенных инноваций — и, таким образом, в конечном счете, влияние промежуточных ящиков на Интернет как место нефильтрованной, неконтролируемой свободы слова — является реальным.

Воздействие:

• Право на свободу выражения
• Право на свободу собраний и ассоциаций

6.2.2. Конфиденциальность

Вопросы:

• Вы ознакомились с рекомендациями в Разделе 7 [RFC6973] («Вопросы конфиденциальности для интернет-протоколов»)?
• Может ли ваш протокол каким-либо образом повлиять на конфиденциальность метаданных протокола?
• Может ли ваш протокол противостоять анализу трафика?
• Может ли ваш протокол улучшить минимизацию данных?
• Идентифицирует ли ваш документ потенциально конфиденциальные данные, зарегистрированные вашим протоколом и / или как долго эти данные должны храниться по техническим причинам?

Пояснение: «Конфиденциальность» относится к праву субъекта (обычно лица), действующего от своего имени, определять степень, в которой он будет взаимодействовать со своей средой, включая степень, в которой субъект готов поделиться своим личным информация с другими [RFC4949]. Если протокол обеспечивает недостаточную защиту конфиденциальности, он может оказать негативное влияние на свободу выражения мнений, поскольку пользователи подвергают самоцензуре опасения слежки или неспособность свободно выражать свое мнение.

Пример: см. [RFC6973].

Воздействие:

• право на свободу выражения
• право на недискриминацию

6.2.3. Содержание Агностицизма

Вопросы:

• Если ваш протокол влияет на обработку пакетов, использует ли он пользовательские данные (данные пакетов, которые не включены в заголовок)?
• Принимает ли ваш протокол решения на основе полезной нагрузки пакета?
• Приоритетно ли в вашем протоколе определенное содержимое или службы перед другими в процессе маршрутизации?
• Является ли протокол прозрачным в отношении определения приоритетов (если таковые имеются)?

Объяснение: «Агностицизм контента» относится к понятию, что сетевой трафик обрабатывается одинаково, независимо от полезной нагрузки, за некоторыми исключениями, когда речь идет об эффективной обработке трафика — например, пакетах с допустимой задержкой или задержкой на основе заголовка.

Пример: независимость содержимого предотвращает дискриминацию пакетов на основе полезной нагрузки. Это важно, потому что изменения этого принципа могут привести к двухуровневому Интернету, где определенные пакеты имеют приоритет над другими на основе их содержимого. По сути, это будет означать, что, хотя все пользователи имеют право получать свои пакеты с определенной скоростью, некоторые пользователи становятся более равными, чем другие.

Воздействие:

• Право на свободу выражения
• Право на недискриминацию
• Право на равную защиту

6.2.4. Безопасность

Вопросы:

• Вы смотрели [BCP72] («Руководство по написанию текста RFC по соображениям безопасности»)?
• Нашли ли вы какие-либо атаки, которые в некоторой степени связаны с вашим протоколом, но считаются не входящими в ваш документ?
• Будут ли эти атаки иметь отношение к функциям Интернета, которые обеспечивают права человека (как описано в этом документе)?

Объяснение: Большинство людей говорят о безопасности, как если бы это было одно монолитное свойство протокола или системы; однако, поразмышляя, понимаешь, что это явно не так. Скорее, безопасность — это ряд связанных, но несколько независимых свойств. Не все эти свойства требуются для каждого приложения. Поскольку связь осуществляется системами, а доступ к системам осуществляется через каналы связи, эти цели, очевидно, взаимосвязаны, но они также могут быть предоставлены независимо [BCP72].

Пример: см. [BCP72].

Воздействие:

• Право на свободу выражения
• Право на свободу собраний и ассоциаций
• Право на недискриминацию
• Право на безопасность

6.2.5. Интернационализация

Вопросы:

• Есть ли в вашем протоколе текстовые строки, которые должны быть поняты или введены людьми?
• Ваш протокол позволяет Unicode? Если да, принимаете ли вы тексты в одной кодировке (которая должна быть UTF-8) или в нескольких (что опасно для совместимости)?
• Если разрешены наборы символов или кодировки, отличные от UTF-8, предписывает ли ваш протокол правильную маркировку кодировки?
• Вы смотрели [RFC6365]?

Пояснение: «Интернационализация» относится к практике создания протоколов, стандартов и реализаций, используемых на разных языках и в различных сценариях (см. Раздел 6.2.12 («Локализация»)). «В IETF« интернационализация »означает добавление или улучшение обработки текста, не относящегося к ASCII, в протоколе» [RFC6365].
Другая точка зрения, более подходящая для протоколов, которые с самого начала предназначены для глобального использования, — это определение, используемое W3C [W3Ci18nDef]: «Интернационализация — это проектирование и разработка содержимого продукта, приложения или документа, которое обеспечивает легкую локализацию для целевого объекта». аудитории, которые различаются по культуре, региону или языку «.

Многие протоколы, которые обрабатывают текст, обрабатывают только одну кодировку (US-ASCII), или они оставляют вопрос о том, какой набор кодированных символов (CCS) и кодирование используются до локальных догадок (что, конечно, приводит к проблемам совместимости) [RFC3536] , Если разрешено несколько кодировок, они должны быть явно идентифицированы [RFC2277]. Добавление не-ASCII текста в протокол позволяет протоколу обрабатывать больше сценариев, возможно, все сценарии, используемые в мире. В современном мире это обычно лучше всего достигается, если использовать Unicode, кодированный только в UTF-8.

В текущей политике IETF [RFC2277] интернационализация направлена ​​на строки, обращенные к пользователю, а не на элементы протокола, такие как глаголы, используемые некоторыми текстовыми протоколами. (Обратите внимание, что некоторые строки, такие как идентификаторы, являются как содержимым, так и элементами протокола.) Если Интернет хочет быть глобальной сетью сетей, протоколы должны работать с языками, отличными от английского, и с наборами символов, отличными от латинских символов. Поэтому крайне важно, чтобы, по крайней мере, содержимое, переносимое протоколом, могло быть в любом сценарии и чтобы все сценарии обрабатывались одинаково.
Пример: см. Раздел 6.2.12 («Локализация»).

Воздействие:

• Право на свободу выражения
• Право на участие в политической жизни
• Право участвовать в культурной жизни, искусстве и науке

6.2.6. Сопротивление цензуре

Вопросы:

• Вводит ли этот протокол новые идентификаторы или повторно использует существующие идентификаторы (например, адреса управления доступом к среде (MAC)), которые могут быть связаны с людьми или контентом?
• Ваш протокол делает это очевидным или прозрачным, когда доступ к ресурсу ограничен?
• Может ли ваш протокол способствовать фильтрации таким образом, чтобы его можно было применять для цензуры данных или услуг? Если да, может ли ваш протокол быть разработан таким образом, чтобы этого не происходило?

Пояснение: «Сопротивление цензуре» относится к методам и мерам по предотвращению цензуры в Интернете.

Пример: при разработке IPv6 обсуждалось встраивание MAC-адреса в уникальные IP-адреса. Согласно [RFC4941], это позволяет «перехватчикам и другим сборщикам информации идентифицировать, когда разные адреса, используемые в разных транзакциях, действительно соответствуют одному и тому же узлу». Вот почему были введены расширения конфиденциальности для автоматической настройки адреса без учета состояния в IPv6 [RFC4941].

Идентификаторы контента, представленного в протоколе, могут использоваться для облегчения цензуры, как в случае цензуры на уровне приложений, которая влияет на протоколы, такие как HTTP. Отказ или ограничение доступа могут стать очевидными при использовании кода состояния 451, что позволяет операторам серверов работать с большей прозрачностью в обстоятельствах, когда вопросы права или государственной политики влияют на их работу [RFC7725].

Воздействие:

• Право на свободу выражения
• Право на участие в политической жизни
• Право участвовать в культурной жизни, искусстве и науке
• Право на свободу собраний и ассоциаций

6.2.7. Открытые стандарты

Вопросы:

• Является ли ваш протокол полностью документированным таким образом, чтобы его можно было легко внедрить, улучшить, построить и / или доработать?
• Вы зависите от проприетарного кода для реализации, выполнения или дальнейшей разработки вашего протокола?
• Предпочитает ли ваш протокол конкретную проприетарную спецификацию по сравнению с технически эквивалентной и конкурирующей (ыми) спецификацией (ами) — например, делая какую-либо включенную спецификацию поставщика «обязательной» или «рекомендуемой» [RFC2026]?
• Вы нормативно ссылаетесь на другой стандарт, который не доступен без затрат (и не могли бы вы обойтись без него)?
• Известны ли вам какие-либо патенты, которые могут помешать полному внедрению вашего стандарта [RFC6701] [RFC8179]?

Пояснение: Интернет смог превратиться в глобальную сеть сетей благодаря существованию открытых, не являющихся собственностью стандартов [Zittrain]. Они имеют решающее значение для обеспечения взаимодействия. Тем не менее, открытые стандарты не определены явно в IETF. По этому вопросу в [RFC2026] говорится следующее: «Различные национальные и международные органы по стандартизации, такие как ANSI, ISO, IEEE и ITU-T, разрабатывают различные спецификации протокола и услуг, которые аналогичны техническим спецификациям, определенным на IETF. «Национальные и международные группы также публикуют« соглашения исполнителей », которые аналогичны заявлениям о применимости, и содержат подробные сведения о реализации, связанные с практическим применением их стандартов. Все они считаются« открытыми внешними стандартами »для целей Процесс интернет-стандартов «. Точно так же, [RFC3935] не определяет открытые стандарты, но подчеркивает важность «открытого процесса»: любой заинтересованный человек может участвовать в работе, знать, что решается, и сделать свой голос услышанным по данному вопросу. Частью этого принципа является обязательство IETF сделать свои документы, списки рассылки WG, списки посещаемости и протоколы заседаний общедоступными в Интернете.

Открытые стандарты важны, так как они допускают неразрешенные инновации, что, в свою очередь, важно для обеспечения свободы и способности свободно создавать и развертывать новые протоколы поверх существующих в настоящее время коммуникационных конструкций. Он лежит в основе Интернета, каким мы его знаем, и чтобы сохранить его принципиально открытый характер, мы должны помнить о необходимости разработки открытых стандартов.

Все стандарты, которые должны быть нормативно реализованы, должны быть в свободном доступе и должны обеспечивать разумную защиту от заявлений о нарушении патента, так что они также могут быть реализованы в открытом или свободном программном обеспечении. Патенты часто сдерживали открытую стандартизацию или использовались против тех, кто применяет открытые стандарты, особенно в области криптографии [Newegg]. Иногда делается исключение, когда стандартизирован протокол, который нормативно опирается на спецификации, произведенные другими SDO, которые не являются свободно доступными. Патенты в открытых стандартах или в нормативных ссылках на другие стандарты должны иметь раскрытие патента [примечание], лицензирование без лицензионных платежей [патентная политика] или некоторую другую форму разумной защиты. Разумная патентная защита должна включать, но не ограничиваться, криптографическими примитивами.

Пример: [RFC6108] описывает систему, развернутую интернет-провайдером Comcast для предоставления критических уведомлений конечного пользователя веб-браузерам. Такая система уведомлений используется для предоставления почти мгновенных уведомлений клиентам, таких как предупреждение их о том, что их трафик демонстрирует шаблоны, которые указывают на вредоносное ПО или вирусную инфекцию. Существуют и другие проприетарные системы, которые могут выполнять такие уведомления, но в этих системах используется технология Deep Packet Inspection (DPI). В отличие от DPI в [RFC6108] описывается система, которая не использует DPI и вместо этого основана на открытых стандартах IETF и приложениях с открытым исходным кодом.

Воздействие:

• Право на свободу выражения
• Право участвовать в культурной жизни, искусстве и науке

6.2.8. Поддержка неоднородности

Вопросы:

• Поддерживает ли ваш протокол неоднородность по конструкции?
• Ваш протокол допускает несколько типов оборудования?
• Поддерживает ли ваш протокол несколько типов прикладных протоколов?
• Является ли ваш протокол либеральным в том, что он получает и обрабатывает?
• Будет ли ваш протокол оставаться пригодным для использования и открытым, если контекст изменится?
• Разрешает ли ваш протокол четко определенные точки расширения? Если да, позволяют ли эти точки расширения открывать инновации?

Пояснение: [FIArch] отмечает следующее: «Интернет характеризуется неоднородностью на многих уровнях: устройства и узлы, алгоритмы планирования маршрутизаторов и механизмы управления очередями, протоколы маршрутизации, уровни мультиплексирования, версии и реализации протоколов, базовые уровни каналов (например, двухточечные соединения с множественным доступом, беспроводная связь, FDDI и т. д.), в структуре трафика и на уровнях перегруженности в разное время и в разных местах.
Более того, поскольку Интернет состоит из автономных организаций и поставщиков интернет-услуг, каждая из которых имеет свои собственные политические интересы, существует большая неоднородность административных доменов и структур ценообразования. «В результате, как также отмечалось в [FIArch], неоднородность Принцип, предложенный в [RFC1958], должен быть поддержан проектом.

Пример: неоднородность неизбежна и должна поддерживаться проектом. Например, для типов скоростей передачи, различающихся не менее чем на семь порядков, различаются длины компьютерных слов и хосты, от микропроцессоров с нехваткой памяти до массивно параллельных суперкомпьютеров. Как отмечено в [RFC1958], «должно быть разрешено использование нескольких типов прикладных протоколов, начиная от самых простых, таких как удаленный вход в систему, до самых сложных, таких как распределенные базы данных».

Воздействие:

• Право на свободу выражения
• Право на участие в политической жизни

6.2.9. Анонимность

Вопрос:

• Вы изучили [RFC6973] («Вопросы конфиденциальности для интернет-протоколов»), особенно раздел 6.1.1 этого документа?

Пояснение: «Анонимность» означает, что личность неизвестна или скрыта [RFC4949]. Несмотря на то, что трудно добиться полной анонимности, это недвоичная концепция. Усиление повсеместного мониторинга и отслеживания важно для многих пользователей, а также для IETF [RFC7258]. Достижение более высокого уровня анонимности является важной функцией для многих конечных пользователей, так как она предоставляет им различные степени конфиденциальности в Интернете.

Пример: протоколы часто предоставляют личные данные; поэтому важно рассмотреть способы смягчения очевидного воздействия на конфиденциальность. Протокол, который использует данные, которые могут помочь идентифицировать отправителя (интересующие объекты), должен быть защищен от третьих лиц.

Например, если кто-то хочет скрыть IP-адреса источника / назначения пакета, использование IPsec в режиме туннелирования (например, внутри VPN) может помочь защитить от третьих сторон, которые могут подслушивать пакеты, которыми обмениваются конечные точки туннеля.

Воздействие:

• Право на недискриминацию
• Право на участие в политической жизни
• Право на свободу собраний и ассоциаций
• Право на безопасность

6.2.10. Псевдонимность

Вопросы:

• Рассматривали ли вы [RFC6973] («Вопросы конфиденциальности для интернет-протоколов»), особенно раздел 6.1.2 этого документа?
• Собирает ли протокол личные данные?
• Генерирует ли или обрабатывает ли протокол что-либо, что может быть тесно связано с информацией, позволяющей установить личность?
• Использует ли протокол данные, полученные лично, т. Е. От взаимодействия одного человека или от его устройства или адреса?
• Генерирует ли этот протокол личные данные? Если да, то как будут обрабатываться эти данные?

Объяснение: Псевдонимность — возможность использовать постоянный идентификатор, который не связан непосредственно с автономной идентификацией — является важной функцией для многих конечных пользователей, поскольку позволяет им в разной степени скрывать личность и конфиденциальность в Интернете.

Пример: при разработке стандарта, который предоставляет персональные данные, важно рассмотреть способы смягчения очевидных последствий. Хотя псевдонимы не могут быть легко перепроектированы — например, некоторые ранние подходы использовали такие методы, как простое хеширование IP-адресов, которые, в свою очередь, могли быть легко изменены путем генерации хеша для каждого потенциального IP-адреса и сравнения его с псевдонимом — ограничение раскрытие личных данных остается важным.

«Псевдонимность» означает использование псевдонима вместо «настоящего» имени. У пользователей есть много причин использовать псевдонимы — например, чтобы скрыть свой пол; защитить себя от преследования; защитить частную жизнь своих семей; откровенно обсудить сексуальность; или развивать художественную или журналистскую личность без возмездия со стороны работодателя, (потенциальных) клиентов или социального окружения [geekfeminism]. Разница между анонимностью и псевдонимом заключается в том, что псевдоним часто является постоянным.

«Псевдонимность усиливается, когда с псевдонимом может быть связано меньше персональных данных; когда один и тот же псевдоним используется реже и в меньшем количестве контекстов; и когда независимо выбранные псевдонимы чаще используются для новых действий (их создание, с точки зрения наблюдателя или злоумышленника) , не связываемый) [RFC6973]

Воздействие:

• Право на недискриминацию
• Право на свободу собраний и ассоциаций

6.2.11. Доступность

Вопросы:

• Разработан ли ваш протокол для создания благоприятных условий для людей, которые не являются трудоспособными?
• Вы смотрели на Инициативу W3C по обеспечению доступности веб-сайтов [W3CAccessibility] для примеров и рекомендаций?

Пояснение: Интернет в основном предназначен для работы со всеми людьми, независимо от их аппаратного, программного обеспечения, языка, культуры, местоположения, физических или умственных способностей. Когда Интернет достигает этой цели, он становится доступным для людей с разнообразными слуховыми, двигательными, зрительными и когнитивными способностями [W3CAccessibility]. Иногда при разработке протоколов, веб-сайтов, веб-технологий или веб-инструментов создаются барьеры, которые не позволяют людям использовать Интернет.

Пример: протокол HTML, как определено в [HTML5], в частности, требует, чтобы (за некоторыми исключениями) каждое изображение имело атрибут «alt», чтобы гарантировать, что изображения доступны для людей, которые сами не могут расшифровать нетекстовый контент на веб-страницах.

Воздействие:

• Право на недискриминацию
• Право на свободу собраний и ассоциаций
• Право на образование
• Право на участие в политической жизни

6.2.12. Локализация

Вопросы:

• Поддерживает ли ваш протокол стандарты интернационализации?
• Предприняли ли вы какие-либо конкретные шаги по локализации вашего протокола для соответствующей аудитории?

Пояснение: согласно [W3Ci18nDef], «Локализация означает адаптацию содержимого продукта, приложения или документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (« локаль »)». Это также описывается как практика перевода реализации, чтобы сделать ее функциональной на определенном языке или для пользователей в определенной локали (см. Раздел 6.2.5 («Интернационализация»)).

Пример: Интернет является глобальной средой, но многие из его протоколов и продуктов разрабатываются с учетом определенной аудитории; эта аудитория часто разделяет определенные особенности, такие как умение читать и писать в ASCII и знание английского языка. Это ограничивает способность значительной части онлайн-населения мира использовать Интернет таким образом, чтобы он был доступен с точки зрения культуры и языка. Пример протокола, в котором учтено мнение, что людям нравится иметь доступ к данным на их родном языке, можно найти в [RFC5646]; такой протокол маркирует информационное содержимое идентификатором языка, на котором оно написано, и позволяет представлять информацию на нескольких языках.

Воздействие:

• Право на недискриминацию
• Право участвовать в культурной жизни, искусстве и науке
• Право на свободу выражения

6.2.13. Децентрализация

Вопросы:

• Может ли ваш протокол быть реализован без единой точки контроля?
• Если применимо, может ли ваш протокол быть развернут федеративным способом?
• Какова вероятность дискриминации пользователей вашего протокола?
• Можно ли использовать ваш протокол для отрицательного вовлечения пользователей (например, обвинения, обвинения)?
• Создает ли ваш протокол дополнительные централизованные точки контроля?

Пояснение: Децентрализация является одной из центральных технических концепций архитектуры сетей и принята в качестве таковой IETF [RFC3935]. Это относится к отсутствию или минимизации централизованных точек контроля — «функция, которая, как предполагается, облегчает присоединение новых пользователей и развертывание новых применений» [Браун]. Это также уменьшает проблемы, связанные с отдельными точками отказа, и распределяет сеть так, что она продолжает функционировать, если один или несколько узлов отключены. С коммерциализацией Интернета в начале 1990-х годов наблюдалась медленная тенденция к отходу от децентрализации в ущерб любым техническим преимуществам, которые иначе обеспечивает децентрализованный Интернет.

Пример: биты, путешествующие по Интернету, становятся все более восприимчивыми к мониторингу и цензуре как со стороны правительств и интернет-провайдеров, так и третьих (злонамеренных) сторон. Возможность мониторинга и цензуры дополнительно обеспечивается за счет усиления централизации сети, создавая центральные точки инфраструктуры, к которым можно подключаться. Создание сетей P2P и разработка протоколов передачи голоса по IP с использованием технологии P2P в сочетании с распределенной хэш-таблицей (DHT) для масштабируемости являются примерами того, как протоколы могут сохранять децентрализацию [Pouwelse].

Воздействие:

• Право на свободу выражения
• Право на свободу собраний и ассоциаций

6.2.14. Надежность

Вопросы:

• Является ли ваш протокол отказоустойчивым?
• Ваш протокол изящно ухудшается?
• Может ли ваш протокол противостоять злонамеренным попыткам деградации?
• Есть ли у вас документированный способ объявить о деградации?
• Есть ли у вас меры по восстановлению или частичному излечению от неудачи?
• Может ли ваш протокол поддерживать надежность и производительность перед лицом непредвиденных изменений или обстоятельств?

Объяснение: Надежность гарантирует, что протокол будет выполнять свою функцию последовательно, быть устойчивым к ошибкам, как описано, и функционировать без неожиданных результатов. Система, которая является надежной, изящно вырождается и будет иметь документированный способ объявить о деградации. У этого также есть механизмы, чтобы излечиться от отказа изящно и, если применимо, позволить частичное излечение. Здесь важно провести различие между случайной деградацией и злонамеренной деградацией. Например, во многих современных атаках на TLS используется способность TLS постепенно снижаться до более старых наборов шифров; с функциональной точки зрения эта способность хороша, но с точки зрения безопасности она может быть очень плохой. Как и в случае с конфиденциальностью, рост интернета и стимулирование инноваций в услугах зависят от доверия пользователей к сети [RFC3724]. Для надежности необходимо, чтобы службы уведомляли пользователей о сбое доставки пакетов. В случае систем реального времени протокол должен обеспечивать своевременность в дополнение к обеспечению надежной доставки.

Пример. В современной структуре стека IP для надежного транспортного уровня требуется указание того, что транспортная обработка успешно завершена, например указание, данное в сообщении ACK TCP [RFC793], а не просто указание уровня IP о том, что пакет прибыл. Точно так же протокол прикладного уровня может требовать подтверждения для конкретного приложения, которое содержит, помимо прочего, код состояния, указывающий расположение запроса (см. [RFC3724]).

Воздействие:

• Право на свободу выражения
• Право на безопасность

6.2.15. Конфиденциальность

Вопросы:

• Предоставляет ли этот протокол информацию, связанную с идентификаторами или данными? Если это так, то относится ли это к каждому из других протокольных объектов (т. Е. Получателям, посредникам и инициаторам) [RFC6973]?
• Какие варианты существуют для разработчиков протоколов, чтобы ограничить информацию, передаваемую каждому объекту?
• Какие операционные средства контроля доступны для ограничения информации, передаваемой каждому субъекту?
• Какие механизмы контроля или механизмы согласия определяются или требуются протоколом до того, как личные данные или идентификаторы передаются или предоставляются через протокол? Если такие механизмы или средства контроля не указаны, ожидается ли, что контроль и согласие будут рассматриваться вне протокола?
• Предоставляет ли протокол инициаторам возможность обмена разными частями информации с разными получателями? Если нет, существуют ли механизмы вне протокола для предоставления инициаторам такого контроля?
• Предоставляет ли протокол инициаторам возможность ограничить передачу информации посредникам? Если нет, существуют ли механизмы вне протокола для предоставления пользователям такого контроля?
• Ожидается ли, что у пользователей будут отношения, регулирующие использование информации (договорные или иные) с теми, кто управляет этими посредниками?
• Протокол предпочитает шифрование, а не операции с открытым текстом?
• Предоставляет ли протокол инициаторам возможность выразить предпочтения отдельных лиц получателям или посредникам в отношении сбора, использования или раскрытия их личных данных?

Объяснение: «Конфиденциальность» означает сохранение данных пользователя в тайне от непреднамеренных слушателей [BCP72]. Рост Интернета зависит от уверенности пользователей в том, что сеть защищает их личные данные [RFC1984].

Пример. Протоколы, которые не шифруют свою полезную нагрузку, делают весь контент сообщения доступным для идеализированного злоумышленника на его пути [RFC7624]. Следуя рекомендациям в [RFC3365], большинство таких протоколов имеют безопасный вариант, который шифрует полезную нагрузку для обеспечения конфиденциальности, и эти безопасные варианты получают все более широкое развертывание. Примечательным исключением является DNS [RFC1035], поскольку DNSSEC [RFC4033] не требует конфиденциальности в качестве требования. Это означает, что в отсутствие изменений протокола, которые в настоящее время разрабатываются в рабочей группе IETF DNS Private Exchange (DPRIVE), все DNS-запросы и ответы, генерируемые действиями любого протокола, доступны злоумышленнику. Когда используются протоколы хранения и пересылки (например, SMTP [RFC5321]), посредники оставляют эти данные под наблюдением злоумышленника, который скомпрометировал этих посредников, если только данные не зашифрованы сквозным протоколом прикладного уровня или Реализация использует зашифрованное хранилище для этих данных [RFC7624].

Воздействие:

• Право на неприкосновенность частной жизни
• Право на безопасность

6.2.16. Целостность

Вопросы:

• Поддерживает ли ваш протокол, обеспечивает ли и / или проверяет точность данных полезной нагрузки?
• Поддерживает ли ваш протокол и обеспечивает ли согласованность данных?
• Позволяет ли ваш протокол каким-либо образом (преднамеренно или непреднамеренно) изменять данные?

Пояснение: «Целостность» относится к поддержанию и обеспечению точности и согласованности данных, чтобы гарантировать, что они не были (преднамеренно или непреднамеренно) изменены.

Пример: проверка целостности данных важна для предотвращения уязвимостей и атак, таких как атаки «человек посередине». Эти атаки происходят, когда третья сторона (часто по злонамеренным причинам) перехватывает связь между двумя сторонами, вставляя себя посередине и изменяя содержимое данных. На практике это выглядит следующим образом:

Алиса хочет общаться с Бобом. Коринн подделывает и отправляет сообщение Бобу, выдавая себя за Алису. Боб не может видеть, что данные от Алисы были изменены Коринн. Коринн перехватывает и изменяет связь, передаваемую между Алисой и Бобом.
Коринна умеет контролировать коммуникационный контент.

Воздействие:

• Право на свободу выражения
• Право на безопасность

6.2.17. Аутентичность

Вопросы:

• Есть ли у вас достаточные меры для подтверждения истинности атрибута объекта или отдельного фрагмента данных?
• Могут ли атрибуты искажаться по пути (см. Раздел 6.2.4 («Безопасность»))?
• При необходимости внедрили ли вы IPsec, DNSSEC, HTTPS и другие стандартные рекомендации по обеспечению безопасности?

Объяснение: Подлинность гарантирует, что данные действительно поступают из источника, из которого, по их утверждению, они поступили. Это важно для предотвращения (1) определенных атак или (2) несанкционированного доступа к данным и их использования.

Пример. Аутентификация данных важна для предотвращения уязвимостей и атак, таких как атаки «человек посередине». Эти атаки происходят, когда третья сторона (часто по злонамеренным причинам) перехватывает связь между двумя сторонами, вставая посередине и выдавая себя за обе стороны. На практике это выглядит следующим образом:
Алиса хочет общаться с Бобом. Алиса отправляет данные Бобу. Коринн перехватывает данные, отправленные Бобу. Коринн читает и изменяет сообщение Бобу. Боб не видит, что данные пришли не от Алисы, а от Коринны.

При правильной аутентификации сценарий будет следующим:

Алиса хочет общаться с Бобом. Алиса отправляет данные Бобу. Коринн перехватывает данные, отправленные Бобу. Коринн читает и изменяет сообщение Бобу. Боб видит, что данные пришли не от Алисы, а от Коринны.

Воздействие:

• Право на неприкосновенность частной жизни
• Право на свободу выражения
• Право на безопасность

6.2.18. Адаптируемость

Вопросы:

• Ваш протокол написан таким образом, чтобы другие протоколы могли легко разрабатываться поверх него или взаимодействовать с ним?
• Влияет ли ваш протокол на неразрешенные инновации (см. Раздел 6.2.1 («Подключение») выше)?

Объяснение: Адаптивность тесно связана с неразрешенными инновациями; оба поддерживают свободу и способность свободно создавать и развертывать новые протоколы поверх существующих в настоящее время коммуникационных конструкций. Бесконтрольные инновации лежат в основе Интернета, как мы его знаем. Чтобы сохранить принципиально открытый характер Интернета и обеспечить его дальнейшее развитие, мы должны помнить о влиянии протоколов на поддержание или сокращение неразрешенных инноваций.

Пример: WebRTC генерирует аудио и / или видео данные. Чтобы гарантировать возможность использования WebRTC в разных местах разными сторонами, важно, чтобы были разработаны стандартные API-интерфейсы JavaScript для поддержки приложений от разных поставщиков голосовых услуг. Несколько сторон будут иметь аналогичные возможности; для того, чтобы все стороны могли опираться на существующие стандарты, эти стандарты должны быть адаптируемыми и предусматривать безосновательные инновации.

Воздействие:

• Право на образование
• Право на свободу выражения
• Право на свободу собраний и ассоциаций

6.2.19. Прозрачность результатов

Вопрос:

— Являются ли эффекты вашего протокола полностью и легко понятными, в том числе в отношении непреднамеренных последствий выбора протокола?

Объяснение: Некоторые технические решения могут иметь непредвиденные последствия.

Пример: Недостаток подлинности может привести к недостатку целостности и негативным внешним воздействиям; спам является примером. Нехватка данных, которые могли бы использоваться для выставления счетов и учета, может привести к так называемым «бесплатным» соглашениям, которые скрывают фактические затраты и распределение затрат — например, (1) бартерные соглашения, которые обычно используются для подключения к Интернету, и (2) коммерческое использование персональных данных для целевой рекламы, которая является наиболее распространенной моделью финансирования так называемых «бесплатных» услуг, таких как поисковые системы и социальные сети.

Воздействие:

• Право на свободу выражения
• Право на неприкосновенность частной жизни
• Право на свободу собраний и ассоциаций
• Право на доступ к информации

7. Вопросы безопасности

Поскольку в этом документе обсуждаются исследования, соображений безопасности не существует.

8. Соображения IANA

Этот документ не требует никаких действий IANA.

9. Информация исследовательской группы

Список для обсуждения в исследовательской группе IRTF по вопросам протокола о правах человека находится по адресу электронной почты <hrpc@ietf.org>.

Информация о группе и информация о том, как подписаться на список, доступна по адресу <https://www.irtf.org/mailman/listinfo/hrpc>.

Архивы списка можно найти по адресу <https://www.irtf.org/mail-archive/web/hrpc/current/index.html>.

10. Информационные ссылки

[Ababil] Danchev, D., «Dissecting ’Operation Ababil’ — an OSINT Analysis», September 2012, <http://ddanchev.blogspot.be/2012/09/dissecting-operation-ababil-osint.html>.

[Abbate] Abbate, J., «Inventing the Internet», MIT Press, 2000, <https://mitpress.mit.edu/books/inventing-internet>.

[Adrian] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Beguelin, S., and P. Zimmermann, «Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice», Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 5-17, DOI 10.1145/2810103.2813707, October 2015.

[Alshalan-etal] Alshalan, A., Pisharody, S., and D. Huang, «A Survey of Mobile VPN Technologies», IEEE Communications Surveys & Tutorials, Volume 18, Issue 2, pp. 1177-1196, DOI 10.1109/COMST.2015.2496624, 2016, <http://ieeexplore.ieee.org/document/7314859/?arnumber=7314859>.

[APIP] Naylor, D., Mukerjee, M., and P. Steenkiste, «Balancing accountability and privacy in the network», SIGCOMM ’14, Proceedings of the 2014 ACM Conference on SIGCOMM, pp. 75-86, DOI 10.1145/2740070.2626306, October 2014, <https://dl.acm.org/citation.cfm?id=2626306>.

[Appelbaum] Appelbaum, J., Gibson, A., Goetz, J., Kabisch, V., Kampf, L., and L. Ryge, «NSA targets the privacy-conscious»,
2014, <http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html>.

[ars] Anderson, N., «P2P researchers: use a blocklist or you will be tracked… 100% of the time», October 2007,
<http://arstechnica.com/uncategorized/2007/10/p2p-researchers-use-a-blocklist-or-you-will-be-tracked-100-of-the-time/>.

[Aryan-etal] Aryan, S., Aryan, H., and J. Alex Halderman, «Internet Censorship in Iran: A First Look», 2013,
<https://jhalderm.com/pub/papers/iran-foci13.pdf>.

[Babbie] Babbie, E., «The Basics of Social Research», Cengage, Belmont, CA, 2017.

[BBC-wikileaks] BBC, «Whistle-blower site taken offline», February 2008, <http://news.bbc.co.uk/2/hi/technology/7250916.stm>.

[BCP72] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552,
July 2003, <https://www.rfc-editor.org/info/bcp72>.

[Benkler] Benkler, Y., «The Wealth of Networks — How Social Production Transforms Markets and Freedom», Yale
University Press, New Haven and London, 2006,
<http://is.gd/rxUpTQ>.

[Berners-Lee] Berners-Lee, T. and M. Fischetti, «Weaving the Web: The Original Design and Ultimate Destiny of the World Wide
Web», HarperCollins, p. 208, 1999.

[BernersLeeHalpin] Berners-Lee, T. and H. Halpin, «Internet Access is a Human Right», 2012, <http://www.ibiblio.org/hhalpin/homepage/publications/def-timbl-halpin.pdf>.

[Bhargavan] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, «Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS», 2014 IEEE Symposium on Security and Privacy, pp. 98-113, DOI 10.1109/SP.2014.14, May 2014.

[Bitmessage] Bitmessage, «Bitmessage Wiki», March 2017, <https://bitmessage.org/wiki/Main_Page>.

[Bless1] Orwat, C. and R. Bless, «Values and Networks — Steps Toward Exploring their Relationships», ACM SIGCOMM Computer Communication Review, Volume 46, Number 2, pp. 25-31, DOI 10.1145/2935634.2935640, April 2016, <http://www.sigcomm.org/sites/default/files/ccr/papers/2016/April/0000000-0000003.pdf>.

[Bless2] Bless, R. and C. Orwat, «Values and Networks», July 2015, <https://www.ietf.org/proceedings/93/slides/slides-93-hrpc-2.pdf>.

[Broeders] Broeders, D., «The public core of the Internet. An international agenda for Internet governance», The Netherlands Scientific Council for Government Policy (WRR) Report No. 94 (under «Reports to the government»), 2015, <https://english.wrr.nl/publications/reports/2015/10/01/the-public-core-of-the-internet>

[Brown] Ziewitz, M. and I. Brown, Ed., «A Prehistory of Internet Governance», Research Handbook on Governance of the Internet, Part 1, Chapter 1 (pp. 3-26), Edward Elgar Publishing Ltd, Cheltenham, DOI 10.4337/9781849805049, 2013.

[Brown-etal] Brown, I., Clark, D., and D. Trossen, «Should Specific Values Be Embedded In The Internet Architecture?», ReARCH ’10, Proceedings of the Re-Architecting the Internet Workshop, Article No. 10, DOI 10.1145/1921233.1921246, November 2010, <http://conferences.sigcomm.org/co-next/2010/Workshops/REARCH/ReArch_papers/10-Brown.pdf>.

[BrownMarsden] Brown, I. and C. Marsden, «Regulating Code: Good Governance and Better Regulation in the Information Age», MIT Press, 2013,
<https://mitpress.mit.edu/books/regulating-code>.

[CAIDA] Dainotti, A., Squarcella, C., Aben, E., Claffy, K., Chiesa, M., Russo, M., and A. Pescape, «Analysis of Country-wide Internet Outages Caused by Censorship», DOI 10.1109/TNET.2013.2291244, December 2013, <http://www.caida.org/publications/papers/2014/outages_censorship/outages_censorship.pdf>.

[Cath] Cath, C., «A Case Study of Coding Rights: Should Freedom of Speech Be Instantiated in the Protocols and Standards Designed by the Internet Engineering Task Force?», August 2015, <https://www.ietf.org/mail-archive/web/hrpc/current/pdf36GrmRM84S.pdf>.

[CathFloridi] Cath, C. and L. Floridi, «The Design of the Internet’s Architecture by the Internet Engineering Task Force (IETF) and Human Rights», April 2017.

[Clark] Clark, D., «The Design Philosophy of the DARPA Internet Protocols», SIGCOMM ’88, Proceedings of the ACM CCR, Volume 18, Number 4, pp. 106-114, DOI 10.1145/52324.52336, August 1988.

[Clark-etal] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, «Tussle in cyberspace: defining tomorrow’s Internet», IEEE/ACM Transactions on Networking (TON) archive, Volume 13, Issue 3, pp. 462-475, DOI 10.1109/TNET.2005.850224, June 2005, <https://dl.acm.org/citation.cfm?id=1074049>.

[CoE] Council of Europe, «Applications to ICANN for Communitybased New Generic Top Level Domains (gTLDs): Opportunities and challenges from a human rights perspective», 2016, <https://rm.coe.int/CoERMPublicCommonSearchServices/DisplayDCTMContent?documentId=09000016806b5a14>.

[Collins] Collins, K., «Hacking Team’s oppressive regimes customer list revealed in hack», July 2015, <http://www.wired.co.uk/news/archive/2015-07/06/hacking-team-spyware-company-hacked>.

[Davidson-etal] Davidson, A., Morris, J., and R. Courtney, «Strangers in a Strange Land: Public Interest Advocacy and Internet Standards», Telecommunications Policy Research Conference, Alexandria, VA, September 2002, <https://www.cdt.org/files/publications/piais.pdf>.

[DeNardis14] DeNardis, L., «The Global War for Internet Governance», Yale University Press, 2014, <https://www.jstor.org/stable/j.ctt5vkz4n>.

[DeNardis15] DeNardis, L., «The Internet Design Tension between Surveillance and Security», IEEE Annals of the History of Computing, Volume 37, Issue 2, DOI 10.1109/MAHC.2015.29, 2015, <http://is.gd/7GAnFy>.

[Denzin] Denzin, N., Ed., and Y. Lincoln, Ed., «The SAGE Handbook of Qualitative Research», SAGE Handbooks, Thousand Oaks, CA, 2011, <http://www.amazon.com/SAGE-Handbook-Qualitative-Research-Handbooks/dp/1412974178>.

[dict] BusinessDictionary.com, «Reliability (dictionary entry)», WebFinance, Inc., 2017, <http://www.businessdictionary.com/definition/reliability.html>.

[Doty] Doty, N., «Automated text analysis of Requests for Comment (RFCs)», 2014, <https://github.com/npdoty/rfc-analysis>.

[Douceur] Douceur, J., «The Sybil Attack», 2002, <https://www.microsoft.com/en-us/research/wp-content/uploads/2002/01/IPTPS2002.pdf>.

[Dutton] Dutton, W., Dopatka, A., Law, G., and V. Nash, «Freedom of Connection, Freedom of Expression: The Changing Legal and Regulatory Ecology Shaping the Internet», 2011, <http://www.unesco.org/new/en/communication-andinformation/resources/publications-and-communicationmaterials/publications/full-list/freedom-of-connectionfreedom-of-expression-the-changing-legal-and-regulatoryecology-shaping-the-internet/>.

[Farrow] Farrow, R., «Source Address Spoofing», 2016, <https://technet.microsoft.com/library/cc723706.aspx>.

[FIArch] «Future Internet Design Principles», January 2012, <http://www.future-internet.eu/uploads/media/FIArch_Design_Principles_V1.0.pdf>.

[FOC] Ministers of the Freedom Online Coalition, «The Tallinn Agenda — Recommendations for Freedom Online», 2014, <https://www.freedomonlinecoalition.com/wp-content/uploads/2014/04/FOC-recommendations-consensus.pdf>.

[FRAMEWORK] ISO/IEC, «Information technology — Framework for internationalization», prepared by ISO/IEC JTC 1/SC 22/WG 20 ISO/IEC TR 11017, 1998.

[Franklin] Franklin, U., «The Real World of Technology», June 1999, <http://houseofanansi.com/products/the-real-world-of-technology-digital>.

[freenet1] Freenet, «What is Freenet?», n.d., <https://freenetproject.org/whatis.html>.

[freenet2] Clarke, I., «The Philosophy behind Freenet», n.d., <https://freenetproject.org/pages/about.html>.

[geekfeminism] Geek Feminism Wiki, «Pseudonymity», 2015, <http://geekfeminism.wikia.com/wiki/Pseudonymity>.

[Geertz] Geertz, H. and C. Geertz, «Kinship in Bali», University of Chicago Press, Chicago, 1975, <http://press.uchicago.edu/ucp/books/book/chicago/K/bo25832222.html>.

[Googlepatent] Google, «Method and device for network traffic manipulation», 2012, <https://www.google.com/patents/EP2601774A1?cl=en>.

[greatfirewall] Anonymous, «Towards a Comprehensive Picture of the Great Firewall’s DNS Censorship», 4th USENIX Workshop on Free and Open Communications on the Internet (FOCI) ’14, August 2014, <https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf>.

[GreenMovement] Villeneuve, N., «Iran DDoS», 2009, <https://www.nartv.org/2009/06/16/iran-ddos/>.

[Greenwald] Greenwald, G., «XKeyscore: NSA tool collects ’nearly everything a user does on the internet’», July 2013, <https://www.theguardian.com/world/2013/jul/31/nsa-top-secret-program-online-data>.

[Haagsma] Haagsma, L., «Deep dive into QUANTUM INSERT», April 2015, <http://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-insert/>.

[Hall] Hall, J., Aaron, M., Jones, B., and N. Feamster, «A Survey of Worldwide Censorship Techniques», Work in Progress, draft-hall-censorship-tech-04, July 2016.

[Hill2014] Hill, R., «Partial Catalog of Human Rights Related to ICT Activities», May 2014, <http://www.apig.ch/UNIGE%20Catalog.pdf>.

[HORNET] Chen, C., Asoni, D., Barrera, D., Danezis, G., and A. Perrig, «HORNET: High-speed Onion Routing at the Network Layer», CCS ’15, Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 1441-1454, DOI 10.1145/2810103.2813628, October 2015,
<https://dl.acm.org/citation.cfm?id=2813628>.

[HTML5] Hickson, I., Ed., Berjon, R., Ed., Faulkner, S., Ed., Leithead, T., Ed., Navara, E., Ed., O’Connor, E., Ed., and S. Pfeiffer, Ed., «HTML5», W3C Recommendation, October 2014, <https://www.w3.org/TR/html5/>.

[ICCPR] United Nations General Assembly, «International Covenant on Civil and Political Rights», 1966, <http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR.aspx>.

[ICESCR] United Nations General Assembly, «International Covenant on Economic, Social and Cultural Rights», 1966,
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/CESCR.aspx>.

[Insinuator] Schiess, N., «Vulnerabilities & attack vectors of VPNs (Pt 1)», August 2013, <https://www.insinuator.net/2013/08/vulnerabilities-attack-vectors-of-vpns-pt-1/>.

[IRP] Internet Rights and Principles Dynamic Coalition, «10 Internet Rights & Principles», 2017, <http://internetrightsandprinciples.org/site/campaign/>.

[Jabri] Jabri, V., «Discourses on violence: conflict analysis reconsidered», Manchester University Press, 1996.

[Kaye] Kaye, D., «Freedom of expression and the private sector in the digital age», 2016, <http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/Privatesectorinthedigitalage.aspx>.

[King] King, C., «Power, Social Violence and Civil Wars», Chapter 8 of «Leashing the Dogs of War: Conflict Management in a Divided World», United States Institute of Peace Press, Washington, D.C., 2007.

[Lessig] Lessig, L., «Code and Other Laws of Cyberspace, Version 2.0 (’Codev2’)», Basic Books, New York, 2006, <http://codev2.cc/>.

[Marcak] Marcak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, «China’s Great Cannon», April 2015, <https://citizenlab.org/2015/04/chinas-great-cannon/>.

[Marquis-Boire] Marquis-Boire, M., «Schrodinger’s Cat Video and the Death of Clear-Text», August 2014, <https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/>.

[Meyer] Meyer, J., «Defining and Evaluating Resilience: A Performability Perspective», presentation at International Workshop on Performability Modeling of Computer and Communication Systems, September 2009.

[Mueller] Mueller, M., «Networks and States: The Global Politics of Internet Governance», MIT Press, DOI 10.7551/mitpress/9780262014595.001.0001, 2010,
<https://mitpress.mit.edu/books/networks-and-states>.

[Musiani] Musiani, F., «Giants, Dwarfs and Decentralized Alternatives to Internet-based Services: An Issue of Internet Governance», Westminster Papers in Communication and Culture, 10(1), pp. 81-94, DOI 10.16997/wpcc.214, 2015, <https://www.westminsterpapers.org/articles/10.16997/wpcc.214/>.

[Namecoin] Namecoin, «Namecoin», 2015, <https://namecoin.info/>.

[NATusage] Maier, G., Schneider, F., and A. Feldmann, «NAT usage in Residential Broadband networks», PAM: International Conference on Passive and Active Network
Measurement Lecture Notes in Computer Science, Volume 6579, Springer, Berlin and Heidelberg, DOI 10.1007/978-3-642-19260-9_4, 2011,
<http://www.icsi.berkeley.edu/pubs/networking/NATusage11.pdf>.

[NETmundial] NETmundial, «NETmundial Multistakeholder Statement», April 2014, <http://netmundial.br/wp-content/uploads/2014/04/NETmundial-Multistakeholder-Document.pdf>.

[Newegg] Mullin, J., «Newegg on trial: Mystery company TQP rewrites the history of encryption», November 2013, <http://arstechnica.com/tech-policy/2013/11/newegg-ontrial-mystery-company-tqp-re-writes-the-history-ofencryption/>.

[notewell] IETF, «Note Well», 2015, <https://www.ietf.org/about/note-well.html>.

[patentpolicy] Weitzner, D., Ed., «W3C Patent Policy», World Wide Web Consortium, February 2004,
<https://www.w3.org/Consortium/Patent-Policy-20040205/>.

[Penney] Penney, J., «Chilling Effects: Online Surveillance and Wikipedia Use», 2016, <http://papers.ssrn.com/sol3/
papers.cfm?abstract_id=2769645>.

[Peterson] Peterson, A., Gellman, B., and A. Soltani, «Yahoo to make SSL encryption the default for Webmail users. Finally.»,
October 2013, <https://www.washingtonpost.com/news/the-switch/wp/2013/10/14/yahoo-to-make-ssl-encryption-the-defaultfor-webmail-users-finally/?utm_term=.a17eca45ddfe>.

[PETS2015VPN] Perta, V., Barbera, M., Tyson, G., Haddadi, H., and A. Mei, «A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients», DOI 10.1515/popets-2015-0006, 2015, <http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf>.

[Pidgin] js and Pidgin Developers, «[XMPP] Invisible mode violating standard», 2007,
<https://developer.pidgin.im/ticket/4322>.

[Pouwelse] Pouwelse, J., Ed., «Media without censorship (CensorFree) scenarios», Work in Progress, draft-pouwelse-censorfreescenarios-02, October 2012.

[Rachovitsa] Rachovitsa, A., «Engineering and lawyering privacy by design: understanding online privacy both as a technical and an international human rights issue», International Journal of Law and Information Technology, Volume 24, Issue 4, pp. 374-399, DOI 10.1093/ijlit/eaw012, December 2016, <https://academic.oup.com/ijlit/article/24/4/374/2566975/Engineering-and-lawyering-privacy-by-design>.

[RFC760] Postel, J., «DoD standard Internet Protocol», RFC 760, DOI 10.17487/RFC0760, January 1980, <https://www.rfc-editor.org/info/rfc760>.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC894] Hornig, C., «A Standard for the Transmission of IP Datagrams over Ethernet Networks», STD 41, RFC 894, DOI 10.17487/RFC0894, April 1984,
<https://www.rfc-editor.org/info/rfc894>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1958] Carpenter, B., Ed., «Architectural Principles of the Internet», RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.

[RFC1984] IAB and IESG, «IAB and IESG Statement on Cryptographic Technology and the Internet», BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996,
<https://www.rfc-editor.org/info/rfc1984>.

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[RFC2277] Alvestrand, H., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <https://www.rfc-editor.org/info/rfc2277>.

[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.

[RFC3022] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.

[RFC3365] Schiller, J., «Strong Security Requirements for Internet Engineering Task Force Standard Protocols», BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <https://www.rfc-editor.org/info/rfc3365>.

[RFC3439] Bush, R. and D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, DOI 10.17487/RFC3439, December 2002,
<https://www.rfc-editor.org/info/rfc3439>.

[RFC3536] Hoffman, P., «Terminology Used in Internationalization in the IETF», RFC 3536, DOI 10.17487/RFC3536, May 2003, <https://www.rfc-editor.org/info/rfc3536>.

[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, «The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture», RFC 3724, DOI 10.17487/RFC3724, March 2004, <https://www.rfc-editor.org/info/rfc3724>.

[RFC3935] Alvestrand, H., «A Mission Statement for the IETF», BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/info/rfc3935>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4084] Klensin, J., «Terminology for Describing Internet Connectivity», BCP 104, RFC 4084, DOI 10.17487/RFC4084,
May 2005, <https://www.rfc-editor.org/info/rfc4084>.

[RFC4101] Rescorla, E. and IAB, «Writing Protocol Models», RFC 4101, DOI 10.17487/RFC4101, June 2005, <https://www.rfc-editor.org/info/rfc4101>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.

[RFC5646] Phillips, A., Ed., and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,
<https://www.rfc-editor.org/info/rfc5646>.

[RFC5694] Camarillo, G., Ed., and IAB, «Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability», RFC 5694, DOI 10.17487/RFC5694,
November 2009, <https://www.rfc-editor.org/info/rfc5694>.

[RFC5944] Perkins, C., Ed., «IP Mobility Support for IPv4, Revised», RFC 5944, DOI 10.17487/RFC5944, November 2010, <https://www.rfc-editor.org/info/rfc5944>.

[RFC6101] Freier, A., Karlton, P., and P. Kocher, «The Secure Sockets Layer (SSL) Protocol Version 3.0», RFC 6101, DOI 10.17487/RFC6101, August 2011,
<https://www.rfc-editor.org/info/rfc6101>.

[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, «Comcast’s Web Notification System Design», RFC 6108, DOI 10.17487/RFC6108, February 2011, <https://www.rfc-editor.org/info/rfc6108>.

[RFC6120] Saint-Andre, P., «Extensible Messaging and Presence Protocol (XMPP): Core», RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.

[RFC6365] Hoffman, P. and J. Klensin, «Terminology Used in Internationalization in the IETF», BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.

[RFC6698] Hoffman, P. and J. Schlyter, «The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA», RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.

[RFC6701] Farrel, A. and P. Resnick, «Sanctions Available for Application to Violators of IETF IPR Policy», RFC 6701, DOI 10.17487/RFC6701, August 2012,
<https://www.rfc-editor.org/info/rfc6701>.

[RFC6797] Hodges, J., Jackson, C., and A. Barth, «HTTP Strict Transport Security (HSTS)», RFC 6797, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.

[RFC7232] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Range Requests», RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.

[RFC7235] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.

[RFC7236] Reschke, J., «Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations», RFC 7236, DOI 10.17487/RFC7236, June 2014,
<https://www.rfc-editor.org/info/rfc7236>.

[RFC7237] Reschke, J., «Initial Hypertext Transfer Protocol (HTTP) Method Registrations», RFC 7237, DOI 10.17487/RFC7237,
June 2014, <https://www.rfc-editor.org/info/rfc7237>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258,
May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7469] Evans, C., Palmer, C., and R. Sleevi, «Public Key Pinning Extension for HTTP», RFC 7469, DOI 10.17487/RFC7469,
April 2015, <https://www.rfc-editor.org/info/rfc7469>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., «Hypertext Transfer Protocol Version 2 (HTTP/2)», RFC 7540, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.

[RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, «Peer-to-Peer Streaming Peer Protocol (PPSPP)», RFC 7574, DOI 10.17487/RFC7574, July 2015,
<https://www.rfc-editor.org/info/rfc7574>.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, «Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement», RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7626] Bortzmeyer, S., «DNS Privacy Considerations», RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.

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

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, «Technical Considerations for Internet Service Blocking and Filtering», RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, «Specification for DNS over Transport Layer Security (TLS)», RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8164] Nottingham, M. and M. Thomson, «Opportunistic Security for HTTP/2», RFC 8164, DOI 10.17487/RFC8164, May 2017,
<https://www.rfc-editor.org/info/rfc8164>.

[RFC8179] Bradner, S. and J. Contreras, «Intellectual Property Rights in IETF Technology», BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[Rideout] Rideout, A., «Making security easier», July 2008, <http://gmailblog.blogspot.de/2008/07/making-security-easier.html>.

[Ritchie] Ritchie, J. and J. Lewis, «Qualitative Research Practice: A Guide for Social Science Students and Researchers», SAGE Publishing, London, 2003, <http://www.amazon.co.uk/Qualitative-Research-Practice-Students-Researchers/dp/0761971106>.

[RSF] Reporters Without Borders (RSF), «Syria using 34 Blue Coat servers to spy on Internet users», January 2016, <https://rsf.org/en/news/syria-using-34-blue-coat-servers-spy-internet-users>.

[Saltzer] Saltzer, J., Reed, D., and D. Clark, «End-to-End Arguments in System Design», ACM Transactions on Computer Systems (TOCS), Volume 2, Number 4, pp. 277-288, DOI 10.1145/357401.357402, November 1984.

[Sandvine] Sandvine, «Sandvine: Over 70% Of North American Traffic Is Now Streaming Video And Audio», December 2015,
<https://www.sandvine.com/pr/2015/12/7/sandvine-over-70-of-north-american-traffic-is-now-streaming-video-andaudio.html>.

[Schillace] Schillace, S., «Default https access for Gmail», January 2010, <http://gmailblog.blogspot.de/2010/01/default-https-access-for-gmail.html>.

[Schneier] Schneier, B., «Attacking Tor: how the NSA targets users’ online anonymity», October 2013,
<http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity>.

[SPIEGEL] SPIEGEL, «Prying Eyes — Inside the NSA’s War on Internet Security», December 2014, <http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html>.

[sslstrip] Marlinspike, M., «Software >> sslstrip», 2011, <https://moxie.org/software/sslstrip/>.

[techyum] Violet, «Official — vb.ly Link Shortener Seized by Libyan Government», October 2010, <http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-libyangovernment/>.

[TorProject] The Tor Project, «Anonymity Online», 2006, <https://www.torproject.org/>.

[torrentfreak1] Van der Sar, E., «Is Your ISP Messing With BitTorrent Traffic? Find Out», January 2014, <https://torrentfreak.com/is-your-isp-messing-withbittorrent-traffic-find-out-140123/>.

[torrentfreak2] Andy, «Lawyers Sent 109,000 Piracy Threats in Germany During 2013», March 2014,

<https://torrentfreak.com/lawyers-sent-109000-piracy-threats-in-germany-during-2013-140304/>.

[Tribler] Delft University of Technology, Department EWI/PDS/Tribler, «About Tribler», 2013, <https://www.tribler.org/about.html>.

[UDHR] United Nations General Assembly, «The Universal Declaration of Human Rights», 1948, <http://www.un.org/en/universal-declaration-human-rights/index.html>.

[UNGA2013] United Nations General Assembly, «UN General Assembly Resolution «The right to privacy in the digital age» (A/C.3/68/L.45)», 2013,
<https://documents-dds-ny.un.org/doc/UNDOC/LTD/N13/576/77/PDF/N1357677.pdf?OpenElement>.

[UNHRC2016] United Nations Human Rights Council, «The promotion, protection and enjoyment of human rights on the Internet», Resolution A/HRC/32/L.20, 2016, <http://ap.ohchr.org/documents/alldocs.aspx?doc_id=20340>.

[Ververis] Ververis, V., Kargiotakis, G., Filasto, A., Fabian, B., and A. Alexandros, «Understanding Internet Censorship Policy: The Case of Greece», 5th USENIX Workshop on Free and Open Communications on the Internet (FOCI) ’15, August 2015, <https://www.usenix.org/system/files/conference/foci15/foci15-paper-ververis-update.pdf>.

[W3CAccessibility] World Wide Web Consortium, «Accessibility», 2016, <https://www.w3.org/standards/webdesign/accessibility>.

[W3Ci18nDef] Ishida, R. and S. Miller, «Localization vs. Internationalization», World Wide Web Consortium, April 2015, <http://www.w3.org/International/questions/qa-i18n.en>.

[wikileaks] Sladek, T. and E. Broese, «Market Survey: Detection & Filtering Solutions to Identify File Transfer of Copyright Protected Content for Warner Bros. and movielabs», 2011, <https://wikileaks.org/sony/docs/05/docs/Anti-Piracy/CDSA/EANTC-Survey-1.5-unsecured.pdf>.

[WP-Tempora] Wikipedia, «Tempora», September 2017, <https://en.wikipedia.org/wiki/Tempora>.

[WSJ] Sonne, P. and M. Coker, «Firms Aided Libyan Spies», The Wall Street Journal, August 2011, <http://www.wsj.com/articles/SB10001424053111904199404576538721260166388>.

[WynsbergheMoura] Nguyen, B., Ed., van Wynsberghe, A., van Wynsberghe, A., and G. Moreira Moura, «The concept of embedded values and the example of internet security», June 2013, <http://doc.utwente.nl/87095/>.

[XMPP-Manifesto] Saint-Andre, P. and XMPP Operators, «A Public Statement Regarding Ubiquitous Encryption on the XMPP Network»,
March 2014, <https://raw.githubusercontent.com/stpeter/manifesto/master/manifesto.txt>.

[Zittrain] Zittrain, J., «The Future of the Internet — And How to Stop It», Yale University Press & Penguin UK, 2008, <https://dash.harvard.edu/bitstream/handle/1/4455262/
Zittrain_Future%20of%20the%20Internet.pdf?sequence=1>.

Благодарности

Особая благодарность всем членам Исследовательской группы HRPC, которые внесли свой вклад в этот документ. Следующее заслуживает особого упоминания:

• Джоана Варон за помощь в разработке первой итерации методологии и предыдущих проектов, а также за руководство фильмом «Сеть прав» и работу над интервью на IETF 92 в Далласе.
• Дэниелу Кану Гилмору (dkg) за помощь в первой итерации глоссария (раздел 2), а также за множество технических рекомендаций, поддержки и предложений по языку.
• Клаудио Гуарнери (Claudio Guarnieri) за написание первых итераций тематических исследований по VPN, HTTP и P2P.
• Уилла Скотта за написание первых итераций тематических исследований по DNS, IP и XMPP.
• Аври Дориа за то, что она предложила написать глоссарий в первую очередь, помочь с написанием первоначальных предложений и интернет-проектов, ее обзоров и ее вкладов в глоссарий.

Также спасибо Стефану Борцмейеру, Джону Керрану, Барри Шейну, Джо Холлу, Джоссу Райту, Гарри Хэлпину и Тиму Саммуту, которые внесли множество отличных предложений, многие из которых нашли свое отражение непосредственно в тексте. Мы хотим поблагодарить Амелию Андерсдоттер, Стивена Фаррелла, Стефана Борцмейера, Шейна Керра, Джована Моуру, Джеймса Гэннона, Алиссу Купер, Эндрю Салливана, С. Мунесами, Роланда Блесса и Скотта Крейга за их обзоры и за тестирование рекомендаций HRPC в дикой природе. , Мы также хотели бы поблагодарить Молли Саутер, Артуро Филасто, Натали Марешал, Элеонору Саитту, Ричарда Хилла и всех других, кто внес вклад в этот документ или концептуализацию идеи. Спасибо Эдварду Сноудену за его комментарии на IETF 93 в Праге относительно влияния протоколов на права пользователей.

Адреса авторов

Niels ten Oever
ARTICLE 19
Email: mail@nielstenoever.net
Corinne Cath
Oxford Internet Institute
Email: corinnecath@gmail.com