Your Daily Source for Apache News and Information  
Breaking News Preferences Contribute Triggers Link Us Search About
Apache Today [Your Apache News Source] To internet.com

Apache HTTPD Links
The Apache FAQ
The Jakarta Project
Apache XML Project
Apache Project
Apache Module Registry
Apache-Perl Integration Project
The Apache Software Foundation
The Java Apache Project
PHP Server Side Scripting
Apache-Related Projects
ApacheCon

  internet.com

Internet News
Internet Investing
Internet Technology
Windows Internet Tech.
Linux/Open Source
Web Developer
ECommerce/Marketing
ISP Resources
ASP Resources
Wireless Internet
Downloads
Internet Resources
Internet Lists
International
EarthWeb
Career Resources

Search internet.com
Advertising Info
Corporate Info
Keeping Your Images from Adorning Other Sites
Jun 14, 2000, 08 :00 UTC (57 Talkback[s]) (41973 reads) (Other stories by Ken Coar)

By Ken Coar

Webmasters are ever searching for ways to make their sites look cool and attractive. One way is to dress it up with images, logos, and other graphics--sometimes referred to as 'eye candy.' Of course, if you happen to be in the forefront of this in any way, you run the risk of having others cadge your art in order to dress up their sites. And they probably won't even ask permission nor pay you a royalty, either.

This article shows how you can use Apache configuration directives to limit access to your art so that it's more difficult to use elsewhere.

The Problem

Simply put, there are two types of "infringement" involved here:

  1. Someone uses an IMG tag on its site to refer to a graphic on yours
  2. Someone downloads an image from your site and makes a copy on its

The first type not only causes your images to prettify someone else's site, but hurts you more directly because visitors to their site are hammering yours to get the images. Your log files get filled with access request entries, your bandwidth gets used -- and you're getting no benefit from it. This type of theft is almost completely preventable.

The second type of theft is more insidious. The 'borrower' doesn't cause your site to get pounded on for access to the images, since they've been copied to the borrower's site, but you probably weren't given any credit for the artwork--and you probably don't even know the theft happened. Because of the way the Web works, this type of theft can't really be prevented, but you can at least make it a little more difficult.

You can't completely prevent either of these, of course, but you can make them more difficult to do.

Identifying the Files to Protect

You're probably not going to want to protect every document on your site. Even if you do, for the sake of this article I'm assuming you only want to protect your artwork. So how do you indicate that the rules only apply to them? With directives such as the following in your server config files:

    <FilesMatch ".(gif|jpg)">
        [limiting directives will go here]
    </FilesMatch>
  

You can put a container such as this inside a <Directory> container, or inside a <VirtualHost> container, or outside any containers at all (in which case it applies to all such files on your server), or even inside .htaccess files. Put it wherever it makes sense to protect what you want protected.

The Key: the Referer Header Field

Down on the wire, where the browsers, spiders, and servers live, every request for a Web page includes a component called the HTTP request header. This contains information about the request, such as the user's preferred languages, the types of documents the client is able to handle -- and not least, the name of the item being requested. This information is conveyed in a series of name/value pairs called header fields.

One of these header fields is of particular importance to what we want to do. It's called the Referer field (yes, I know, it's misspelt--but that's how it's misspelt in the definition, too), and it indicates the URL of the client's last page if and only if the client is following a link. That is, if you're viewing page A, and click on a link to page B, the request for page B will include a Referer field that says "I'm following a link on page A." If no link is being followed, such as if the user just typed B's URL into the Location field of his browser, there will be no Referer field in the request header.

How does this help? Well, it gives us a way to tell whether an image is being requested because it was linked to by one of our pages -- or by someone else's.

Using SetEnvIf to 'Tag' Images

For a simple case, suppose our Web site's main page is <http://my.apache.org/>. In this case, we want to restrict any artwork requests that don't originate on our site (i.e., only allow them if the image was linked to by one of our pages). We can do this by using an environment variable (also called an envariable) as a flag, and setting it if the conditions are right. Something like the following ought to do it:

    SetEnvIfNoCase Referer "^http://my.apache.org/" local_ref=1
  

When Apache processes a request, it will examine the Referer field in the header, and set the environment variable local_ref to "1" if the value starts with our site address--i.e., is one of our pages.

The string inside the quotation marks is a regular expression pattern that the value must match in order for the environment variable to be set. Describing how to use regular expressions (REs) is far beyond the scope of this article; for now, just be aware that the SetEnvIf* directives use them.

The "NoCase" portion of the directive name means, "do this whether the Referer is 'http://my.apache.org/', or 'http://My.Apache.Org/', or 'http://MY.APACHE.ORG/' -- in other words, ignore the upper/lower caseness of the value.

Using Envariables in Access Control

The Order, Allow, and Deny directives allow us to control access to documents based upon the setting (or unset-ness) of an envariable. The first thing to do is to indicate the order in which Apache will process Allow and Deny directives; you do with the Order directive as follows:

    Order Allow,Deny
  

