Jump to content

Inline linking: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Common uses of linked content: Per MOS:YOU the pronoun 'you' shouldn't be used in articles
m Reverted edits by 2001:1670:18:892A:FDF1:6102:556A:3B66 (talk): unexplained content removal (HG) (3.4.12)
 
(36 intermediate revisions by 23 users not shown)
Line 1: Line 1:
{{Short description|Use of a linked object on one web page to a second site}}
{{redirect|Hotlink|the Malaysian prepaid mobile service|Maxis Communications}}
{{redirect|Hotlink|the Malaysian prepaid mobile service|Maxis Communications}}
'''Inline linking''' (also known as '''hotlinking''', '''piggy-backing''', '''direct linking''', '''offsite image grabs''', '''bandwidth theft''',<ref name=bandwidth-theft /> and '''leeching''') is the use of a linked object, often an image, on one site by a web page belonging to a second site. One site is said to have an inline link to the other site where the object is located.
{{redirect|Hot link|the spicy type of sausage|Hot link (sausage)}}
{{multiple issues|
{{Missing information|Remote&nbsp;loading|date=March 2008}}
{{More citations needed|date=November 2007}}
{{Self reference|{{for|information about inline image linking on Wikipedia|WP:HOTLINK}}|}}
}}

'''Inline linking''' (also known as '''hotlinking''', '''leeching''', '''piggy-backing''', '''direct linking''', '''offsite image grabs''') is the use of a linked object, often an image, on one site by a [[web page]] belonging to a second site. One site is said to have an inline link to the other site where the object is located.


==Inline linking and HTTP==
==Inline linking and HTTP==
The technology behind the World Wide Web, the [[Hypertext Transfer Protocol]] (HTTP), does not make any distinction of types of links—all links are functionally equal. Resources may be located on any server at any location.
The technology behind the World Wide Web, the [[Hypertext Transfer Protocol]] (HTTP), does not make any distinction of types of links—all links are functionally equal. Resources may be located on any server at any location.


When a web site is visited, the browser first downloads the textual content in the form of an HTML document. The downloaded HTML document may call for other HTML files, images, scripts and/or [[style sheet (web development)|stylesheet]] files to be processed. These files may contain <code>&lt;img&gt;</code> tags which supply the [[Uniform Resource Locator|URLs]] which allow images to display on the page. The HTML code generally does not specify a server, meaning that the web browser should use the same server as the parent code (<code>&lt;img src="picture.jpg" /&gt;</code>). It also permits absolute URLs that refer to images hosted on other servers (<code>&lt;img src="<nowiki>http://www.example.com/picture.jpg</nowiki>" /&gt;</code>).
When a website is visited, the browser first downloads the textual content in the form of an HTML document. The downloaded HTML document may call for other HTML files, images, scripts and/or [[style sheet (web development)|stylesheet]] files to be processed. These files may contain <code>&lt;img&gt;</code> tags which supply the [[Uniform Resource Locator|URLs]] which allow images to display on the page. The HTML code generally does not specify a server, meaning that the web browser should use the same server as the parent code (<code>&lt;img src="picture.jpg" /&gt;</code>). It also permits absolute URLs that refer to images hosted on other servers (<code>&lt;img src="<nowiki>http://www.example.com/picture.jpg</nowiki>" /&gt;</code>).


When a browser downloads an HTML page containing such an image, the browser will contact the remote server to request the image content.
When a browser downloads an HTML page containing such an image, the browser will contact the remote server to request the image content.
Line 19: Line 13:
The ability to display content from one site within another is part of the original design of the Web's [[hypertext]] medium. Common uses include:
The ability to display content from one site within another is part of the original design of the Web's [[hypertext]] medium. Common uses include:


