I got a commission for an "artistic site" that had to protect a large library of images from leeches and downloaders. They wanted to display their images, but not allow anyone to download or link to their images. So, I first had to explain that no image is entirely "safe". Even with the best web security available, a user could use a screen capture utility to snap their screen and throw it into an image editor to capture the image. Needless to say, they weren't happy to hear that, but they wanted me to protect their images as much as possible.

My problem broke down into two problems. Stop normal users from saving the images, and stop file and bandwidth leeches. I'm so thrilled. :glare:

There are javascript options to disable right-click access, but because javascript is a client side scripting languange instead of being server side, users can simply disable scripting and your "security" is disabled as well. This wasn't going to be an option, so I needed a different way to protect my client's images. My answer was to encode the JPG files as they were being uploaded into Adobe Flash SWF files. You can find more detail about it here.

When the user attempts to right click on the image, he gets the SWF menu, instead of an option to download. Unfortunately, there is an option to print, which the client did not want. So, I did a little research and found out how to disable the print function in Flash, but leave the rest of the menu. I posted a quick job up on http://www.scriptlance.com and found someone to edit the PHP code to disable print functionality. You can also disable the right click menu completely, by simply adding menu="false" within the embed and object tags. That took care of my users downloading.

Now for my leeches. I had the flexibility of whom to use for a host for my client and I found an ISP that allowed me to edit my .htaccess file. I found a very elegant solution at http://www.alistapart.com/articles/hotlinking/ that took care of my leech issue, after adding my SWF files into the .htaccess conditions.

Is it a perfect solution? No, but combined with some other tricks, like URL obfuscation, md5 hashing, appending obfucated gobbledy-gook on the end of the image file, session checking for login, etc. , I have a layered solution that makes it extremely difficult for someone to acquire my client's images.

One humorous side effect of converting JPG images to SWF is that Flash's right click menu allows the user to "zoom in" on parts of the "artistic" image. This "feature" was actually appreciated by the client, so they got a bonus!

    hmm... you know how PHP can generate imagery based on math?

    I wonder if it would be possible to createimagefromJpeg() in conjunction with other gd2 features and serve it up as raw data vs a url so that you woudlnt be able to save down (other then screen caputre) because the image would not be linked, it would have been generated by PHP. but then again, how does the HTML handle it at that point?

    Dunno, but the SWF solution is probably your best shot. Even though someone with trickery enough can dl the swf and open it if they have riight tools.

    The thing about security is, if someone wants to get in bad enough they will, it's one of thoese "where there's a will there's a way" sort of thing. No matter how much systematical defence you put up, smart people whom have nothing better to do can always learn your system and use it against you.

      There's nothing you can do about screenshot applications, however you can make it (more) difficult for casual users to steal the images or link them.

      To stop people linking images, simply change their URLs frequently. Any links they create will soon be broken. This is easy enough so I won't discuss it further.

      To stop people saving the images out, you could break up an image into several parts.

      This would involve some image manipulation (Hint: GD's jpeg-encoder is not good enough for many people in some cases; consider using a different one if you want high quality, or use another format). You could for instance, create a base image which is the original with selected small parts "missing", then put a transparent PNG on layered on top in the page which fills in those parts.

      If the user saves the image out, they're either saving a transparent PNG that only contains a few bits, or the original image with a bunch of "holes" in it. Of course it's trivial for someone with basic photoshop skills to recombine them, but annoying.

      Another risk might come if you're worried that someone will make a (reasonably clever) screen-scraping robot to leech your entire image collection and stick the pieces back together automatically. This can be prevented by using CAPTCHAs and/or other techniques to make sure that only humans can get into those parts of the site. Don't rely on email registration as spammers can pass that (there are loads of sites which provide free throw-away emails to bypass registrations).

      Mark

        As previously said there is no simple way to avoid leeching images. the right click disabling works until someone hovers on the image and actually presses the contextual menu key on their keyboard. they then get the regular right click menu. A simple solution to prevent the casuals to right click is to put the image as background of a div and show a transparent gif on top covering it entirely. Another solution is to generate a hash. store it in session and output the image from a php script which will find the image based on hash. doing so with a referer check will stop many leeching solutions. This can also allow you to output a standard "Hey leech, you suck" image which will make the leecher very unhappy. Either that or redirect to an image on another site like microsoft.com. That should significantly reduce the bandwidth eaten up.

          As a note, I have found that most of the above suggestions will work.

          You can't stop (no matter what you do) someone who does indeed know what they are doing, as in, the image is still in the cache if there is a transparent gif over it, etc. And nobody can stop screen caps.

          The Good thing is, taking a screen capture is time consuming, you especially would not want to have to do it for any apreciable number of images.

          Depending on how you feel about .. iframes, one could even (with very little skill) use photoshop/imageready to export slices,which would inherantly appear to be one image, but it could be broken down into 100 slices easily, which would make it for difficult for the leech to put it together.

          Always remember that any decent methods will work; Many users who are intelegent enough to get past these methods will take what they want & go, which in retrospect isn't all that bad. That or, like most of us here, will just do what they need on their own.

            big.nerd wrote:

            Depending on how you feel about .. iframes,

            You should probably avoid using iframes, it creates extra overhead (sub requests, work for the browser and server) without any benefit.

            one could even (with very little skill) use photoshop/imageready to export slices,which would inherantly appear to be one image, but it could be broken down into 100 slices easily, which would make it for difficult for the leech to put it together.

            100 slices would require 100 requests to get from the server - this is going to create a large amount of lag loading an image and place a lot of unnecessary load on the server.

            Personally I'd go with two or three pieces for each image, but ensure that they're not all the same (e.g. slice the image at random points and have the html glue them back together) to make it much harder for a leecher to write a bot to reconstruct them all.

            Always remember that any decent methods will work; Many users who are intelegent enough to get past these methods will take what they want & go, which in retrospect isn't all that bad. That or, like most of us here, will just do what they need on their own.

            Provided there aren't any "off the shelf" apps which can leech your images, you're mostly ok.

            Defending against someone who is prepared to pay a skilled programmer to create an advanced custom leech-bot is both very difficult and uneconomic.

            Mark

              If you display an image in my browser, I can capture it--no special software is needed. All I have to do is type Alt-PrntScrn, open up Windows Paint, type Ctrl-V, crop the image as needed, then save it in the desired format. In other words, in spite of all the contortions you might go through, I still have a copy of the image in a JPEG file in 30 seconds or so.

              The only thing that will stop most image stealing is some sort of "water-marking", perhaps overlaying the image with a translucent copyright notice or "sample" verbiage (which, of course, may not be aesthetically desirable depending on what the images are being used for in your application). Note that this could be done "on the fly" by using a PHP image server script that would put in the water-mark without altering the original image file (which would then be stored in a non-HTTP-accessible directory).

                NogDog wrote:

                If you display an image in my browser, I can capture it--no special software is needed. All I have to do is type Alt-PrntScrn, open up Windows Paint, type Ctrl-V, crop the image as needed, then save it in the desired format.

                Yes, however, if the leecher is prepared to pay someone to do this manually for every single one of your images, fair enough.

                I think what the OP is getting at is preventing bot-based leeches where the entire catalogue is systematically stripped.

                Mark

                  On the note of overhead (MarkR's Point) I agree 100%, the purpose wasn't that one would make 100 different slices, 2-3 in different points is optimum.

                  As I stated, for someone who has sufficiant determination (Alt-PrintScrn) or skill (programmers) there is nothing you can.

                  Anything you do is merely a deterant, which is sufficiant for most users.

                    Write a Reply...