19
HTML5, a zabezpieczenia obrazków przed kopiowaniem
Wszystko co wyświetlane jest po stronie klienta jest w praktyce niemożliwe do zabezpieczenia przed kopiowaniem. Jedynym sposobem jest utrudnienie kopiowania, tak, aby dla przeciętnego Kowalskiego było ono zbyt trudne do osiągnięcia, a dla robotów przeczesujących Sieć – nieopłacalne (ze względu na czasochłonność wydobycia odpowiednich danych).
Poniżej prezentuję garstkę lekkich przemyśleń jak można taki efekt osiągnąć (działa tylko dla małych obrazków, wymiary 256×256 zajmują jeszcze znośny czas generowania).
W skrócie, co chcemy osiągnąć: zablokowania możliwości skopiowania metodą zapisz jako/PrintScreen/podania bezpośredniego linka do obrazka.
Do napisania tego wpisu zachęcił mnie post na forum UW-team, a konkretniej zdanie „niestety, na zrobienie screena nie ma rady”. Szanse, że uda nam się zablokować klawisz PrintScreen są rzeczywiście marne. O tym, że przeglądarki nie mają do niego dostępu możemy przekonać się używając chociażby metody onKeyPress, która na ten klawisz nie reaguje. Spróbujmy więc zapomnieć na chwilę o PrintScreen i zajmijmy się efektem, który on generuje. Otóż wrzuca on do systemowego schowka zrzut ekranu. Co, gdyby nasza strona, która chcemy zabezpieczyć czyściła/nadpisywała schowek? To już jest jak najbardziej osiągalne. Można wspomóc się obiektami typu Flash, lub skorzystać z jednej z najpopularniejszych do tego bibliotek Zero Clipboard (w tym przypadku, jedno drugiego nie wyklucza ;> ) – lub zrobić to jeszcze na wiele innych sposobów.
Swój malutki PoC opieram na przeglądarce Firefox, stąd (i jeszcze kilku innych powodów, wśród których jest „jeszcze nigdy tego nie robiłem i chcę zobaczyć jak to działa”) wybrałem zabawę z XUL. Pomogłem sobie tym (osoby, które chciałyby trochę bardziej zagłębić się w ten kawałek kodu, który jest jedynie przykładowym dodatkiem mogę przeczytać jeszcze to).
Metoda ta jest dość inwazyjna, bo wymaga, aby signed.applets.codebase_principal_support
był ustawiony na wartość true. Możemy zrobić to wpisując w pasek adresu about:config, następnie znajdujemy signed.applets.codebase_principal_support
i zmieniamy mu wartość.
OK, załóżmy, że mamy już funkcję, która będzie czyściła nasz schowek. Tylko gdzie ją wywołać? Ja proponuję takie działanie:
Tworzymy dwie warstwy (jedna na drugiej – pomoże nam w tym z-index). Kiedy myszka opuści okno przeglądarki, jedna z warstw zasłoni zawartość okna, wywołując przy tym funkcję czyszczącą schowek. Zasłanianie okna jest potrzebne tylko po to, żeby zapobiec sytuacji, w której okno przeglądarki nie jest aktywne (wtedy nasz skrypt zerujący schowek nie wykona się), a użytkownik wciśnie klawisz PrintScreen. W moim kodzie używam onmouseover = „this.style.zIndex=’0′;
Można powiedzieć, że zabezpieczenie przed PrintScreen’em już mamy – jest jednak jedno „ale”. Nawet przeciętny zjadacz chleba wie, że wystarczy wyłączyć obsługę JavaScript, żeby ominąć nasze pseudo-zabezpieczenie. I właśnie w tym miejscu czas na HTML5, a konkretniej na <canvas>! Jeśli zabezpieczenia są zależne od JS, to zróbmy również, aby wyświetlanie obrazka było od niego zależne. Pomysł jest następujący. Administrator trzyma wszystkie pliki graficzne, które chce zabezpieczyć w jakimś folderze. Oczywiście, nikomu nie zdradza ścieżki do tego folderu. Za wyświetlanie obrazków będzie odpowiadał jeden plik PHP, który przed wyświetleniem sprawdzać będzie, czy dany użytkownik ma prawo do wyświetlenia danej grafiki:
if ( checkPermission($user) ) { $canvas = imagecreatetruecolor(200, 200); $color = imagecolorallocate($canvas, 130, 130, 30); imagerectangle($canvas, 100, 100, 75, 150, $color); header('Content-Type: image/jpeg'); imagejpeg($canvas); imagedestroy($canvas); } |
Rozwiązaliśmy właśnie problem kopiowania adresu URL. Bo nawet gdyby użytkownik posiadał link do pliku PHP, to i tak skrypt wyświetliłby obrazek tylko dla uprawninej grupy userów. OK, wróćmy teraz do <canvas>. Skrypt PHP będzie parsował obrazek z tajnego folderu, a następnie wyświetlał go na html-owym płótnie. Używam tu funkcji imagecolorat(), która pobiera kolor piksela na danej pozycji. Mając już odpowiednie dane możemy teraz zapisać je na płótnie. Sposobów jest kilka, ja robię to za pomocą rysowania małego (1×1) prostokąta:
ctx.fillStyle = "rgba("+r+","+g+","+b+","+(1)+")"; ctx.fillRect( x, y, 1, 1 ); |
Żeby dodatkowo zabezpieczyć obrazek przed możliwością kopiowania metodą „Zapisz obrazek jako” nie generuję wszystkiego na jednym elemencie <canvas>. Całość podzieliłem na pionowe pasy – za każdy pas odpowiada jedno płótno. Na koniec cały kod można jeszcze zaciemnić.
Takim oto (przekombinowanym) sposobem zabezpieczyliśmy obrazek przed kradzieżą przed przeciętnym Kowalskim. Zdaję sobie sprawę, że pomysł jest wyjątkowo egzotyczny. Może kiedyś standard umożliwi nam zabezpieczenia przed kopiowaniem (w co głęboko wątpię, chociażby dlatego, że przykładowo dostęp przez przeglądarkę do Schowka systemowego jest dość poważna luką w zabezpieczeniach). Na koniec prezentuję niewielki PoC (dla posiadaczy Firefox’a). Nie zapomnijcie ponownie ustawić
signed.applets.codebase_principal_support
na wartość false po przetestowaniu.
Cześć,
Ciekawy post 🙂
Pozwolę sobie odnieść się do kilku rzeczy i dorzucić kilka przemyśleń (może wyniknie z tego ciekawa dyskusja ;>).
Zacznę średnio-związaną uwagą dot. „PrintScreen” – mianowicie, np. w Windows 7 screenshoty wygodniej robi się aplikacją dostarczoną z systemem, zwaną w polskiej wersji językowej dość zabawnie: „Narzędzie Wycinanie” [sic], która nie korzysta ani ze schowka, ani z PrintScreen.
Warto również dodać, że na innych systemach są czasami inne skróty klawiszowe (np. na OSX jest to Command+Shift+3). Również, nie wszystkie systemy korzystają ze schowka (np. Ubuntu czy wspomniany OSX od razu zapisują screenshot do pliku).
OK, od tego miejsca zakładam, podobnie jak Ty, że screenshot trafia jednak do schowka 🙂
Ad Zero Clipboard – chciałem rzucić uwagę, że w Flash 10 dodali wymóg ‚user interaction’ jeśli chodzi o operacje na schowku, ale ekhem, właśnie przeczytałem na stronie Zero Clipboard, że obeszli to w dość zabawny sposób. Więc nvm 🙂
Ad „wiele innych sposobów” – nie wiem czy się wgłębiałeś, ale szczerze mówiąc, to nie ma za wiele innych sposobów. Sporo przeglądarek umie odbierać eventy związane ze schowkiem, ale niekoniecznie umieją coś do niego wrzucić lub go wyczyścić.
Da się w IE (window.clipboardData.setData()), ale IE zapyta użytkownika czy ten się zgadzam, żeby strona mu mieszała w schowku.
Da się również w Java, o ile applet ma odpowiednie uprawnienia i jest podpisany cyfrowo (wg informacji z podanego przez Ciebie linka, przyznaje, że o tym nie wiedziałem).
Nie wiem jak wygląda sytuacja z execCommand, ale afair dostęp do tego był też jakoś limitowany.
Więc hmm… poza flashem to trudno o jakieś dostęp do schowka na którym można polegać. Również, nie sądzę by można założyć, że user który chce obrazek skopiować, dał stronie chciane uprawnienia (ofc, powstaje pytanie czy wtedy wyświetlać w ogóle owy obrazek ;>).
Od tego miejsca zakładam, że jednak takową funkcje mamy i user się jakimś sposobem zgodził na wszystko.
Ad opisana metoda z zasłanianiem okna – przypomina mi to zabezpieczenia, które stosują banki. Ale po kolei…
Więc tak: banki borykają się dookładnie z tym problemem o którym dyskutujemy, tj nie chcą żeby coś robiło screenshoty. I teraz tak – nie mówię o polski bankach, tylko o niektórych zagranicznych, które oferują np. wpisywanie hasła via tzw „wirtualna klawiatura” (czyli po prostu klawiatura wyświetlona na ekranie w postaci serii klikalnych buttonów).
Taka wirtualna klawiatura w przypadku banków jest odpowiedzią na malware który miał keyloggery. Ofc, autorzy malware nie śpią, więc po kroku „wprowadzenie wirtualnej klawiatury” ze strony banków, sami wprowadzili.. no właśnie, robienie screenshotów on mouse click (tak, że dokładnie widać co user klika na wirtualnej klawiaturze).
No i, ofc banki nie chciały, żeby screenshoty były robione, więc w momencie gdy user wjechał myszką na jakikolwiek button (onmouseover), wszystkie literki na buttonach były zamieniane na np. gwiazdki 🙂
No cóż, podobny problem, podobne rozwiązanie.
Dla uzupełnienia historii dodam, że autorzy malware zaczeli injectować JS w strony banków który nadpisywał funkcje „ukrywające” literki, a banki zaczeły obfuskować JS i generować losowe nazwy funkcji, etc…
Ad canvas – na pierwszy rzut oka chciałem zaproponowac jednak uzycie img z visibility: hidden i odkrywaniem w JS, ale użycie canvas ma jednak swoje zalety.
Anyway, sama metoda przy przyjętych założeniach (użycie kopiowania do schowka, możliwość czyszczenia schowka) wydaje się być OK, i jako PoC faktycznie by mogła ujść (alas, nie brzmi to zbyt user friendly ;>).
A, jeszcze jedna uwaga – nie „ukryty folder”, a po prostu folder bez dostępu via www (można to w Apache+PHP osiągnąć np wrzucając do folderu .htaccess z linijką deny from all – wtedy nie trzeba się martwić czy ktoś zgadnie nazwę ;>).
A btw, i warto by, żeby strona była serwowana via https – niektóre źle skonfigurowane proxy http mają zwyczaj cache’ować tego typu zapytania i np. podawać tajne-dane innym userom danego proxy, którzy niekoniecznie musza mięc dostęp do tych danych.
OK, tyle 🙂
Wow, jaki długi komentarz ;>. Nie będę cytował – tylko odpowiadał na paragrafy w kolejności chronologicznej.
Rzeczywiście, o tworzeniu zrzutów ekranu bez wykorzystania schowka nie pomyślałem – tzn. pomyślałem, ale nie wymyśliłem jak można się przed tym zabezpieczyć. Wątpię, żeby przeglądarki dostawały aż takie uprawnienia, które mogłyby w to ingerować. Popatrz, że ogólnie cały ten dostarczony przeze mnie PoC jest bardziej zawężeniem grupy osób, które mogą kopiować obrazki, niż 100% metodą na pozbycie się problemów z ochroną plików graficznych (co nie zmienia faktu, że możemy pomyśleć, czy nie dałoby się tego zrobić lepiej – tj. zabezpieczyć się przed większą grupą użytkowników).
Opisując taki sposób wyświetlania obrazków miałem na myśli głównie dane prywatne. Przykładowo strona uczelni, która listuje dane wszystkich pracowników/studentów, a wśród nich znajdują się zdjęcia legitymacyjne (akurat ich rozmiary są w miarę strawne dla mojego skryptu). Wtedy jakiś poziom zabezpieczenia jest i przed osobami z niskimi umiejętnościami obsługi komputera (które chciałyby udostępnić dane zdjęcie nieupoważnionym), i przed tymi bardziej zaawansowanymi (które chciałyby napisać sobie bota do zebrania wszystkich zdjęć, bo: a) skrypt js trochę się wykonuje b) nawet gdyby wyłączyć js i pobrać sam kod, to jego przeprasowanie również zajmie trochę czasu).
Kolejny przykład wykorzystania to portal społecznościowy. Rzeczywiście, pomysł ze wrzucaniem bezpośrednio z aparatu wysokiej rozdzielczości zdjęcia i rzutowanie ich piksel po pikselu jest głupi – generowanie będzie trwało za długo. Zawsze jednak w jakiś sprytny sposób można wykryć twarz na danym zdjęciu (lub jeśli twarz jest zbyt duża – jak to czasem pokazują w Wiadomościach przy przestępcach – czarny paseczek na oczy ;>) i ukryć tylko najistotniejszy fragment obrazka.
OK., ale czemu o tym mówię – twierdzisz, że reszta z opisanych metod blokady schowka wymaga zgody użytkownika. Naprawdę myślisz, że przykładowo biorąc takiego FaceBook’a mało ludzi zgodziłoby się na udostępnienie systemowego schowka dla przeglądarki? Wydaje mi się całkiem inaczej – jeśli serwis oferujący takie (tu się zgodzę, mało user-friendly) rozwiązanie jest stosunkowo popularny, korzysta z niego masę ludzi to raczej dość dużo osób udostępni schowek w zamian za oglądanie zdjęć swoich znajomych 😛 (a przecież stosowanie takiego rozwiązania do domowych homepage’y nie ma najmniejszego sensu).
Teraz trochę o bankach – hah, planowałem napisać post mówiący o tym, że wirtualne klawiatury są złe (i jeśli znajdę więcej czasu to pewnie cos skrobnę na ten temat). Napiszę więc tylko skrótowo. PrintScreen to nie jedyna metoda. Zauważ, że odpalając wirtualna klawiaturę, możemy ustalić położenie okna, a następnie logować pozycję kursora w momencie kliknięcia. Na tej podstawie wyliczymy sobie, w jaki klawisz kliknął user – i nie trzeba do tego PrintScreena.
Co do deny from all – zapomniałem o tym napisać, za to w myśl zasady security-in-depth do słowa folder dodałem przymiotnik „ukryty”. Znam człowieka, który podczas prac konserwacyjnych na serwerze wrzuca nowy (z innymi regułami) plik .htaccess 😀 – także przed takimi osobami warto wspomnieć o obu metodach – dzięki, ze o tym wspomniałeś.
A o Proxy nie słyszałem. Mógłbyś napisać trochę więcej, ewentualnie zalinkować? Chcesz powiedzieć, że źle skonfigurowane proxy wyświetli zawartość cache nawet wtedy, gdy kod php (czyli serwer) wymusza wyświetlenie zupełnie innego wyniku?
Hey,
Analogicznie, bez cytatów, w kolejności góra-dół 😉
Zgadzam się, że przeglądarki w tym momencie nie mają odpowiednich uprawnień, żeby skutecznie zabronić robienia screenshotów.
Hmm… ciekawe czy przyszłość przyniesie jakieś DRM-like zabezpieczenia przez screenshotami contentu z przeglądarek – szczególnie jeśli oglądanie filmów via przeglądarki się rozpowszechni. Chociaż pewnie jakiś dodatkowy plugin w takich wypadkach będzie potrzebny (jak i teraz często bywa), a pluginy z native code mają kapkę większe możliwości.
Obawiam się, że na osoby zaawansowane (i mam tu na myśli co bardziej doświadczonych userów) sobie poradzą z tą metodą. Rzucę kilka pomysłów (w kolejności od najmniej zaawansowanych technicznie, do bardziej zaawansowanych technicznie):
1. Zamiast robić screenshot zrobić nagrywanie pulpitu (screencast). Filmik trwał by np 2 sec, w których zawierałoby się włączenie nagrywania, wjechanie myszką na okno z obrazkiem, i wyłączenie nagrywania. A potem można albo wyripować daną klatkę, albo prościej: zrobić screenshota filmiku podczas jego odtwarzania 😉
2. Jak pisałeś – jakieś zautomatyzowanie sprawy, jak np bot. W prostym przypadku byłby to program do automatyzowania klikania po ekranie – taki bot wchodził by na kolejną stronę, czekał np 5 sekund, robił screenshot, i przechodził na następną. Ofc, cichym założeniem tutaj jest, że screenshot, nawet jeśli zahaczyłby o schowek, to byłby zapisany na dysk przed opuszczeniem okna przez myszkę.
3. Extension do przeglądarki wyłączający akcje onmouseover w danym elemencie (w zasadzie dość prosta rzecz do zrobienia).
4. Bot ściągający stronę a potem jakimś regexpem wyciągający kolejne kolory pixeli (jeśli renderowanie obrazka składałoby się z serii statycznych ctx.fillStyle = „rgba(„+r+”,”+g+”,”+b+”,”+(1)+”)” (gdzie r g b to stałe) w kodzie, to jest to kwestia regexpa). Ofc, to wymaga spełnienia specyficznych założeń.
5. Bot będący połączeniem curl z jakimś engine JS (czyli wykonujący skrypt po stronie bota, ale bez udziału samej przeglądarki).
6. Etc.
Anyway, pisałeś, że skrypt się trochę wykonuje a przeparsowanie zajmię trochę czasu – osobiście bym na tym za bardzo nie polegał. Zauważ, że atakujący zazwyczaj ma czas. Nawet jeśli napisanie skryptu zajmie mu dzień, to potem ten skrypt będzie działał OK i nawet jeśli JS będzie renderował obrazek 5 minut (co jest zupełnie nie user friendly), to atakującemu to nie robi żadnej różnicy – po prostu zostawi bota na noc, albo zapuści go na 50 maszynach.
Ad zgoda na schowek
Zgadzam się, że sporo userów faktycznie by się zgodziła na dostęp do schowka, szczególnie gdyby, tak jak pisałem, uzależnić wyświetlenie zdjęć od tej zgody.
Chodziło mi jednak o wskazanie, że niektórzy się nie zgodzą i są to potencjalnie straceni userzy ;>
Ad wirtualna klawiatura
Ah, akurat na to banki też już odpowiedziały – za każdym razem układ klawiszy jest losowy (co nie jest user friendly, ale jest skuteczne jeśli chodzi o metodę o której piszesz).
Ad deny from all
W sumie deny from all i tak jest bardziej lekarstwem niż prewencją. Z punktu widzenia prewencji powinno się taki katalog umieścić poza katalogami zamapowanymi przez httpd via www, np. w katalogu nad public_html. PHP będzie miał tam dostęp (przy odpowiedniej konfiguracji), ale via www po prostu nie będzie możliwe odwołanie się do tego katalogu.
Natomiast zgadzam się, że zgodznie z defense-in-depth np. losowa nazwa katalogu nie zaszkodzi 😉
Ad proxy
Niestety linkami nie dysponuje. To jest coś z czym się osobiście spotkałem ze dwa razy w życiu – proxy kompletnie ignorowało ustawienia cache zażądane przez server.
Nie sądzę żeby zdarzało się to często, natomiast niestety takie sytuacje mają miejsce. Więc HTTPS 😉
OK tyle, cheers 😉
A może domyślne blokowanie przed kopiowaniem, like wyłączenie PrintScreena/Schowka kiedy proces przeglądarki jest uruchomiany + możliwość dodania przez webmastera jakiejś linijki w kodzie, która dezaktywowałaby to zabezpieczenie (albo na odwrót)? Z drugiej jednak strony wiązałoby się to z rozbiciem ustawień przeglądarki na dwie grupy – te, które mogą być modyfikowane przez osoby trzecie, oraz te, których zmiana może być dokonana tylko przez użytkownika danej przeglądarki.
Btw, przez chwilę pomyślałem sobie, jak wyglądałaby mentalność ludzi, gdyby firmy bardziej skupiały się na zabezpieczeniach przed kradzieżą ich twórczości, niż na funkcjonalności (wbrew pozorom to się coraz częściej zdarza – cykliczne łączenie się z serwerem podczas gry, czy nawet widziałem kiedyś grę (nie pamiętam tytuły niestety), która nie chciała się uruchomić, bo w tle działał debugger – nie podpięty do procesu tej gry…). Później przypomniało mi się Sony :P, i rzeczywiście chyba zawsze znalazłby się ktoś, komu nie podoba się ograniczenie funkcjonalności na rzecz ochrony przed kradzieżą.
Pewnie, że da się to ominąć – zaznaczyłem na początku, że jest to sposób głównie dla mniej-zaawansowanych posiadaczy komputerów. Napisałeś kilka fajnych sposobów – ja dodam jeszcze ten, który jako pierwszy wpadł mi do głowy.
Kod miał być zaciemniony (w związku z tym, że chciałem pokazać PoC darowałem sobie obfuskację). Załóżmy jednak, że tak jest. Pierwsze co wpadło mi na myśl to próba deobfuskacji wygenerowanego kodu. Napisanie sobie jakiegoś narzędzia, które „odciemniałoby” kod, a następnie wycięcie funkcji odpowiadającej za wyłączenie PrintScreena/schowka. Problem pojawiłby się jednak, gdyby skrypt dynamicznie generował różne algorytmy zaciemniania – wtedy każde wygenerowanie strony trzeba by było analizować osobno.
Mówiąc bot miałem przede wszystkim różnego rodzaju crawlery, które istnieją tylko po to, żeby nagromadzić jak najwięcej danych. Jeśli taki bot ma wybór: wydobyć jeden obrazek w czasie 5 minut, lub wyciągnąć w tym czasie tysiąc innych obrazków z innych stron, to myślę, że raczej pójdzie on na ilość, a nie jakość ;> Zwłaszcza, że roboty nie są jeszcze na tyle inteligentne, żeby przeanalizować, czy to co wydobywają ma rzeczywiście jakąś wartość.
Skoro jesteśmy już przy botach, to rzucę taką małą ciekawostką. Mój znajomy użerał się z dość sporą gromadą spamerskich botów. Używał darmowego CMS’a z włączonym obrazkowym CAPTCHA. Najśmieszniejsze jest to, że kiedy zmienił w opcjach wyświetlanie CAPTCHA obrazkowego, na tekst zabezpieczający – roboty przestały atakować. Widać, twórcy crawlerów nie przejmują się już wydawałoby się starymi i najprostszymi metodami.
Odnośnie straty pewnej części użytkowników – wracamy w pewnym sensie do punktu wyjścia (taki okrąg :P). Osoby, które zdają sobie sprawę z zagrożeń płynących z udostępniania schowka przeglądarce są w pewnym sensie zaawansowane i można założyć, że również znajdą sposób na obejście przedstawionej metody zabezpieczenia obrazków. Jedyny kompromis jaki w tej chwili widzę to mówiąc brutalnie – uciążliwy (ale możliwy) dostęp do niezabezpieczonych zdjęć – np. wklepywanie kodu potwierdzającego za każdym razem przy wyświetlaniu obrazka. Osoby, które nie zgadzają się na udostępnienie schowka (i które potencjalnie i tak ominęłyby sposób ochrony) będą miały dostęp do zdjęć. Tymczasem osoby, którym sprawa udostępniania schowka nie robi różnicy – wybiorą mniej uciążliwą drogę (czyli schowek udostępnią, ale pozbędą się kodu weryfikacyjnego). Przy takim założeniu i tak pojawia się problem. Użytkownik, który udostępnił schowek i nie potrafi skopiować zdjęcia (a bardzo chce to zrobić) może zmienić tę metodę. W sensie blokuje schowek, dostaje niezabezpieczony obrazek, kopiuje go, znowu udostępnia schowek…. chyba, że ustalenie czy pozwolenie przeglądarce na korzystanie ze schowka będzie jednorazowe… ale to chyba zbyt brutalne i zdecydowanie mało przyjazne rozwiązanie.
Co do banków – nie widziałem jeszcze zabezpieczenie, które modyfikuje standardowy układ klawiatury wirtualnej, ale już zdaję sobie sprawę, jak bardzo by mnie to irytowało :D. Wydaje mi się, że na metodę, którą opisałem jest bardziej user-friendly sposób. Zamiast za każdym razem zmieniać ustawienie literek na klawiaturze zmieniajmy przy każdym jej generowaniu odległość pomiędzy klawiszami. Wtedy nie da się jednoznacznie stwierdzić, jaki klawisz został kliknięty.
Ja tam niewiele z tego rozumiem, ale może mój informatyk by coś zczaił 🙂
Zanim jednak zacznę mu zawracać głowę, możesz podać adres strony, na której można zbadać w praktyce Twoje hipotezy? (proponuje go umieścić na początku artykułu, a potem się do niego odnosić)
Boję się, że niektóre z zaproponowanych rozwiązań obniżą znacznie użyteczność strony z punktu widzenia użytkownika…
Cały opisany pomysł ma dwie podstawowe wady. Pierwszą z nich jest to (co zostało zaznaczone wyżej w komentarzach), że nie istnieje w 100% skuteczny sposób, który zabezpiecza przed kopiowaniem obrazków. Można go jedynie modyfikować tak, aby samo kopiowanie stawało się bardziej uciążliwe [czyt. zniechęcić] dla ludzi, bądź bardzo trudne dla automatów [czyt. nieopłacalne].
Drugą wadą jest wydajność (która w tym przypadku wpływa również na użyteczność). Dzielenie obrazu na części (nie muszą być to, tak jak w tym przypadku piksele), a następnie ich wyświetlanie może okazać się dla przeglądarki zabójcze. Stąd jasne, że "zabezpieczanie" olbrzymich obrazów w zaproponowany sposób byłby zły. Ale o podobny rozwiązaniu można pomyśleć w kontekście obrazków mniejszych (np. niektóre serwisy przechowują zdjęcia w wymiarach legitymacyjnych), lub nawet fragmentów większych zdjęć (możemy przecież wyodrębnić z większego zdjęcia elementy, które chcemy zabezpieczyć przed kopiowaniem i dalszym rozpowszechnianiem – jak np. poszczególne twarze z umieszczone na cyfrowej fotografii).