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.
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!
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
Am I correct in assuming that for demo purposes you didn't worry about that, but if you had intended to do this in practice, you would have to feed the data in cat.png to client in some non-obvious way?Give credit to the artist, that's all we want in the end.
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?
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?
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).
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."
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).
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.
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?
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 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.
What? It gave you a seizure? Well that's just our DRM. Obviously your brain was trying to circumvent...
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.
Indeed, it would be great if Mozilla did work against those techniques. I really don't like websites that implement them...
Some people really are trisky.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAPAAAADwCAYAAAA+VemSAAAgAElEQVR4nLS96ZMUV5rm6x/Czd2P7+7h4REeHntkZETkvkAmCYh
A simple save page later, and I get your image. Bang.