Jak utrudnić kopiowanie tekstu ze strony cz. 3 – dokończenie

Autor: Paweł Rajewski

Kolejne utrudnienia dla kradnących treści ze stron WWW – tym razem nieco bardziej egzotyczne. Na podstawie uwag zgłoszonych po poprzedniej części artykułu o zabezpieczaniu tekstu w serwisie, wysłano do mnie kilka ciekawych komentarzy. Na początek parę zdań polemiki.

Czy tylko amatorzy stosują zabezpieczenia? Jeden z czytelników zasugerował, że w HTML nie tworzy się nic, co warte by było zabezpieczania, a teksty próbują chronić jedynie amatorzy. Ja sądzę, że kwestia jest bardziej złożona. HTML to nie tylko serwisy i strony www. To także niskonakładowe, niszowe publikacje na CD czy dostępne e-mailem w formie subskrypcji – raczej specjalistyczne i nie przewidziane do masowej dystrybucji. Również w ogólnodostępnej Sieci mogą znaleźć się materiały, których darmowe rozprzestrzenianie chcielibyśmy ograniczyć. Praca dyplomowa, referat, artykuł, opis pracy badawczej – można nie zgadzać się, by były bezpłatnie i bez naszej wiedzy wykorzystywane. Utrudniając kopiowanie można równocześnie zachęcać zainteresowanych do kontaktu i otrzymania oryginału – co zapewni przynajmniej minimalny stopień kontroli nad wykorzystaniem własnej pracy. Wydaje się więc, że jest odwrotnie niż sugerował czytelnik, i potrzeba stosowania zabezpieczeń wzrasta w miarę oddalania się od tematyki typowo amatorskiej.

Czy zabezpieczenia mają sens gdy można je złamać? Część czytelników uważa, że względna łatwość pokonania dyskwalifikuje zabezpieczenie. Jest w tym trochę racji – nie ma stuprocentowo pewnej metody uniemożliwiającej przeniesienie tekstu z serwisu do innego programu. Dlatego nazywam te sposoby metodami utrudniającymi, a nie uniemożliwiającymi kopiowanie. Krytycy nie dostrzegają przy tym, że stuprocentowe zabezpieczenie wcale nie jest konieczne. Każdy tekst wyświetlany na monitorze można przecież przepisać i przed tym nie sposób się obronić. Rolą zabezpieczenia jest więc „związanie sił przeciwnika” na czas dłuższy niż wymagałoby tego – powiedzmy – dwukrotne przepisanie materiału. I tylko tyle.

Warto też zauważyć, że stosowanie zabezpieczeń, choćby i mało skutecznych, w połączeniu ze znakiem Copyright, jest oczywistym sygnałem. Widocznie autor nie życzy sobie kopiowania bez swojej wiedzy. Wolę autora można uszanować, albo złamać. Zamknięte drzwi można wyważyć, albo zapukać. Wybór świadczy o czytelniku.

Czy te zabezpieczenia naprawdę łatwo złamać? Przedstawione – tak. Prezentowane przykłady to same idee, jakby fundament dla własnych pomysłów. Nie podaję skryptów finalnych, po części z tzw. oczywistych powodów, a po części dlatego, że mogą być one naprawdę bardzo różne (pomysły też ewoluują…). Dość powiedzieć, że szukając w kodzie strony prezentowanych zapisów, nie powinno się ich tam znaleźć. Pominąłem również kwestie przenoszenia plików – takiego ich konstruowania, aby „nie chciały działać” po wyjęciu z serwisu np. po typowym zapisaniu na dysk z poziomu przeglądarki. Można wymyślać różne śmieszne pułapki, których głównym atutem jest zaskoczenie. Jeśli więc przedstawione przykłady możesz łatwo „rozbroić”, nie znaczy to jeszcze, że równie szybko pokonasz bardziej skomplikowane konstrukcje oparte o prezentowane zasady. Można to zrobić, lecz wymagać to będzie analizy, którą, rzecz jasna, autor skryptu maksymalnie utrudni. Pytanie, czy taka analiza się opłaci, gdy tekst można niedrogo kupić lub wręcz otrzymać od autora.

