Съгласно предното ми писание описвам идеята за създаване на дистрибутирана архитектура за реализацията на Wikileaks сайт без необходимост от наличието на хостинг провайдери и хардуерни сървъри.
Идеята е проста – всеки участник да си изтегли и стартира малка програмка, която да се прави на web сървър и да сървира файловете и информацията на сайта. По този начин всеки, който желае да участва и да помага на wikileaks е достатъчно да инсталира на компютъра си малък софтуер, който не би отнел много ресурси. Ресурсите не са проблем, тъй като Wikileaks тип сайтове заемат малко място. Не е проблем и скоростта за достъп до Интернет тъй като ще става въпрос за достатъчно много потребители, които сборно ще осигурят огромен капацитет, докато поединично (на една сесия, за участък от сайта) не е необходима висока скорост за достъп до малки web файлове, а големите файлове за данни ще се транспортират дистрибутирано чрез peer to peer техника от типа на bittorrent, рекомбинираща скоростите на много участници.
(Wikileaks сайта се състои от 2 типа файлове – web страниците, които са много малки – 2-4kb, и самите документни файлове, които се теглят като архиви и ще бъдат торент файлове)
Създаването на дистрибутирана архитектура, която да създаде инфраструктура за услуги от тип на Wikileaks е техническо предизвикателство.
Системата трябва да бъде:
Максимално опростена – не трябва да се изискват специални познания за да се използва или инсталира от участниците
Да бъде напълно автоматизирана, с цел да минимизира умишленото участие от страна на потребителите при каквато и да е операция
Трябва да бъде open source за да се пресекат евентуални злонамерени слухове за потенциална злоупотреба от създателите на софтуера за цели извън прокламираните и подкрепени от самите потребители
Трябва да позволява да се превърне в web server всяко PC дори и намиращо се на домашен компютър и в домашна или публична мрежа
Трябва да позволява лесно насочване на потребителите към най-лесния и близък сървър
Трябва да може успешно да се скалира до около 1 милион хоста
Трябва да бъде максимално защитена
Някой операции изпълнявани там (например качване на информация) трябва да бъдат изпълнени максимално анонимно, така че да не могат лесно да бъдат проследявани инициаторите им
Информацията, която е публикувана на web сървъра трябва да е проверена и достоверна, с цел невъзможност за злоупотреба (някой да сложи информация, която не трябва да е там)
Трябва да използва някаква публична инфраструктура, с цел по трудно стопиране на услугата и по лесно размножаване на информацията
Особено проблематична е комбинацията от изисквания – публична инфраструктура, open source и анонимност.
Няма много стабилни и децентрализирани публични инфраструктури.
От своя страна Wikileaks използва доста добре bittorrent инфраструктурата. Всичките и файлове се намират там. Bittorrent (в случаите когато се използва DHT и PER) може да бъде децентрализирана.
Но е лошо проектирана:
Не е отказоустойчива, при отпадане на Node може да мине доста време преди DHT дървото да се възстанови отново
Bittorrent (и въобще Kademila) DHT е структурирана децентрализация. Тя създава дърво, на което обаче root node (router, boot strap node) трябва да е предварително известен (статичен), иначе не може да се структурира/създаде, и при отпадане на node да се възстанови. Така например ако router.bittorrent.com изчезне, ще изчезне цялата DHT мрежа. Приемам че този риск е минимален.
Не позволява (стандартно) търсене по имена или част от име.
Не позволява (стандартно) търсене в, и добавяне на допълнителна информация към файловете
Не позволява пренасянето на съобщения в мрежата (всякакви)
Тотално не анонимна структура е. Лесно се открива кой кой е. Лесно се открива кой е първоизточник на даден файл. Това е голям проблем по отношение на скриването на източниците.
Голям плюс е възможността да намериш файл по HASH чрез магнет линк. Няма нужда от торент файлове и от тракери. Недостатък – няма децентрализиран механизъм за обмяната на магнет линковете и съпътстващата ги информация, нещо, което да замести напълно нуждата от съществуването на web сървър.
Въпреки, че peer-to-peer комуникацията може да бъде криптирана между двама обменящи си файл, самата DHT система не е защитена, не е криптирана. Отделно структурата се поддава на Man In the Middle атаки. Отделно е изключително неустойчива на спуфинг – всеки който вкара хешове подобни на файловете, които иска да спре, може да блокира трансфера на всеки файл. Отделно самата структура на DHT-то може да бъде разрушена от един единствен компютър (анонсиращ се като на колкото се може по-близък до root node и отговарящ на всички търсения с фалшиви нодове, уж директно закачени за него). Добре разработена от гледна точка на сигурност е maidsafe-dht (имам забележки, пак може да се разруши с атака над руут нода, липсва им и white-noise прикритие), но тя не се поддържа от bittorrent клиентите и се загубва идеята на публичната инфраструктура.
Въпреки всичките си недостатъци, аз реших да заложа на Bittorrent с DHT инфраструктура. Причината е много проста – всеки, който има битторент клиент, дори да не бъде web сървър инсталирал специалният софтуер, може да бъде и да подсигурява инфраструктурата на сайта, а това значи лесна размножимост до милиони. Технически дори някой да иска да спре бит торента, той ще е „пост фактум“, след като информацията се е размножила и ще бъде притежание на хиляди. Отделно бит торент DHT протокола е лесен за възстановяване при умишлен краш (макар и с ръчно усилие), всеки път при падане на руут нод, може да се направи нов, или може да се направи нов bootstrap на DHT-то, ако трябва може да се направи нов тракер и всичко да започва отначало. Технологията е точно толкова устойчива, колкото са нейните поддръжници. Повече поддръжници значи невъзможност за спиране. А това дали ще има такива или не, не е въпрос на закони, а е въпрос на морал. Ако хората вярват, че нещо е справедливо и редно да се случва, то ще се случва.
Та така, следните задачи/проблеми е редно да бъдат решени:
Най на първо място – как да обменям съобщения по DHT. Съобщения ми трябват, защото торент протокола не поддържа механизъм за автоматично обновяване на файловете от даден торент, ако работи през DHT (въпреки че такава техника, макар и частна за някой клиенти, съществува при наличието на тракер). Следователно аз трябва да намеря механизъм да известявам клиентите реализиращи web server-и, че има нова версия на пакета за уеб сайта, или някой от системните файлове. Също така при ъплоад на нов файл от „анонимен източник“ е добре останалите да могат да бъдат нотифицирани да го получат.
Как да запазя анонимността на източника на съобщение. Това е принципен проблем при торент DHT. Дори при използване на анонимни проксита като TOR има механизъм как да се накара нода да си (по)каже реалното IP. Трябва сериозна модификация на библиотеките и протокола, но аз исках да ползвам популярната библиотека libtorrent rastebar без никакви модификации (опростяване на кода, и по лесни ъпгрейди), с цел по добро наследство.
Как да подсигуря вершънинг – механизъм да знам дали има по-нова версия на съобщението, торент, компонент, заобикаляйки недостатъците на стандартната DHT мрежа, не позволяваща търсене по име или част от име, а само то точен HASH стринг.
Как да наименовам компонентите?
В DHT има само един елемент служещ като вектор към информацията – това е хаша на файла.
И аз използвам трик - създавам торент HASH код с предназначението на файла (който ми служи като системно име) – той се състои от 160 бита (20 байта), от които „WIKILEAKS“ префикс, един байт версия на протокола „00“, след което следват два байта тип на кода/файла (от 0001 – 000F са сертификати, 1000 – основният Web сайт, 1111 – съобщения, 1010 – неоторизирани допълнителни файлове за качване, 8080 – оторизирани файлове, на които се вярва), следват 4 байта за идентификатор за различен файл (тези които не са различни са винаги 00000001) и последните 4 байта са версия на файла.
Най-важният файл – файла с уеб сайта се проверява в DHT-то за теглене с предварително закодираният в клиента hash. Ако е вече изтеглен се проверява неговата достоверност чрез RSA сертификат (публични и частни ключове), публичният ключ на който е предварително записан в клиента. Така само притежателят на частният ключ може да публикува. След като се изтегли и верифицира успешно, започва да се опитва да се изтегли по-новата версия (частта за версията увеличена с единица). Ако RSA оторизацията не мине, изтегленото се игнорира. Няма как някой да сложи фалшив файл, или да модифицира версиите, без да притежава частният ключ за публикуване.
Методът за web съдържанието се използва реално за теглене на всеки файл с изключение на неоторизираните файлове с префикс 1010.
Възможно е обаче някой да публикува в DHT файл, чиито хаш да съвпада с хашовете, които аз използвам. Има два начина да се случи това – случаен и нарочен. Случайно, е невероятно рядко да се случи заради начина, по който се генерира торент хаша. Дори да стане, не е проблем тъй като част от клиентите ще получат правилни пииъри, и макар част да получат грешни, на последвалата верификация ще се изхвърлят грешните от добрите.
Възможно е някой обаче нарочно да зашумява с фалшиви добрите пиъри с цел да попречи на разпространението на информацията. Тогава е необходимо – той да може да бъде открит (верификацията на изтегленият файл срещу node id-то на DHT node-то анонсирало проблемните пиъри е механизъм за това) и да може да бъде блокиран.
Тоест DHT клиентите да не закачват блокирани нодове и да не взимат информация от блокирани нодове. Това е един от големите недостатъци на днешният торент DHT – няма механизъм за изолация. И аз си създадох мой – един от специалните файлове (оторизиран с RSA ключ) носи информация с лошите пиъри. Достатъчно е да има (поне) един клиент в мрежата, който да знае частният ключ за публикуването на този списък, и да прилага следният алгоритъм – ако верификацията на някой от файловете не мине, вредният нод посочил грешни пиъри се проверява и се вкарва в списъка (процесът може да е автоматичен). Останалите след като обновят списъка просто изолират този нод от мрежата (изолацията може да е и умна, като за целта един нод може да го изпълнява с по-интелигентен клиент и да лъже лошите нодове, че са регистрирани за него, но същевременно търсене никога да не стига до него).
С цел да се опитвам да държа анонсите само в нодове, които са в дърво поддържащо моят алгоритъм, аз използвам хашове за нодовете (създадени и добавени в мрежата от моят софтуер) използвайки същият алгоритъм като за хаша на файловете – WIKILEAKS000000000000 + уникален идентификатор (създаден от случаен алгоритъм). Така DHT XOR алгоритъма за определяне на дистанция ще преферира винаги при анонсиране и търсене моите нодове.
Всеки различен тип файл е криптиран с различен RSA ключ. Всеки публичен RSA ключ е файл и може да се изтегли през DHT мрежата. Всяка следваща версия е криптирана частният ключ на предната. Стартовите клиенти ще имат 3 или повече версии на публичният ключ предварително заредени. Така при добра техника (липса на държане на частните ключове на едно и също място в едни и същи лица) на безопасност се намалява риска от компрометиране на частните ключове, тъй като те могат да бъдат подменени в движение на всички клиенти, без да се налага преинсталация. Това значително ще затрудни опитите за публикуване на неоторизирана информация в оторизираният списък.
Така притежаващите частните ключове могат да публикуват майн-стриим оторизираните файлове. Те обаче са фиксирано ограничено число, и техните хаш префикси се знаят от клиентите предварително. Единствената информация, която е динамично променима е евентуално магнет линк към файлове публикуващи информация (от Wikilekas). Но тези линкове ще бъдат в някоя Web страничка на web частта.
Всяка различна оторизирана публикация (web, rsa ключове, обновяване на сървърският софтуер, и т.н.) използва различна двойка RSA ключове. Обновяването на всеки RSA ключ използва нова различна двойка RSA ключове. Така, макар ключовете да са много, значително се намалява риска от компрометиране на една двойка ключове (чрез извъртяване или чрез открадване), и се запазва възможността за бърза реакция и подмяна на ключовете и дори самият софтуер, преди да е настъпила сериозна вреда, каквато и да е компрометираната RSA група (осен ако не са компрометирани всички едновременно, а този проблем трябва да се контролира физически).
Аз искам през моят клиент да може да се публикува неоторизирана информация, която да се пази от инфраструктурата (макар и да не се вижда на web-а).
За нея имам два проблема -
как да известя другите клиенти, че има нещо (ново), което е важно да изтеглят и кешират при себе си, макар и да не го публикуват на web-а
как да запазя анонимността на източника ако мога
как да не позволя на MIM патерн устройства да могат да идентифицират по патерн какво се транспортира
Срещу патерн откриването използвам peer to peer торент криптацията (obfuscation protocol). Също така е препоръчително информацията да е събрана в компресиран архив и с допълнителна криптация отгоре (за да не могат да се видят и имената на файловете в архива). В бъдеще време ще вкарам вграден архиватор/криптатор със зашумяване (добавяне на случаен и излишен префикс-суфикс към файла) в моят клиент.
За известяването на клиентите използвам вградената възможност при peer to peer комуникация да се разшири стандартният бит торент протокол (и libtorrent поддръжката му) (bittorrent extension protocol – BEP) и съм си създал свой протокол.
Съобщение с префикс Wikileaks-версия-команда (msg push)-хаш на файла, който трябва да се изтегли. Отсрещната страна потвърждава или отказва протокола, но не казва нищо за действието, което ще предприеме. Ако го откаже – значи е стандартен клиент. Ако не, значи е моят торент клиент.
Тук обаче има проблем с анонимността. Достатъчно е някой да има един клиент (поддържащ протокола) и да следи кой първи анонсира нов файл, и по IP адреса ще го успее да намери къде е в момента с всички последствия (евентуален обиск, съд и т.н.).
За да намаля риска, използвам техниката на създаване на шум чрез случайност – новият файл не се анонсира на всички пиъри а само на един от тях, избран случайно и то след случаен интервал от време (със забавяне от до 4 дни, средно 2).
Той от своя страна го анонсира на някой друг спазвайки този алгоритъм. Това изолира драматично възможността за проследяване на първоизточника на данните, защото не знаеш кой подред е бил този, който ти прави анонса и след какво време. Също така не можеш да оцениш, кой има файла, кой не, и тъй като в анонса не е записана информация предпазваща от зацикляне, не можеш да направиш обратно проследяване, ако не подслушваш поне 1/3 от всички пиъри на всичките им мрежи за достъп, което при определен обем (над 2000 пиъра) и географска дистрибуция ще бъде изключително трудно.
Тази техника позволява и добра мобилност, анонси могат да се правят от web/интернет кафета и други публични места. Хаша на ъплоадвания неоторизиран файл ще е случаен (няма да следва останалите алгоритми), следователно ще е технически невероятно проследяването на целият спектър 160 бита за да следиш за нови файлове и да ги различиш от нормалните публикувани в DHT (тоест сред шума).
Недостатъка на тази техника е липсата на loop prevention механизъм (предпазване от зацикляне) – може да се направи анонс на пиър, който вече има файла. Това обаче не е проблем заради много големите таймаути (което намалява възможността от флууд, докато броят на клиентите съставляващи инфраструктурата чрез моят специализиран софтуер е по-малка от 400000, което е едно добро число).
Недостатък, който обаче остава е факта, че времето за редистрибутиране на нов файл между всички пиъри би било равно на максимално 4 дни по (1 + 1 / 2 + 1 / 3 + 1 / 4 + .... 1 / n ) където n е броят на пиърите. Но това не е голяма драма, тъй като дори при 1000000 пиъра максималното време би било някъде около 14.4 * 4 дни = 57.6 дни, но ще е покрило 80% от пиърите за 20-25 дни и ще е обменило файловете до тогава.
Как откривам кои са пиърите, с които мога да комуникирам? Това са всички тези, които анонсират, че вече имат зареден хаша на web сървърните файлове (търся предварително познатия хаш и след това получавам пиърите за него).
Това че участниците (пиърите) могат да бъдат извлечени бързо е проблем за анонимността им. От друга страна, публикуването на информация не е престъпление. Престъпление може да бъде открадването и, но не и публикуването (което се пази от първата поправка в американската конституция и от общата свобода на словото и законите за приоритет на общественият интерес в Европа). Това е нещо, с което дори ДАНС се сблъскаха у нас (Опасните.нет), така че си е стабилно законово правило в западният свят.
Заплахи за съучастничество също не могат да бъдат проблем за използването на подобен клиент и публикуването на информация, тъй като отново – трябва съучастие в открадването на данните, а не публикуването им, и трябва умишленост на действията, което напълно освобождава от отговорност всички потребители на моят торент клиент, тъй като те нямат проявена инициатива към всяко публикуване конкретно. Общата и индиректна отговорност не съществува в такива случаи, тъй като иначе строителите на магистрали щяха да бъдат съдени задето хората извършват ПТП-та върху тях.
Моят софтуер пробва да се закачи на два локални порта (за сервирането на web-а) – 80 и 18880. Вторият порт е за защита, тъй като не всеки ще може да отвори локален 80-ти порт (ограничени за сигурност или вече съществуващ софтуер там). След това с UPnP тези портове се опитват да бъдат отворени на локалният firewall (ако сте зад домашен маршрутизатор) автоматично. Това означава, че в 80% от случаите, без да се налага да правите каквото и да е, вие ще имате достъпен от интернет сървър на wikileaks. Няма нужда да знаете какво и как да си конфигурирате на firewall-а, за това.
Как потребителите от Интернет биха използвали тази инфраструктура?
Първо тези, които имат клиента инсталиран на своят компютър могат да се закачват локално – на порт 80 или 18880. Това е най-сигурният начин – изтегляте си клиента, и изчаквате да се синхронизира, след което се закачвате локално, а и доизграждате инфраструктурата на Wikileaks.
Но не можем да очакваме всеки да инсталира клиента си локално за да достъпва Wikileaks. Трябва да можем да осигуряваме достъп и за тези, разполагащи само с web клиент.
За целта трябва да можем да насочим browser-ите към IP адрес на клиент изпълняващ в момента web сървър. Тоест трябва да имаме DNS за даден домейн (wikileaks.ch ?) и конфигурация насочваща към IP адресите.
Малък софтуер (скрипт за DNS от типа на PowerDNS) може да извлича всички сиидъри (пиъри) за Web-а от неговият хаш (по подобие на техниката, която използвам за анонсиране на съобщения). След което може да проверява бавно кой от тях има порт 80 отворен и анонсира правилно web информацията. След което проверените peers влизат в списък, на който при запитване по DNS връща IP на web сървъра. Може да се върне най-близкото IP към запитващият, по геогравски признак (разстояние между автономни системи – публична информация) или дори още по опростено да изважда от адресите този на запитващият и да връща този, който има най-малък резултат от операцията по абсолютна стойност.
Така потребителите питащи за wikileaks.org например биха получавали най-близкият до тях работещ IP адрес, ако ще да е домашно PC. Ако то умре, автоматично (в рамките на до 15 мин) ще бъде анонсиран някой друг при запитване.
Освен скорост, отказоустойчивост, тази схема не позволява лесно проследяване на web сървърите (и тяхното събаряне) освен ако не изпратиш DNS запитвания от всички мрежи където има такива сървъри (а това е невъзможно без предварителна информация).
Така направената структура би имала над средната (за сегашните технологии и атаки) устойчивост като инфраструктура и би позволила истински дистрибутиран и децентрализиран клауд (ако съответният web сървър има стандартно API, това е достатъчно за да се постигне дефиницията).
Но тясно място остава домейна на организацията, тъй като той е под централизиран контрол. DNS-а е най-слабият протокол в Интернет от гледна точка на сигурността, бутането му е лесно, а е самодостатъчно да унищожи над 90% интернета, който познаваме, но в частният случай на Wikileaks – тъй като повечето GTLD-та подлежат на контрол индиректно (все още) от MD на USA, и следователно (както видяхме с Wikileaks) домейните могат да бъдат бързо спирани, без необходимост да се доказва незаконност на дейността на сайта. Ако домейните бъдат спирани, повечето от клиентите няма да могат да се закачат към уеб сървърите, и така нейната достъпност значително се намалява.
Слабостта на DNS е оръжие в ръцете на тези, които искат да заобикалят съдебните процедури и да разчитат на авторитарен механизъм на налагане на бързо решение. Точно и за това, след дълги и реално неуспешни лобизми на RIAA в телеком пакета в EU, DMCA в US и ACTA (от която отпадна задължителното изискване ISP-тата да блокират трафик и да съдействат на контент провайдерите преди съдебно решение), и неуспешните (на глобално ниво) обиколки сред ISP-тата за да бъдат подканени „те сами да решат“ да съдействат, както и проблемите, които се оформят от новите движения за мрежова неутралност в US и EU (които индиректно посочват, че блокирания на услуги ще изискват нещо да бъде обявено предварително за незаконно, което значи наличие на съдебно решение), това мотивира RIAA да се насочи към GTLD-тата с идеята да ги кара те да премахват домайни при оплакване, без чакане на съдебно решение (безкрайно интересният случай течащ в момента с rapidshare.com).
В частният случай на моят клиент аз боря DNS проблема чрез 3 начина -
Предполагам, че Wikileaks ще работи с (наистина) независим GTLD (както те опитаха да напеавят мигрирайки към .ch домейн). Това прави изключително трудно спирането на услугата преди да тя да бъде обвинена, че извършва престъпление и то от съдебно решение (и дори тогава, то подлежи на обжалване по международните норми в Швейцария). Няма как Хилъри просто да каже „спрете домейна“ и това да стане.
Локален достъп до данните, ако си инсталираш клиента (ако нямаш достъп до някой сървър просто си инсталираш клиента и вече си имаш сървър)
Мултикаст DNS – новото развитие на DNS протокола, което на всичко отгоре се поддържа от много от съвременните операционни системи. Просто те запитват при DNS заявка и мултикаст група на порт 5353 (от там нататък всичко е същото) и много машини могат локално да отговорят кой обслужва този домейн. Моят клиент пробва да се биндне на порт 5353 за мултикаст DNS (дори ако там вече има нещо), оправя локалните hosts кешове, и ако намери bonjour (Multicast DNS услуга от Apple) я преконфигурира. Така дори да паднат международните DNS-и, локалните продължават да работят и да подават коректна информация. Стига да има по един „wikileaks“ клиент във всеки мрежов сегмент, и няма да има нужда от никакви GTLD-та, както и контрола върху информацията там. Спуфинг и флуудинг атаки не работят (ефекта им е само локален, евентуално) и системата става много по отказоустойчива, но най-вече децентрализирана и неконтролируема авторитарно
Всичко описано тук го имам направено в python базиран торен клиент и web сървър, с буквално 300-400 реда код като концепция. Това, което се каня да разработя е хубав графичен интерфейс и да го пусна като демонстрационен клиент. Той няма за цел нищо друго освен демонстрация на идеята. Избрах python тъй като има лесен порт на ползваните от мен библиотеки, програмирането е бързо и е относително преносим, както и позволява близко коопериране с операционната система. Съжалявам, но Java не ми е сила, а C++ би изисквал повече време за разработката на концепцията. Ако реша да напиша реален клиент, ще бъде на C++, но концепцията трябва да е лесна за модификация.
А самата идея е интересна. Тя позволява сериозна дистрибуция, отказоустойчивост и производителност при относително малко използвани (напълно домашни) ресурси дадени под наем от доброволци.
Една подобна инфраструктура може да поддържа множество сайтове и дори приложения (които могат да се изтеглят като python плъгини и ъпгрейди по стандартният начин описан за обмен на файлове и съобщения). При дефиниране на стандартно API и Framework тя би могла да изглежда като напълно дистрибутирана клауд услуга, без гаранция за производителност (но без никаква цена за същесъвуването си и със значително завишена отказоустойчивост при произволни удари и атаки). Отделно клъстеризация чрез MPI API и дистрибутиране на web заявки децентрализирано от един клиент на друг може да се доразработи много лесно, тъй като всеки клиент може да научи къде са му съседите, и от там нататък с минимално протоколно разширение може да знае кой как е натоварен и да служи като локален разпределител на заявки. Чрез структуриран алгоритъм (подобен на DHT) може тези заявки макар с дистрибутирано локално редиректване да получат глобално синхронизирано контролиране, и като ефект всички услуги, които една клауд инфраструктура типично предлага днес, но направени в една стъпка по напред.
Подобна инфраструктура би могла да обслужва и торент сайтове като thepiratebay или arenabg, по начин невъзможен за спиране (като инфраструктура) без значителна модификация на начина, по който службите оперират и то с много ограничен ефект.
Недостатък обаче би било практическата невъзможност за рекламна печалба (не и върху моят клиент) от съответните организации, поради трудната възможност за създаване на контент и потребитело зависими реклами (заради архитектурата и стремежа към анонимност) и следователно липсва потенциал за комерсиален интерес, освен ако не се модифицират клиентите, така че да могат да се използват и за някаква форма на дистрибуция на реклама.
При всички обстоятелства, такива системи предлагат доста голямо разширение на понятието и визията ни за това какво точно представлява една инфраструктура и как (и дали) тя може да се контролира въобще. Тази идея и демонстрира, че технологията позволява (и следователно не позволява) авторитивно налагане на мнение, разчитайки само на поддръжката на машините. Не можеш да изфилтрираш или да блокираш нещо лесно, нито да спреш на някой сървъра, задето не ти харесва. Щом има хора, които се интересуват от подобна услуга, тя ще съществува. Ако това е „неправилно и неморално“, то е редно хората да бъдат най-вече убедени в това, минимизирайки необходимостта от прилагане на сила, тъй като тя не би работила под никаква форма, когато подкрепата за „каузата“ е масова.
Saturday 28 May 2011
Блогът на Делян Делчев: Децентрализирана инфраструктура за Wikileaks