This means that Apache will go through any list of Allow directives it has that apply to the current request, and then repeat the process with any Deny directives. With this ordering, the default condition is 'denied;' that is, no-one will be able to access anything unless there's an applicable Allow directive.

All right, so let's add the directive that will let local references work:

    Order Allow,Deny
    Allow from env=local_ref
  

This will let a request proceed if the local_ref envariable is set (with any value whatsoever). Any and all other requests will be denied because they don't meet the Allow conditions and the default is to deny access.

Note:
Please don't fall into the trap of sprinkling your .htaccess and server config files with <Limit> containers. You almost certainly don't need them, and they'll just confuse the issue. Don't use them unless you really want to have GET requests treated differently from POST requests, for instance.

Putting It All Together

Putting all these pieces together, we end up with a stanza of directives that looks something like this:

        SetEnvIfNoCase Referer "^http://my.apache.org/" local_ref=1
        <FilesMatch ".(gif|jpg)">
            Order Allow,Deny
            Allow from env=local_ref
        </FilesMatch>
  

These may all appear in your server-wide configuration files (e.g., httpd.conf), or you can put the <FilesMatch> container in one or more .htaccess files. The effect is the same: Within the scope of these directives, images can only be fetched if they were linked to from one of your pages.

Note:
As of Apache 1.3.12 and earlier, the SetEnvIf* directives are only allowed in the server-wide configuration files. In later versions, they can be used inside containers and in .htaccess files.

Going Further

I mentioned earlier that you can't fully prevent image theft. That's because of two things, which apply pretty much to the two different types of poaching respectively:

  • Someone who really wants your artwork can always request it using a faked-up Referer value that happens to meet your criteria. In other words, by jiggering up the request so it looks like it's a reference from your site.
  • If someone legitimately views your artwork by going through your pages, the image files are almost certainly in his client's cache somewhere. So he can pull it out of a cached valid request rather than making another one just to pick up the image.

Though it's essentially impossible to foil someone who's really desperate to snitch your artwork, the steps described in this article should make it too difficult for the casual poacher.

Another thing you can do, depending upon how protective you are of your art, is to watermark the images. Watermarking a digital image consists of encoding a special 'signature' into the graphic so that it can be detected later. Digital watermarking doesn't degrade the quality of the image, and can be done in such a way that even a cropped subsection of the image contains the mark, and it's detectable even if the image has been otherwise edited since the mark was inserted. It's even possible to detect a watermark in an image that was printed and then scanned in, having left the digital realm altogether! If you watermark your images, there's an excellent chance you'll be able to prove snitching if you ever find a suspicious image on another site somewhere.

Logging Snitch-Attempt Requests

If you're not sure whether anyone is really after your artwork, you can use the same detection mechanism and envariable to log suspicious requests. For instance, if you add the following directives to your httpd.conf file, an entry will be made in the /usr/local/web/apache/logs/poachers_log file any time someone accesses one of your images without a valid Referer:

    SetEnvIfNoCase Referer      !"^http://my.apache.org/" not_local_ref=1
    SetEnvIfNoCase Request_URI  ".(gif|jpg)"               is_image=1
    RewriteEngine  On
    RewriteCond    ${ENV:not_local_ref} =1
    RewriteCond    ${ENV:is_image}      =1
    RewriteRule    .*                   -     [Last,Env=poach_attempt:1]
    CustomLog logs/poachers_log         CLF   env=poach_attempt
  

This should have the effect of logging all attempts to access your images using one of the potential 'snitching' techniques described in this article. The first two lines set flags for the conditions (that it's an image, and that it was't referred by a local document), the RewriteCond lines check to see if the flags are set, the RewriteRule line sets a third flag combining the two, and the last line causes the logging of the request in a special file if that last flag is set. The log entry is written in the pre-defined 'CLF' format ('Common Log Format'), but you could put together your own format just as easily.

Other Resources

The techniques described in this article are geared toward a single purpose, but illustrate some of the capabilities of the Apache server. Here are some pointers to resources for further investigation:

  • The HTTP/1.1 definition document: <URL:ftp://ftp.isi.edu/in-notes/rfc2616.txt>
  • The main Apache Web site, of course: <URL:http://www.apache.org/>
  • The documentation for Apache and its modules: <URL:http://www.apache.org/docs/>
  • The canonical email response page: <URL:http://www.apache.org/foundation/email-response.html>
    (This page is normally used to respond to email requests for support, but there are lots of good resources listed on it.)

Then there are the specific pieces of the Apache documentation that are directly related to the directives and commands described in this article:

  • The documentation for <FilesMatch> documentation: <URL:http://www.apache.org/docs/mod/core.html#filesmatch>
  • The mod_setenvif documentation: <URL:http://www.apache.org/docs/mod/mod_setenvif.html>
  • The mod_access documentation: <URL:http://www.apache.org/docs/mod/mod_access.html>
  • The mod_rewrite documentation: <URL:http://www.apache.org/docs/mod/mod_rewrite.html>
  • The documentation on the CustomLog directive: <URL:http://www.apache.org/docs/mod/mod_log_config.html>

Conclusion