Co z innymi przeglądarkami? Wadą prezentowanych pomysłów jest ich opracowanie „pod” Internet Explorera. Artykuł to proste przykłady oparte na moich potrzebach (serwis pracujący off-line dostosowany właśnie do MSIE). Starałem się wybrać te metody, które mają przynajmniej szansę zadziałać w przeglądarkach innych niż Microsoftu. Pominąłem np. sposoby dostępne wyłącznie w Internet Explorerze pracującym off-line. Nie podejmuję się przedstawienia metod „uniwersalnych”, ale może przedstawione rozwiązania nasuną komuś własne pomysły..?

Bawmy się! Niezależnie od możliwych zastosowań praktycznych, wymyślanie zabezpieczeń to świetna szkoła i zabawa, do której wszystkich zachęcam. Opracowując te łamigłówki chronicie swoją pracę i prawa autorskie (o ile uważacie je za istotne w danym przypadku), propagujecie uczciwość w Sieci, a jednocześnie odkrywacie ile ciekawych rzeczy można zdziałać kilkoma prostymi instrukcjami. I w ten sposób warto odbierać prezentowane przykłady – jako ciekawe wyzwania i inspirację do własnych poszukiwań.

Kopiowanie przez schowek

W jednym z komentarzy zasugerowano możliwość skopiowania tekstu jako grafiki, poprzez schowek, klawiszem Print Screen, a następnie odczytania takiego obrazka programem OCR. Pojawia się pytanie, ile osób używa programów OCR na tyle często, by umieć się nimi wprawnie posłużyć (śmiem twierdzić, że jednak niewiele). Ale faktycznie, gdy zabezpieczony tekst jest krótki i w miarę prosto złożony, to dość efektywna metoda kopiowania, na pewno szybsza niż przepisywanie ręczne czy analiza kodu strony.

Początkowo myślałem, że to sposób nie do utrudnienia – klawisz Print Screen „należy” do systemu operacyjnego i nie można wykryć jego naciśnięcia z poziomu Internet Explorera (przynajmniej nic o takich sposobach nie słyszałem). Nie można więc zablokować Print Screen, czy w jakiś inny sposób anulować wykonywanej nim operacji. A jednak…

Od wersji 5 (a w ograniczonym zakresie od 4) Internet Explorer potrafi korzystać ze schowka. Można kopiować, wklejać i – co w tym przypadku najważniejsze – kasować zawartość schowka. Nie można zabronić użytkownikowi skopiowania obrazu ekranu, ale można wyczyścić schowek zanim zdąży on z tego obrazu skorzystać. W efekcie utrudnimy i tę, dość egzotyczną, metodę kradzieży.

Do skasowania schowka można użyć wywołanej skryptem komendy „kopiuj”, albo prościej – obiektu clipboardData wraz z metodą clearData(). Polecenie window.clipboardData.clearData() całkowicie oczyści schowek. Zostaną usunięte wszystkie dane, niezależnie od ich rodzaju (można czyścić schowek selektywnie, ale w tym przypadku nie jest to konieczne).

Niestety, nie znam zdarzeń sygnalizujących zmianę zawartości schowka, a tym samym wskazujących na konieczność jego wyczyszczenia. Można przeprowadzać tę czynność co określony czas (np. co 5 sek.), ale nie jest to rozwiązanie eleganckie, poza tym uniemożliwi korzystanie ze schowka innym programom pracującym w tle, a w pewnych sytuacjach może też utrudnić korzystanie ze strony. Proponowałbym więc skorzystanie ze zdarzenia onblur umieszczonego w ramach znacznika BODY. Zdarzenie będzie wywoływane przy usuwaniu fokusu z obiektu BODY – przenoszeniu go do innych obiektów umieszczonych na stronie, oraz – co jest dla nas najważniejsze – przy opuszczaniu całej strony. Schowek będzie więc kasowany przy przełączaniu się do innego programu (okna) co jest niezbędne, by wkleić tam skopiowaną zawartość. Po przełączeniu i próbie wklejenia okaże się, że schowek jest pusty…

<BODY onblur="window.clipboardData.clearData();"> 

Ponieważ schowek czyszczony jest m.in. w momencie „wychodzenia” z okna Explorera, nasuwa się proste rozwiązanie: skopiować zawartość ekranu w momencie, gdy okno Explorera jest nieaktywne, i natychmiast przejść do okna docelowego. W takiej sytuacji obraz ze schowka nie zostanie usunięty. Oczywiście, ten pomysł przyjdzie do głowy komuś, kto wie już co dana strona „wyrabia” ze schowkiem. Przeciętny użytkownik raczej na to nie wpadnie, i zrezygnuje po kilku próbach przekonany, że obraz po prostu „nie kopiuje się” z nieznanego powodu. Załóżmy jednak, że chcemy zamknąć i tę furtkę. Co można poradzić?

