FeedBurner Plants a Bug

FeedBurner has begun adding web bugs to syndicated feeds that enable the service to track use of individual items. I noticed them recently in RSS feeds for The Nation:

Priscilla Owen's confirmation is the bitter fruit of the unprincipled "compromise" on judical nominations.

The img tag at the end of this description loads the web bug, a transparent one-by-one pixel graphic. Niall Kennedy wrote earlier this month that they're part of a paid statistics package.

Every time a bugged item is viewed in an aggregator, FeedBurner can track the IP address and user agent making the request. If a blog republishes an item verbatim, that also shows up in the usage stats.

Web bugs have privacy implications but have become commonplace in web sites and e-mail.

This is the first time I've seen one in RSS. I wrote some PHP code to squash the bugs before I pass along any stories from The Nation on my sites.

Rss · Publishing · 2005/05/26 · 10 COMMENTS · Link

Comments

Sweet! A lovely companion to the link element that isn't a permalink and the guid that is the permalink but claims not to be. In the last week, I've seen three posts where someone didn't realize that they were linking to someone's else's post through the Feedburner redirect link that in theory tells the publisher how many people click through from reading their feed.

#1 · Phil Ringnalda · 2005/05/27

Feedster's been doing it for months (which would be the reason I switched to PubSub).

feedster.com (view source and search for the img element)

#2 · Richard · 2005/05/27

If they're going to plant bugs, they could at least do it with width, height, and empty alt attributes...

#3 · James Kew · 2005/05/27

The FeedBurner developers are likely to see this discussion. They should fix the guid element to indicate that it's a permalink -- they're missing out on useful functionality for no discernible advantage.

#4 · Rogers Cadenhead · 2005/05/27

Thanks, Rogers. I've passed it along internally, will report back with an update...

It should be noted, by the way, that this web bug is inserted if (and only if) the publisher/blogger enables it as part of our Total Stats Pro service; the link rewrite is (as Phil points out) so that we can track click-throughs on items. That's also an opt-in thing - if publishers don't like it or don't want it, they simply don't turn that particular service on.

--Rick

----
Rick Klau
VP, Business Development
FeedBurner - http://www.feedburner.com
rickk -at- feedburner -dot- com
office: 312.442.9490
cell: 630.362.8911

#5 · Rick Klau · 2005/05/27

The web bugs are loaded when the feed is loaded and its entries are passed through an HTML engine. In the case of most desktop aggregators I've seen this means that if you load a feed with 15 entries all 15 web bugs are called even if no one actually viewed the item.

#6 · Niall Kennedy · 2005/05/27

Yah, I wasn't reporting a bug (heh) so much as an inevitable breakage of the stats, just like the way an invisible web bug will inevitably break with aggregators and posting tools that let people avoid ever seeing the HTML behind what they repost and quote.

But, I do see one potential bug: since feedburner.com certainly has higher PageRank than most of its users, you're poised to do 302 Hijacking in Google, if you haven't already done it. Having statistics that are skewed by one or two blog posts including the redirect URL is nothing compared to having all Google searches go through it. Dunno if the feeds. subdomain is enough to avoid that, or if it would take a separate feedburnerredirects.com domain to be sure you didn't accumulate PR (or, if you still would and it's unavoidable).

#7 · Phil Ringnalda · 2005/05/27

I don't understand the 302 hijack problem. Are you saying that if a high pagerank site like Scripting News were to use redirected URLS like this for links to Workbench, Google would conclude that the redirection was the real URL for my homepage?

#8 · Rogers Cadenhead · 2005/05/27

Thanks, Rogers, for hosting another great discussion. I'd like to add to what Rick said earlier in this thread and try to address some of the other questions presented by you, Phil, and James.

First off, as Rick mentioned, publishers have to explicitly add the premium "Total Stats PRO" service in order to have the gif added -- not only do they have to select the service, they have to pay for it!

While we do have access to the requesting IP address and user-agent (which as you mention could imply security concerns), we don't report that information. What we *do* report to the publisher is the "referrer" header, which is very exciting: it gives the publishers visibility to how their content is being "resyndicated". If the publisher notices that one of their posts is getting way more impressions than normal, they can look at the referrer stats and see where their content ended up. It's often surprising where one's content gets repurposed, and we want to provide publishers with that information. To that end, we hope that the gif travels with the item as it flows through the syndication networks.

A couple of other points, for Phil and Rogers. One thing we never touch as we process a feed is the guid element, although we may switch the isPermaLink attribute from "true" to "false" if we're rewriting a link on behalf of the publisher. Some more information on how we handle the link and guid elements is here: www.burningdoor.com

Phil, I see your point about 302 hijacking, but you'll have to take my word that it had never even crossed my mind that we'd ever use our domain for nefarious purposes. Our credability is of paramount importance to us; using a separate domain name for these redirects is a really good idea and I'll put it on the list -- thanks for that.

Finally, to James' point about adding height, width, and alt attributes: yes, we could, but we just wanted to make it as lightweight as possible. Since it's a 1x1 gif, we didn't think it would mess with layouts that much as it was rendered. But, point taken.

Sorry for the very wordy comment. I'll continue to follow this thread and try to address any follow-up questions. Thanks!

Eric Lunt
CTO, FeedBurner

#9 · Eric Lunt · 2005/05/27

302 Hijacking - yeah, you don't have to intend to do it, they just aren't perfect about guessing a canonical URL when they see 302s. The other day, they got hijacked themselves, the first result for "google adsense" was someone's redirect to the AdSense page.

#10 · Phil Ringnalda · 2005/05/27