by pa7 on 7/11/14, 8:52 PM with 44 comments
by azakai on 7/11/14, 9:33 PM
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.
by sebular on 7/11/14, 11:20 PM
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!
by pa7 on 7/11/14, 10:40 PM
by Someone1234 on 7/11/14, 10:07 PM
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?
by iSnow on 7/11/14, 9:58 PM
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?
by callmeed on 7/11/14, 9:33 PM
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).
by jbaiter on 7/11/14, 10:45 PM
by thothamon on 7/11/14, 10:13 PM
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.
by nobullet on 7/11/14, 9:36 PM
by majika on 7/11/14, 10:20 PM
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.
by timdorr on 7/11/14, 9:58 PM
by geoffsanders on 7/11/14, 11:34 PM
by raving-richard on 7/12/14, 12:46 AM
Some people really are trisky.
by ibrad on 7/11/14, 11:26 PM
by n0body on 7/11/14, 8:58 PM