7 comments

[ 2.4 ms ] story [ 27.8 ms ] thread
Steals traffic - Digg doubles its traffic by showing your content in its frame and redirecting the shortened urls back to Digg instead of to your site.

When I share a site on Twitter or whatever, I usually link to the social news site instead of the site directly. I want my karma, and I want all the comments in one place. So toolbar or not, you aren't getting linked directly.

Also, this is not stealing. This gives you traffic that you wouldn't have had otherwise.

Steals links - by creating shortened urls that are redirect to Digg first and foremost

Not stealing. Want some cheese with that whine?

Steals content - your content is essentially being hosted by Digg through it’s framing structure.

Completely wrong, unless you think that web browsers are stealing your content. I mean, on Macs there is that Apple logo above your page, and in Firefox, there is a Firefox logo! Oh noes! (What's the difference between a Digg toolbar and browser chrome? I certainly don't see one.)

Steals potential revenue - by either blocking your content/ads or by stealing ad impressions/clicks.

Completely false. I use AdBlock anyway, so no need to worry. Nobody sees your ads.

Enables others to justify framing as well - then we are right back to where we started in the late 1990’s when websites were nothing more than frames within frames and lawsuits are handed dished out like candy.

"Handed dished"? Citation needed.

Citation needed for everything, in fact.

I'm pretty sure that pages loading in the diggbar iframe still count towards your pageview numbers (your internal analytics will pick it up). Not to mention the fact that your ads get displayed, allowing ppl to still click them.

The whole 'Digg is making money off your content' argument is moot. They have always made money off your content. There was never anything original on digg. They've just decided to take it to a whole new level. Now if someone comes up with data that shows that the diggbar lowers your revenue (which as of now, I don't think it does) while raising theirs, then it's time to grab the pitchforks and torches to go pay kevin rose a visit.

P.S. I just realized, another difference is with 3rd party traffic estimates. Comscore and quantcast probably won't count those iframe pageviews. Compare that with the traffic lost by blocking the diggbar (assuming yours is a 'diggable' site to begin with)

About the page view argument: this article shows a lack of understanding about the HTTP request. The browser does not add additional headers to a request indicating that a page is loading in an iframe. Therefore loading a page in an iframe has the same effects (from a traffic standpoint) as loading the page normally.

About the ads argument: Eh...maybe. I work on content-based websites everyday and a lot of thinking goes into ad placement. Digg/Facebook/Stumbleupon/whoever else are altering the presentation of these content sites and essentially placing ads on every site a user visits through their pages. Maybe that is the cost of having your content promoted on these sites. A 20 px toolbar won't affect most sites although it does look unprofessional and sloppy. At the end of the day, the content publishers have the right to control the presentation of their content and I would expect many to just break these toolbars using js. To my knowledge the top.location hack can't be stopped...believe me. Whether, as a content publisher, you support the toolbar doesn't matter. If you are in support of it you don't need to do anything otherwise you can insert a little js on your site and call it a day.

To my knowledge the top.location hack can't be stopped...believe me.

I did a quick experiment. If you set top = null, then top.location stops working.

It turns out that I am wrong:

http://gist.github.com/90381

Were you able to get it working in any browsers or did you discover it does not work at all later? That would be a huge loophole if it worked in any browser under any circumstances.
I only tried Firefox.

Basically, you can set top = null in the parent page, and it behaves as you expect -- there is no magic going on. But "top" gets reset for the iframe.

I didn't try anything more evil than that, though. I think if the parent script did something like "while(1){}", it could "starve" the iframe of CPU time, and it would never have the chance to change the URL.

At that point, though, I think I would just implement the toolbar as browser chrome.