* It is copyright infringement to make copies of a work for which the person making copies has no license, but there is no infringement when the re-user provides a simple text link within an HTML document that points to the location of the original image or file (simply called a "link").<ref>{{cite web|url=http://www.techdirt.com/articles/20100105/0109067611.shtml|title=Is Inline Linking To An Image Copyright Infringement?|access-date=2014-02-15|publisher=Techdirt|author=Mike Masnick}}</ref>
* It is copyright infringement to make copies of a work for which the person making copies has no license, but there is no infringement when the re-user provides a simple text link within an HTML document that points to the location of the original image or file (simply called a "link").<ref>{{cite web|url=http://www.techdirt.com/articles/20100105/0109067611.shtml|title=Is Inline Linking To An Image Copyright Infringement?|access-date=2014-02-15|publisher=Techdirt|author=Mike Masnick|date=6 January 2010 }}</ref>
* Web architects may deliberately segregate the images of a site on one server or a group of servers. Hosting images on separate servers allows the site to divide the bandwidth requirements between servers. As an example, the high-volume site [[Slashdot]] stores its "front page" at <code>slashdot.org</code>; individual stories on servers such as <code>games.slashdot.org</code> or <code>it.slashdot.org</code>; and serves images for each host from <code>images.slashdot.org</code>.
* Web architects may deliberately segregate the images of a site on one server or a group of servers. Hosting images on separate servers allows the site to divide the bandwidth requirements between servers. As an example, the high-volume site [[Slashdot]] stores its "front page" at <code>slashdot.org</code>, individual stories on servers such as <code>games.slashdot.org</code> or <code>it.slashdot.org</code>, and serves images for each host from <code>images.slashdot.org</code>.
* An article on one site may choose to refer to copyrighted images or content on another site via inline linking, which may avoid rights and ownership issues that copying the original files could raise. However, this practice is generally discouraged due to resulting bandwidth loading of the source, and the source provider is often offended because the viewer is not seeing the whole original page, which provides the intended context of the image.
* An article on one site may choose to refer to copyrighted images or content on another site via inline linking, which may avoid rights and ownership issues that copying the original files could raise. However, this practice is generally discouraged due to resulting bandwidth loading of the source, and the source provider is often offended because the viewer is not seeing the whole original page, which provides the intended context of the image.
* Many web pages include [[Web banner|banner ad]]s. Banner ads are images hosted by a company that acts as middleman between the advertisers and the web sites on which the ads appear. The <code>&lt;img&gt;</code> tag may specify a URL to a [[Common Gateway Interface|CGI]] 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.
* Many web pages include [[Web banner|banner ad]]s. Banner ads are images hosted by a company that acts as middleman between the advertisers and the websites on which the ads appear. The <code>&lt;img&gt;</code> tag may specify a URL to a [[Common Gateway Interface|CGI]] 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.
* Some websites hotlink from a faster server to increase client loading speed.
* Some websites hotlink from a faster server to increase client loading speed.
* [[Hit counter]]s or [[Web counter]]s show how many times a page has been loaded. Several companies provide hit counters that are maintained off site and displayed with an inline link.
* [[Hit counter]]s or [[Web counter]]s show how many times a page has been loaded. Several companies provide hit counters that are maintained off site and displayed with an inline link.
Line 36: Line 30:
* The requests for inline objects usually contain the [[HTTP referrer|referrer]] information. This leaks information about the browsed pages to the servers hosting the objects (see [[web visitor tracking]]).
* The requests for inline objects usually contain the [[HTTP referrer|referrer]] information. This leaks information about the browsed pages to the servers hosting the objects (see [[web visitor tracking]]).


==Prevention==
== Prevention ==
[[File:Oops! Hotlinking not allowed (Tahupedia.com).jpg|thumb|right|A placeholder image used when attempting to hotlink to a website which disallows it]]


===Client side===
=== Client side ===


Most web browsers will blindly follow the URL for inline links, even though it is a frequent security complaint.<ref>{{cite web
Most web browsers will blindly follow the URL for inline links, even though it is a frequent security complaint.<ref>{{cite web
Line 49: Line 44:
}}</ref> Embedded images may be used as a [[web bug]] to track users or to relay information to a third party. Many [[ad filtering]] browser tools will restrict this behavior to varying degrees.
}}</ref> Embedded images may be used as a [[web bug]] to track users or to relay information to a third party. Many [[ad filtering]] browser tools will restrict this behavior to varying degrees.


===Server side===
=== Server side ===


Some servers are programmed to use the [[HTTP referer|HTTP 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.<ref>{{cite web
Some servers are programmed to use the [[HTTP referer|HTTP 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.<ref name=bandwidth-theft>{{cite web
|url=http://www.yourhtmlsource.com/sitemanagement/bandwidththeft.html
|url=http://www.yourhtmlsource.com/sitemanagement/bandwidththeft.html
|title=Bandwidth Theft
|title=Bandwidth Theft
Line 70: Line 65:
[[URL rewriting]] is often used (e.g., mod_rewrite with [[Apache 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 as [[Adobe Flash|Flash]]).
[[URL rewriting]] is often used (e.g., mod_rewrite with [[Apache 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 as [[Adobe Flash|Flash]]).


Other solutions usually combine [[URL 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.<ref>{{cite web|last1=Aleksandersen|first1=Daniel|title=Image quality degradation as a hotlink prevention measure and deterrent|url=https://www.slightfuture.com/webdev/modern-hotlink-protection|website=Slight Future|access-date=1 September 2016}}</ref>
Other solutions usually combine [[URL 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.<ref>{{cite web|last1=Aleksandersen|first1=Daniel|title=Image quality degradation as a hotlink prevention measure and deterrent|url=https://www.slightfuture.com/webdev/modern-hotlink-protection|website=Slight Future|date=30 August 2016 |access-date=1 September 2016}}</ref>


==Copyright issues raised by inline linking==
==Copyright issues raised by inline linking==
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, in ''[[Perfect 10, Inc. v. Amazon.com, Inc.]]'',<ref>487 F.3d 701 (9th Cir. 2007).</ref> the [[United States Court of Appeals for the Ninth Circuit]] explained why inline linking did not violate US copyright law:
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, in ''[[Perfect 10, Inc. v. Amazon.com, Inc.]]'',<ref>487 F.3d 701 (9th Cir. 2007).</ref> the [[United States Court of Appeals for the Ninth Circuit]] explained why inline linking did not violate US copyright law:


<blockquote>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....</blockquote>
<blockquote>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....</blockquote>


==See also==
==See also==
*[[Copyright aspects of hyperlinking and framing]]
*[[Copyright aspects of hyperlinking and framing]]
*[[Deep linking]]
*[[Deep linking]]
*Link awareness


==References==
==References==
{{reflist|30em}}
{{reflist|30em}}{{Authority control}}


[[Category:Internet terminology]]
[[Category:Internet terminology]]

Latest revision as of 08:32, 24 November 2024

Inline linking (also known as hotlinking, piggy-backing, direct linking, offsite image grabs, bandwidth theft,[1] and leeching) is the use of a linked object, often an image, on one site by a web page belonging to a second site. One site is said to have an inline link to the other site where the object is located.

Inline linking and HTTP

[edit]

The technology behind the World Wide Web, the Hypertext Transfer Protocol (HTTP), does not make any distinction of types of links—all links are functionally equal. Resources may be located on any server at any location.

When a website is visited, the browser first downloads the textual content in the form of an HTML document. The downloaded HTML document may call for other HTML files, images, scripts and/or stylesheet files to be processed. These files may contain <img> tags which supply the URLs which allow images to display on the page. The HTML code generally does not specify a server, meaning that the web browser should use the same server as the parent code (<img src="picture.jpg" />). It also permits absolute URLs that refer to images hosted on other servers (<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.

Common uses of linked content

[edit]

The ability to display content from one site within another is part of the original design of the Web's hypertext medium. Common uses include:

  • It is copyright infringement to make copies of a work for which the person making copies has no license, but there is no infringement when the re-user provides a simple text link within an HTML document that points to the location of the original image or file (simply called a "link").[2]
  • Web architects may deliberately segregate the images of a site on one server or a group of servers. Hosting images on separate servers allows the site to divide the bandwidth requirements between servers. As an example, the high-volume site Slashdot stores its "front page" at slashdot.org, individual stories on servers such as games.slashdot.org or it.slashdot.org, and serves images for each host from images.slashdot.org.
  • An article on one site may choose to refer to copyrighted images or content on another site via inline linking, which may avoid rights and ownership issues that copying the original files could raise. However, this practice is generally discouraged due to resulting bandwidth loading of the source, and the source provider is often offended because the viewer is not seeing the whole original page, which provides the intended context of the image.
  • Many web pages include banner ads. Banner ads are images hosted by a company that acts as middleman between the advertisers and the websites on which the ads appear. The <img> tag may specify a URL to a CGI 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.
  • Some websites hotlink from a faster server to increase client loading speed.
  • Hit counters or Web counters show how many times a page has been loaded. Several companies provide hit counters that are maintained off site and displayed with an inline link.

Controversial uses of inline linking

[edit]

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.

  • Content sites where the object is stored and from which it is retrieved may not like the new placement.
  • Inline linking to an image stored on another site increases the bandwidth use of that site even though the site is not being viewed as intended. The complaint may be the loss of ad revenue or changing the perceived meaning through an unapproved context.
  • Cross-site scripting and phishing attacks may include inline links to a legitimate site to gain the confidence of a victim.
  • Pay-per-content services may attempt to restrict access to their content through complex scripting and inline linking techniques.
  • Inline objects can be used to perform drive-by attacks on the client, exploiting faults in the code that interprets the objects. When an object is stored on an external server, the referring site has no control over if and when an originally beneficial object's content is replaced by malicious content.
  • The requests for inline objects usually contain the referrer information. This leaks information about the browsed pages to the servers hosting the objects (see web visitor tracking).

Prevention

[edit]
A placeholder image used when attempting to hotlink to a website which disallows it

Client side

[edit]

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 a web bug to track users or to relay information to a third party. Many ad filtering browser tools will restrict this behavior to varying degrees.

Server side

[edit]

Some servers are programmed to use the HTTP 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 with Apache 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 as Flash).

Other solutions usually combine URL 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]

[edit]

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, in Perfect 10, Inc. v. Amazon.com, Inc.,[6] the United 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....

See also

[edit]

References

[edit]
  1. ^ a b Ross Shannon (2007-02-26). "Bandwidth Theft". yourhtmlsource.com. Retrieved 2007-11-16. Some webmasters will try to directly link to your images from their pages. Luckily, a simple configuration change provides the necessary fix.
  2. ^ Mike Masnick (6 January 2010). "Is Inline Linking To An Image Copyright Infringement?". Techdirt. Retrieved 2014-02-15.
  3. ^ Thomas C Greene (2007-02-20). "Vista Security Oversold". theregister.co.uk. Retrieved 2007-11-16.
  4. ^ Thomas Scott (2004-07-13). "Smarter Image Hotlinking Prevention". alistapart.com. Retrieved 2007-11-16.
  5. ^ Aleksandersen, Daniel (30 August 2016). "Image quality degradation as a hotlink prevention measure and deterrent". Slight Future. Retrieved 1 September 2016.
  6. ^ 487 F.3d 701 (9th Cir. 2007).