Защита Контента От Кражи

Готовых систем для защиты информации на сайтах достаточно много, но все они слишком сырые, ненадежные, плохо совместимые с браузерами отличными от Internet Explorer и, как следствие, не бесплатные. В этой статье я расскажу как надо и как не надо защищать контент от кражи. Сложность защиты контента (под которым мы будем понимать всю совокупность текстового и графического содержимого вместе с особенностями оформления сайта довольно антагонистична по своей природе: с одной стороны мы стремимся передать информацию посетителю, а с другой — очень сильно не хотим, чтобы он получил эту информацию в любом виде, пригодном для дальнейшего осмысления и обработки. Современные сайты далеко ушли от своих родителей и, собственно, самого HTML- кода в них практически не осталось. Сейчас в основном затраты идут на составление и разработку графического дизайна, проектирование PHP "движка" или покупку готового движка для сайта. Ну и, наконец, наполнение сайта живым содержимым — текстами статей, фотографиями и прочим. Дизайн — единственное, что нельзя защитить. Потому что расположение графических элементов и организация доступа к ним — это задумка в чистом виде, выпадающая из поля зрения авторского и патентного прав. Но вот графические элементы, представляющие дизайн, защитить можно хоть и сложно. PHP-движок в защите не нуждается, поскольку правильно настроенный сервер никогда не отдает программные модули, а всего лишь возвращает результат их работы, представляющий собой WEB-страничку, сгенерированную "на лету", благодаря чему потребность в защите самого HTML-кода практически полностью отсутствует. Чисто теоретически, WEB-мастер может запрограммировать скажем Java-скрипт, внедряемый в страницу в "чистом виде", однако, что мешает ему реализовать весь "стратегический" код на серверной стороне? Конечно, какая-то часть кода неизбежно должна присутствовать и на стороне клиента, для обеспечения надлежащего уровня интерактивности (разные выпадающие меню, всплывающие подсказки и прочее), но все это уже давно написано и претендовать на уникальность в этой "отрасли" по крайней мере довольно странно, а по большей — отдает явным пионерством. В настоящей защите нуждается не дизайн и не PHP/Java-код, а именно само содержимое блога, во всей его текстовой и графической совокупности, ведь посещаемость (в долговременной перспективе) определяется именно качеством наполнения блога, неприкосновенности которого угрожает: а) сохранение HTML кода на диск; в) копирование фрагментов текста в буфер обмена; г) сохранение изображений правой кнопкой мыши; Бороться с грабежом контента традиционными средствами совершенно бесполезно. Можно например отображать текстовое содержимое в графическом виде? Хорошая идея, совсем не так уж и безумна, какой кажется сначала. Ведь преобразование текста в графику не обязательно осуществлять на стороне сервера. Это можно поручить и Java скрипту (или ActiveX модулю, который находится в IE). На сервере мы имеем PHP-модуль, шифрующий текст и передающий его на сторону клиента. Браузер клиента отправляет его Java-скрипту/ActiveX модулю и тот в конечном виде выводит его на экран. Для чтения разрешения вполне достаточно, а вот для OCR уже маловато, да и кому придет в голову пропускать web-страницы через OCR одну за другой? Конечно, назвать это "защитой" можно только с огромной натяжкой, поскольку вместе с зашифрованным текстом клиенту передается и сам ключ, следовательно, разобравшись в алгоритме шифрования (изучив код Java-скрипта), хакер без труда напишет программу, расшифровывающую текст, но не преобразовывающего его в графику. Все это именно так но хакеров среди обычных пользователей не так уж и много и далеко не у каждого из них есть желание копаться в Java-скрипте только затем, чтобы сохранить "первородный" текст. К тому же, подобная защитная методика "нейтрализует" различия между браузерами, поскольку разметкой страницы занимается совсем не бразуер, а наш скрипт! Браузер просто отображает графическую картинку. Прокрутка, изменение размера шрифтов, цвета фона так же обеспечивается непосредственно уже самим скриптом. Естественно, на медленных компьютерах такой скрипт будет очень сильно тормозить и по сложности своего исполнения он вплотную приближается к самому браузеру или… к Adobe c ее PDF, в последние версии которого добавлена возможность эффективной работы по сети со всеми прелестями атрибутов запрета — невозможность выделения текста/печати, запрет сохранения себе на диск и т. д. Зачем же изобретать велосипед, когда можно купить готовый?! Но увы, готовый страдает целым рядом врожденных пороков. Как и любая серийная защита, Adobe взломан еще много лет тому назад и никакие ухищрения не позволят ему противостоять армии хакеров уже хотя бы в силу того факта, что хакеров много, а он — один единственный. Напротив, ковырять Java-скрипт, созданный на "коленках" web-дизайнером Васей скорее всего никто не будет. К тому же, реализовывать полноценный rendering-engine в скрипте совершенно необязательно. Достаточно ограничиться одним лишь текстом. Для усложнения взлом можно преобразовывать в графику некоторое количество символов еще на сервере (например, 6% или 9%, чтобы не сильно затормозят время загрузки страницы), тогда без OCR'а уже не обойтись. Потребность в охране контента стоит уже давно, но адекватных методик по защите до сих пор предложено не было. И дело тут совсем не в открытости формата HTML. Защищать пытаются и eBook'и, и аудио/видео контент, но все с тем же неуспехом. Если цифровое содержимое можно просмотреть , то, очевидно, его можно и скопировать! Единственная надежда — на аппаратную защиту, вживленную непосредственно в аппаратную часть, но «железная защита» наших дней сводится все к той же программе, упрятанной в микропрограммную прошивку (которую можно перешить), да и уровень технического развития уже позволяет создавать копирующие устройства самостоятельно. Кстати, некоторые стеганографические алгоритмы (и утилиты их реализующие) переживают различные трансформации изображения и даже полиграфическую печать (естественно, не отечественного качества). С другой стороны, практически все современные печатающие устройства оснащены специальными видами защиты от несанкционированного тиражирования банкнот и других ценных бумаг. Хакеры давно разгадали алгоритм по которому принтер отличает банкноту от всего остального. Не вдаваясь в технические подробности достаточно отметить, что там используется многоуровневая защита, в том числе основанная и на практически неразличимых (глазу) малоконтрастных окружностей и желтых точках на светлом фоне. В сети имеется множество различных утилит, позволяющих обходить данную защиту, просто вырезания эти метки из изображения, но их можно применять и в мирных целях — вносить в свою фотографию эти метки, после чего никакой принтер не станет их печатать! К сожалению, в силу своей изначальной криминальной ориентации данные утилиты постоянно меняют адреса и дать постоянный URL невозможно. Остается только воспользоваться google и поискать. Прежде чем вкладывать средства, время в защиту web-контента следует хорошо подумать: какие убытки это принесет и не превысят ли они "упущенную выгоду" от плагиаторов и пиратов. Практически все защиты, упомянутые в статье, базируется на Java- скриптах, а это значит, что мы теряем пользователей, отключающих яву по соображениям безопасности, а так же всех тех, кто пользуется браузерами в которых Jav'ы не было еще с рождения (к таким браузерам, в частности, относится например Lynx). Про несовместимость различных реализаций Java вообще не говорить не прходится. Тестировать не только весь зоопарк имеющихся браузеров, но и различные версии каждого браузера. Это требует создания тестовой лаборатории и существенных расходов. Так что вопрос: защищать или не защищать остается открытым.