How to protect pictures, your ideas and hints?

[TomKa]

To view pictures over the web the picture must be downloaded into the cache of the browser, that's clear.

But to have some protection I have found the following possibilities:

1. Slicing the pictures and encrypting the slice-code with java script, generated , for example, from HTML Guardian
http://www.protware.com/

2. Encrypting the pictures with PTCrypt from PanoTools. To display the pictures you must use the PTViewer java applet. This is possible with the panorama tag in EE.

3. The picture resides in a table as a background image with a transparent gif in front of the real picture.

4. Using htaccess to protect the image directory from direct downloads using www.yoursite.com as referer.

[Pekka]

TomKa wrote:
1. Slicing the pictures and encrypting the slice-code with java script, generated , for example, from HTML Guardian
http://www.protware.com/

ALT+PrintScreen -> paste. When a photo is displayed on screen it can be captured. Also, slicing will be difficult to database systems as photos are referred by filename. Of course code can be written to redirect certain arbitrary filename code to retrieve certain block of code which in turn loads the slices to page but if after all this the resulting phtoo can be captured I don't see much sense spending time to code that sort of a system.

2. Encrypting the pictures with PTCrypt from PanoTools. To display the pictures you must use the PTViewer java applet. This is possible with the panorama tag in EE.

Again, there are plenty of methods to do a screen capture. Panotools output is supported by EE, only downside is Java requirement (not included in Windows any more) and how it will delay loading of first photo page as Java engine needs to be loaded by OS.

3. The picture resides in a table as a background image with a transparent gif in front of the real picture.

Picture URL can be read from html source.

4. Using htaccess to protect the image directory from direct downloads using www.yoursite.com as referer.

This is a good way to protect hackers from guessing photo filenames and folder names.

[TomKa]

Thank you for your answer, Pekka.
I know you can capture the screen, but with captured low resolution pictures it's not possible to print the picture, for example, in magazines.

I have found another explanation and a snippet in php, this version works with transparent gif in a table, htaccess and a session variable for the picture to display:
in german:
http://www.drweb.de/programmierung/php_bilderklau.shtml
copy and paste the link above to translate with Google

[Pekka]

TomKa wrote:
Thank you for your answer, Pekka.
I know you can capture the screen, but with captured low resolution pictures it's not possible to print the picture, for example, in magazines.

Everything you put on the net on display can be stolen. But also at the same time you have the law on your side if that happens. I'm sure published magazines do not steel photos they print, that is simply too big a risk for loosing face and credibility.

I have found another explanation and a snippet in php, this version works with transparent gif in a table, htaccess and a session variable for the picture to display:
in german:
http://www.drweb.de/programmierung/php_bilderklau.shtml
copy and paste the link above to translate with Google

That is also a way which prints image url into source code, and uses php functions which do not work in some safe mode configurations.