Custom artwork can result from someone's effort, and taking without permission something that another has created is generally accepted as theft. This article has described a basic way to put your works of art behind a velvet rope--if you're so inclined. It won't stop determined thieves, but it should hopefully stymy or dissuade the more casual ones.


Got a Topic You Want Covered?

If you have a particular Apache-related topic that you'd like covered in a future article in this column, please let me know; drop me an email at <>. I do read and answer my email, usually within a few hours (although a few days may pass if I'm travelling or my mail volume is 'way up). If I don't respond within what seems to be a reasonable amount of time, feel free to ping me again.

About the Author

Ken Coar is a member of the Apache Group and a director and vice president of the Apache Software Foundation. He is also a core member of the Jikes open-source Java compiler project, a contributor to the PHP project, the author of Apache Server for Dummies, and a contributing author to Apache Server Unleashed. He can be reached via email at <>.

  Current Newswire:
Apache Jakarta James Mailserver v2.0a2 Released

PostgreSQL v7.2 Final Release

Daemon News: Multiple webservers behind one IP address

Zend Technologies launches Zend Studio 2.0

NuSphere first to enable development of PHP web services

Covalent Technologies raises $18 million in venture capital

Apache 1.3.23 released

wdvl: Build Your Own Database Driven Website Using PHP and MySQL: Part 4

Business 2.0: Find High Tech in the Bargain Basement

Another mod_xslt added to the Apache Module Registry database

 Talkback(s) Name  Date
  Nice... :)
Nice article, Ken. Good Apache magic. :)

-- Matthew Keller http://mattwork.potsdam.edu/   
  Jun 14, 2000, 15:08:57
  How incredibly stupid...
If you are surfing from beyond a privacy proxy
such as web washer or if you disabled referers
in your browser for privacy reasons, you will
see the site without images at all.

Great concept.
  
  Jun 14, 2000, 18:31:17
  help!!!
i have a real problem but you may just call me stupid im a newbie and proud
i have been using apache 1.3 for 5 days and i have come to a difficult spot i want the virtual hosts to work like any other server eg proper!
if a client types the web address they just get a list of directorys where the
pages are contained i cant get them to show automatically what am i doing wrong
any help would be appriciated (ive never worked with web serving till 5 days ago so please help in nice way) thankyou all!!
  
  Jun 16, 2000, 11:13:16
   Re: How incredibly stupid...
> If you are surfing from beyond a privacy proxy such as web washer or if you
> disabled referers in your browser for privacy reasons, you will see the site
> without images at all. Great concept.

The following line should allow empty referer headers through:
SetEnvIfNoCase Referer "^$" local_ref=1

This slightly reduces the effeciveness, but the linker should still get enough "broken link" complaint mail to make them stop.   
  Jun 14, 2000, 21:20:05
   Re: How incredibly stupid...
Hey, this is actually great, I'm disabling my Referer headers and will speed up loading sites that "prevent" image theft.

However, there is curl, and I assume you would need Authentication to really prevent image theft.   
  Jun 15, 2000, 06:58:07
   Re: How incredibly stupid...
> If you are surfing from beyond a privacy proxy
> such as web washer or if you disabled referers
> in your browser for privacy reasons, you will
> see the site without images at all.
>
>Great concept.

You're clearly concerned about people having
access to your information only in ways you
want to dictate; why should a Web site owner
not be permitted the same concern? *shrug* This
isn't a magic bullet; there is no one solution
for all circumstances. Just because yours may
not be one of the ones it fits doesn't invalidate
its potential usefulness to others.

#ken    P-)}   
  Jun 15, 2000, 09:53:06
   Re: How incredibly stupid...
That is true, many public Proxies filter the Referer field as well as anonymizers and such.

I wouldnt call the concept stupid, the problem is that you cannot rely on _any_ of the fields in the HTTP_HEADER since they can all be faked easily.


regards,

  
  Jun 15, 2000, 10:05:04
   Re: How incredibly stupid...
> If you are surfing from beyond a privacy proxy
such as web washer or if you disabled referers
in your browser for privacy reasons, you will
see the site without images at all.
Great concept.


ROFL. For some reason, I *knew* Kris would find this article and bash it. :)   
  Jun 17, 2000, 16:31:13
   Re: How incredibly stupid...
LOL. Just enable HTTP_REFERER in your webwasher/proxy. The workshop is very good!
  
  Jan 4, 2001, 12:32:45
  Technique
While I tend to agree with the arguments posted by friends Kristian and Wienerdog, I MUST challenge their rather singeing comments. Certainly, it is a valid ROT (Rule Of Thumb) that one wouldn't want to "publish" anything one doesn't wish viewed and/or copied. However, the more important issue here, seems to me to be less what can be done about it than the fact that SOMETHING can be done about it, if one is using Apache.

Thanks Ken for giving us yet another example of the power of a tool that we all have grown to love!   
  Jun 16, 2000, 15:37:51
   Re: Re: How incredibly stupid...
