Изграждане на блог агрегатор, предотвратяващ събиране на социограми

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Съдържание:

Добра практика за управление на агрегатора

1. Увод

Прочита на съдържанието на блогове или други подобни ресурси (напр. форуми), се улеснява изключително много от наличието в тях на RSS емисии или Atom. Това са стандартни методи за синтезирано извличане на съдържание и уведомяване на читателите за прибавянето на ново. Всеки блог има тематика, а контролът над съдържанието му е твърде труден, а понякога и невъзможен, доколкото най-често той домува на място с чужда юрисдикция. С нарастване на влиянието на блогосферата, се засилва и стремежа на някои заинтересовани кръгове да следят не само издателите на блогове, но и техните читатели. Това особено важи за блогове с екологично и политическо съдържание. Следенето се улеснява неимоверно много на база на наредби за събиране на трафични данни. Ако събраните данни бъдат анализирани, за всеки един потребител може да се получи социограма, чрез която да се определи политическата му ориентация, дали подкрепя екологичните и антиправителствени протести и др. В едно достатъчно недемократично общество тази информация може да се използва срещу гражданите. Именно затова следва да бъдат разработени и реализирани технологии, които да им помагат безопасно да четат информация от блогове и подобни ресурси, без при това да се излагат на опасност от преследване заради тяхната политическа принадлежност, екологично мислене, желание за протест и др.

Как се съставя социограма на основата на четене на блогове? Много често хората си мислят за социограмата като за дървовидна структура, свързваща ги на различни структурни нива с техни близки, познати, приятели и т.н. На практика социограмата е обект с по-широко съдържание. Тя може да включва и политическата принадлежност на гражданина, интересите му към определен род информация и т.н. Такава социограма се прави най-лесно на основата на трафични данни и тук ще бъде показано принципно как става това, за частния случай на HTTP достъпа. Ако трафичните данни за активността по протокола HTTP бъдат съхранявани, то в тях се съдържа не само името на сървъра, който потребителя достъпва, но и името на достъпвания ресурс на самия сървър. Например:

Ако даден ресурс има рейтинг в шаблона за изграждане на социограмата, който го определя като блог с определена политическа ориентация, то е вероятно читателя му да я споделя. Ако той чете още поне 2 блога с подобна насоченост, вече може да се каже с голяма вероятност каква политическа ориентация има. При това на основа на достъпвания ресурс може да се провери какво съдържание е достъпвано, без да се налага то да влиза в състава на събираните трафични данни - просто при анализа записания URL се достъпва с обикновен браузър.

Доколкото RSS емисията е част от съдържанието на даден блог, то описанието на изтеглянето й в трафичните данни, служи на анализа по същия начин, по който и информацията за директния достъп чрез браузър. Например, изтеглянето на RSS емисията на даден блог, може да е описано в трафичните данни като достъп до URL

Следователно от особена важност за препятстване на събирането на информация за посещаемостта на блогове по трафични данни, е да се скрие URL информацията или ако не може да бъде скрита, да се предлага на един адрес заедно с огромен брой друга разнородна информация, от анализа на която не може да се каже нищо конкретно за конкретните й читатели (например агрегиране на несъвместими по своите политически възгледи блогове).

Дори в трафичните данни да не се описват HTTP URL стойности, то ако даден блог или подобен ресурс използват самостоятелен IP адрес, несподелен с други подобни ресурси, идентификацията на IP адреса на сървъра е достатъчна за да се определи какво точно посещава дадения потребител.

Всъщност не само проблема с трафичните данни е този, който агрегатора с предложената по-долу конструкция трябва да преодолее. Никой не може да гарантира, че данни за активността на един или друг потребител не се събират от журналните файлове на уеб сървърите, които обслужват блог приложенията. Съществуват множество фирмени блогове, които използват какви ли не тактики за проучването на потребителите си и заливането им след това с нежелани оферти, "префенциални" цени или откровено изнудване. Ето една проста схема - потребител се регистрира в електронен магазин. IP адреса му в почти всички случаи се описва в някаква база от данни. След това потребителя преглежда фирмения блог, блог на работещ в същата фирма или просто агрегатора на форум, в който се обсъждат продуктите на фирмата. Съвсем лесно е на база на IP адреса посетил блога, да се претърси базата от данни на електронния магазин, да се идентифицира потребителя и според разглежданата тематиката в блога, да се генерира съответния целенасочен SPAM и т.н.

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

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

2. Добра практика за управление на агрегатора

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

