Interesting tricks, but it seems impractical or even dangerous. For example, showing the images at a specific quick refresh rate may cause them to not appear on some monitors, or worse, may annoy some people whose eyes are more sensitive, possibly even trigger an epileptic seizure.

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.

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!

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!

  http://www.patrick-wied.at/talks/image-protection/demos/demo-interlacing.html

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?

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?

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).

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...

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.

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.

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.

Why not interlace by splitting every other line of the image into two transparent PNGs (or GIFs, I guess), and overlaying them with the "invisible wall" technique? There's no artifacting from refresh rates there, and the image isn't usable unless you have both.

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?

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.

We can do lots of hacks, then the user clicks on print screen and its a done deal.

interesting.