Идея «подпольного» канального интернета

в 11:21, , рубрики: Dura Lex, Peer-to-Peer, блокировки, Сетевые технологии, социальные сети, цензура, метки: , , ,

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

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

Но любом случае «крайнего» всегда можно найти. Т.е. вся проблема в том, что тот кто публикует на интернет ресурсе информацию — тот и отвечает за нее. Точнее на самом деле никакой проблемы нет — все логично. Казалось бы — так и должно быть! Но вот как определить меру этой ответственности? Вот тут и начинаются злоупотребления, когда за шутку можно сесть в тюрьму, а за выложенную в общий доступ, причем честно купленную, песенку получить 6-ти значный штраф и т.д.

Наиболее уязвимым в цепочке: «владелец сервера» (хостер) > «владелец сайта» > «пользователь сайта», является именно владелец сайта. Так как хостер обычно по договору перекладывает по максимуму ответственность на владельца сайта. Личность или организация владельца сайта легко выясняется т.к. он оплачивает услуги хостера и регистратора домена, т.е. предоставляет им достаточное количество информации о себе. Из за того, что выяснить личность пользователя сайта намного труднее, особенно если он лично не принес образцы своей ДНК при регистрации владельцу сайта, то обычно всех собак вешают именно на владельца сайта.

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

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

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

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

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

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

Обмен информацией может происходить периодически в автоматическом режиме или по команде пользователя. ПО само проверяет/отправляет, шифрует/дешифрует почту, при приеме очередного блока обновления ВСЕГДА показывает пользователю список пришедших обновлений для проверки и разрешения их публикации на локальном сайте пользователя, т.к. повторяю еще раз — пользователь несет полную ответственность за публикуемую на его локальном сайте информацию.

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

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

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

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

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

На данный момент имеются все технологии для реализации предложенной идеи.

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

Скорее всего я далеко не все предусмотрел и продумал — жду ваших комментариев.

Автор: AlexTest

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js