3. Принципна схема на агрегатора

Съществуват много и различни по конструкцията си публични уеб достъпни агрегатори, но за нуждите на анонимизиране на потребителите, те следва да имат малко или повече особена конструкция.

Всеки блог или друг ресурс, който ще бъде достъпван през агрегатора, следва да включва в своята RSS емисия пълното съдържание на документите. Безполезно за целите на решението е агрегирането на блогове или други ресурси в Мрежата, които предоставят само резюме или част от съдържанието в RSS емисията си, с последваща препратка към самия ресурс. Подобно частично публикуване не може да предотврати съставянето на социограма за читателите на даден ресурс, защото те следва да достъпят пълното съдържание директно и този достъп може да бъде отчетен по генерираните за целта трафични данни.

В подобни агрегатори следва да се агрегира само такова съдържание, което е с ясен лиценз за разпространение и употреба и позволява свободата на разпространение през подобни системи (напр. "Creative Commons" лиценз). Това не е проблем, доколкото повечето социално и технически значими блогове предоставят съдържанието си за разпространение и употреба под свободни и отворени лицензи. Въпреки това оператора на агрегатора следва внимателно да проверява всяка включена за агрегиране RSS емисия, относно нейния лиценз за разпространение и употреба. Възможно е работата на агрегатора да бъде препятствана и дори прекратена по съдебен път, чрез включване на лицензни и патентни "тролове" в съдържанието на някои блогове или други ресурси. Поради именно тази причина е наложителна постоянна и задължителна лицензна проверка на агрегираното съдържание.

Сървърът, на който ще се функционира агрегатора, следва да предлага достъп на съдържание по HTTPS. Болшинството хостинг услуги (дори споделени такива), предоставят подобна възможност. От изключителна важност е да не може да бъде записано съдържанието на сесиите между клиента и сървъра, от трета страна в пакетния обмен. Това става чрез задължително преминаване към HTTPS сесийност, т.е. дори клиента да иницира сесия по HTTP, сървъра да я пренасочи към HTTPS (напр. може да се използва mod_rewrite за Apache).

Въпреки наличието на HTTPS и следващата от това защитена комуникация, все пак трафичните данни дават информация за това кой е клиента и кой е сървъра (като IP адреси, протоколи, портове, обем и продължителност на сесията). Следователно на пръв поглед изглежда така, все едно няма как дори с HTTPS да се избяга от съставянето на социограма. Всъщност начин има и той е много прост. Той се основава на това, че след като сесията е защитена от подслушване, няма как да се разкрие URL-а в HTTP заявката за достъп до ресурса. Т.е. няма как на база на подслушване на криптирания трафик от една HTTPS сесия да се определи точно какъв ресурс се посещава върху сървъра с даден IP адрес. За да се илюстрира това, ето два примерни URL записа за завяки от страна на браузъра на клиент към HTTPS базиран сървър, предлагащ съдържание:

(реално поради особеностите на SSL, сървъра ще получи завките като /resource_1/ и /resource_100/).

Ако тези две HTTPS заявки бъдат анализирани от софтуера за построяване на социограми, последния няма да може да определи ресурса, който ще се достъпва на сървъра. Трябва да се отбележи обаче, че доколкото поради особеност на SSL най-често един X.509 сертификат удостоверява едно сървърско име, всички ресурси трябва да имат URL включващ името на хоста, за който е издаден сертификата!

Следователно важна част от дейността по препятстване на съставянето на социограми относно прочита на блогове и др. ресурси, е "маскирането" на агрегратора сред другите предоставяни ресурси на сървъра така, че достъпа до него да не може да бъде ясно определен. Това означава обаче агрегатора да се маскира там, където има голямо потребление на HTTPS базирани ресурси, за да не може да бъде отличен еднозначно трафика между отделните услуги. Едно сполучливо решение е агрегатора да се маскира зад интензивно използвано уеб решение за поща, базирано на HTTPS. Например:

По този начин наблюдаващата трафичните данни система за съставяне на социограми няма как да определи дали даден потребител достъпва уеб базираното решение или електронната си поща (поне не и лесно и еднозначно). Но дори и да определи, няма как да провери какво точно съдържание е чел потребителя. Оттук следва, че потребителите на всеки уеб базиран пощенски сървър, предоставящ достъп през HTTPS, могат да получат като допълнителна услуга достъп до блог агрегатор.

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

Благодаря на Николай Ангелов за бързата и качествена редакция на текста.