Rozwiązania są dość skomplikowane, choć ich zasada jest prosta. Trzeba w taki sposób zbudować stronę, aby chroniony tekst był wyświetlany tylko wtedy, gdy okno przeglądarki jest aktywne. Przy nieaktywnym oknie chroniony tekst nie będzie widoczny, a więc nie da się go skopiować. Można to zrobić np. tak:

<BODY onblur="window.document.all('tajne').style.visibility='hidden'; 
window.clipboardData.clearData();" 
onfocus="window.document.all('tajne').style.visibility='visible';"> 
<DIV ID="tajne">Chroniony tekst</DIV> 
</BODY> 

Zawartość kontenera DIV o nazwie „tajne” będzie wyświetlana tylko w aktywnym oknie. Gdy okno nie będzie aktywne, tekst nie będzie widoczny. (To uproszczony przykład nie uwzględniający kilku sytuacji szczególnych. W praktyce trzeba rozpatrzyć zachowanie się strony w różnych sytuacjach – np. działanie na niej formularzy czy innych obiektów wymagających fokusu, zdejmowanie fokusu z BODY klikaniem np. na obrazki, a także sposób przywracania strony po aktywacji okna).

Złośliwym uzupełnieniem tej metody może być przewijanie strony przy każdym jej ukrywaniu (lub przywracaniu) do określonego miejsca – np. do końca lub początku. To bardzo utrudni ręczne przepisywanie tekstu do edytora otworzonego w osobnym oknie (a taką metodę kradzieży zasugerował żartem jeden z czytelników). Nie dość, że pisząc nie widzimy strony i co chwilę musimy przełączać się między oknami, to jeszcze po każdym przełączeniu miejsce, które przepisywaliśmy, ucieka nam gdzieś w siną dal. W tym celu wystarczy uzupełnić zdarzenie onblur w znaczniku BODY o zapis: window.scrollTo(0,0); a strona za każdym razem będzie przewijana do początku. Warto tę metodę stosować, gdy chcemy zdenerwować i już na zawsze pozbyć się czytelnika!

Malkontenci skrzywią się, że czyszczenie schowka nie zadziała w przeglądarkach innych niż Internet Explorer (prawdopodobnie), a nawet w starszych Explorerach (choć tam można spróbować skorzystać z polecenia „kopiuj” aby zamazać zawartość schowka). Ingerencja przeglądarki w schowek jest też z założenia nietrudna do pokonania. Nie będę pisał jak to zrobić, powiem tylko, że dość łatwo jest obejść to zabezpieczenie gdy strona jest ściągana z Sieci, nieco trudniej, gdy jest zapisana na dysku lokalnym. Mimo to przeciętny użytkownik MSIE poczuje się zdezorientowany próbując kopiowania niezawodnym dotychczas klawiszem Print Screen – a przecież właśnie o zaskoczenie tu chodzi.

Drukowanie

Zastanawiałem się, czy utrudnianie drukowania ma sens. Drukowanie to forma przepisywania (a to zawsze będzie możliwe), a tekst na papierze i tak wymaga kolejnego przepisania, aby mógł być wykorzystany w jakiejś pracy. No, chyba, że skorzystamy ze skanera i programu OCR… A zatem utrudniamy wydruk.

Pierwsza metoda jest banalnie prosta – wielu twórców stron stosuje ją nawet o tym nie wiedząc. To odpowiedni układ strony. Gdy stosujemy rozmiary w jednostkach bezwzględnych (w pikselach), nietrudno jest dobrać taki układ elementów strony (ramek, szpalt, grafiki), aby Internet Explorer nie poradził sobie z właściwym rozłożeniem tekstu na typowej kartce A4 (piszę o wersji 5.5, być może wersja 6 jest pod tym względem poprawiona). Taka sytuacja, zupełnie przypadkowo, zachodzi w niektórych moich archiwach – wydruk całego artykułu jest praktycznie niemożliwy, a układ tekstu po wydrukowaniu bardzo odbiega od tego, co widać na ekranie… Czasami takie utrudnienie w zupełności wystarczy.

