What is the def of a web bug as termned in the http proxy content filter..and i am assuming it only protects regular http traffic? will it also stop web bugs inside html mails?
Determining "what is a web bug" is harder than it looks, because the definiton relies on something that's mostly unavailable to the proxy server. A transparent, one-pixel GIF can either be used for alignment or for tracking, and it's not obvious how to tell which is which.
The operational definition I use is
A one-pixel transparent GIF served from a machine under different administrative control than the page that requests it.
One cannot simply look at the domain names and conclude that "different domain = it's a web bug". There are plenty of sites that hosts images from a different domain than the main page, and this is done to avoid having to send cookie traffic to an image server. There's no point in sending the main site's cookie in order to fetch a smiley face or an alignment GIF.
This is the case at BroadbandReports: the images are served from i.dslr.net, but because it's under the same administrative control as the main site, it can't be used for tracking that couldn't be done by just looking at the main site's logs. It's just not a web bug.
Only when the bug is served from a third party webserver under different administrative control (and often with tracking information appended) is it a web bug.
There are some cases that are pretty easy to get right: if the GIF is from the same site, then it's not a web bug. If the GIF includes tracking information appended, then it almost certainly is a web bug. But this leaves a lot of other uncertain cases.
I'm not sure how software can really tell the difference in practice unless extensive whitelists and blacklists are maintained.
Determining "what is a web bug" is harder than it looks, because the definiton relies on something that's mostly unavailable to the proxy server. A transparent, one-pixel GIF can either be used for alignment or for tracking, and it's not obvious how to tell which is which.
The operational definition I use is
A one-pixel transparent GIF served from a machine under different administrative control than the page that requests it.
One cannot simply look at the domain names and conclude that "different domain = it's a web bug". There are plenty of sites that hosts images from a different domain than the main page, and this is done to avoid having to send cookie traffic to an image server. There's no point in sending the main site's cookie in order to fetch a smiley face or an alignment GIF.
This is the case at BroadbandReports: the images are served from i.dslr.net, but because it's under the same administrative control as the main site, it can't be used for tracking that couldn't be done by just looking at the main site's logs. It's just not a web bug.
Only when the bug is served from a third party webserver under different administrative control (and often with tracking information appended) is it a web bug.
There are some cases that are pretty easy to get right: if the GIF is from the same site, then it's not a web bug. If the GIF includes tracking information appended, then it almost certainly is a web bug. But this leaves a lot of other uncertain cases.
I'm not sure how software can really tell the difference in practice unless extensive whitelists and blacklists are maintained.