But it gave me some ideas and I actually coded today an additional security setting into EE: now you can choose to totally hide your size paths for the big photos. You see no path at all in source code. EE will fetch those images from selected size path with ftp (very fast), rename them randomly and display the renamed file from gallery/temp/ -folder. Every image viewed will create a new temp image so the cleanup needed is done from e.g. ratio based on list page counter or index page counter (haven't decided yet) so that temp folder does not grow too big. I try to set it so that last X photos are not deleted, even if a chance of a visitor getting an empty photo is simply minimal (image download time is a factor, though). This option is for those who care about hiding their big size folder names from public. If server is average speed and photos are in same server the ftp does not slow page loads at all.

[TomKa]

Everything you put on the net on display can be stolen. But also at the same time you have the law on your side if that happens. I'm sure published magazines do not steel photos they print, that is simply too big a risk for loosing face and credibility.

There are quite huge differences in business practices between Northern and Southern Europe.... so I prefer to be on the safe side.

[kilted_roo]

Originally Posted by TomKa

To view pictures over the web the picture must be downloaded into the cache of the browser, that's clear.

But to have some protection I have found the following possibilities:

2. Encrypting the pictures with PTCrypt from PanoTools. To display the pictures you must use the PTViewer java applet. This is possible with the panorama tag in EE.

3. The picture resides in a table as a background image with a transparent gif in front of the real picture.

PTC could be cool...of course they say it has been cracked. Here is another option that might work. At some point someone will probably figure a way around it, but for now this may work. I do not see a copywrite or source for the script (otherwise I'd just say go get it from them). Rather than disable right clicking, it seems to disable caching. So when you go to save the file it grabs the image again but not on the page. You end up saving "can't display" an image. This works against firefox's Tools>Page Info>Media to save images. Clicking on the save icon in IE forces the jpg to be saved as untitled.bmp, but that can be corrected with option 3 above. Like i say it does not cache the file so its not in the temp internet folders either.

What they have seems to be a javascript
<script language="JavaScript" src="includes/js/multifile.js"></script>
And the image is loaded by img.php
I don't know anything about img.php, but it seems to determine if the image is requested at the same time as the page, and either sends the actual picture, or the dummy "can't display"


Multifile.js:

I am not even sure if this js file is the one that makes it work, but I don't see anything else. Or even if it is the same/real one (php script sends fake script just as img.php does images)

function MultiSelector( list_target, max ){
this.list_target = list_target;
this.count = 0;
this.id = 0;

if (max) {
this.max = max;
} else {
this.max = -1;
}

this.addElement = function( element ) {
if( element.tagName == 'INPUT' && element.type == 'file' ){
this.id++;
element.name = "fle_upload[]";
element.multi_selector = this;
element.size = "40";

element.onchange = function() {
var new_element = document.createElement( 'input' );
new_element.type = "file";
//new_element.class = "file";

this.parentNode.insertBefore( new_element, this );
this.multi_selector.addElement( new_element );
this.multi_selector.addListRow( this );
this.style.position = 'absolute';
this.style.left = '-1000px';
};

if( this.max != -1 && this.count >= this.max ){
element.disabled = true;
}

this.count++;
this.current_element = element;
} else {
alert( 'Error: not a file input element' );
}
};

this.addListRow = function( element ){
var new_row = document.createElement( 'div' );
var new_row_text = document.createElement( 'input' );
var new_row_button = document.createElement( 'input' );

new_row_text.type = "text";
//new_row_text.class = "text";
new_row_text.size = "45";
new_row_text.readOnly = true;
new_row_text.value = element.value;

new_row_button.type = "button";
new_row_button.value = "Delete";

new_row.element = element;

new_row_button.onclick = function() {
this.parentNode.element.parentNode.removeChild( this.parentNode.element );
this.parentNode.parentNode.removeChild( this.parentNode );
this.parentNode.element.multi_selector.count--;
this.parentNode.element.multi_selector.current_ele ment.disabled = false;
return false;
}

//new_row.innerHTML = element.value;
new_row.appendChild( new_row_text );
new_row.appendChild( new_row_button );
this.list_target.appendChild( new_row );
};
};

[MMCM]

A Pekka said, everything you see on the screen can be captured.
So protecting them of being saved is pretty much useless.

I disable the right mouse click and the image toolbar for IE, but that keeps only the beginners from storing the pictures.

Checking for valid referrers with .htaccess (I do that too), will prevent cross linking pictures from other sites and prevent downloads of single pictures by their direct URL with tools without the ability to pass referrers.
You could block specific user agents too (wget, ...).

BUT:
My primary goal is to protect non public images from public viewers.
With my strict file naming convention, it's simple to guess where to find the files on the server, and how the names are.

A quick & dirty solution for the current EE could be a separate path for each group of images, proctected by browser authentication with .htaccess and .htpasswd.

IMHO the only solution is to move all pictures to a place outside the web tree, and check the access rights of the current user before the delivery.

Copy/rename to the temp folder is an interesting solution, but somehow i don't like it. But isn't that available in the current EE release too?

In the recent discussion about moving to gallery2, I took a look at it too, and I noticed, it stores pictures outside the web root, and uses a separate function to return the pictures.
At least for the thumbnail display, this has a negative impact on performance.

So maybe the optimum solution would be to be able to configure how to return the pictures? On a filetype basis (microthumbs, thums, normal, ...) or on exhibition basis, ...
Everybody could decide how important the protection from unathorized users was.


looking forward to the next EE
Martin

[Pekka]

In EE 2.0 you have the 1.5's "ftp view". It is an effective way of hiding image path and name. Then you'll have "obfuscate http" switch which makes image links show.php links and fetches the image transparently using http protocol while checking privileges. Because all thumbs are printed with one function, it is very easy to make a separate obfuscate switch for larger images, thumbs and microthumbs - I'll add that to todo list.

Note that EE's Ftp view is the only method which can not be cracked without great effort (anything can be cracked!). An experienced cracker can set up http protocol sniffer and perhaps find the http-obfuscated url that way.

Note that EE 2.0 lets you make size path "protected". When it is protected it appears in user editor and you must choose it to give user permission to view it. All others do not see that path at all.

[floydianslip6]

being involved with computers and security it's pretty clear that whatever you do someone can beat. The best you can do is only provide low res, low quality online via a save for web thing. That way the photos can't really be made any larger than the size you provide. Digital watermarking is also a good idea. Other than that, no matter how elaborate you get with the code it's nothing a screen capture can't fix.

[detective]

Do NOT disable Right-Click: it can be bypassed.

One method that works very well is stamping the images with user's name on-the-fly before they are downloaded. This approach allows you to know who stole your image if you find a copy floating on the internet or a Peer-to-Peer network.

So what's so great about knowing WHO STOLE your image? If you collected their CREDIT CARD numbers, you can charge them!!! You know where they live, etc!!! In practice, this is a strong enough deterrent that people don't steal images, since they are not "anonymous" anymore.

Newer generation software can embed visibly and invisibly the user's name into the image. This stamp persists even after screen-capturing, cropping, etc. HTML protector and all the other software mentined in this thread will not prevent screen-capture on FireFox browsers.

A company that does fingerprinting as a subscription service is:
http://www.catchlock.com/

In addition to fingerprinting, they can also do the run-of-the mill right-click disabling and prevent "save-as"

[xenon2000]

Originally Posted by floydianslip6

... that whatever you do someone can beat. The best you can do is only provide low res, low quality online ....

I agree with Pekka and floydianslip6 (and others). Is just a waste of time to try and prevent your images from being saved from your server. Now I do think it's important to be able to keep private pictures private and other made public. But either way, the private pictures could be copied by the private viewers and the public saved by anyone.

Really the best solution is like they said, only put low res images on the server. For me, that is about 1280x960. Maybe for others that is 1600x1200. But keep it low res and if a client or user wants a high res version for printing, you can send it to them via other means, mail, email, scp, sftp ftp, https, etc, etc....

No point wasting a lot of time trying to think of ways to completely protect publicly available content on your server.

Now from what I have read here, is it true that EE (not installed on my server right now) is not setup to keep private pictures private? I would like non authenticated users to only be able to access public images, and authenticated users to only access their group of private images. Such as family pictures and client pictures.

I have seen some gallery apps that appear to be secure because the app doesn't generate the url or page if you are not logged in. But I tested by bookmarking an image and logged out and I was able to go to another PC and view the page. So obviously it wasn't really protected by any authentication methods.

But the ultimate point is, nothing is 100% secure on the internet. Though if someone would make a gallery use 128bit SSL authentication and session based, I think that would be sufficient.

In the meantime, if you are really paranoid, then don't put the image online. Only put online what you are comfortable in being stolen. Such as low res images and pictures of family that you don't mind possibly being stolen. But please do take simple measures to prevent images being directly linked from your server, saves bandwidth. And please, slicing and disabling right-click are pathetic.

[Pekka]

Originally Posted by xenon2000

Now from what I have read here, is it true that EE (not installed on my server right now) is not setup to keep private pictures private? I would like non authenticated users to only be able to access public images, and authenticated users to only access their group of private images. Such as family pictures and client pictures.

EE 2.0 has user authentication for exhibitions and paths.

I have seen some gallery apps that appear to be secure because the app doesn't generate the url or page if you are not logged in. But I tested by bookmarking an image and logged out and I was able to go to another PC and view the page. So obviously it wasn't really protected by any authentication methods.

This is because you view gallery with www browser on screen. The image must be retrieved, that is why path to it must be available to browser. The image must be displayed so it must be stored in RAM and on disk.

In EE, as I have said, the "ftp retrieve method" is the only way to hide paths completely from access. With it, you can place the image folders outside www root which means you can not open the images in those folders with browser. The ftp method gets the image you need to view in temp folder (with random filename) for a short time, which means if you store the URL it won't be there in few moments. Of course the drawback of this is that it is CPU hungry and bandwith hungry, on fast server you hardly notice it but on slower ones it will make a difference - luckily you can set that up for specific images if you like.

But the ultimate point is, nothing is 100% secure on the internet.

Correct! Many say Flash is secure - you can take a screenshot and you have exact copy right there. Nothing is fully safe.

[InZone]

@WarrenO: wrong thread? But your ideas are good!

[leungstanley]

Something we can do, it is better than we do nothing.

[Pelican]

Originally Posted by Pekka

Nothing is fully safe.

Agreed, however most of the suggestions offered here offer no more than a hindrance to anyone wanting your image.

If you want to protect the images stored on the server and in cache, consider using encrypted images that are displayed in a security applet. I'm surprised the option is not mentioned here because its been available since 1998.

If you want to further protect images from screen capture and printscreen, that solution is also available.

Of course there are workarounds to these solutions, but they have been the most secure solutions available since 1998 and it doesn't get better... no-one has comparable solutions despite their claims to the contrary.

Banks and online surveys use these solutions and they are the best available!

Want to know more?

Romp on over to their demo site at www.artistscope.com