Image Protection on the Web(patrick-wied.at)
patrick-wied.at
Image Protection on the Web
http://www.patrick-wied.at/blog/image-protection-on-the-web
44 comments
Very interesting! Even though (as you've already stated) the whole exercise is kind of futile and pointless, it is rather interesting.
It got me thinking of some other tricks you could do to annoy the person attempting to "steal" the image.
Do you think sub-dividing the image into many small adjacent tiles could be an interesting way of defeating right-click > save as? Perhaps to make it even more difficult, you could randomize the elements and/or IDs, so it would be difficult to write a script that collected and reassembled the tiles. Of course, if you did this server-side to prevent the original complete image from being sent to the client, you'd have terrible load times.
I also wonder if it's possible to detect and respond to the common key combinations used to take screenshots. In that case, you could frustrate the would-be copier (of course, until they disabled scripts).
Ultimately, nothing can be done. No matter how clever your defense, someone could always load up the site in a VM and take the screenshot with a host machine. But it's a cool exercise nonetheless, thanks for sharing!
It got me thinking of some other tricks you could do to annoy the person attempting to "steal" the image.
Do you think sub-dividing the image into many small adjacent tiles could be an interesting way of defeating right-click > save as? Perhaps to make it even more difficult, you could randomize the elements and/or IDs, so it would be difficult to write a script that collected and reassembled the tiles. Of course, if you did this server-side to prevent the original complete image from being sent to the client, you'd have terrible load times.
I also wonder if it's possible to detect and respond to the common key combinations used to take screenshots. In that case, you could frustrate the would-be copier (of course, until they disabled scripts).
Ultimately, nothing can be done. No matter how clever your defense, someone could always load up the site in a VM and take the screenshot with a host machine. But it's a cool exercise nonetheless, thanks for sharing!
author here: I do not advocate using any of the techniques, please don't use it, it's terrible and will give your users headaches! I'm against ressource "protection" on the web, what's on the internet should be fully consumed by users of it! The article describes just a few experiments I set up to see how far someone could go if it WAS important ( "for a few minutes, let's assume things on the web should be protected…" ). Thanks for the feedback so far!
Your final demo is easily defeated because a link to cat.png appears right in the page source:
I mean this line:
<img id="cat" src="cat.png" width="237" height="235" />
in the source code to this page:
I mean this line:
<img id="cat" src="cat.png" width="237" height="235" />
in the source code to this page:
http://www.patrick-wied.at/talks/image-protection/demos/demo-interlacing.html
Yes you are right, the main purpose of the last demo is to try to prevent a screen shot (ignoring all other techniques to obtain the image). thank you I, already forgot about it and will change that
Thank you for this article - I think the best way to protect our artwork (in any medium) is to sensibilize our users.
Give credit to the artist, that's all we want in the end.
Give credit to the artist, that's all we want in the end.
The final demo literally gives me a headache. It shimmers. However for whatever reason I am able to screenshot it perfectly from Chrome on Windows 7.
Internet Explorer 10 won't render the image at all (blackness) and in Firefox it looks both corrupt AND shimmers (and screenshots look equally as horrible).
Given the choice between a watermark which might decrease my viewing experience and some shimmering buggy image that literally gives me a headache (like sea-sickness), I'm definitely opting for a watermark.
Does anyone else get sick while staring at the final demo?
Internet Explorer 10 won't render the image at all (blackness) and in Firefox it looks both corrupt AND shimmers (and screenshots look equally as horrible).
Given the choice between a watermark which might decrease my viewing experience and some shimmering buggy image that literally gives me a headache (like sea-sickness), I'm definitely opting for a watermark.
Does anyone else get sick while staring at the final demo?
It shimmers using Chrome on OS 10.6 on an HP LP3065. The kitty looks like he's about to barf. All in all, a substandard image. Here's a screenshot. It doesn't shimmer, but it is ugly!
http://goo.gl/8Cekr8
http://goo.gl/8Cekr8
I am surely not the only one using noscript.
To me, the interlaced image demo looks like this: http://imgur.com/NsVvgEZ - now I concede that most people do not use script blocking tools, but quite a lot do. Ruining the user-experience of your own site for some cheesy protection scheme seems like a really bad idea to me.
Besides: what is keeping me from taking several screen shots (JS enabled of course) and then overlaying them in Photoshop?
To me, the interlaced image demo looks like this: http://imgur.com/NsVvgEZ - now I concede that most people do not use script blocking tools, but quite a lot do. Ruining the user-experience of your own site for some cheesy protection scheme seems like a really bad idea to me.
Besides: what is keeping me from taking several screen shots (JS enabled of course) and then overlaying them in Photoshop?
I don't think web developers are under any obligation to provide support for people who selectively disable portions of the page they built. If you want to turn off javascript, downloading images, the color blue, etc, that's your right, but you can't comment on the user experience when you've deliberately muddled with it.
There are lots of arguments for supporting users who have javascript turned off, accessibility and SEO being two of the more common ones. http://programmers.stackexchange.com/questions/149021/should...
This is super interesting because we've had to deal with it for a long time. In fact, "I don't want my images stolen" was one of the main objections we had when trying to get website customers to move from Flash to HTML5 (even post-iPad).
We still give customers the option to disable right-clicking. It might annoy users, but they don't seem to care. Many will still not upload images above 600px on the long side.
The demo isn't great because there's some visible flickering. I also can't tell if the image looks like crap because it's a crappy image or because of the techniques used. Would love to see a demo with a real-ish image (say, a high-quality image that's 900 pixels wide).
We still give customers the option to disable right-clicking. It might annoy users, but they don't seem to care. Many will still not upload images above 600px on the long side.
The demo isn't great because there's some visible flickering. I also can't tell if the image looks like crap because it's a crappy image or because of the techniques used. Would love to see a demo with a real-ish image (say, a high-quality image that's 900 pixels wide).
Each time I see a site with right-click blocked I put that site on my black list. Really is one of the most annoying thing ever made on the internet. Surpassed only when you block right-click AND bind the right-click with a popup that says "sorry you can't right-click on our site for yyyyy purposes".
Indeed. Plus many of those sites inadvertently break the middle mouse button which I use for scrolling, and several laptop/touchpad dedicated scroll buttons.
It just feels childish to me. Everyone knows that you cannot protect an image by binding to the right mouse button event, but yet they continue to do it anyway. It is trivial to bypass and just annoys legitimate "customers."
It just feels childish to me. Everyone knows that you cannot protect an image by binding to the right mouse button event, but yet they continue to do it anyway. It is trivial to bypass and just annoys legitimate "customers."
That's understandable from the HN crowd. BUT a wedding photographer doesn't care about your black list (no offense).
In his/her mind (right or wrong), a bride-to-be has no reason to right click. The only people who might-right click would be nefarious people who want to steal an image and put it on their portfolio as their own work (this does happen).
In his/her mind (right or wrong), a bride-to-be has no reason to right click. The only people who might-right click would be nefarious people who want to steal an image and put it on their portfolio as their own work (this does happen).
Working for a major library that does a lot of digitization work for external partners like museums and art galleries, I deal with this a lot.
Our solution usually involves (in addition to the obvious approaches mentioned in the beginning of the article) not sending out full-sized images but only tiles, severely rate-limiting the API (heavy users can contact us for an exception) and displaying a discreet watermark with the origin.
It's very frustrating as a developer, especially given the fact that 90% of the material is public domain anyways...
I like your thinking. With 'deepzoom' images composed of lots of tiles that overlap by 4 pixels ('Seadragon') you can change the tile size from the default 254px to anything else that works with jpg and powers of two. Theoretically you could deliver thousands and thousands of tiles for a high-resolution image. You could also get the viewer to change the zoom level by a small percentage on each 'move' so that anyone trying to stitch together an image from screen-grabs will have that random bonus scaling to deal with - lovely!!!
A half-decent programmer could reverse-de-obfuscate the image tiles into a whole image if they really wanted to, they could even post their code for that onto github, however, in all of the years that Seadragon has been around the tools to make the tiles in the first place haven't exactly proliferated so the tools to decipher the tiles aren't likely to get widespread circulation either. With tiles you are pretty well protecting your stuff as a convenient by-product, the real aim is to deliver a superior viewing experience.
A half-decent programmer could reverse-de-obfuscate the image tiles into a whole image if they really wanted to, they could even post their code for that onto github, however, in all of the years that Seadragon has been around the tools to make the tiles in the first place haven't exactly proliferated so the tools to decipher the tiles aren't likely to get widespread circulation either. With tiles you are pretty well protecting your stuff as a convenient by-product, the real aim is to deliver a superior viewing experience.
>>discreet watermark with the origin
I'm assuming you are using steganography to achieve this? What kind of information are you imbedding into the image and when exactly does that process occur? Every time someone "downloads" the image?
I'm assuming you are using steganography to achieve this? What kind of information are you imbedding into the image and when exactly does that process occur? Every time someone "downloads" the image?
that reminds me of another technique I used but didn't describe in the article which could be interesting for you:
encode the viewer's IP into the image (with steganography, wrote a small script for that) on the server (every request). whenever your image pops up somewhere in the web you know which IP address is to "blame" (easily bypassed with IP obfusication software though :) )
encode the viewer's IP into the image (with steganography, wrote a small script for that) on the server (every request). whenever your image pops up somewhere in the web you know which IP address is to "blame" (easily bypassed with IP obfusication software though :) )
This is a commonly used technique in game alphas under NDAs (TESO and WoW WLK are the most recent example that come to my mind). The player's account information are embedded in the exif of the screenshots. If a screenshot leaks from someone who doesn't know better, it's possible to track it down.
>exif
WoW does much more than that: http://www.ownedcore.com/forums/world-of-warcraft/world-of-w...
WoW does much more than that: http://www.ownedcore.com/forums/world-of-warcraft/world-of-w...
I've though about it, but there's a privacy concern that turns me off, it's the equivalent of having exif data in pictures, it's really great, until someone decides to do something questionable with the embedded data.
While clever, the items in the article merely accelerate the DRM arms race; they do not deliver a war-winning weapon to any side. All the tricks here can be defeated with technology, even the interlace idea.
This whole line of thinking is an attempt to re-fight the music DRM battle, and the conclusions are the same now as they were then. First, if you deliver media to a user, then given sufficient technical means, the user can copy it. Either your users don't care to copy your content, in which case it didn't need to be DRMed, or they do wish to do so, in which case it can be copied, so DRM is a waste of money. Second, the cost of such technical means drops exponentially with the popularity of the DRM that is being used, because only one person needs to develop the circumvention technology and then everyone can share it. This last principle holds regardless of laws such as the DMCA, and regardless of lawsuits such as the thousands of lawsuits filed by the RCAA and MPAA.
In a way, this is all good. Entities that seek to control when and how other people copy data will waste their money and time they are weak enough that wiser competitors can remove them from the ecosystem. Sony is a good case in point. While they were wasting resources with DRM, Apple was eating their lunch in the music market. I now think of iTunes when I think of music, way before I think of Sony.
This whole line of thinking is an attempt to re-fight the music DRM battle, and the conclusions are the same now as they were then. First, if you deliver media to a user, then given sufficient technical means, the user can copy it. Either your users don't care to copy your content, in which case it didn't need to be DRMed, or they do wish to do so, in which case it can be copied, so DRM is a waste of money. Second, the cost of such technical means drops exponentially with the popularity of the DRM that is being used, because only one person needs to develop the circumvention technology and then everyone can share it. This last principle holds regardless of laws such as the DMCA, and regardless of lawsuits such as the thousands of lawsuits filed by the RCAA and MPAA.
In a way, this is all good. Entities that seek to control when and how other people copy data will waste their money and time they are weak enough that wiser competitors can remove them from the ecosystem. Sony is a good case in point. While they were wasting resources with DRM, Apple was eating their lunch in the music market. I now think of iTunes when I think of music, way before I think of Sony.
When you request a page over internet you receive a copy of this data. The text, images, styles, scripts, videos.
The key point: you receive a copy.
Unless this data is encrypted en requires reverse engineering to decrypt (e.g. understand how the obfuscated JS decypter work). That's the goal of the interlaced "trick".
Yes, and the logical extension of this is developing an image that people won't be able to remember since we all know that remembering things is copyright infringement.
What? It gave you a seizure? Well that's just our DRM. Obviously your brain was trying to circumvent...
What? It gave you a seizure? Well that's just our DRM. Obviously your brain was trying to circumvent...
I'm just replying to a comment about how data could be altered and don't endorse such "stupid trick" nor I'm the author :)
You don’t need to deobfuscate the code to run it.
This is terribly antithetical to the principles of the Internet, but... the interlacing is very clever, even though it doesn't look right on my browser (shimmering black).
I could solve the invisible wall demo trivially (Inspector > Network > cat.png -- this also worked for the interlacing demo). The encrypted demo took a few more seconds: Inspector > Delete transparent.jpg > Right click canvas > Save Image As.
If the interlacing one was using the encrypted image, and if its JavaScript was obfuscated (so I couldn't easily determine the encryption algorithm), I could (kinda) solve it by pausing script execution in Firefox's debugger, then changing the opacity on both canvases to 1 - then taking a screenshot of the picture. But this is harder to achieve reliably for scaled-down images.
Mozilla should start thinking about ways to help users fight this kind of bullshit; e.g. having right-clicks apply to highest opaque image or canvas, ignoring any transparent elements.
I could solve the invisible wall demo trivially (Inspector > Network > cat.png -- this also worked for the interlacing demo). The encrypted demo took a few more seconds: Inspector > Delete transparent.jpg > Right click canvas > Save Image As.
If the interlacing one was using the encrypted image, and if its JavaScript was obfuscated (so I couldn't easily determine the encryption algorithm), I could (kinda) solve it by pausing script execution in Firefox's debugger, then changing the opacity on both canvases to 1 - then taking a screenshot of the picture. But this is harder to achieve reliably for scaled-down images.
Mozilla should start thinking about ways to help users fight this kind of bullshit; e.g. having right-clicks apply to highest opaque image or canvas, ignoring any transparent elements.
for me it was primarily about the technical challenge of trying to prevent a screen shot in a web browser.
Indeed, it would be great if Mozilla did work against those techniques. I really don't like websites that implement them...
Indeed, it would be great if Mozilla did work against those techniques. I really don't like websites that implement them...
Instead of hiding or modifying the image entirely at tiny random intervals, why not modify subsections of the image at all times, rolling the imperceptible modification around the image itself, so that at no time interval is there ever an unmodified image?
The human eye detects motion very readily, so this technique would actually be far more perceptible than keeping the modified portion in the same location of the image.
These are all interesting, but defeated by me with one easy keyboard command (for the rest of you, it's View->Page Style->No Style). Without CSS, the main image is displayed just fine.
Some people really are trisky.
Some people really are trisky.
Without CSS it still displays the encrypted image with the Encryption / Decryption - technique, doesn't it?
Without JS, it's all bad :(.
But, with JS, and without CSS, I can just right-click¸ view-image. This gives me the base64 in the address bar (Firefox).
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAPAAAADwCAYAAAA+VemSAAAgAElEQVR4nLS96ZMUV5rm6x/Czd2P7+7h4REeHntkZETkvkAmCYh
A simple save page later, and I get your image. Bang.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAPAAAADwCAYAAAA+VemSAAAgAElEQVR4nLS96ZMUV5rm6x/Czd2P7+7h4REeHntkZETkvkAmCYh
A simple save page later, and I get your image. Bang.
interesting.
apparently a lot of people disagree.
I didn't downvote you but it's likely not disagreement -- HN just dislikes comments that don't add value to the conversation. A message with an "I agree" or "That sucks" by itself doesn't contribute to the dialogue.
I'm sure a lot of people do agree. However single word replied rarely add anything to the discussion and definitely worsen the signal:noise ratio.
In the end, if the content is meant to be seen by people, it is copyable. Seeing presumes the information is being transmitted. The only compromise you can make is to watermark, i.e., degrade quality and only hint at the full image.