When GeoCities suspended hundreds of WebTV users for a "remote loading" violation of their
Terms of Service, many of them wrote to us and asked what it meant, and how they could avoid
it. Remote loading is sometimes called "linking in" graphics or audio files. In this article,
we'll try to explain and to answer some of the most common questions.
Everything Has An Address
Everything that's available on the World Wide Web has an Internet address, which is how our browsers (PC or WebTV) are able to find it. Even if you don't build homepages, you're already
familiar with some Internet addresses. Here's what the various elements mean, using Net4TV
Voice as an example:
The address (URL, or Uniform Resource Locator) of this page is:
This means that the page is provided by a web server, because it's using Hypertext
Protocol. That tells your browser how to ask for it.
This is the domain name of our site. The "real" address is a string of numbers called an
IP (Internet Protocol) number. When you enter "Net4TV.com," the browser (or WebTV proxy
server) looks up the name in an Internet directory called a DNS server and gets the number. We
use names in the address, rather than the actual number, because they're easier for people to
remember, and also so that if the number changes, we can change it in the DNS server but don't
have to change the domain name.
This is the path to the directory where the file (the page you're looking at) is
stored. In the case of a GeoCities site, for example, /Heartland/Hills/Address_Number
is the path.
This is the actual file name -- it could end in ".htm" or "html" for web pages, ".GIF" for
GIF images, ".MID" or ".MIDI" for MIDI files, etc. In our case, we serve our stories from a
database using a program called ColdFusion. The ending ".cfm?storyID=xxxx" tells the
ColdFusion engine to make a web page by putting the story with the ID number XXXX into a
template, before giving it to the web server to send it to you.
How Your Browser Shows a Page
All of the graphics that are in a web page also have an address. When your browser receives
the HTML page (our CFM pages are also HTML pages to the browser), it reads it and says "oh, I
need these graphics files... 'logo.gif' and 'picture.gif'... in order to display this
In the case of Net4TV, all of our graphics are on the same server as the web pages -- that is,
they have the same basic website address (domain name). So, your browser asks our server again
-- "would you send me the graphics files named (filename) that you have stored in (this
path)?" When it receives them, it puts them in the page that it is showing you. Here's an
animation that shows you how that works.
What Is "Remote Loading?"
Fundamentally, "remote loading" means calling resources -- GIFs, JPEGs, MIDIs, and other files
-- that are stored on a different server or website than the one where the web page is
stored. Remember, everything on the web has an address, and if you know that address, you
can call the file by using it.
Here are two example images, with their addresses as they are in the page source code:
Because the graphics are in the same place as the web page that's calling them, we're using
a "relative" URL -- an address that's relative to the page that is referencing them. When your
web browser receives the HTML page and asks for the graphics, it just tacks on the relative
reference to the page address to request the full address of the graphics: <IMG
SRC="graphics/story/newvoice3.gif"> <IMG SRC="http://www.iacta.com/graphics/carrier.jpg">
This graphic is on another server. The complete address of the file is necessary in order
to call it.
The Net4TV Voice banner is not being remote loaded -- it is located in the same website
as the Net4TV Voice page that is calling it. The "Carrier" graphic is being remote
loaded -- it is being called from another website on a different server and domain (in this
case, from our company site).
Here's an animation that shows what happens when a page uses remote loading. Sometimes, some
of the servers holding the "remote" resources don't answer or can't find the file, which slows
down the page display and causes "broken" images:
If you are remote-loading graphics into your web page, the other web servers have to be called for the graphics every time someone views your page. If 100 people visit your page today, and you are remote-loading a graphic from another server, that server is called 100 times to supply that graphic. If that graphic is 20K in size, those 100 hits cost the server that is storing it 2 Megabytes (20K * 100) in bandwidth.
Remote Loading in Email
ALL images and audio in HTML email are using remote loading, with the exception
of "vidcaps" or "audio captures" (pictures or audio recording you've captured into that email
using the WebTV Plus -- these files are actually attached to your email and travel along with
Does this mean that you are guilty of remote loading if you are using a GIF as a page
background in your email, playing a MIDI, or are showing a picture in your sig? Yes, it
For example, if you are using a 20K graphic in your email sig, every time someone who can see
HTML email opens an email that you've sent, that 20K graphic is called from the server where
it is stored. If you send out 10 emails to your mailing list of 10 friends, that is 2
Megabytes of bandwidth from the server where the graphic is stored -- as much as 100 hits to a
web page that has it. If you make just one post in a newsgroup and 100 people read it, that's
another 2 Megabytes. And if they read that post again tomorrow, that's another 2 Megabytes --
the graphics are all called again.
Why Remote Loading is a Bad Idea
We've seen a good example this week of why remote-loading is a bad idea -- it can cause the
website that is being loaded from to be shut down. GeoCities, Tripod, Angelfire, and most
other hosts, prohibit remote loading from a website on their service. The reason is
that it costs them bandwidth -- a lot of money -- but it does not give them the page views
(and ad views) that pay their bills.
One of the curious things is that none of these hosts prohibit remote-loading to a site
on their service. Their concern seems to be for their own bandwidth and pageviews, not for
good Netiquette or eliminating the remote-loading problem in general.
But there are also some other reasons why remote loading is a bad idea:
Slow Loading and Broken Images
Web pages and email that are remote loading require every server that holds some of the files
to be contacted and to respond with the files, before the page can be completed. This causes
pages to load very slowly, and to display "broken images" if the files have been moved or
deleted, or the web server doesn't answer.
And, when you remote load from another website, you have no control over whether or not those
files you've called are going to be deleted or moved, or even if another graphic with the same
name might be put in their place.
Webmasters who have a lot of remote linking to their images often rename their files on a
regular basis. Whenever we move or rename some of our files, we often get an email saying
"hey! you broke my sig (or web page)!" We try to explain that they are our files, and
that the person should not have been remote loading them. Sometimes, they apologize... and
sometimes, they just curse at us or remote-load another one of our files.
The picture or audio called by that filename also can be changed. For example, this month, we
found that a WebTV user was remote-loading a picture of a WebTV Plus from Net4TV into his
auction on eBay. We wrote to the user and asked him to stop. Not only did he ignore us and
fail to reply, but he put up a second auction and also remote-loaded the same image. Several
Megabytes of traffic per day was being pulled off of Net4TV by this user's auctions, and the
graphic also was being used without our permission.
So, we simply renamed the image (changing our web page that referenced it to the new name),
and put a new image in the directory with the name of the file that he was remote-linking.
Instantly, the picture of the WebTV Plus disappeared from his auction, replaced by this:
How, you might ask, did we know that this user was remote-loading our image onto eBay? Very
simple -- we can see remote-loading in our server logs, and any website administrator who has
access to the server logs can, too.
Every time a request for a file (HTML, graphic, audio, or any other) is made to a web server,
it carries some information along with the request. One piece of information is the IP address
of the computer that is requesting it (that's how we know how much of our traffic is WebTV
users, for example, because we see the IP address of the WebTV proxy servers). Another piece
of information is the "referring page."
If you have a regular hyperlink on your page to Net4TV and someone clicks on that link to come
to our site, their request for the HTML page comes with the information that they were
referred by your page. That's just fine, and we appreciate it.
But if you're remote-loading one of our images, we can see that, too. The server log
shows the hit to the image, and gives us the referring page address -- yours. When we get
concerned is when we see a lot of bandwidth going out from our graphics or audio files,
and those are the ones that we follow back to the source and ask the person not to do
If you're remote-loading something into WebTV email, we can see that, too. We can't see the
email address of the person who is doing it, but we can see the referring page as
This is how GeoCities was able to "sweep" and shut down a lot of websites for remote loading,
without having to examine every one in detail. The server logs showed them the outgoing
traffic that was not being referred by a webpage in the same GeoCities address.
How to Avoid Remote Loading
Use the Transloader, Freeloader, or the uploaders that are at Tripod and Angelfire (if you
build there) to make sure that all of the resources that you are using in your web page -- the
graphics and the audio -- are also in your website directory.
Once they are there, you can use "relative references" (just the filename, rather than the
full address) to call them. This also makes it easy to mirror or move your site to another
host. Once the calling page has a new address, all of the relative references will point to
the new address, too.
Things You Might Overlook....
Award banners and graphics for webring control panels often are remote-loaded. If someone
gives you an award or you join a webring, transload the graphics to your own directory, and
then hyperlink (make a clickable link) back to the site that they come from.
If you hand out awards or run a webring, ask your recipients and members to transload
the graphics to their own site, and follow up to make sure that they have. Otherwise, your
site host may shut you down because of the "outbound" traffic from the hits your graphics are
getting on another site.
Avoiding Remote Loading in Email
Don't use backgrounds or images from websites in your email, unless the person who owns the
website gives you specific permission and is paying themselves for the website, or is
on a web host that doesn't mind (if any exist).
Many of the sites that were suspended on GeoCities were not themselves involved in remote
loading, but other people were remote-loading from them into WebTV email. Some of these site owners
even thought it was OK, and gave people permission. But GeoCities, who pays the bills and makes
the rules, didn't think it was OK. Don't cost your friend his or her site by
remote-loading from it, even if you've got permission.
The ONE Place for Remote-Loading for WebTV Email
If you want to have HTML email that shows off some pictures, there is one place that it's
OK to remote load them from -- your WebTV PageBuilder web page.
The remote-loading problems in WebTV email are caused by the HTML display of that email
calling the remote servers. If you send me an HTML-filled email, I can't see the graphics --
my email reader doesn't show them -- so there's no remote loading when I open the mail. But
when you send to a WebTV user, or post in a newsgroup, the graphics are remote-loaded when the
mail or post is opened and displayed.
WebTV email to other WebTV users stays inside the WebTV service. So do the posts on WebTV's
newsreader (and on their news servers). So, if you remote-load from your PageBuilder page on
the WebTV servers, most of the bandwidth stays inside the WebTV service.
Right now, the WebTV PageBuilder does not support MIDI files. What this means, unfortunately,
is that there is no way currently to include a song in your email without remote-loading from
another site outside the WebTV service. Please don't do it -- complain to WebTV instead until
they support MIDI in the PageBuilder.
IMPORTANT: WebTV's Customer Service department has told users that "to put MIDI in your
email, you have to know HTML." In other words, they are telling you that you have to remote
load it from another site. This is bad advice. Tell them that they are promoting theft if
they tell you this, and that they must support MIDI in the PageBuilder.
The Cost of Bandwidth
The reason that this is such as sensitive issue is that Internet bandwidth is expensive! At
Net4TV, our T1 costs us over $26,000 per year, and that is a relative "thin" line that can get
full very quickly. Bigger sites have "fat pipes" connecting them directly to the Internet
backbone, but they not only pay a very high price for these, they also pay in addition for the
amount of bandwidth they actually use.
Free hosts like GeoCities and Tripod rely on advertising views to pay for the bandwidth, so
that's why they don't want remote loading that takes the bandwidth but doesn't give them ad
views in return.
Others, like the "free sites" that some ISPs will give you when you sign up with them, or
sites that may charge $10 per month or so for hosting, usually have a monthly bandwidth
allotment. A typical ISP may give you 500 MB a month in traffic with your "free site," or "$10
per month" site, and then charge from 3-cents to 10-cents per Megabyte for anything over that.
I know of several artists who had to shut down their sites, when their ISP presented them with
a bill for several hundred dollars worth of bandwidth -- all from people remote-loading
graphics from their sites.