Subject:
|
Re: Cracking down on unauthorized image links
|
Newsgroups:
|
lugnet.admin.general
|
Date:
|
Fri, 4 Jun 1999 18:23:49 GMT
|
Viewed:
|
850 times
|
| |
|
|
In lugnet.admin.general, david_nospam@sork.com (D Sorkin) writes:
> Instead of frustrating both the image pirates and their prospective
> customers, why not turn this situation to your advantage? Suppose that
> each time an HTTP request is made for an unauthorized image, you serve
> up a substitute image containing an advertisement in place of the
> original. The substitute image could be mostly text in a limited number
> of colors (does this reduce the size of a JPEG image much, or does it
> only work for GIFs?), but with the same dimensions as the original (in
> case the embedded image link includes HEIGHT and WIDTH paramaters).
> The text would be an advertisement for Lugnet, perhaps with instructions
> to prospective bidders on how they can locate Lugnet images in an
> authorized manner. (You could also include a statement chastising the
> image thief, of course, but why bother if you end up benefiting from it?
> For that matter, you could even sell this advertising space to others --
> Mega Blocks and Amazon.com auctions come to mind -- perhaps for a
> premium, since it's relatively well targeted.)
That's an intriguing idea. I've seen similar sorts of things where a static
(maybe 2KB) image is plopped up in place of the real image, and it typically
gets scaled by modern browsers and looks all chunky and like that. But
you're talking about actually returning something that doesn't need to be
scaled at the client?
Returning a static image is just as easy (from an implementation standpoint)
as returning a broken/empty image, but even a 2KB static image is still a
resource drag -- about 9 times as much of a drag as a broken/empty image is.
Returning a dynamically scaled or sized image is a bit more difficult (from
an implementation standpoint) and a much larger drag, both in bandwidth and
CPU, compared to a static image or a broken/empty image. Consider that, to
be readable, a custom-scaled image has to be down-sampled from a
significantly larger image rather than up-sampled from a smaller image.
So it really wouldn't be worth the bandwidth- and CPU- hit, unfortunately,
to return a custom-scaled image each time.
In any case, how many people are going to attempt to make a link and see
that it doesn't work, and then actually leave it that way (broken)? I think
very, very few people would do that -- especially those running auctions.
My real concern with making accidentally broken links is the browser's
cache. If someone visits the a page for a set, and they do View Image from
their browser, and they cut & paste the image's URL into their own page,
then it's very likely that when they view their own page to test the link,
the image will actually show up (because it's still in their browser's
cache)! One way around this is to include a no-cache pragma in the HTTP
headers whenever the images are served, but then that creates an additional
drag on both the server and clients.
--Todd
|
|
Message has 1 Reply:
 | | Re: Cracking down on unauthorized image links
|
| (...) By the way: David, there is no way that an HTTP server can know the size of an image that a client/browser is expecting. That is, the HEIGHT and WIDTH attributes of the <IMG> tag are known only to the client/browser and to the originator of (...) (25 years ago, 4-Jun-99, to lugnet.admin.general)
|
Message is in Reply To:
| | Re: Cracking down on unauthorized image links
|
| (...) Todd - Instead of frustrating both the image pirates and their prospective customers, why not turn this situation to your advantage? Suppose that each time an HTTP request is made for an unauthorized image, you serve up a substitute image (...) (25 years ago, 4-Jun-99, to lugnet.admin.general)
|
41 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
