Requirements;
My situation requires that the original image be overwritten with the watermark and degraded somewhat to a 60% JPEG file so that unauthorized downloads are unusable.

Action Taken:
I installed and implemented the imagecache_actions watermark function. Watermarks are displayed on the original image when viewed in the browser when the cursor is off the image. When the cursor is placed on the image, the watermarks disappear. This is great as long as the image cannot be copied either by [prt sc] or other means.

Perceived Problem:
1. Users can use [prt sc] to screen capture the image without the watermark.
2. If the browser's [Inspect Element] is used, the original image without the watermarks can be downloaded by a knowledgeable user using the folder information displayed by [Inspect Element].

My Question
Since the purpose of watermarking is to prevent unauthorized use of images, I would think that having the original image still accessible is not to be expected. Am I correct and, if so, could you please tell me what steps I should take to ensure that unauthorized is not achievable?

FYI
Image Style:
Overlay: source image to canvas xpos:0, ypos:0 alpha:100%
Overlay (watermark) sites/all/modules/imagecache_actions/tests/watermark_3x3.png x:0, y:0 alpha:100%
Scale width 3000

Environment: Cloud Zoom in Commerce Kickstart:
Slide image style : watermark_3000x3000
Zoom area image style : keyword_positioning
Gallery settings
Gallery mode : 0
Thumbnails image style : keyword_positioning
Zoom area possition
Zoom width : auto
Zoom height : auto
Position : inside
Adjust X : 0
Adjust Y : 0
Zoom style
Tint : false
Tint opacity : 0.5
Lens opacity : 0.5
Soft focus : 0
Smooth move : 3
Show title : 1
Title opacity : 0.5

Comments

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

You can never protect files that are on or below your virtual root. So you should use the private file system to store your original images. I never personally worked with it, but I guess you need to set up some permissions for who may access private files (as well as who may upload or delete them).

If this answers your question please close the issue.

jparker’s picture

jparker commented

Thanks for your reply.

Yes, I fully agree with what you have stated. I have created such a path for the files that paid users can download their file(s) from.

My purpose in asking the question is to confirm whether or not the results that I have with the module are the expected results. Namely, are the images presented on the browser screen actually processed with the watermarks in them or is the watermark merely being layered over the image as it is displayed without effecting the original image?

Based on the results I am getting, it is the latter. If so, then I will locally process the images prior to their being uploaded for display. No big thing but just a step that I would like to avoid if possible.

dman’s picture

dman commented

What you describe is a side-effect (probably intentional) of the "Cloud zoom" behavior.
The imagecache_actions pipeline does generate a full, unique image with the effects applied (not just layered) and that is what is displayed to the screen when rendered. That image would be the 'degraded' one, and would be what a normal user gets if trying to save it.

However, another module, like lightbox, or the one you are using, has the option of *replacing* that image with the path to the original, or maybe an alternative bigger image derivative. Then that image is available to anyone who can see it in their browser.

The normal image processing pipeline does not have any security restrictions built into it, though it respects the 'private' file settings. I'm not aware of any existing solution that will let you upload the original as 'private' but make the just the derivative 'public'.
When using the public uploads, it's near-trivial for anyone with knowledge of the Drupal file system to find their way to the original file through URL-hacking, and there is no prevention of this (though someone may have built it).

I understand what you are asking for, but it's outside of the scope of imagecache_actions, as control of this would have to happen at a higher level, around the field display options or somewhere. image processing merely takes an image, changes it, and saves the new copy nearby. It's up to the system (core image module) to decide how to render it.

To answer your question - yes, a new modified image is created by imagecache_actions - it's not a browser-side 'layer'
But cloud_zoom has the ability to bypass the use of that image and display the original if it chooses to do so. That may be what seems to be looking like a 'layer' effect in your browser. It's actually a different image.

I'd say either cloud_zoom is incompatible with what you are trying to do, has an option that you are not yet using (use a different, also-watermarked bigger version as its substitute), or this would be a feature request against that module.

jparker’s picture

jparker commented

I greatly appreciate your detail explanation. Thanks for the time and effort you put into it. It was very helpful.
I will look a little more into the settings I have for Cloud_zoom to see if I can find another option as you suggest. If so, I will list it here later. If not, I will watermark the images prior to uploading them with cloud_zoom.
Thanks again!

Looking at the image module (admin/config/media/image-styles), I found the following statement: "Image styles commonly provide thumbnail sizes by scaling and cropping images, but can also add various effects before an image is displayed. When an image is displayed with a style, a new file is created and the original image is left unchanged."

So there ya are...... I should be a bit more careful when reading.....

Thanks for all your replies.

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented
Status: Active » Closed (works as designed)

I guess that your questions have been answered. If not, feel free to reopen this issue.