Готових систем для захисту інформації на сайтах досить багато, але всі вони дуже сирі, ненадійні, погано сумісні з браузерами відмінними від 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 взагалі не говорити не прходится. Тестувати не тільки весь зоопарк наявних браузерів, але і різні версії кожного браузера. Це вимагає створення тестової лабораторії і істотних витрат. Так що питання: захищати чи не захищати залишається відкритим.