intertwingly

There are, as I'm sure you're aware, technical measures against such things. LiveJournal has a quick guide.

Martin, I did forbidden for a few days.  That was ineffective in either case.  Now, I'm doing a redirect.  That got quickly noticed in one case, and corrected.

For a while, I would substitute the images for some of an inappropriate nature, but it was happening so often that I gave up.

Bandwidth theft really sucks, and it is always some child posting to a forum or something.

If you're feeling mischievous you could make your images require HTTP authentication when accessed from offsite, so that the page in question will pop up a username/password dialog box when the image loads. A lot more noticeable than a broken image.

I did that once to get a particularly annoying linker off my back, but you don't really need it once you've got rid of the few folks who persist for a while after you introduce preventative measures.

A solution for Sam's little problem: change the picture identified by the URL they are referencing. I had this happen a while back so I changed the image to include a message, something like: "You're seeing this message because the...... [more]

Trackback from snellspace

http://www.harrumph.com/020727.shtml contains some cute before and after shots of a creative redirect.

I must admit that I am quite enamored of Martin's suggestion above and have now applied it to the remaining culprit.

I took a low-tech method to this problem.  I use some of that free web space given to me by my ISP, and host my highest HTTP GETs there (I look at the web logs every couple of days to make sure that I don't find anything new).

But, I do like the code method better.  The best design I remember is using an ASPX file with an id that returns the desired image, but only to if the page referrer matches the desired qualifications.

It had never occurred to me that this was something that upset people.  I don't think I've ever included an image from a remote site on my page (can't think why I'd want to) but I'm sure there are a lot of people out there who would never think, "I am costing someone money."  Internet content seems so free to the average web surfer, I bet you have to be hosting a site and hit a bandwidth limit before you even give it a thought.

So I think it's best to be polite about it.  I dunno; maybe there are people out there who do this maliciously (that would be awful) but I bet most people just think "hey there's this image out there I want people to be able to see on my page."

I haven't been paying a lot of attention to atom lately, but the embedding of mime content as a possibility caught my eye.  This is just an awful, awful idea.  Why?  Have a look at my comment here:

<a href="http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237052708">http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237052708</a>

Say you stick a 3 MB attachment into your feed.  Every new entry you add after that will ensure that all blog clients download your entire atom feed again (because last-modified and etags will have changed).  That means that until that attachment post ages off, everyone who subscribes to your feed is stuck downloading the whole blasted thing over and over again.  RSS got this right with enclosures, and Atom gets it horribly wrong. 

If people start using Atom and feed providers start using this feature in a big way, then you'll see aggregator usage drop off a lot - it will become painful - bandwidth sucking on the feed side, and memory sucking on the client side. Kill this bad idea now.

Just because you can embed a 3MB attachment into your feed doesn't mean you should. I can use IMG tags on a web page and point them at a 3MB image but it doesn't make it a good idea. What's the difference?

The difference is that news aggregators will be downloading the entire image every time the feed gets updated, whereas a web page image will gete cached.  If you put a link in a feed, an aggregator could have an option to follow the link, and cache the image.  Slapping the image bits in the feed itself is just hostile, and it should not be part of any standard.

Copying from what I wrote on Scott Johnson's FuzzyBlog,

The Atom <content> element (currently) has a "src=" attribute specifically for content-by-reference, whether it's a 3MB MPEG or a 5KB HTML entry. Feed size recommendations (ie. warnings) will be included in the validator, which already has a 200KB limit on feed size anyway.

Adding: if people were to make use of 'src=' for full body content (that is to say, the publisher wants their content displayed in the aggregator but doesn't want to burden the feed with that content), Atom feeds may turn out to be far smaller than many current RSS feeds.