На Хабре уже было несколько статей по поводу трудностей, связанных с получением доступа к списку запрещенных сайтов, с его обновлением и использованием. Эта статья — логическое продолжение ранее высказанной другими (в том числе в комментариях) критики. Сразу оговорюсь, что я не являюсь сотрудником никакого провайдера.
Итак, предположим, что вы собрались предоставлять клиентам услуги доступа в Интернет, или, проще говоря, стать провайдером. Чтобы добиться лояльности клиентов, вы решили купить навороченную DPI-систему, блокировать запрещенную информацию по URL'ам и не блокировать ничего лишнего. Никакой фильтрации по доменам и IP, только по URL'ам! Все юридические, бюрократические, этические и денежные вопросы улажены, остались технические. Осталось только взять готовую автоматическую качалку списка запрещенных сайтов и настроить автоматическую загрузку этого списка в DPI-систему в том формате, который она понимает. Т.е. написать скрипт-конвертер. Так вот, вынужден вас разочаровать — написать работающий конвертер не получится. Не получится до тех пор, пока в Роскомнадзоре не пошевелятся и не поменяют формат данных, а также не исправят явные ошибки в существующих элементах списка.
Начнем с того, в каком именно формате Роскомнадзор отдает список запрещенной информации. Это XML, соответствующий XSD-схеме, опубликованной как часть Памятки оператору связи. Или, говоря проще, XML, содержащий последовательность блоков наподобие следующего:
При этом, согласно схеме, тегов <url> может быть от нуля до бесконечности, за ними следует ноль или один тег <domain>, а затем от одного до бесконечности тегов <ip>. Нас, очевидно, интересуют теги <url>. Итак, вроде бы, надо только закрыть доступ к перечисленному списку URL'ов.
А теперь посмотрим, какими средствами похожие задачи решались ранее и какие умные слова при этом говорились.
Доступ к URL'ам на серверах надо закрывать не только от людей, но и от роботов. Для этого служит файл /robots.txt с документированным синтаксисом. Что не менее важно, в этом же документе подробно описана и семантика, т.е. точные правила интерпретации каждой записи для решения вопроса, можно ли роботу посещать какой-либо URL:
Т.е., чтобы запись сработала, путь в записи robots.txt должен быть префиксом пути в URL. Соответствующих правил на сайте Роскомнадзора просто нет, и это, с моей точки зрения, баг. Может, попробовать написать эти правила за них? И ведь похоже, что фильтрация по префиксу, а не по точному совпадению URL'а, более уместна и в случае блокировок контента от людей. Не будет же Роскомнадзор перечислять все URL'ы сайта, который надо заблокировать целиком!
Еще к стандарту robots.txt есть расширение Clean-Param. Оно указывает, какие GET-параметры являются незначащими, т.е. не должны учитываться при сравнении URL'ов. Само понятие значимости параметров является важным — это ведь плохо, если пользователь сможет обойти блокировку, добавив unblock_me=1& после вопросительного знака в URL'е. Только вот в случае блокировки контента от людей, правильнее будет говорить о значащих параметрах и о том, что порядок этих параметров на самом деле не имеет значения.
Итого, вырисовывается такая умозрительная схема правдоподобной интерпретации смысла URL'ов в реестре запрещенных сайтов:
Только вот эта схема все равно является неполной. Надо ли проводить сравнение с учетом регистра? Как именно учитывать регистр — ведь у нас есть только байты в неизвестной кодировке?
И самое главное — существующие данные в реестре под эту схему не подходят. Чего только стоят вот такие записи:
В первых двух случаях мне, как читателю мыслей, очевидно намерение заблокировать сайт целиком, вместо чего блокируются только URL'ы, путь которых начинается с /index.php. В третьем параметр s похож на незначащий идентификатор сессии. В четвертом вообще есть хеш-тег. В общем — исходные данные слишком грязные, чтобы схема работала.
И даже если бы она работала, я бы эту схему использовать не стал. При ее написании я произвел слишком много попыток что-то угадать, и все это сильно напоминает попытку написать очередной клон libastral. При интерпретации законов такие действия недопустимы.
Итак, если кто-то пытается вам продать систему фильтрации по URL'ам на основе официальных данных с zapret-info.gov.ru, не верьте ему — это однозначно развод. Пока Роскомнадзор не сделает свои данные по-настоящему машиночитаемыми и однозначно интерпретируемыми, такие решения просто не могут работать. На сей день тег <url> в XML-дампе реестра годится только как справочная информация для проверки обоснованности включения сайта в реестр. Нужны на самом деле не URL'ы, а правила фильтрации.
Теперь поговорим о том, что Роскомнадзор мог бы сделать для исправления ситуации, когда люди говорят о принципиальной возможности URL-фильтрации по его спискам, а на деле такой возможности нет.
Самый простой (и, на мой взгляд, самый правильный) способ — это оставить все как есть, но публично признать, что информация в реестре запрещенных сайтов непригодна и не может быть пригодна для фильтрации по URL'ам. Тег <url> оставить — как уже было сказано, он полезен для проверки решений о блокировках и тем самым для обеспечения прозрачности процесса.
Способ посложнее — написать правила интерпретации содержимого тега <url> (как я пытался сделать выше) и подогнать под них существующее содержимое базы.
Еще способ — переделать структуру XML. Сделать вместо одного тега <url> конструкцию, способную хранить префикс, обязательные параметры и, возможно, другую информацию, способную описать группу связанных URL'ов. Тогда ее можно будет превратить в регулярное выражение для «acl aclname url_regex» в SQUID или в glob для «match protocol http url» в Cisco NBAR.
А вот почему я считаю первый способ самым правильным. В Роскомнадзоре, похоже, внедрена такая схема работы: приходит жалоба с URL'ом противоправного контента, модераторы ее проверяют и вносят тот же URL в базу. В этом процессе нет места для преобразования URL'а, на который пожаловались, в машиночитаемые правила фильтрации. И если пытаться внести этот (существенно ручной) шаг, то надо искать людей, способных его выполнить. ��то же надо объяснить исполнителям, что машина не умеет читать мысли. Это же надо найти людей, которые и психологически устойчивы, и способны поставить себя на место машины и проверить, действительно ли правило работает, как надо. Тяжелая задача для отдела кадров! Ну и если оставить тег <url> чисто информационным и явно сказать об этом, то у провайдеров не будет возникать желания потратить деньги на навороченную DPI-систему, которую по факту все равно не получится использовать по назначению.
Итак, предположим, что вы собрались предоставлять клиентам услуги доступа в Интернет, или, проще говоря, стать провайдером. Чтобы добиться лояльности клиентов, вы решили купить навороченную DPI-систему, блокировать запрещенную информацию по URL'ам и не блокировать ничего лишнего. Никакой фильтрации по доменам и IP, только по URL'ам! Все юридические, бюрократические, этические и денежные вопросы улажены, остались технические. Осталось только взять готовую автоматическую качалку списка запрещенных сайтов и настроить автоматическую загрузку этого списка в DPI-систему в том формате, который она понимает. Т.е. написать скрипт-конвертер. Так вот, вынужден вас разочаровать — написать работающий конвертер не получится. Не получится до тех пор, пока в Роскомнадзоре не пошевелятся и не поменяют формат данных, а также не исправят явные ошибки в существующих элементах списка.
Начнем с того, в каком именно формате Роскомнадзор отдает список запрещенной информации. Это XML, соответствующий XSD-схеме, опубликованной как часть Памятки оператору связи. Или, говоря проще, XML, содержащий последовательность блоков наподобие следующего:
<content id="105" includeTime="2012-11-11T15:39:37">
<decision date="2012-11-04" number="2/1/16402" org="ФСКН"/>
<url>http://go-****.com/workshop/</url>
<domain>go-****.com</domain>
<ip>62.75.***.***</ip>
</content>
При этом, согласно схеме, тегов <url> может быть от нуля до бесконечности, за ними следует ноль или один тег <domain>, а затем от одного до бесконечности тегов <ip>. Нас, очевидно, интересуют теги <url>. Итак, вроде бы, надо только закрыть доступ к перечисленному списку URL'ов.
А теперь посмотрим, какими средствами похожие задачи решались ранее и какие умные слова при этом говорились.
Доступ к URL'ам на серверах надо закрывать не только от людей, но и от роботов. Для этого служит файл /robots.txt с документированным синтаксисом. Что не менее важно, в этом же документе подробно описана и семантика, т.е. точные правила интерпретации каждой записи для решения вопроса, можно ли роботу посещать какой-либо URL:
The matching process compares every octet in the path portion of
the URL and the path from the record. If a %xx encoded octet is
encountered it is unencoded prior to comparison, unless it is the
"/" character, which has special meaning in a path. The match
evaluates positively if and only if the end of the path from the
record is reached before a difference in octets is encountered.
Т.е., чтобы запись сработала, путь в записи robots.txt должен быть префиксом пути в URL. Соответствующих правил на сайте Роскомнадзора просто нет, и это, с моей точки зрения, баг. Может, попробовать написать эти правила за них? И ведь похоже, что фильтрация по префиксу, а не по точному совпадению URL'а, более уместна и в случае блокировок контента от людей. Не будет же Роскомнадзор перечислять все URL'ы сайта, который надо заблокировать целиком!
Еще к стандарту robots.txt есть расширение Clean-Param. Оно указывает, какие GET-параметры являются незначащими, т.е. не должны учитываться при сравнении URL'ов. Само понятие значимости параметров является важным — это ведь плохо, если пользователь сможет обойти блокировку, добавив unblock_me=1& после вопросительного знака в URL'е. Только вот в случае блокировки контента от людей, правильнее будет говорить о значащих параметрах и о том, что порядок этих параметров на самом деле не имеет значения.
Итого, вырисовывается такая умозрительная схема правдоподобной интерпретации смысла URL'ов в реестре запрещенных сайтов:
- Перед применением следующих шагов как URL в реестре, так и URL, к которому обратился пользователь, должны быть нормализованы путем замены октетов, закодированных в формате %xx, на раскодированные октеты, за исключением символа "/".
- Если в списке запрещенных сайтов URL не содержит символа "?", то для того, чтобы блокировка сработала, URL в реестре должен быть префиксом URL'а, к которому обратился пользователь.
- Если в списке запрещенных сайтов URL содержит символ "?", то для того, чтобы блокировка сработала, URL в реестре и URL, к которому обратился пользователь, должны посимвольно совпадать в позициях до первого знака "?" включительно. Набор GET-параметров в URL'е из реестра должен быть подмножеством набора GET-параметров из пользовательского URL'а. Считается, что GET-параметры разделяются символом "&".
Только вот эта схема все равно является неполной. Надо ли проводить сравнение с учетом регистра? Как именно учитывать регистр — ведь у нас есть только байты в неизвестной кодировке?
И самое главное — существующие данные в реестре под эту схему не подходят. Чего только стоят вот такие записи:
<url>http://*******tube.ru/index.php</url>
<url>http://********.kiev.ua/index.php</url>
<url>http://***forum.org/index.php?s=3a95f6da301a36067be68329be6f88a8&showforum=8</url>
<url>http://****lib.net/b/27415/read#t16</url>
В первых двух случаях мне, как читателю мыслей, очевидно намерение заблокировать сайт целиком, вместо чего блокируются только URL'ы, путь которых начинается с /index.php. В третьем параметр s похож на незначащий идентификатор сессии. В четвертом вообще есть хеш-тег. В общем — исходные данные слишком грязные, чтобы схема работала.
И даже если бы она работала, я бы эту схему использовать не стал. При ее написании я произвел слишком много попыток что-то угадать, и все это сильно напоминает попытку написать очередной клон libastral. При интерпретации законов такие действия недопустимы.
Итак, если кто-то пытается вам продать систему фильтрации по URL'ам на основе официальных данных с zapret-info.gov.ru, не верьте ему — это однозначно развод. Пока Роскомнадзор не сделает свои данные по-настоящему машиночитаемыми и однозначно интерпретируемыми, такие решения просто не могут работать. На сей день тег <url> в XML-дампе реестра годится только как справочная информация для проверки обоснованности включения сайта в реестр. Нужны на самом деле не URL'ы, а правила фильтрации.
Теперь поговорим о том, что Роскомнадзор мог бы сделать для исправления ситуации, когда люди говорят о принципиальной возможности URL-фильтрации по его спискам, а на деле такой возможности нет.
Самый простой (и, на мой взгляд, самый правильный) способ — это оставить все как есть, но публично признать, что информация в реестре запрещенных сайтов непригодна и не может быть пригодна для фильтрации по URL'ам. Тег <url> оставить — как уже было сказано, он полезен для проверки решений о блокировках и тем самым для обеспечения прозрачности процесса.
Способ посложнее — написать правила интерпретации содержимого тега <url> (как я пытался сделать выше) и подогнать под них существующее содержимое базы.
Еще способ — переделать структуру XML. Сделать вместо одного тега <url> конструкцию, способную хранить префикс, обязательные параметры и, возможно, другую информацию, способную описать группу связанных URL'ов. Тогда ее можно будет превратить в регулярное выражение для «acl aclname url_regex» в SQUID или в glob для «match protocol http url» в Cisco NBAR.
А вот почему я считаю первый способ самым правильным. В Роскомнадзоре, похоже, внедрена такая схема работы: приходит жалоба с URL'ом противоправного контента, модераторы ее проверяют и вносят тот же URL в базу. В этом процессе нет места для преобразования URL'а, на который пожаловались, в машиночитаемые правила фильтрации. И если пытаться внести этот (существенно ручной) шаг, то надо искать людей, способных его выполнить. ��то же надо объяснить исполнителям, что машина не умеет читать мысли. Это же надо найти людей, которые и психологически устойчивы, и способны поставить себя на место машины и проверить, действительно ли правило работает, как надо. Тяжелая задача для отдела кадров! Ну и если оставить тег <url> чисто информационным и явно сказать об этом, то у провайдеров не будет возникать желания потратить деньги на навороченную DPI-систему, которую по факту все равно не получится использовать по назначению.
