Slashdot Mirror


Dealing with Deep-Linking to Your Online Photos?

Pig Hogger asks: "I've had my own hobby website since 1993, and over the years it has expanded to be quite a reference for the domain I am covering (some pro websites list it as additional reference, and so does Wikipedia. Google page-ranks it amongst the top). Every so often, I peruse the logs, most especially looking at the referrers to see where people come from, and once in a while, I notice that some webloggers deep-link to an image on my site. I do not mind too much when it's on-topic, but when it's not *AND* it's sucking-up bandwidth, I tend to be irked. Or worse, when you can't go look at the referring page without registering on the weblog site. In those cases, I change the picture filename (and the corresponding webpage that calls it), and I substitute a smaller (and most often, naughty) picture. What other tricks those of you are facing the same problem have to address this problem?"

139 comments

  1. irked? by Anonymous Coward · · Score: 1, Funny

    > I do not mind too much when it's on-topic, but when it's not *AND* it's sucking-up bandwidth, I tend to be irked.

    And you ask this question on Slashdot? Why don't you tell us the URL?
    We will show you what deep linking can feel like.

  2. Use a CGI script to block them. by MooseGuy529 · · Score: 3, Informative

    What most websites do is use a CGI script that blocks by Referer and/or IP Address (so like allow any request with your site as a referer, or any IP that has requested another page within the past ~5 minutes, in case people hide referers with crappy paranoid firewalls). You could make it generate a list of pages for you to easily review and allow or block.

    --

    Tired of free iPod sigs? Subscribe to my blacklist

    1. Re:Use a CGI script to block them. by miu · · Score: 2
      This technique is actually so common that wget has an option get around it. If external links directly to your images, downloads, or mail sending scripts is really is a problem for you I'd think that 'unlock this resource for this ip when ip requests this page' methods are slightly more effective, although a dynamic system that changes the referring page and the target on a periodic basis or per session (automate what the question submitter mentioned as his method) could be better.

      HTTP headers are so incredibly easy to fake that methods that depend on them are probably a bad idea

      --

      [Set Cain on fire and steal his lute.]
    2. Re:Use a CGI script to block them. by pv2b · · Score: 2, Insightful

      So you can tell wget to lie to the web server when raiding your favorite web page for images.

      That's not what the person asking the question asked for. He wants to stop sites from deep-linking his jpegs, not protect his nuclear launch code CGI to be used only from his own home page.

      A simple filter which would require the referer to be on his web site would pretty much stop his problems anyway. The people deep-linking to his web site write their web pages for browsers with <img src> tags, and as far as I know, you can't in HTML tell the web browser to fake a referer header. Then again, I'm not a HTML-head...

      And it's not really practical to tell your user to use wget to download your web site either. :-) At that rate, it's probably easier to mirror the image. Problem solved.

    3. Re:Use a CGI script to block them. by AndroidCat · · Score: 1

      The OP was complaining about the bandwidth. An occasional hit from wget isn't as likely to be a problem. Most broswers aren't set up to fake headers, and certainly not at the direction of site x that's linking pictures from site y.

      --
      One line blog. I hear that they're called Twitters now.
    4. Re:Use a CGI script to block them. by miu · · Score: 1
      My point is not that wget can get around 'referer' header filters, but that the technique itself is a very weak protection. The fact that wget has a built feature to get around it shows that a large number of people are already aware of the technique and how to defeat it.

      Since referer restriction is becoming common I bet it is only a matter of time before web board software comes up with a script for all signature images. The signature img tag is rewritten from www.whatever.tld/myimage.jpg to www.board.tld/img-sig.cgi?www.whatever.tld and a request that fakes up a referer header to make the request look like an internal link from www.whatever.tld sent instead by way of the cgi.

      I know this isn't rocket science or supposed to be secure, but header based security is so weak that if it becomes an irritant people will automate a way to break it.

      --

      [Set Cain on fire and steal his lute.]
    5. Re:Use a CGI script to block them. by miu · · Score: 1

      I don't think that wget itself is likely to be a problem, it merely illustrates a desire to defeat 'referer' restrictions. In my previous reply in this thread I describe a simple cgi that could easily become part of webboard code to handle signatures and automate the process of faking a referer header.

      --

      [Set Cain on fire and steal his lute.]
    6. Re:Use a CGI script to block them. by pv2b · · Score: 1

      I'm sorry, I'm not so skilled in the ways of HTML. But can the proper javascripts or HTTP headers tell a browser to fake a referrer header?

      Or do you mean that the CGI script goes to fetch it, and then relays it to the user? That could work, but the bboard software would be retarded not to cache it in that case.

    7. Re:Use a CGI script to block them. by JimDabell · · Score: 2, Insightful

      My point is not that wget can get around 'referer' header filters, but that the technique itself is a very weak protection.

      No, it's very strong protection. You seem to think that this is some sort of anti-copying measure. It's a way of protecting server resources. Nobody's going to bother deep linking when 99% of their visitors are going to get broken images. They'll just copy it to their own server instead.

      I bet it is only a matter of time before web board software comes up with a script for all signature images. The signature img tag is rewritten from www.whatever.tld/myimage.jpg to www.board.tld/img-sig.cgi?www.whatever.tld and a request that fakes up a referer header to make the request look like an internal link from www.whatever.tld sent instead by way of the cgi.

      Why on earth would somebody do that instead of simply copying the image to their server?

    8. Re:Use a CGI script to block them. by miu · · Score: 1
      Why on earth would somebody do that instead of simply copying the image to their server?

      Some people might just copy the image, but a system that just works transparently has the potential to be more popular. Once such a script is written it works the exact same way that an img tag would.

      --

      [Set Cain on fire and steal his lute.]
    9. Re:Use a CGI script to block them. by Anonymous Coward · · Score: 0
      Why on earth would somebody do that instead of simply copying the image to their server?
      Um... because, why in the world should they waste their own resources (i.e. hosting the image on their machine, using their bandwidth) when they can plunder the resources of someone else? You seem to forget that more people operate in a mode in which they only care for their own self, and not for the concerns or problems that they may place on other people.
    10. Re:Use a CGI script to block them. by JimDabell · · Score: 1

      Um... because, why in the world should they waste their own resources (i.e. hosting the image on their machine, using their bandwidth) when they can plunder the resources of someone else?

      Read the comment again. It's not a method to trick browsers into requesting the image with a particular Referer header. The method suggested uses double the bandwidth as simply hosting the image themselves - once when the CGI downloads from the original server, and once when the CGI serves the image to the visitor.

    11. Re:Use a CGI script to block them. by arkanes · · Score: 1

      Yes, but nobody would actually do that because it would defeat the purpose of the deep-link, which is to *not host the image themselves*. It's a lousy way to prevent someone from spidering your site, but it's a really good (and effective) way of preventing deep-linking.

    12. Re:Use a CGI script to block them. by JimDabell · · Score: 1

      You could just as easily write a script that will save the images locally. This would work quicker and use half the bandwidth.

    13. Re:Use a CGI script to block them. by |<amikaze · · Score: 1


      Except for the fact that it also uses more resources on the server than just straight copying would. You're doubling the bandwidth needed (1 "unit" to grab the image from the other server, 1 "unit" to send it off to the client).

    14. Re:Use a CGI script to block them. by miu · · Score: 1
      There is no need to "trick" browsers into sending any particular value for referer, it is optional and somewhat freeform - a browser could be completely complaint with all standards and set the referer on every request to match the domain of the resource being requested. I used a cgi to illustrate for convenience because it shows an easily understandable way in which arbitrary headers can be injected into a request, I'm certain there is some client scripting method to manipulate the headers of requests for embeded objects.

      Any dependancy on unverifiable information supplied by the client is dangerous and the level of actual protection it affords is trivial.

      --

      [Set Cain on fire and steal his lute.]
    15. Re:Use a CGI script to block them. by Anonymous Coward · · Score: 0

      Instead of using the Referer or IP, why not use a cookie?

      My site uses an Apache/Tomcat setup and Tomcat automatically sets a session cookie when the user first hits my site. So I just have an Apache mod_rewrite rule that redirects all resource requests (images, flash, audio, video, etc) through a servlet. It's a simple check to see if there was a session prior to the current request. As an added bonus, it's trivial to add simple caching to the resource servlet to cut down on disk I/O.

      I imagine a similar setup could easily be used by php/perl/asp sites.

    16. Re:Use a CGI script to block them. by JimDabell · · Score: 1

      There is no need to "trick" browsers into sending any particular value for referer

      You're looking at the little details but missing the big picture.

      I know that the Referer header is optional. I also know that virtually everybody transmits an accurate Referer header.

      If you deep link and the person you are deep linking to filters based on the Referer header, sure, there will be a few people who have switched off their Referer header that will see what you intended them to see. But most people won't.

      This is why it is an effective way of stopping people from deep linking. They don't want to deep link if only 1% of their visitors will see it. They don't want to deep link if it means they have to tell their visitors to reconfigure their browsers.

      It simply doesn't matter that the Referer header is untrustworthy. You are using it to deter other web developers from misappropriating your bandwidth, not as a means to stop every last page load from working.

      it is optional and somewhat freeform

      It is not freeform, as per RFC 2616, it is a relative or absolute URI.

      I used a cgi to illustrate for convenience because it shows an easily understandable way in which arbitrary headers can be injected into a request

      You used a CGI because that's the only reliable way of doing it. It's also pretty nonsensical because it's a waste of bandwidth, which is exactly what deep linkers want to avoid.

      I'm certain there is some client scripting method to manipulate the headers of requests for embeded objects.

      I'm unaware of anything like that. Even if something like that existed, it certainly isn't reliable, which means the deterrent will still be effective.

      If you are so certain that you can manipulate HTTP headers for requests for resources on different domains, by all means, post the code.

      Any dependancy on unverifiable information supplied by the client is dangerous and the level of actual protection it affords is trivial.

      You've missed the point. Completely.

    17. Re:Use a CGI script to block them. by IpalindromeI · · Score: 1

      It's also pretty nonsensical because it's a waste of bandwidth, which is exactly what deep linkers want to avoid.

      It's probably one reason, but it isn't the only reason, and may not even be the major reason. I would guess that the major reason is that people don't know how or are unable to copy the picture locally. Just because you have a blog somewhere doesn't mean you can put arbitrary content on its server.

      Another possibility, although far less likely, is that the picture changes periodically, but keeps the same URL. Then copying it locally wouldn't show the new one when it gets updated, but using the redirection would.

      --

      --
      Promoting critical thinking since 1994.
    18. Re:Use a CGI script to block them. by MooseGuy529 · · Score: 1

      Um, you totally missed my point. I would use a CGI script to control access to the images, not another CGI script. Instead of /images/image001.jpg, you would do /cgi-bin/image.cgi?id=001 and it would check the referer and/or and provide the image if correct, otherwise provide 1. nothing, 2. an "Image Hosted by OtherSite", or 3. something nasty (perhaps selected by amount of hits per "stealing" domain).

      --

      Tired of free iPod sigs? Subscribe to my blacklist

    19. Re:Use a CGI script to block them. by MooseGuy529 · · Score: 1
      ...why not use a cookie?

      Because cookies aren't accepted by all browsers, and are blocked by every paranoid lunatic on the internet. It's fine not to let them sign in to something without cookies, but keeping them from viewing images is bad. Besides, most people hate cookies sent to them randomly, when they didn't log in or provide any information to be saved.

      --

      Tired of free iPod sigs? Subscribe to my blacklist

    20. Re:Use a CGI script to block them. by TheZeusJuice · · Score: 1

      Can a client-side java applet spoof the referer field in an http request, dl the image, and display it? Or better yet, dl the webpage (out-of-sight), and embed the image in the rip-offer's webpage? Since the java applet would be cached by the browser, if a website were to use many deep-linked images, such an applet could lower bandwith for the rip-offer in comparison to serving the image themselves.

    21. Re:Use a CGI script to block them. by raju1kabir · · Score: 2, Funny
      Because cookies aren't accepted by all browsers, and are blocked by every paranoid lunatic on the internet.

      That's why I gratuitously make sure my site requires cookies.

      There's no virtue in lunatic paranoia if it doesn't come at a cost, and I'm here to levy that cost.

      --
      "Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
    22. Re:Use a CGI script to block them. by MooseGuy529 · · Score: 1

      True, it's good to discourage paranoid lunatics. They've probably killed more interesting internet technologies (or made them more useless by anonymizing) than they've helped fix. (The HTTP User: header could have been useful sometimes, but for privacy reasons it's gone... and so on...)

      --

      Tired of free iPod sigs? Subscribe to my blacklist

    23. Re:Use a CGI script to block them. by Anonymous Coward · · Score: 0

      And your site is called what? Hm. Haven't heard of it, probably. Wonder why. I don't allow cookies by default. There's no reason every single site should use a cookie. It's like gratuitous javascript. I'm not coming to a website for the cookies. If a site has a legitimate reason for it (Slashdot log in cookies, for example), that's fine. I'm not a paranoid lunatic, but you, sir, are an asshole.

    24. Re:Use a CGI script to block them. by raju1kabir · · Score: 0, Flamebait
      And your site is called what? Hm. Haven't heard of it, probably. Wonder why. I don't allow cookies by default. There's no reason every single site should use a cookie. It's like gratuitous javascript. I'm not coming to a website for the cookies. If a site has a legitimate reason for it (Slashdot log in cookies, for example), that's fine. I'm not a paranoid lunatic, but you, sir, are an asshole.

      If this is the intensity of your reaction to learning that some Slashdot joker (me) may or may not be requiring cookies on a site you've never heard of and never will, then it's safe to say you are definitely some kind of lunatic, even if not specifically the paranoid kind.

      --
      "Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
  3. Get over it. by LittleBigLui · · Score: 2, Insightful

    "Deep linking" is what makes the web the web.

    --
    Free as in mason.
    1. Re:Get over it. by Anonymous Coward · · Score: 2, Insightful

      Show us where it says "Must allow deep linking no matter the cost in bandwidth" in the Internet Constitution.

    2. Re:Get over it. by Daniel+Dvorkin · · Score: 4, Insightful

      What makes the Web the Web is hyperlinking, period. Using an image at another site on your own page isn't the same thing.

      I kinda sorta halfway agree with you about "deep linking" in its original sense: if there's a really good page at http://www.bigco.com/foo/bar/spam/eggs/x/y/z.html, and you want to have a link on your page that says "Click here to read this really good page," it's really dumb for BigCo Inc.(R)(c)(tm) to force you to link to the main page at bigco.com so people have to navigate through their site to get to the page in question. That kind of thing is a violation of the spirit of the Web, I agree. But neither BigCo nor (more often) some guy running a site out of his basement on a 256k DSL line is obligated to be your image hosting service.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    3. Re:Get over it. by digitalchinky · · Score: 2, Insightful

      That sounds a little like me port scanning your system without permission, finding a hole, busting in, then using your webserver for my own world domination plans - complete with 500 gigabytes of transfer per day.

      Nothing in any internet constitution to prevent me doing that. You left the door open. Not everyone lives in the US, not everyone has a legal system in place to deal with or care about exploiting overseas computer systems. (I live in Asia)

      Getting over it is not always an option for some. I'm certain you'd be pissed if I did that. Remember, your laws don't apply to what I do.

    4. Re:Get over it. by Chess_the_cat · · Score: 1

      I believe it's in the Preamble.

      --
      Support the First Amendment. Read at -1
    5. Re:Get over it. by real+gumby · · Score: 0

      LittleBigLui's comment is right on; I don't know why some of the moderators thought it a troll or offtopic. If you don't like how people use your data, don't put it online.

      What's the difference between the submitter's complaint and the RIAA's complaint that you are trying to play a DVD out of region (or fast-forward through the ads, or...). Or a web designer complaining that you resized your browser window?

      The web is all about links and the reader making the choices.

    6. Re:Get over it. by Lehk228 · · Score: 2, Insightful

      because embedding other people's images costs them money you dumbfuck, image hosts (except for shitty ones) usually cost money, and to avoid paying for hosting some jackasses decide to use other people's servers to take the hit for them.

      --
      Snowden and Manning are heroes.
    7. Re:Get over it. by LittleBigLui · · Score: 1

      Oh my. Sorry, should have read TFA in a bit more detail. Only saw that horrible abomination "Deep linking" and started ranting.

      --
      Free as in mason.
  4. Solved problem by JimDabell · · Score: 3, Informative

    The typical solution to this is serving a complaint image to requests with the Referer header set to something starting with 'http' that don't correspond to your website. Five minutes on Google would have told you this (and provided ready-made recipes for Apache).

    1. Re:Solved problem by Scyber · · Score: 1

      On problem with this solution is that newer firewall software blocks referer headers. I know Norton Internet Security 2004 does this.

    2. Re:Solved problem by dougmc · · Score: 1
      On problem with this solution is that newer firewall software blocks referer headers. I know Norton Internet Security 2004 does this.
      Then Norton Internet Security 2004 will not work with a lot of web sites, because a lot of web sites do this already.

      In reality, the sites usually work if the Referrer: header is empty, or if it says you came from the same site. It's when the Referrer: site says the link is from another site that the site denies the request, so NIS 2004 won't break every site. But I'm sure it still breaks a good number of them, the ones that go to great pains to make sure you only go through their web site the way that _they_ want you to. (Granted, these are good web sites to avoid, but still.)

    3. Re:Solved problem by JimDabell · · Score: 1

      On problem with this solution is that newer firewall software blocks referer headers.

      That's no problem; if you re-read my comment, you'll see that I suggested only blocking requests with a Referer header that started with http that didn't match your website. Blank Referer headers and Referer headers that say "blocked by [xxx]" will not trigger this.

    4. Re:Solved problem by Sentry21 · · Score: 1

      Yeha, but it's a lot more funny to post it on slashdot and read the replies. That Uconn thing had me laughing for quite a while.

    5. Re:Solved problem by Anonymous Coward · · Score: 0, Troll

      Of course, if he doesn't want his images to be available to the public, maybe he shouldn't put them on the internet. Just a thought.

    6. Re:Solved problem by Otto · · Score: 1

      The problem on some webforums I read from time to time got so severe for a while that I wrote a proxomitron rule to change the referrer header of whatever image I was requesting to be the site that I was requesting it from. So basically it looked like the referrer was the directory that the image was in. http://foo/bar/image.png would get a referrer of http://foo/bar/.

      This worked on every site I checked. Leaving it blank/non-existant did not always work, although it did work most of the time.

      I no longer use the Proxomitron, but there's equivalent ways to defeat referrer based rulesets. However with stock browsers, most people will be stopped by simply referrer based rewriting and so that is an effective means to stop the vast majority of image deep linking.

      --
      - Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
  5. Here's what I did by Sentry21 · · Score: 5, Funny

    I have a file called bestgif.gif on my website - simply put, the best gif ever. Then Mexicans started putting it in their sig on these huge forums, and my bandwidth went up near a few gigs a month (from almost nothing). So...

    RewriteCond %{HTTP_REFERER} ^http://pkpidgeot.com/.*$ [NC]
    RewriteRule .*bestgif\.gif$ http://sites.darien.ca/temp/.tubgirl.jpg [R,NC]

    I'm willing to bet their accounts got suspended when suddenly their sigs contained a large picture of a large woman spewing a fountain of shit into the air.

    My bandwidth usage drops off completely soon after I add a site to the list.

    1. Re:Here's what I did by Anonymous Coward · · Score: 0

      Does anyone else see the humor in the fact that you've redirected their deep link to a different deep link? (Albiet
      one the site's author probably won't mind to much)

    2. Re:Here's what I did by Nos. · · Score: 1

      I did something similar, though not quite as mean. I ran a site for awhile that did an image a day. I was checking the stats and found a site that was giving me huge referals. Except they weren't, they had just linked to my image. In any case, used mod_rewrite to instead put an add up for my site. Worked wonders!

    3. Re:Here's what I did by sysadmn · · Score: 1

      So now, of course, you're slashdotting every other site that has a "bestgif.gif".

      --
      Envy my 5 digit Slashdot User ID!
    4. Re:Here's what I did by St.+Arbirix · · Score: 1

      Perhaps people should start using the Coral to coralized things like what I think you're talking about.

      The gif truly is amazing. I found it in someone's sig last week and was blown away.

      --
      Direct away from face when opening.
    5. Re:Here's what I did by Anonymous Coward · · Score: 0

      That seems like a better idea. Played with making a little add and got it down to 1112 bytes, which will probably be smaller than most of the other graphics. (All it was: "Visit: http://www.mysite.com" in a GIF, indexed as one bit). I guess even more fun would be for it to wait until referals from that site get above some preset limit (like 5/day? 5/forever?) so it wasn't obvious that they shouldn't had linked.

      Plus the whole refering them to tubgirl and other "shocker" stuff has always been, in my opinion, a little extreme. What I think is worse is when you go to a forum, post your photos, then someone else (in the same forum) links to them to explain how you have faked what you are talking about, so to retaliate you set it up for the shocker photos.

    6. Re:Here's what I did by Anonymous Coward · · Score: 0

      Well you know those theiving dirty mexicans, always stealing stuff like bandwidth.

    7. Re:Here's what I did by Anonymous Coward · · Score: 0

      If you served up tubgirl to minors, I'd like to think you'd see some jail time. Next time, please don't over react. This worlds a nasty enough place without people trying to make it worse.

    8. Re:Here's what I did by Stavr0 · · Score: 1

      Perhaps people should start using the Coral to coralized things like what I think you're talking about. How about mod_rewrite images as coralized?

    9. Re:Here's what I did by Sentry21 · · Score: 2, Funny

      For reference, it's this gif that I have that gets linked to.

      I was thinking of linking my copy here and setting the rewrite rule to 'if the referer isn't slashdot, show tubgirl', but then people would copy/paste the links to their friends, who would get an unpleasant surprise.

      Either way, the link I provided above seems to be webspace on an ISP's server. I'm sure it can handle it.

    10. Re:Here's what I did by Morris+Thorpe · · Score: 2, Interesting

      The site that was deeplinking to you is a Pokemon site, which means it was a bunch of kids.

      Yep, you're a tough guy and a class act.

      And what the hell does the fact that they are Mexicans have to do with anything?

    11. Re:Here's what I did by Sentry21 · · Score: 2, Insightful

      Plus the whole refering them to tubgirl and other "shocker" stuff has always been, in my opinion, a little extreme.

      If I were a simple webhost client with a bandwidth limit, those links would most likely have put me over my limit. Fortunately, the server I have is colocated at a rather large colo, and we don't pay much for bandwidth, so it only really came down to a few dollars (basically it cost me a day's worth of my usual decadent lunch).

      Yeah, it's extreme, but putting an image on someone else's server into your sig on an absurdly popular message board is also extreme - but they don't realize it. I certainly can't e-mail them and say 'please don't use my image', and I shouldn't have to waste my time making a 'don't steal this image' image for one site. So, I just used what I had, managed to wget an image without having to look at it, and voila, problem solved.

    12. Re:Here's what I did by John+Harrison · · Score: 1

      While it might not be the best gif ever, it was better than I was expecting.

    13. Re:Here's what I did by Godeke · · Score: 1

      If that was his rewrite rule, I wonder who might be interested in his deliberate exposure of children to that material. This thread is a public admission that he deliberately placed indecent material on a children's site.

      I'm not a big fan of censorship or our indecency laws, but placing that image on a children's site seem a bit of an overreaction. On that might come back and bite.

      --
      Sig under construction since 1998.
    14. Re:Here's what I did by Anonymous Coward · · Score: 0

      I think you're mixing up your terms.

      Indecent is defined in various ways, but usually in the english speaking world it involves something of sexual content. The tubgirl pic is better described as "disgusting".

      Of course if you ask me, it shouldn't be placed anywhere.

      Eeew.

    15. Re:Here's what I did by Anonymous Coward · · Score: 0

      Fuck you, cunt.

    16. Re:Here's what I did by macdaddy · · Score: 1

      Sentry21, you're going on my friends list because I can't afford to have foes like you. ;-)

    17. Re:Here's what I did by networkBoy · · Score: 1

      Mind if I put a copy on my server?
      I love it!
      -nB

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    18. Re:Here's what I did by Pig+Hogger · · Score: 1
      If that was his rewrite rule, I wonder who might be interested in his deliberate exposure of children to that material. This thread is a public admission that he deliberately placed indecent material on a children's site.
      Yes, I routinely replace often-linked pictures with TUBGIRL, and no, I don't have any problem risking to expose such pictures to children. The very least it can do is teach parents to teach their children to be smart.

      And to those who say "please think of the children", I say that a lot of bad things are being justified "just because of the children", and children will only think that something is bad because their parents say so.

      So, in other words, if you bring your children in a fucked-up way, don't blame me if they are shocked because I sunbathe naked on my balcony (yes, I routinely sunbathe naked on my balcony where neighbours can see me).

    19. Re:Here's what I did by exhilaration · · Score: 1

      That's awesome.

  6. Server config? by AndroidCat · · Score: 1

    Does your server allow setting up rules by refering site? If a lot came from one place, point them at a "deep linking not accepted" image or give them a 302 redirection back to an image on their site. You could generally turn off deep linking by file type (e.g. jpeg, gif, etc), but that seems extreme.

    --
    One line blog. I hear that they're called Twitters now.
  7. What picture? by Anonymous Coward · · Score: 0
    ...and I substitute a smaller (and most often, naughty) picture...

    Is that perhaps where the goatse picture went?

  8. Wonder if this will promote simply copying images by DavidNWelton · · Score: 1

    I use this technique as well, although with a less harsh image saying "thanks for your interest in my pictures, feel free to look at them on dedasys.com".

    I wonder what will happen if enough people start using it though - will people simply start copying the images?

    I guess if you're worried enough, you can watermark them or use other things to keep them from being useful, if you want people to pay.

    BTW, whenever anyone actually asks to use my photos, I always say yes and have never asked for money - what irritates me is people not even asking, or putting a small photo credit.

  9. Switching images is far more fun by jgaynor · · Score: 4, Funny

    Blocking is easy enough nowadays, but switching images is far more fun. I had this image in my gallery, from when a bus at my university crashed into a dorm. Before a recent football game, a fan from Uconn found this image and used it in a 'we're gonna kick your ass'-type post on their athletics message board. So I saw this in my logs and removed/changed the image to this one. The post was then filled with 'wtf' comments and was pulled a day later :).

    1. Re:Switching images is far more fun by gstoddart · · Score: 1

      Must ... click ... links ... through ... corporate ... firewall ...

      Doh, the temptation to see.

      --
      Lost at C:>. Found at C.
    2. Re:Switching images is far more fun by Anonymous Coward · · Score: 1, Informative

      Don't worry they're both SFW.

    3. Re:Switching images is far more fun by gstoddart · · Score: 1
      Don't worry they're both SFW.


      Thank you. Had seen several references to tub girl, and didn't want to see that from work. (Well, I don't want to see it from home either.)

      --
      Lost at C:>. Found at C.
    4. Re:Switching images is far more fun by Mmm+coffee · · Score: 4, Funny

      I used image switching on a site I was working on, only my image was a bit more disruptive.

      Create a 1px x 1px transparent gif and open it in a hex editor. I forgot which bytes exactly to change, but if you change a some of the 01's to FF in the first X bytes, you can create a 64kX64K pixel GIF file that weighs in at roughly 100 bytes. Use that as your switched image, and you will have lots of laughs as you see the hotlinker's sites 50 screens wide by god knows how many screens tall. It makes any site totally unreadable and costs almost zero bandwidth to boot. Works for me. ;)

    5. Re:Switching images is far more fun by macdaddy · · Score: 1

      You are too cool to not be a friend of mine. Welcome to my friends list!

    6. Re:Switching images is far more fun by macdaddy · · Score: 1

      Damn. I'm sure getting a lot of new friends out of this deep-linking thread.

    7. Re:Switching images is far more fun by exhilaration · · Score: 1

      Dude, save use the trouble and link to it.

    8. Re:Switching images is far more fun by I8TheWorm · · Score: 1

      Not knowing much at all about images, I experimented a bit with what you said. I created a 1px x 1px transparent gif. I opened it with UltraEdit and changed they 7th and 9th bytes from 01 to FF (these were the only 01's I found in the initial bytes of the file).

      It did enlarge the image, but kept the file at 1k in size. However, it didn't make it huge... just 255px x 255px.

      Can you remember any more about it? I couldn't find a link anywhere, but it sounds like a great way to prevent deep linking without offending anyone.

      --
      Saying Android is a family of phones is akin to saying Linux is a family of PCs.
    9. Re:Switching images is far more fun by Mmm+coffee · · Score: 1

      Yeah, edit bytes 6 and 8 to FF, that would make it a short integer and thus have an upper boundary of 64ksomething. That should do it.

      Yeah, it was a wonderful little replacement image. Totally disruptive, very hilarious, non-offensive (harmless), and costs next to no bandwidth.

    10. Re:Switching images is far more fun by I8TheWorm · · Score: 2, Informative

      IPalindromeI replied to a journal entry I made about this topic, and pointed out that it's 2 bytes per axis, which I should have realized given the values of 255 mentioned before. So it's bytes 7-10 that become FF. I tested it and it worked... the images is HUGE, but the filesize is 43 bytes.

      You're also right about being disruptive and non-offensive, and keeps your bandwidth usage pretty low.

      So do I have to pay you some royalties if I use this in the future?

      --
      Saying Android is a family of phones is akin to saying Linux is a family of PCs.
  10. Apache recipe by ccarr.com · · Score: 4, Informative

    I have a number of photo sites, most of which would be interesting only to friends and family, but a couple are of general interest. I don't mind LINKING (as in anchor tags) to my photos, but nobody does that. They EMBED (with img tags) my photos, thus sucking up my bandwidth to enhance their own pages.

    First, name your photos with a unique file extension. I use ".jpeg" for photos and ".jpg" for other incidental JPEG files on the site. Then, place this in the relevant area of your Apache config:

    ### BLOCK IMAGE EMBEDDING
    SetEnvIfNoCase Referer "^http://.*yourdomain\.com/" local_ref=1
    <FilesMatch "\.(jpeg)">
    Order Allow,Deny
    Allow from env=local_ref
    </FileMatch>

    --
    I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. BB
  11. Copying photos vs. deep-linking by JavaRob · · Score: 2, Insightful

    Preventing people from *copying* the images is a completely new challenge, and fortunately most people don't worry about that too much.

    Deep-linking is more dangerous than copying, because it can unexpectedly cause vast increases to your bandwidth if the image is redisplayed in a more popular location.

    Copying... well, it's annoying if someone else uses your photo on a site w/o crediting you, and especially annoying if they are selling prints or something like that, but neither one costs you money (remember, you were displaying it for free), and in both cases they are violating copyright, so you can complain to their host with some reasonable hope of action.

    If you're actually a good photographer and are *selling* those photos, then you need to look into ways to make them hard to copy. The obvious is only letting people preview a low-res or plainly watermarked version. You can use that annoying trick of catching the right-click event in JavaScript and popping a copyright reminder notice. You can display a transparent gif *over* the actual photo (defined in CSS instead of an image tag), like Google does for their photos of copyrighted book pages.

    1. Re:Copying photos vs. deep-linking by tchuladdiass · · Score: 1

      Just out of curiosity, do any of those anti-copying techniques prevent the image from being in the browsers cache? If not, then one could always pull up the most recent gif/jpegs from their cache directory.

    2. Re:Copying photos vs. deep-linking by digitalvengeance · · Score: 1

      I've never seen an image protection trick that worked without changing the actual image itself. (Pre-processing it and applying a watermark, for example.) Even Kodak's website (www.proshots.com) for professional photographers has a huge flaw that lets any competent geek download the full quality high-res images without any sort of watermark or copyright indicator.

      --
      How many roads must a man walk down? 42.
    3. Re:Copying photos vs. deep-linking by Anonymous Coward · · Score: 0

      I've seen one. It used an activeX component to download an encrypted version of the file and didn't store it anywhere on disk. It went so far as to recognize the "prt scr" key and replace the image with a message telling you to buy the image.

      I suppose I could have looked for the encryption key or the raster data somewhere in memory, but it just wasn't worth the effort.

    4. Re:Copying photos vs. deep-linking by macdaddy · · Score: 1

      You can also put them in a Flash movie. I'm sure they can be extracted but how many of the people that would be stealing his images are smart enough to do that?

    5. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      Not the ones I mentioned (and browser are such a simple technology, really, that it's damned hard to *really* protect the thing) -- but they will foil the majority of people out there, which is the point.

      Most people don't know how to read through the source to find the "real" image, most people don't know how the find the file in their browser cache... and even the ones that do might not think it's worth the trouble.

      Once you have some basic protection, even it it's easy for a technical person to sidestep, you're making it impossible for them to claim that they simply didn't realize they were doing something they shouldn't. It's like a bike lock -- yes, anyone with bolt cutters can still take your bicycle in 10 seconds... but the lock will still do the trick in most situations.

    6. Re:Copying photos vs. deep-linking by Lehk228 · · Score: 1

      No, they also do not keep them from being downloaded in the firefox view page info>media dialog, which also happens to be a great tool for grabbing flash files off a website.

      In addidion to this, there is an extention for firefox that blocks the right-click capture javascript.

      --
      Snowden and Manning are heroes.
    7. Re:Copying photos vs. deep-linking by CrackerJack9 · · Score: 1

      Most people don't know how to read through the source to find the "real" image, most people don't know how the find the file in their browser cache... and even the ones that do might not think it's worth the trouble.

      I'd have to guess the people that do will just Right-Click and Save As...

    8. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      I'd have to guess the people that do will just Right-Click and Save As...

      Exactly -- *that's* easy to defeat.

    9. Re:Copying photos vs. deep-linking by CrackerJack9 · · Score: 1

      Of course there are drawbacks in defeating it, and defeating it wasn't what I was referring to. Not to mention a lot of methods to defeat the Right-Click don't work at all, and even more only work on specific types of browsers. Perhaps you should have said "that's *easy* to defeat" ?

    10. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      I think I'm still missing your point, then... yes, most people will try first to save an image they want using right-click/save as. If this doesn't work, the average person will give up, and the geek may find a way to grab the file from cache, or by browsing the HTML source... but he/she will probably realize at the same time that because you are willing to put some effort into protecting your photos, it would be wise to NOT try to reuse it on another site.

      I disagree that it's hard to stop right-clicking. I wouldn't ever recommend the JavaScript catch-click-event method (because that's just annoying, and doesn't work everywhere).

      But it's darned easy to just put your image as the background of a simple table cell, and display a transparent gif over it. That'll work on just about any browser in use nowadays.

    11. Re:Copying photos vs. deep-linking by CrackerJack9 · · Score: 1

      Well, my point is (if you read this thread) that it would seem what you call "most people" isn't too many people at all. And that the "average person" seems to be "deep-linking" to the picture instead (even if you are using JavaScript or some other method).

      I'm fairly certain that is the point of this entire thread in the first place, but I would just be speculating.

      I admit the last thing you said actually has some merit to it, and that most people will not dig into the source to find the real location and link/download it that way.

      I disagree that it's hard to stop right-clicking.

      So what is your point of mentioning the JavaScript method(s) if it is not only to make my point?
      Your suggestion isn't stopping Right-clicking at all, it's merely changing what image they are (not think they are) clicking on. I hate the be nit-picky, but in this context it's a pretty big difference.

    12. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      it would seem what you call "most people" isn't too many people at all. And that the "average person" seems to be "deep-linking" to the picture instead (even if you are using JavaScript or some other method).

      Now you've really lost me. This thread is not about deep-linking, it's a tangent about preventing copying.

      So what is your point of mentioning the JavaScript method(s) if it is not only to make my point?
      Your suggestion isn't stopping Right-clicking at all, it's merely changing what image they are (not think they are) clicking on. I hate the be nit-picky, but in this context it's a pretty big difference.


      Again, you lost me. We're talking about preventing people from easily saving an image, by right-clicking and choosing save as. I mention the JavaScript method because it's an irritating and unreliable way to do that. Then I mention a reliable, non-irritating way to stop that method of saving an image. It looks like they are saving the photo, but they are actually only saving the transparent gif.

      How is this "a pretty big difference" in the context? It serves exactly the same purpose: it prevents them from saving your photo using a right-click->save-as.

    13. Re:Copying photos vs. deep-linking by CrackerJack9 · · Score: 1

      Clearly you like arguing for argument's sake. Read the title of this thread and what this article is about and tell me it doesn't have anything to do with deep-linking.

      I thought you had a good idea, but I guess you took offense to that. Did you read your post, I really don't have time to highlight your own words for you--but if you read it you might stumble upon the part where you say JavaScript is unreliable. (I actually said the same thing in the parent to your reply, if you'll see - so it's odd that you're arguing that as well).

    14. Re:Copying photos vs. deep-linking by iamacat · · Score: 1

      Ah, but most people can figure out how to take a screenshot. Just add "please don't copy" text to the bottom of the image, because that's just as effective as any protection you can manage and a lot nicer. In the end, you can not plug the analog hole. People can always take a photo of the screen.

    15. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      Okay, last shot, to see if we can get on the same page.

      Read the title of this thread and what this article is about and tell me it doesn't have anything to do with deep-linking.

      The article is about deep-linking. This thread starts here, and is a tangential discussion about copying.

      I thought you had a good idea, but I guess you took offense to that.

      I'm not taking offense -- I'm just having trouble figuring out where your disagreement lies.

      Did you read your post, I really don't have time to highlight your own words for you--but if you read it you might stumble upon the part where you say JavaScript is unreliable. (I actually said the same thing in the parent to your reply, if you'll see - so it's odd that you're arguing that as well).

      Right, using JavaScript to prevent right-click-save is unreliable. I've said that a few times now. I've also explained twice now that there are better ways to achieve the same thing (prevent right-click-save). If you agree with me, there's no argument. If you don't, you'll need to clarify what you agree/disagree with, or we're both just wasting our time.

    16. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      Ah, but most people can figure out how to take a screenshot

      Totally true, but that's not my point. Firefox users can also use the "Media" tab in their "View Page Info" dialog to save the image -- this doesn't require technical expertise of any kind.

      It *does* require a bit of effort beyond the basic right-click-save-as, though. And it requires a realization that "someone doesn't want me downloading this image"... so if your photo shows up on my website, I can't just claim ignorance about copyright law (and my host has more of a reason to drop me like a hot potato, which is what you want).

      A watermark on the image (like adding "do not copy" text to the bottom) achieves the same effect -- I'd have to knowingly crop it out -- though watermarks can be irritating; they mar the image, after all, to varying degrees. If someone's thinking of purchasing a print, they might be turned off if your watermark is jolting, wrecks the color scheme, cuts across some important part of the photo, etc..

      Using JavaScript to disable all right-clicks is also irritating, since people use right-clicks for much more than just saving images. My suggestion is to set the actual photo as a table cell background, and fill the cell with a transparent GIF. Users who are just viewing the image won't even be able to tell you did this, and users who right-click-save will get the transparent GIF. You should also put copyright reminders below the images, in a small font (if you are loud about it people will feel like they're being accused of a crime they haven't committed).

    17. Re:Copying photos vs. deep-linking by CrackerJack9 · · Score: 1

      let's just say time is certainly being wasted. you're better than me (it takes intelligence to repeat someone else's thoughts) so let's move on, shall we?

    18. Re:Copying photos vs. deep-linking by JavaRob · · Score: 1

      let's just say time is certainly being wasted. you're better than me (it takes intelligence to repeat someone else's thoughts) so let's move on, shall we?

      Hmmm. Yes, move on.

    19. Re:Copying photos vs. deep-linking by Anonymous Coward · · Score: 0

      I hate to do this, but I feel I have to.

      <sarcasm>(it takes intelligence to repeat someone else's thoughts)</sarcasm> so let's move on, shall we?

      Youre' response:
      Hmmm. Yes, move on.

  12. I wonder how long it'll take... by G-Licious! · · Score: 1

    There has to be someone out there dumb enough to sue over this...

  13. add copyright notice by leehwtsohg · · Score: 1

    I would just automatically add a copyright notice to off-site referrers, i.e. generate images with copyright notices.
    If trafic becomes too high, you could use another solution, but it does hot sound as if that's the problem.
    I think linking is much preferable to copying, since you still have control over the images, and can track who sees them.

  14. Uh Oh! by Anonymous Coward · · Score: 2, Funny

    In those cases, I change the picture filename (and the corresponding webpage that calls it), and I substitute a smaller (and most often, naughty) picture. What other tricks those of you are facing the same problem have to address this problem?"

    Does this mean a goatse or tubgirl link will get you modded up "+1 Informative"?

    A sad day, indeed.

    1. Re:Uh Oh! by Zone-MR · · Score: 1

      Does this mean a goatse or tubgirl link will get you modded up "+1 Informative"?

      Hmm, let's try it. For those of you who don't know what he was refering too, goatse and tubgirl are those sites. ;)

  15. duh by nuggetman · · Score: 1, Funny

    all you need to stop people from stealing your images is a no-right-click javascript. sheesh.

    --
    ...and that's all there is to it.
    1. Re:duh by LouCifer · · Score: 1

      Wow.

      And how can you stop me from using View Source?

      --
      Religion is for people afraid of going to hell.
    2. Re:duh by NewStarRising · · Score: 1

      You'll be wanting the "Remove Menu Toolbar" script.
      No View menu, no view source!

      Ha! Indefeatable security!

      --
      b3 4phr41d 0f my 4bov3-4v3r4g3 c0mpu73r kn0wI3dg3!
      MadDwarf
    3. Re:duh by DarkDust · · Score: 1

      all you need to stop people from stealing your images is a no-right-click javascript. sheesh.

      Except that all browser allow to turn JavaScript off. And then there's still wget, lynx, w3m, ... and "View Source".

    4. Re:duh by magefile · · Score: 1

      And for those web devs who are really stupid, "Print Screen" (yes, I actually saw a guy do this ...).

    5. Re:duh by hoggoth · · Score: 1

      > You'll be wanting the "Remove Menu Toolbar" script.
      > No View menu, no view source!
      > Ha! Indefeatable security!

      telnet 80
      GET /

      Defeated.

      --
      - For the complete works of Shakespeare: cat /dev/random (may take some time)
    6. Re:duh by RevDobbs · · Score: 2, Funny

      Jebus Chrisp, man, you've just created a copy protection circumvention device! Off to the gallows with you!

    7. Re:duh by Pig+Hogger · · Score: 1
      And for those web devs who are really stupid, "Print Screen" (yes, I actually saw a guy do this ...).
      It's not that stupid. I've seen people posting pictures of themselves having sex but cutted-up in tiny pieces pieced together in a table. So, instead of having to save 150 little bits and pieces (only one or two being naughty) and reassembling them, you just do a print screen, and voilà! instant embarrassing picture ready to laugh at...
    8. Re:duh by WhiteDragon · · Score: 1

      not to mention my personal favorite, Firefox's page info, which includes a media section with all the videos, images, objects, etc in a page that you can directly download.

      --
      Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
    9. Re:duh by magefile · · Score: 1

      And low-res - you could probably write a script to get the image in a better resolution, and make it general case (i.e., open the html as text, select the table, and have it parse that, as the simple but inelegant way to do it).

  16. Re:Solved problem (htaccess and geocities) by Jondaley · · Score: 4, Informative

    Here is my .htaccess for doing just this.

    I have gotten a number of emails from people who didn't appreciate my changing their image (or their background -- that was a good one, couldn't read the person's site at all)

    # Need additional rewrite for the directory without a slash, because otherwise
    # the (.*) matches the whole URL. There is probably a better way to do this
    # but this works
    RewriteRule html_gifs$ http://www.geocities.com/last_id_in_the_world/html _gifs/ [L,R=permanent]

    # People who don't get it...
    RewriteCond %{HTTP_REFERER} ^http://www.playahead.com/GroupInfo.aspx.*$ [NC,OR]
    RewriteCond %{HTTP_REFERER} ^http://www.xanga.com/private/home.aspx$ [NC,OR]
    RewriteCond %{HTTP_REFERER} ^http://www.kindertent.nl/template.php?id=278628&t id=38$ [NC,OR]
    RewriteCond %{HTTP_REFERER} ^http://nuvoleinviaggio.blog.excite.it/$ [NC]
    RewriteRule ^(.*)$ http://www.geocities.com/last_id_in_the_world/html _gifs/funny_looking.gif [L,R=permanent]

    # People who don't get it. -- these people are especially annoying,
    # as apparently mozilla-- doesn't set the referrer is not set when using style sheets...
    #RewriteCond %{HTTP_REFERER} ^$ [OR]
    # RewriteCond %{HTTP_REFERER} ^http://www.xanga.com/home.aspx?user=da_forg3tabl3 _1.*$ [NC]
    RewriteRule backgrounds/blue-faded.jpg /~jondaley/html_gifs/funny_looking.gif [L,R=permanent]

    # uncomment this if you want people who don't have their referrer
    # set to also be redirected
    RewriteCond %{HTTP_REFERER} ^$ [OR]

    # If linked to from somewhere else, forward them to geocities
    RewriteCond %{HTTP_REFERER} !^http://www.snurgle.org/.*$ [NC]

    # Forward all requests, since we are within the html_gifs directory
    RewriteRule ^(.*)$ http://www.geocities.com/last_id_in_the_world/html _gifs/$1 [R=permanent]

  17. To those who choose to use referrer by wowbagger · · Score: 3, Insightful
    Some of us block the REFERER header out of privacy concerns, since many browsers do not distinguish between a GET kicked off due to a page element like an IMG tag, and a link click.

    May I make the following suggestions?

    1. If you MUST use a referrer block, please consider simply rate limiting non-matching requests to a very low rate, like 2kB a second. That will keep your bandwidth down, yet allow the paranoid among us to still see your image (albeit after a wait).
    2. Use a CGI to provide the image, and have the page in question generate the link dynamically - that way, for the next five minutes your image might be visible as http://example.com/image.cgi?pic=foo.gif&key=59823 4
      and later the key value may be different. That way, you don't rely upon a spoofable header. Yes, this makes your image non-cachable, but if you are using referrer blocking, perhaps that is not a bad thing?

    1. Re:To those who choose to use referrer by Anonymous Coward · · Score: 0

      #1 doesn't solve the problem of someone deep-linking or embedding the image - it just makes it slower. If anything it should be something like 2K per minute, or, wait for it, 0K per any unit of time.

      #2 is a non-trivial solution to a problem of courtesy that would be better handled by just not allowing certain people to see it in the first place.

      Your paranoia is not my problem. Why should I have to work around it?

    2. Re:To those who choose to use referrer by OblongPlatypus · · Score: 1

      In my experience the best solution is simply to only block those who provide valid referrers, since all you need is to block most remotely referred requests, not all.

      Apache recipe in this previous comment.

      --
      -- If no truths are spoken then no lies can hide --
  18. A better way to do it by Rameriez · · Score: 5, Informative

    I had this exact same problem with a few images I host on my site. Typically from forums that allow avatars to be hosted offsite. I did a bit of a google on the problem of "hot linking", and came up with this:

    http://www.alistapart.com/articles/hotlinking/

    It's an excellent solution that prevents hot/deep image embedding, but allows for normal anchor links to your pictures. You'll need to be hosting on an apache server and be allowed to use .htaccess files and have mod_rewrite, plus the tiniest amount of php/perl scripting knowledge (php example in link).

    Basically, you rewrite any requests for images from offsite with a URL that points to a script. Embedded images will fail, because the browser expects image data when it gets text/html instead. The script simply displays the image, perhaps puts a credit in, and a link back to your site.

    This way, you can block most people from stealing your bandwidth by embedding your images in their pages, but not prevent less-harmful linking.

  19. Ah, the infamous bus crash by Andy+Dodd · · Score: 1

    That image seems to wind up in the Targum and Medium pretty often. :)

    (I'm a grad student at RU right now.)

    --
    retrorocket.o not found, launch anyway?
  20. duh^2 by A+nonymous+Coward · · Score: 1

    The problem is not copying, it is linking and sucking up bandwidth.

    Besides which, disabling javascript defeats your trick, and it's in the browser cache anyway. If it's on someone's screen, it's in their computer.

  21. online porn industry by fearanddread · · Score: 1

    I've always wondered how much of the "bad-ass-apache-admin-handbook" was written by people working in the porn industry. This seems like just the sort of thing they would have mastered way back in the way back. I'd be surprised if there wasn't a handbook somewhere with best practices for serving up the porn.

  22. Problems with simple blocks by wizzy403 · · Score: 2, Insightful

    I used to be the webmaster for a fairly popular (in our particular niche) website with an online store. I got pissed off when I started seeing people putting things up on eBay with IMG tags pointing at our server. So I did what many of you have suggested, set up a mod_rewrite rule that if the referrer was not blank and not our site, it substituted a "Copyright Violation" JPG file (The bosses probably wouldn't approve of Tubgirl or the Goatse guy). I had to discontinue this within a week because a fairly popular BSD router software (can't remember which one, sorry) used to include the IP address of the router in the REFERRER field, and so quite a number of legitimate viewers were getting "Copyright Violation" images in place of ALL the pictures on our site. And the worst thing was, it used the PUBLIC IP in the REFERRER field instead of the private NAT address, so I couldn't even add an exception for NAT space to fix it... After spending another two weeks looking around, I just started banning sites one at a time (eBay...) from being in the REFERRER field and keeping an eye on my logs. PITA, I know...

    That was a few years ago, perhaps this is a non-issue now. But keep in mind that people running braindead routers or webcaches might inadvertantly trigger your rule and get pissed. If you're just a hobby site, no big deal, I guess. But if you're making money off the site (online stores and the like) you risk losing business over it.

  23. [PATCH] spoofing vulnarability by Anonymous Coward · · Score: 1, Informative

    Description: spoofing vulnarability. Allows: myprefix-yourdomain.com. Patch attached, httpd.conf-remvuln.patch:

    --- conf.0 Tue Feb 8 18:07:17 2005
    +++ conf.1 Tue Feb 8 18:07:48 2005
    @@ -1,5 +1,5 @@
    ### BLOCK IMAGE EMBEDDING
    - SetEnvIfNoCase Referer "^http://.*yourdomain\.com/" local_ref=1
    + SetEnvIfNoCase Referer "^http://.*\.yourdomain\.com/" local_ref=1
    <FilesMatch "\.(jpeg)">
    Order Allow,Deny
    Allow from env=local_ref

  24. Dont block them ... by vrai · · Score: 2, Funny

    ... redirect them to one of the GNAA/goats.cx style shock images. Nothing will discourage (most) webloggers from deep linking to your images more than turning their precious 'blogs' in to gay scat porn sites.

  25. Three word solution by Anonymous Coward · · Score: 0

    get over it.

  26. idea by Anonymous Coward · · Score: 0

    Instead of using naughty images, make a transparent .gif that's 1x30000 pixels, so it will mess up the layout of the page it's on. It can be 30000 pixels high or wide for different effects.

  27. Slightly better solution by OblongPlatypus · · Score: 2, Informative

    SetEnvIfNoCase Referer "^http://" remote_ref=1
    SetEnvIfNoCase Referer "^http://.*\.yourdomain\.com/" remote_ref=0
    <FilesMatch "\.(jpeg)">
    Order Deny,Allow
    Deny from env=remote_ref
    </FilesMatch>

    This will let your page work for people with anonymizer services and firewalls which block the referer field. Of course for those people the remote linking will work as well, but usually they are few enough for the bandwidth impact to be negligible.

    --
    -- If no truths are spoken then no lies can hide --
  28. Your provider by macdaddy · · Score: 1

    You nickname sounds awfully familiar to me. Are you on SKTC by chance?

    1. Re:Your provider by wowbagger · · Score: 1

      Yes I am.

    2. Re:Your provider by macdaddy · · Score: 1
      I thought so. It's a fairly unique nickname. You're in Clearwater if memory serves me correctly.

      I used to work with Gene and Jack at the company, before it was all outsourced. I kept the servers running. What's your opinion of the service now that it's outsourced? A number of customer I've known for years are switching due mainly to the dismal customer service. It's sad to see what we built go out that way. It wasn't perfect, but it was better than most IMHO.

    3. Re:Your provider by wowbagger · · Score: 1

      I wasn't aware that it had been outsourced - that's a shame, as their support had been excellent.

      That might explain why I've not gotten a response to a request to add some more optional DNSRBLs to the Greymail system, why I was turned down flat on a suggestion that SKTC offer DNS names in the .sktc.net domain (so that I could have had a name assigned to my firewall, e.g. hagood.sktc.net).

    4. Re:Your provider by macdaddy · · Score: 1
      I'm glad to hear you had good service in the past. I didn't have much to do with the helpdesk after late '97 or so. Gene and Jack brought me in a number of times to fix something, set up a new server, etc. Heck Gene bombarded me with questions on a daily basis. If only I had a nickle for every time Gene and Jack needed a hand. :-) Good guys though. Great guys. Jack is still there but Gene's area was pretty much wiped clean. Gene now works in IT at a bank in Ark City. They had me take on a number of projects last year to improve things. I certainly agreed that they needed improving. The whole works was becoming rather neglected.

      The marketing director brought me in back in December 2003 to set up a new webmail system for them. The one I set up nearly 3 years prior was getting rather dated. It wasn't scaling well (was never designed to be used in production that long). Shortly after that a project came down the pipes to have redundancy at every level. Computer systems can't be treated like telco systems. It doesn't work that way. The management there really thinks in terms of telco everything. Nevertheless we put in 7 new servers, an excellent spam filtering solution (I still use it), revamped everything, added feature after feature after feature. The system was better than the last time they had me rebuild it. It was a massive undertaking for one person. It was built to last and be scalable. The network also underwent massive changes. They fell short of being redundant but they certainly made things better. Unfortunately they didn't have the staff to properly maintain the systems. That wasn't really Gene's job. That wasn't anyone's job, although they assumed it was Gene's. They had 10 servers in 2 POPs with more on the way and no one to maintain them. The servers would have run fine for years I'm sure with them calling on me for assistance every so often. Unfortunately they were outsourced before that became an issue.

      My understanding of the situation is that marketing presented to the powers that be the cost per user based soley on the costs associated with the ISP in 2004. This included the hardware and man hour expenses for installing and configuring the new systems. The results were skewed because the life of the equipment and the job in general weren't part of the equation. The equipment and installation costs should have been amortized over the expected life of the equipment which was 4-5 years. So for example if we spent $36k on equipment and installation in 2004 for 3000 users the actual cost per user for that equipment amortized over 3 years would have $4/user. However if you don't amotorize the costs over the equipment's lifetime then your short-term cost per user would have been $12/user and thus skewed. Marketing then presented to management a company that could do the job for $4/user. Management listened to marketing instead of their ISP IT staff. It happens.

      The ISP side of the business could certainly have offered more services. There was much more they could do. However without adding experienced staff to accomplish those goals, those goals could never have been met. They didn't have the staff to manage the systems properly as it was. I doubt they realize how fortunate they were to get as many free man hours as they did. It really is a shame too because we put a lot of effort into the job. I remember when I knew almost every customer by name. I remember when broke the 100 customer mark. Now when you call tech support you'll get someone you've never spoken with before, has no idea where you are actually located at, has absolutely no contact with the actual administrators of the out-sourcing company's server (so they hear about problems or can relay unusual problems to those with experience who can address the unusual problems), who has no idea who you are or what your personal skills are, and in most cases could simply care less about providing you with accurate and timely information. I've been told by a person who experien

    5. Re:Your provider by wowbagger · · Score: 1

      (It's a shame that /. does not provide a means to generate a message to a user directly, rather than this sort of approach.)

      Tell you what - let's take this over to my journal...

  29. Yeah right (was Re:duh) by Bloody+Peasant · · Score: 1
    The only problem with many of those no-right-click javascript thingies is they assume the right button is number 2. On my system (Linux/X) it's number 3.

    That, and as others have pointed out, "view source" or "view page info", and/or disabling javascript makes that approach rather pointless.

    Besides, it's not about them physically stealing the images (which they can do with screen shots if nothing else; if they can see it, they can save it). The issue here is about them embedding your image in their website.

    Yeah, I've done the switcheroo thing too, though not as grossly as others have. Found someone embedding a St. Patrick's image I had in a very republican type bulletin board, so I slightly modified it. As far as I know it's still there after several months; I wonder if they'll notice...

    --
    -- This .sig intentionally left meaningless.
  30. Try this one by leonbrooks · · Score: 1

    Try this one. Not FOSS, but free-as-in-beer and very pretty. The images are displayed through the Flash app rather than hidden by it, but it's more than enough to stall the average punter, if that's what you want to do.

    Except over a remote RDP link, where the fading and flashing can cause a page to take 20 minutes or more to finish loading over a 128kb ADSL uplink.

    --
    Got time? Spend some of it coding or testing
    1. Re:Try this one by macdaddy · · Score: 1

      I don't much care for them myself, probably because I'm usually the one trying to get the pictures. ;-)

  31. Konqueror runs these scripts... by leonbrooks · · Score: 1

    ...and then shows the menu. It's probably a bug, but it's both useful and amusing.

    --
    Got time? Spend some of it coding or testing
  32. more bait-and-switch ideas by Chuq · · Score: 2

    You could always do what Rob at Cockeyed.com did :)

    --
    - Chuq
  33. Watermark by Anonymous Coward · · Score: 0

    Although maybe you don't need the traffic, what I do on my sites is I use a PHP script and mod_rewrite to dynamically add a watermark (my site's URL) to the bottom of each picture without perminantly modifying the actual picture itself. Their might be a way to write a script that only watermarks it if it's not being displayed on your domain, but I couldn't (easily) find a way. That way, it basically becomes free banner adverts across the 'net.

  34. Re:Wonder if this will promote simply copying imag by jovlinger · · Score: 1

    What you should do is to whitelist everyone who has accessed it already -- this will no doubt include the offending deeplinker. Then when people start complaining to the deep linker about tubgirl or what not, they'll check and see nothing wrong. People will get upset that the deeplinker is both linking to a horrible image, AND denying it.

    should be quite fun.