Implementation
Originally, a web bug was a small (usually 1×1 pixel) transparent GIF or PNG image (or an image of the same color as the background) that was embedded in an HTML page, usually a page on the web or the content of an email. Modern web bugs also use the HTML IFrame, style, script, input link, embed, object, and other tags to track usage. Whenever the user opens the page with a graphical browser or email reader, the image or other information is downloaded. This download requires the browser to request the image from the server storing it, allowing the server to take notice of the download. As a result, the organization running the server is informed when the HTML page has been viewed.
The image or other content does not have to be invisible: any element requested from the third party can be used for tracking. Typically advertisements, banners and buttons are fetched from the site to which they are connected, not from the servers of the main content. This gives the external site information about visitors of the site including these on their pages. Companies or organisations, buttons or images of which are included on many sites, can thus track (part of) the browsing habits of a significant share of web users. Earlier this included mainly ad or counter serving companies, nowadays buttons of social media sites are becoming common.
While web bugs are used in the same way in web pages or emails, they have different purposes:
- If the bug is embedded in an email, the image is requested when the user reads the email for the first time, and can also be requested every time that the user subsequently loads the email;
- Whenever a web page (with or without bugs) is downloaded, the server holding the page knows and can store the IP address of the computer requesting the page; this information can therefore be retrieved from the server log files without the need of using bugs. Bugs are used when the monitoring party does not have easy access to the logs of the main web server. This may be, for example, because the web site owner does not control the web servers (web hotels) or because monitoring is done by a third party.
As with all files transferred using the Hypertext Transfer Protocol, web bugs are requested by sending the server their URL, and possibly the URL of the page containing them. Both URLs contain information that can be useful for the server:
- The URL of the page containing the bug allows the server to determine which particular web page the user has accessed;
- The URL of the bug can be appended with an arbitrary string in various ways while still identifying the same object; this extra information can be used to better identify the conditions under which the bug has been loaded, and can be added while sending the page or by JavaScript scripts after the download.
For example, an email sent to the address somebody@example.org
can contain the embedded image of URL http://example.com/bug.gif?somebody@example.org
. Whenever the user reads the email, the image at this URL is requested. The part of the URL after the question mark is ignored by the server for the purpose of determining which file to send, but the complete URL is stored in the server's log file. As a result, the file bug.gif
is sent and shown in the email reader; at the same time, the server stores the fact that the particular email sent to somebody@example.org
has been read. Using this system, a spammer or email marketer can send similar emails to a large number of addresses to check which ones are valid and read by the users.
Web bugs can be used in combination with HTTP cookies like any other object transferred using the HTTP protocol.
Read more about this topic: Web Bug