Dealing with Deep-Linking to Your Online Photos? 139
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?"
irked? (Score:1, Funny)
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.
Use a CGI script to block them. (Score:4, 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.
Re:Use a CGI script to block them. (Score:3)
HTTP headers are so incr
Re:Use a CGI script to block them. (Score:2, Insightful)
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 a
Re:Use a CGI script to block them. (Score:2)
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.tl
Re:Use a CGI script to block them. (Score:1)
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.
Re:Use a CGI script to block them. (Score:3, Insightful)
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.
Re:Use a CGI script to block them. (Score:2)
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.
Re:Use a CGI script to block them. (Score:2)
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).
Re:Use a CGI script to block them. (Score:2)
Re:Use a CGI script to block them. (Score:2)
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
Re:Use a CGI script to block them. (Score:2)
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 keep
Re:Use a CGI script to block them. (Score:2)
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).
Re:Use a CGI script to block them. (Score:1)
Re:Use a CGI script to block them. (Score:1)
Re:Use a CGI script to block them. (Score:2)
Dont block them ... (Score:3, Funny)
Re:Use a CGI script to block them. (Score:2)
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.
Re:Use a CGI script to block them. (Score:3, Funny)
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.
Get over it. (Score:2, Insightful)
Re:Get over it. (Score:2, Insightful)
Re: (Score:3, Insightful)
Re:Get over it. (Score:2)
Re:Get over it. (Score:5, Insightful)
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
Re:Get over it. (Score:3, Insightful)
Solved problem (Score:4, 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).
Re:Solved problem (Score:2)
Re:Solved problem (Score:2)
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'
Re:Solved problem (Score:2)
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 u
Re:Solved problem (Score:2)
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.
Re:Solved problem (htaccess and geocities) (Score:4, Informative)
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/htm
# 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&
RewriteCond %{HTTP_REFERER} ^http://nuvoleinviaggio.blog.excite.it/$ [NC]
RewriteRule ^(.*)$ http://www.geocities.com/last_id_in_the_world/htm
# 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_forg3tabl
RewriteRule backgrounds/blue-faded.jpg
# 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/htm
Re:Solved problem (Score:2)
Here's what I did (Score:5, Funny)
RewriteCond %{HTTP_REFERER} ^http://pkpidgeot.com/.*$ [NC]
RewriteRule
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.
Wonder if this will promote simply copying images (Score:2)
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 i
Copying photos vs. deep-linking (Score:3, Insightful)
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
Re:Copying photos vs. deep-linking (Score:2)
Re:Copying photos vs. deep-linking (Score:2)
Try this one (Score:2)
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.
Re:Try this one (Score:2)
Re:Copying photos vs. deep-linking (Score:2)
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,
Re:Copying photos vs. deep-linking (Score:2)
Re:Copying photos vs. deep-linking (Score:2)
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 (a
Re:Copying photos vs. deep-linking (Score:2)
Exactly -- *that's* easy to defeat.
Re:Copying photos vs. deep-linking (Score:2)
I disagree that it's hard to stop right-clicking.
Re:Copying photos vs. deep-linking (Score:2)
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 (n
Re:Copying photos vs. deep-linking (Score:2)
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 [slashdot.org], 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 highlig
Re:Copying photos vs. deep-linking (Score:2)
Hmmm. Yes, move on.
Re:Copying photos vs. deep-linking (Score:2)
In addidion to this, there is an extention for firefox that blocks the right-click capture javascript.
Re:Wonder if this will promote simply copying imag (Score:2)
should be quite fun.
Re:Here's what I did (Score:1)
Re:Here's what I did (Score:3, Insightful)
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
Re:Here's what I did (Score:2)
Re:Here's what I did (Score:3, Funny)
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.
Re:Here's what I did (Score:2)
Re:Here's what I did (Score:2)
I love it!
-nB
Re:Here's what I did (Score:2)
Re:Here's what I did (Score:2)
The gif truly is amazing. I found it in someone's sig last week and was blown away.
Re:Here's what I did (Score:2)
Re:Here's what I did (Score:2, Interesting)
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?
Re:Here's what I did (Score:2)
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.
Re:Here's what I did (Score:2)
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
Re:Here's what I did (Score:2)
Server config? (Score:1)
Switching images is far more fun (Score:5, Funny)
Ah, the infamous bus crash (Score:2)
(I'm a grad student at RU right now.)
Re:Switching images is far more fun (Score:2)
Doh, the temptation to see.
Re:Switching images is far more fun (Score:2)
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.)
Re:Switching images is far more fun (Score:5, Funny)
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.
Re:Switching images is far more fun (Score:2)
Re:Switching images is far more fun (Score:2)
Re:Switching images is far more fun (Score:2)
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 witho
Re:Switching images is far more fun (Score:2)
Yeah, it was a wonderful little replacement image. Totally disruptive, very hilarious, non-offensive (harmless), and costs next to no bandwidth.
Re:Switching images is far more fun (Score:3, Informative)
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?
Re:Switching images is far more fun (Score:2)
Apache recipe (Score:5, Informative)
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>
Slightly better solution (Score:3, Informative)
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.
I wonder how long it'll take... (Score:1)
There has to be someone out there dumb enough to sue over this...
add copyright notice (Score:1)
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.
Uh Oh! (Score:2, Funny)
Does this mean a goatse or tubgirl link will get you modded up "+1 Informative"?
A sad day, indeed.
Re:Uh Oh! (Score:2)
Hmm, let's try it. For those of you who don't know what he was refering too, goatse [goat.cx] and tubgirl [tubgurl.com] are those sites.
duh (Score:2, Funny)
Re:duh (Score:1)
And how can you stop me from using View Source?
Re:duh (Score:2)
> No View menu, no view source!
> Ha! Indefeatable security!
telnet 80
GET
Defeated.
Re:duh (Score:2, Funny)
Jebus Chrisp, man, you've just created a copy protection circumvention device! Off to the gallows with you!
duh^2 (Score:2)
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.
Re:duh (Score:2)
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".
Re:duh (Score:2)
Re:duh (Score:2)
Re:duh (Score:2)
Re:duh (Score:2)
Yeah right (was Re:duh) (Score:2)
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 web
Konqueror runs these scripts... (Score:2)
To those who choose to use referrer (Score:4, Insightful)
May I make the following suggestions?
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?
Re:To those who choose to use referrer (Score:2)
Apache recipe in this previous comment [slashdot.org].
Your provider (Score:2)
Re:Your provider (Score:2)
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.
Re:Your provider (Score:2)
A better way to do it (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/ [alistapart.com]
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.
Problems with simple blocks (Score:3, Insightful)
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.
more bait-and-switch ideas (Score:3)