> > If you are surfing from beyond a privacy proxy such as web washer or if you
> disabled referers in your browser for privacy reasons, you will see the site
> without images at all. Great concept.
>The following line should allow empty referer headers through:
>SetEnvIfNoCase Referer "^$" local_ref=1
>This slightly reduces the effeciveness, but the linker should still get enough "broken link" complaint mail to make them stop.

The only problem with THAT, is that it will allow them to type in the URL to the image directly. :-D As Ken mentioned, there is no foolproof solution.

-- Matthew Keller http://mattwork.potsdam.edu/   
  Jun 14, 2000, 22:07:25
  product photos
I have an ecommerce site. If a competitor copies my product photos and puts them on his site, what can I do? Can I sue him? What would be the likely outcome? What kind of proof would I need? What if he alters the photos?   
  Jun 17, 2000, 00:39:59
   Re: product photos
The general policy that I have seen taken in artwork copyright is that if there is significant alteration, then it is no longer your work. For example: in my line of work I produce drawings. Sometimes, my best way of doing this is to have a photograph, reduce it down to 16-greys, lighten it signifcantly, outline it, and then I'm left with a lightly shaded outline that looks like the original.

Of course, I'm satisfied with that if it is my *own* photo. But what if I want to use something for which I have no photo? Well, then I go to the magazines, get several pictures, and paste them together in a near-realistic collage. Then I do the same as above. At that point, it is no longer recognizable either in general form (that is, for example, the body position) or in specific form (that is, detailing). So it is a new artwork, and clearly not copyright infringement.

The same is going to be generally true in lawsuits involving computer artwork theft: the farther it is from the original, the less your chances of recovering are. So if you sell ram disks on ebay, and have pictures of ram chips, and someone else is selling a computer, and shows a collage with *your* ram-chip photo pasted in so that it looks like it was originally part of *his* photo, then probably you won't win much. But if they have *your* photo selling ram ("Just like our competitors! Look at this! The same exact photo!") then you have a better claim of infringement, all other requirements being there.

Not that I agree with this. To me, the rightful definition of property is that which can inherently be controlled, and to limit someone else's productivity is wrong. But as long as the laws say "(c)" and "TM" and "Pat. Pend.", the way to fight our battles is with letters to Congress.

  
  Jan 13, 2001, 21:27:59
  Usefulness
I don't think the real issue here is image theft. Image theft happens often, and web copyrights are difficult to protect. If you put it on the web, don't expect it to not be viewed / mirrored / disassembled.

The most useful purpose for this technique is really only bandwidth protection. Getting broken images in a website would definitely be enough to get another person to mirror their own copy of the image. Individuals could still get to the images by turning of their referer compliance or going directly to the URL of the image, but its still not as convenient.

This is a worthwhile technique.   
  Jun 18, 2000, 22:24:04
   Re: Usefulness
