Inline linking (also known ashotlinking,piggy-backing,directlinking,offsiteimagegrabs,bandwidththeft,[1] orleeching) is the practice of using orembedding a linked object—often an image—from onewebsite onto awebpage of another website. In this process, the second site does nothost the object itself but instead loads it directly from the original source, creating aninline link to the hosting site.
TheHypertext Transfer Protocol (HTTP), the technology behind theWorld Wide Web, does not differentiate between different types of links—all links are functionally equal. As a result, resources can be linked from anyserver and loaded onto aweb page regardless of their original location.
When a website is visited, the browser first downloads the HTML document containing the web page's textual content. This document may reference additional resources, including other HTML files, images, scripts, orstylesheet. Within the HTML,<img>
tags specify theURLs of images to be displayed on the page. If the<img>
tag does not specify a server, theweb browser assumes that the image is hosted on the same server as the parent page (e.g.,<img src="picture.jpg" />
). If the<img>
tag contains an absolute URL, the browser retrieves the image from an external server (e.g.,<img src="http://www.example.com/picture.jpg" />
).
When a browser downloads an HTML page containing such an image, the browser will contact the remote server to request the image content.
The ability to display content from one site within another is part of the original design of the Web'shypertext medium. Common uses include:
slashdot.org
, individual stories on servers such asgames.slashdot.org
orit.slashdot.org
, and serves images for each host fromimages.slashdot.org
.<img>
tag may specify a URL to aCGI script on the ad server, including a string uniquely identifying the site producing the traffic, and possibly other information about the person viewing the ad, previously collected and associated with a cookie. The CGI script determines which image to send in response to the request.The blurring of boundaries between sites can lead to other problems when the site violates users' expectations. Other times, inline linking can be done for malicious purposes.
Most web browsers will blindly follow the URL for inline links, even though it is a frequent security complaint.[3] Embedded images may be used as aweb bug to track users or to relay information to a third party. Manyad filtering browser tools will restrict this behavior to varying degrees.
Some servers are programmed to use theHTTP referer header to detect hotlinking and return a condemnatory message, commonly in the same format, in place of the expected image or media clip. Most servers can be configured to partially protect hosted media from inline linking, usually by not serving the media or by serving a different file.[1][4]
URL rewriting is often used (e.g., mod_rewrite withApache HTTP Server) to reject or redirect attempted hotlinks to images and media to an alternative resource. Most types of electronic media can be redirected this way, including video files, music files, and animations (such asFlash).
Other solutions usually combineURL rewriting with some custom complex server side scripting to allow hotlinking for a short time, or in more complex setups, to allow the hotlinking but return an alternative image with reduced quality and size and thus reduce the bandwidth load when requested from a remote server. All hotlink prevention measures risk deteriorating the user experience on the third-party website.[5]
The most significant legal fact about inline linking, relative to copyright law considerations, is that the inline linker does not place a copy of the image file on its own Internet server. Rather, the inline linker places a pointer on its Internet server that points to the server on which the proprietor of the image has placed the image file. This pointer causes a user's browser to jump to the proprietor's server and fetch the image file to the user's computer. US courts have considered this a decisive fact in copyright analysis. Thus, inPerfect 10, Inc. v. Amazon.com, Inc.,[6] theUnited States Court of Appeals for the Ninth Circuit explained why inline linking did not violate US copyright law:
Google does not...display a copy of full-size infringing photographic images for purposes of the Copyright Act when Google frames in-line linked images that appear on a user's computer screen. Because Google's computers do not store the photographic images, Google does not have a copy of the images for purposes of the Copyright Act. In other words, Google does not have any "material objects...in which a work is fixed...and from which the work can be perceived, reproduced, or otherwise communicated" and thus cannot communicate a copy. Instead of communicating a copy of the image, Google provides HTML instructions that direct a user's browser to a website publisher's computer that stores the full-size photographic image. Providing these HTML instructions is not equivalent to showing a copy. First, the HTML instructions are lines of text, not a photographic image. Second, HTML instructions do not themselves cause infringing images to appear on the user's computer screen. The HTML merely gives the address of the image to the user's browser. The browser then interacts with the computer that stores the infringing image. It is this interaction that causes an infringing image to appear on the user's computer screen. Google may facilitate the user's access to infringing images. However, such assistance raised only contributory liability issues and does not constitute direct infringement of the copyright owner's display rights. ...While in-line linking and framing may cause some computer users to believe they are viewing a single Google webpage, the Copyright Act...does not protect a copyright holder against [such] acts....
Some webmasters will try to directly link to your images from their pages. Luckily, a simple configuration change provides the necessary fix.