Drugi sposób, to wykorzystanie zdarzeń onbeforeprint i onafterprint. Pierwsze wywoływane jest tuż przed drukiem lub podglądem wydruku, drugie – po wydrukowaniu lub po podglądzie. Pierwsze może posłużyć do uruchomienia skryptu dostosowującego stronę do wydruku, drugie – skryptu przywracającego poprzedni wygląd strony po jej wydrukowaniu. W naszym przypadku mogą one posłużyć do „wyłączenia” strony, tak aby wydrukowana została jedynie pusta kartka… Można też poinformować użytkownika dlaczego wydruk nie działa (oszczędzając mu papier i nerwy) – w poniższym przykładzie dodałem stosowny komunikat:

<BODY onbeforeprint="window.document.body.style.visibility='hidden'; 
window.alert('Tekst chroniony prawem autorskim. Kopiowanie wymaga uzyskania zgody autora');" onafterprint="window.document.body.style.visibility='visible';"> 

To najprostszy przykład korzystający z okienka alert() do przekazania komunikatu. Atrakcyjniej byłoby wydrukować komunikat na kartce. Można to zrobić ukrywając przed wydrukiem zawartość strony (nie cały obiekt BODY, lecz np. tabelę, w której zawarta jest treść strony), a wyświetlając normalnie ukryty kontener DIV z odpowiednim komunikatem. Po wydruku przywracamy poprzedni wygląd strony.

Edukacja

Na koniec pomysły nie tyle utrudniające kopiowanie, co edukujące czytelnika. Po zlekceważeniu dwukrotnych ostrzeżeń (po próbach kopiowania) otwiera się okienko modalne ze stosownymi przepisami (prawo autorskie, regulamin strony). Po każdej próbie zamknięcia okienka skrypt wywołuje je ponownie. Z takiej pętli naprawdę trudno powrócić do serwisu:

<SCRIPT TYPE="text/Jscript" LANGUAGE="JScript"> 
function fnLekcja() 
{ for(i=0;i<10;i++) 
  { MD=window.showModalDialog('przepis.html'); 
  }; 
}; 
</SCRIPT> 

W tym przykładzie okienko z zawartością 'przepis.html’ będzie wyświetlane dziesięć razy. Można kontrolować wartość zwracaną po zamknięciu okna urządzając niegrzecznemu czytelnikowi coś w rodzaju „klasówki” (nie zamknie okna, dopóki nie odpowie poprawnie na pytanie związane z wyświetlanym regulaminem).

Drugi, podobny pomysł „nie całkiem serio”, to otwarcie okienka modalnego (w tym przypadku wystarczy nawet zwykłe window.prompt()), w którym trzeba wpisać (bez błędów!) określony tekst. Np.:

<SCRIPT TYPE="text/Jscript" LANGUAGE="JScript"> 
function fnOstrzegam() 
inf='Kto bez uprawnienia zwielokrotnia cudzy utwór, podlega karze pozbawienia 
wolności do lat 2. Potwierdzam, że jestem tego świadomy'; 
{ do 
  { wynik=window.prompt('Napisz: '+inf,''); 
  } 
  while (wynik!=inf); 
}; 
</SCRIPT> 

…a teraz czytelniku, gdy już wiesz co robisz – kopiuj… (Dodajmy, że sąd może orzec przepadek przedmiotów służących do popełnienia przestępstwa – ale to nie mieści się już w okienku).

Wyświetlanie podobnych okienek nie zabezpiecza przed kopiowaniem, ale odbiera amatorowi cudzych tekstów argument, że działał nieświadomie. Pewną odmianą tego rozwiązania może być skrypt zdejmujący zabezpieczenia po podaniu hasła dostępnego jedynie legalnym użytkownikom. Z kolei hasło może zostać uzależnione od daty lub adresu pliku (po skopiowaniu pliku przestanie funkcjonować) itd. itp…

Na koniec warto przypomnieć, że każde utrudnienie wbudowane w stronę frustruje czytelnika i zniechęca go do ponownego odwiedzenia serwisu. Z drugiej strony, umożliwienie kopiowania bez ograniczeń sprawi, że szybko stracimy efekty swojej pracy „rozkradzione” przez osoby, które chciałyby bez wysiłku (a czasem opłaty) skorzystać z cudzej wiedzy. Wszystko zależy od charakteru, tematyki i celu dokumentu. Każdy musi sam znaleźć złoty środek i rozwiązania odpowiadające własnym oczekiwaniom i potrzebom.

Paweł Rajewski