This technique was EXTEREMELY usefull for our site :
http://www.gamers.at protects it bandwith using this technique.
( 15 GIG of downloads (Latest Demo's Etc))
Now they have to link to my page in stead of the file.
  
  Jan 26, 2001, 21:02:19
   Re: Usefulness
Have to aggree there. Using techniques like this on your site/server to protect large files from external referring is definitively a good idea to protect bandwidth. On the issue of image theft, well that _is_ a badly chosen frase...

-mistr   
  Feb 11, 2001, 19:17:53
  OK, what am I missing?
We're using 1.3.6 with mod_setenv compiled in. While using the following in an .htaccess file for a test directroy, we're getting the dreaded Internal Server Error. It would be great for us to use this not only for ,gif/,jpg, but mainly for our .html and php3 files that are linked to from outside our domain. Any help would be appreciated. Thanks.

SetEnvIfNoCase Referer "^http://www.[our domain].com/" local_ref=1

Order Allow,Deny
Allow from env=local_ref
  
  Jun 19, 2000, 08:43:08
   Re: OK, what am I missing?
> We're using 1.3.6 with mod_setenv compiled in.
> While using the following in an .htaccess file
> for a test directroy, we're getting the dreaded
> Internal Server Error.
>
> SetEnvIfNoCase Referer "^http://www.[our domain].com/" local_ref=1
> Order Allow,Deny
> Allow from env=local_ref

As I pointed out in the article, you can't use SetEnvInf*
in .htaccess files *after* 1.3.12. You need to put these
(or at least the first one) into a <Directory> container
in the httpd.conf file.

#ken    P-)}   
  Jun 19, 2000, 14:24:32
   Re: Re: OK, what am I missing?
> > We're using 1.3.6 with mod_setenv compiled in.
> While using the following in an .htaccess file
> for a test directroy, we're getting the dreaded
> Internal Server Error.
>
> SetEnvIfNoCase Referer "^http://www.[our domain].com/" local_ref=1
> Order Allow,Deny
> Allow from env=local_ref
As I pointed out in the article, you can't use SetEnvInf*
in .htaccess files *after* 1.3.12. You need to put these
(or at least the first one) into a container
in the httpd.conf file.
#ken P-)}


I expect you mean _UNTIL_ after 1.3.12 which is what the article seems to say.
Anyway, is there any way to get around this problem for someone who doesn't have access to the httpd.conf file and is using an older version (1.3.9?) I need to protect some files from being downloaded except via one particular page.   

  Aug 22, 2000, 15:49:42
  Does this break with MSIE?
Several years ago, in an attempt to stop piracy of some weather images (other Web sites were including them illegally on their pages), I did some experimenting with a CGI-driven solution that checked the HTTP_REFERER ... worked just dandy with Netscape, broke miserably with Microsoft Internet Explorer. It seemed that Microsoft was not sending referer data when following IMG tags. Is that still a problem? Has this solution been tested thoroughly with multiple browsers?   
  Jun 25, 2000, 14:22:29
  Not a problem
This strikes me as a non-issue, and somewhat reminiscent of the concerns expressed by rank amateur programmers worried that people could look at their HTML code and rip off their way-kewl image rollover scripts. Consider that most sites whose "Webmasters are ever searching for ways to make their sites look cool and attractive" are generally light on content and so don't get many visitors. Furthermore, sites that are merely a conglomeration of "cool and attractive" images pilfered from other sites tend to be even more content-light and attract fewer visitors still. This leads one to the conclusion that, in all likelihood, your site isn't going to suffer much additional traffic in requests for inline images linked from other Web pages, and any copied images aren't likely to see too wide an audience.

Even if someone did copy your art and put it on a high-traffic Web site, you'd likely find out about it -- it is a high-traffic site, after all. And if the high-traffic site was linking to your images, it's easy enough to see where all of those HTTP requests are coming from. In either case, you can certainly contact the Webmaster and ask that they make local copies and acknowledge your authorship, ask them to stop using them altogether, or, perhaps, file a lawsuit.

Assuming, of course, that you think your images are so good that people will want to pilfer them in the first place (instead of taking any of the thousands upon thousands of Web page decorations that are freely and openly distributed), and that you further think that letting other people use your stuff is a bad thing.

Not to mention the cardinal rule of the Web: if they can see it, they can make a copy of it. In fact, if they can see it, they already have a copy of it. If you don't want people making copies of your content, post notices on your site to that effect. If that's not enough protection, don't put them on the Web in the first place.   
  Jun 14, 2000, 19:33:57
   Re: Not a problem
> This strikes me as a non-issue

Well, I receive enough mail asking about
it that I figured it warranted coverage.

#ken    P-)}   
  Jun 15, 2000, 10:16:30
   Re: Not a problem
The need to protect artwork is that a business needs to protect its logo so that unauthorized people can not use it. It would be nice if there were some way for the HTML to tell the browser that the work is protected so that it can not just be downloaded.   
  Jun 16, 2000, 21:28:32
   Re: Re: Not a problem
I've been doing something similar to this for a while, because I've had repeated problems with people stealing bandwidth in this way from my site (www.fractalus.com). My site has thousands of original images, so it is hardly "content-free", and they're not stolen from other sites at all.

Most of the time when people link directly to images, it is NOT a big deal. It's a nuisance, and it's certainly not the way the artists want their work displayed, but compared to the normal amount of traffic the server does, it's pretty inconsequential. But in a few cases the exact opposite is true. The most egregious case was when someone used one of the images as their "photo" in a web chatroom. Over the course of two days my server handled thousands of fulfilled requests for a single image (normally viewed less than a hundred times in a week) and many gigabytes in traffic, all from other visitors to the chat room requesting the image from my server.

Yeah, OK. Small potatoes. What's a few gigabytes of traffic, after all? Well, that depends on your host. Had I not removed the image in question until I could find a more permanent solution, I might have had four times my monthly traffic... which would then be money directly out of my pocket for bandwidth fees.

It would be nice if people had more consideration for the work of others, but even if 95% do... the 5% that don't are enough to be a major pain in the neck.
  
  Jun 16, 2000, 20:56:24
   Re: Re: Not a problem
> The need to protect artwork is that a business needs to protect its logo so that unauthorized people can not use it. It would be nice if there were some way for the HTML to tell the browser that the work is protected so that it can not just be downloaded.

As I believe someone pointed out, your browser can't display an image *until* it is downloaded. It's not psychic after all ;).

This is of course the crux of the problem. An aproach that involves having your server *serve* because that's what it's there for avoids the problem, except as it relates to stolen bandwidth.

Those pirates should be hunted down and introduced to an appropriate LART.

CC   
  Oct 20, 2000, 00:44:00
   Re: Re: Not a problem
> ... It would be nice if there were some way for the HTML to tell the browser that the work is protected so that it can not just be downloaded.

There are JavaScript routines that do this although all you have to do is disable JavaScript support in the browser to get around it.

The problem with doing this in HTML is that there are open source browsers out there, and it would be just a matter of time before a version that ignored such 'protection tags' would be available.

  
  Mar 16, 2001, 03:44:43
   Re: Re: Re: Not a problem
Would it be possible to make a construction that would serve the correct picture if asked from within your site and another message/picture if asked from outside?

This would open a host of options for making your point more or less polite (at your discretion)   
  Feb 6, 2002, 11:28:57
  Protecting (java / css) scripts
I want to do something simelar to this.

I include css en java scripts in my html pages from a /js/ directory containing only the scripts. I don't want anyone to be able to approach the scripts directly and see the source of it, but I do want the homepage to be able to load them (duh).

This seems to be hard to configure. Using referrer doesn't really work.

Does anyone have ny bright idea's? Help would be great, mail me please.   
  Oct 25, 2000, 09:12:06
  It works great - thanks for the workshop !!!
Hi,

I just integrated these lines into my httpd.conf and it works great for my download-site! Nearly all off my users can download my files without a problem. Only a few users run into difficulties or are stealing my bandwith.

Thank`s a lot!!!

Sebastian   
  Jan 17, 2001, 19:31:15
  100% Protection of Images
I created a plug-in for both Netscape and Internet Explorer that works with specially altered images. Using the encrypting program I designed, it infiltrates an image file (gif or jpeg) with "static" that follows an algorithm that is user-defined. This can be performed in batch-mode -- converting thousands of images if necessary at one time. Then the only way to view the images is when the plug-in is accepted on the client (the people accessing your site). In the end, if the client doesn't allow the plug-in to be installed, then all the encrypted images appear as corrupted (completely unviewable) images. With the plugin installed, the images appear crisp and clear. Saving the images, whether the plug-in is installed or not, still prevents the user from fiewing the images by themselves. Also, the plug-in is designed so that the images must be embedded in IMG tags or they will not "decode" the images. In short, dragging an encrypted image into a browser window where the plug-in is installed will not reveal the image. So far I have not found anyone who can get around this image encryption. I'm getting a patent on it this spring.   
  Feb 21, 2001, 02:31:20
   Re: 100% Protection of Images
Schemes that attempt to encrypt Web images are useless against anyone who knows how to do a screen capture. Images captured this way retain all the quality of the original. Security software that attempts to disable screen capture can be easily circumvented by a determined programmer. It seems to me that the most fruitful solution is to vigorously enforce existing copyright protection, rather than to attempt yet another bound-to-fail user-unfriendly technological solution.   
  Mar 9, 2001, 18:20:35
  Apache and Oracle
Hello,
I have a small Web site using an Oracle 8i database and the Oracle 9i Application Server, w/ Apache HTTP server. I am using the mod_plsql cartridge to access the database. The problem I am having is getting images to display. I understand that all Apache configuration is done through .conf files using simple text. I believe I need to define a virtual map of some sort that corresponds to the physical location of the images I want to display, which are stored on disk in a directory. Could someone please give me some direction and maybe an example or two that explains how to do this? Thank you.

Sincerely,
Chris Shaw   
  Feb 26, 2001, 19:03:36
  the next step
I had basically this same thing in my conf and its been working just fine. What I'd like to do, but can't seem to find a way to, is to have a small image sent instead of the requested one. I know that angelfire.com and the likes do this. Anyone got any bright ideas?   
  Feb 27, 2001, 02:55:32
  Great, thanks!
Hey, this is exactly, what I was looking for!
Great article, thank you!
(Well, call it non-bullet-proof, but it IS a working measure against casual image link-theft!)

Yours,
Thomas   
  Mar 13, 2001, 09:08:59
  There is NO such thing as image protection
Images can't be protected from copying on the Web. That's it.

For those who don't agree, I just wanted to refer to a good example of a long and conclusive discussion among concerned photographers and people with programming experience:
How to protect photos from being downloaded (photo.net).

Still, there is a number of commercial 'protecting schemes' that make a lot of money off artists that are happy to remain deceived.   
  Mar 17, 2001, 22:23:38
  Stop Thief
Stealing is a form of compliment. I don't care if people "steal" images on the web. If they link a little, I really don't care. If they link a lot, I can see it in the log and block them.   
  Mar 29, 2001, 14:20:10
  enlightement
ah, now i know why when i shift-click (download link) on those pr0n-thumbs it downloads some rubbish html in a jpeg file!

thanks for the enlightement (sic?) ... but damn it's still annoying as hell ;-]   
  Mar 30, 2001, 16:26:48
  not theft protection, but retrieval path enforcement
Great article! Covered exactly what I needed.

I've got piles of my own music on my website, but I'm not trying to stop people from "snitching" it; rather, I explicitly WANT to give it away for free (see www.boywithmachine.org). However, I want people to see my top-level copyright notice first, so they know what my wishes for redistribution are (i.e., that the music be effectively "GPL'ed")--after that, it's their ethical decision as to whether they'll comply with my wishes or not. Through a combination of several tactics, including those outlined in this article, my server logs would indicate that I have successfully stopped web-crawling scripts that search for "*.mp3" from just grabbing my music directly.

Thanks a lot for putting this together!   
  Apr 3, 2001, 20:18:01
  HTTP_Referer

Hello,

I want to be able to stop anyone from loading pages if they the
referer is from anything other than "http://myhome.com".

How can I do this in Apache web server.

Thanks
Shami
  
  Apr 9, 2001, 11:17:42
   Re: HTTP_Referer
You shouldn't stop them from loading, You should redirect them to "http://MyHome.com". Thus allowing them to view/enter/enjoy your site through the front door only.   
  May 12, 2001, 01:44:50
  How do I ensure SSL is being used
I would like to configure my .htaccess so that all hits to http://myhost/ssl/* are redirected to https://.. for secure connection. Is this possible.

Also, is it possible to map a directory out of my main web tree using .htaccess? eg.

say http://myhost/ is stored in the main www ~/myhost/htdocs/ but I want any hits to http://myhost/cgi mapped to ~/myhost/cgi out of the main www tree.

Thanks.   
  May 16, 2001, 14:53:26
  Prevent "Site Theft"
Hello,
I need to stop my "Site Theft":
I've modified my apache httpd.conf in this way:

SetEnvIf Referer "^http://my.site.it/" ref_local
SetEnvIf Referer "^http://my_own.site.it/" ref_local
SetEnvIf Referer "^$" ref_local

Order Deny,Allow
Deny from all
Allow from env=ref_local


It seems to work fine if I use IE browser, but it doesn't work using Netscape

Do you have some idea?
I've tried to remove
SetEnvIf Referer "^$" ref_local
and Netscape seems to works too.
But I need this rule because a lot of customers use bookmarks

Thanks

francesca
  
  Jun 5, 2001, 14:39:03
  mod_rewrite
How Logging Snitch-Attempt Requests if i have not the mod_rewrite?
Thanks   
  Jun 14, 2001, 01:09:05
  How to trigger a PHP script thrue htaccess
Do anyone know of a way to trigger a php script thrue htaccess

David   
  Jun 16, 2001, 20:29:52
  HTTP_REFERER problem
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://www.domain.com/ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.domain.com [NC]
RewriteRule /* http://www.otherdoamin.com/ [R,L]

How to combine the second and the third strings into one? I'm asking because entering the URL directly in IE without slash on the end sometimes causing the wrong HTTP_REFERER. I'm using this file for referer-based protection.   
  Jun 18, 2001, 13:35:09
  I just can't seem to get it to work...
Please Help,

I operate a clipart site and I have a HUGE problem with image theft. In fact, I actually have higher bandwidth usage resulting from theft than with authorized use.

I've tried every variation of this technique I can think of without success. The apachee version is 1.3.1. The browser is microsoft ie5.5 My hosting provider says "this is my poroblem" and they won't help. Here's what I've tried:

my server runs the earlier apache version 1.3.1, I've tried the following in httpd.conf, access.conf and srm.conf without success:

SetEnvIfNoCase Referer "^http://[mydomain...]/" local_ref=1

Order Allow,Deny
Allow from env=local_ref



I replaced [mydomain...] with my domain. The above resulted in a fatal error when I tried it in httpd.conf. It had no effect in access.conf and srm.conf

I've also tried spliting the directives into two parts, with the "SetEnvIfNoCase Referer..." portion being placed in one of the server configuration files and the " " portion being placed in .htaccess of the directory in which I would like to prevent image theft from occuring.

So, first I placed the following into .htaccess:


Order Allow,Deny
Allow from env=local_ref


I tested the above stanza by itself, which caused any files ending with .gif or .jpg to be excluded from view in all cases. This was expected since "local_ref" would not be set until the "SetEnvIfNoCase Referer..." statement is included in the appropriate .conf file.

So, I then placed the following in httpd.conf without success. I also tried it in access.conf and srm.conf with no luck in all cases:

SetEnvIfNoCase Referer "^http://my.domain.../" local_ref=1

I replaced my.domain in the above statement with my own domain. It didn't work no matter what I did! I even tried it with www. without success.

I also tried the variation below in httpd.conf without success:

SetEnvIf Referer "^http://[my domain]/" local_referal
# Allow browsers that do not send Referer info
SetEnvIf Referer "^$" local_referal

Order Deny,Allow
Deny from all
Allow from env=local_referal


The above prevented execution of tags embedded in .htm files, but had no effect on .htm .jpg or any other files themselves.


I remember reading in one of the email threads that earlier microsoft browsers would not pass the appropriate referrer header info, so could this still be the problem in newer versions if IE5.5? Please advise.

Also, are there any placement stipulations for the "SetEnvIfNoCase..." and related statements that are to be inserted into the .conf file? I'm not an expert in Apache by any means, so maybe the issue is purely syntactical or placement. Any ideas?

Also, is there a way I can test the value of local_ref or the value of the referrer header so I can see the contents of each of these?

I've tried everything I can think of. Any help on this will be much appreciated. Thanks!
  
  Jun 18, 2001, 22:52:34
   Re: I just can't seem to get it to work...
Just a quick addendum regarding the referenced posting of which I am the author:

The container statements did not appear in my original post because I included less-than and greater-than signs, so I'd like to clarify that I used filesmatch and directory containers in the examples I cited in the original posting for the "order allow deny" statements. The "SetEnvIfNoCase Referer" statements were not placed in any container.

Sorry for the confusion; I didn't know that greater-than and less-than signs won't display properly!   
  Jun 19, 2001, 23:58:12
  re http referer
I used to use the following in my .htaccess to provent people from hotlinking to my real audio files.
However after I upgraded to apache 1.3.x, it stopped working, any ideas?

RewriteEngineRewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://([a-z0-9-]+\.)*biensuave.com/ [NC]
RewriteCond %{HTTP_REFERER} !=""
RewriteRule /* http://%{HTTP_HOST}/ [R,L]   
  Jul 7, 2001, 21:03:24
  what about .png files?
I'm running apache locally to test ssi and such, and I found this article and added .(gif|jpg|png) figuring it would work, and now the png files won't load. Does apache not like png (Do I need to do something extra?) Running apache 1.3.20 (Win32) ...this is from httpd.conf

<Directory />
SetEnvIfNoCase Referer "^$" local_ref=1
SetEnvIfNoCase Referer "^http://127.0.0.1/" local_ref=1
<FilesMatch ".(gif|jpg|png)">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>   
  Jul 10, 2001, 02:16:45
  protecting artwork
this is just for those of you who need images protected. I had my site up for about 2 yrs till I decided to stop running the buisness due to health reasons. There are ways to stop 99.9% of image theft. some is theorugh the uses of javascript as well. and Perl cgis. I had a hacker friend try to steal some images and he failed miserably. So for those of you who *think* you know it all, stop being a pain in the butt for those of us who *do* know something about the subject.   
  Nov 30, 2001, 04:01:08
   Re: protecting artwork
> this is just for those of you who need images protected. I had my site up for about 2 yrs till I decided to stop running the buisness due to health reasons. There are ways to stop 99.9% of image theft. some is theorugh the uses of javascript as well. and Perl cgis. I had a hacker friend try to steal some images and he failed miserably. So for those of you who *think* you know it all, stop being a pain in the butt for those of us who *do* know something about the subject.

Wow your "hacker" friend didn't know how to get the image out of his cache?

Doesn't matter because the trump is always: SCREEN GRAB.   
  Nov 30, 2001, 21:54:30
  Re: 100 Protection of Images
>Also, the plug-in is designed so that the images must be embedded in IMG tags or they will not "decode" the images. In short, dragging an encrypted image into a browser window where the plug-in is installed will not reveal the image. So far I have not found anyone who can get around this image encryption. I'm getting a patent on it this spring.
Save your patent. Not only has this already been attempted, I have two words for you:

SCREEN GRAB.   
  Nov 30, 2001, 21:50:35
  Multiple refferers
I have a group of sites that all all share graphics from each other. How can I add extra domains to this tag:
SetEnvIfNoCase Referer "^http://my.apache.org/" local_ref=1

Thanks ahead of time

G   
  Dec 7, 2001, 03:46:41
   Re: Multiple refferers
Just add another line:

SetEnvIfNoCase Referer "^http://my.abc.org/" local_ref=1
SetEnvIfNoCase Referer "^http://my.xyz.org/" local_ref=1

Each line just "set if..." but won't "un-set if not...", so u can add as many as u like.

:Parabola


> I have a group of sites that all all share graphics from each other. How can I add extra domains to this tag:

SetEnvIfNoCase Referer "^http://my.apache.org/" local_ref=1

Thanks ahead of time
G   
  Dec 10, 2001, 04:24:13
  Re: How Incredibly Stupid
You wrote:

If you are surfing from beyond a privacy proxy
such as web washer or if you disabled referers
in your browser for privacy reasons, you will
see the site without images at all.

Great concept.

Yes what a FANTASTIC concept! I run a free ecard site, paid for by sponsor advertising. If you can't look at the ads then you haven't earned the right to SEE the images. Up with NO IMAGES AT ALL if you're surfing behind Web Washer - unless you'd rather pay an entry fee.   
  Jan 12, 2002, 04:09:30
  It doesn't work ...

Hi

I'm running 1.3.22 and put this code in a vhost container:

SetEnvIfNoCase Referer "^http://www.mysite.com/" local_ref=1

Order Allow,Deny
Allow from env=local_ref


Not only does it not keep people from linking to those file types, but every page gives a 403 the first time it is hit! Regreshing each page then allows it to display properly ... Any ideas?

Thanks!   
  Jan 13, 2002, 05:21:18
  Protecting artwork
Do these methods of protection work when inserted in an html document?
How does a person disabled an e-explorer protocol anyway?   
  Jun 16, 2000, 04:08:06
Enter your comments below.
Your Name: Your Email Address:


Subject: CC: [will also send this talkback to an E-Mail address]
Comments:

See our talkback-policy for or guidelines on talkback content.

About Triggers Media Kit Security Triggers Login


All times are recorded in UTC.
Linux is a trademark of Linus Torvalds.
Powered by Linux 2.4, Apache 1.3, and PHP 4
Copyright 2002 INT Media Group, Incorporated All Rights Reserved.
Legal Notices,  Licensing, Reprints, & Permissions,  Privacy Policy.
http://www.internet.com/