Looks like the trick of using redirection CGIs at popular website (described in Phishing with Google) is getting popular among phishers.   I just got a couple that uses AOL's redir-complex CGI at:

http://r.aol.com/cgi/redir-complex?url=whereever

Note that phishers can use not just the redirecting CGIs, but also those CGIs that use return URL as parameters.  In fact, these types of CGIs are popular among financial institutions and single-sign on services.  For example, both Passport and 3D-Secure uses them.

Scoble writes:

RSS is broken, is what happened. It's not scalable when 10s of thousands of people start subscribing to thousands of separate RSS feeds and start pulling down those feeds every few minutes (default aggregator behavior is to pull down a feed every hour).

Bandwidth usage was growing faster than MSDN's ability to pay for, or keep up with, the bandwidth. Terrabytes of bandwidth were being used up by RSS.

So, they are trying to attack the problem by making the feeds lighter weight. I don't like the solution (I've unsubscribed from almost all weblogs.asp.net feeds because they no longer provide full text) but I understand the issues.

I know of a major broadcaster that refuses to turn on RSS feeds because of this issue too. We need smarter aggregators and better defaults.

I think it's high time we addressed this problem and I think the upcoming BloggerCon is the right place to do it.

We need to 'teach' syndication clients to speak with servers and other clients at more intelligent level than that of a spoiled child screaming GIVE ME GIVE ME endlessly.  We need more than just technical solutions.  We need to introduce ways to reward clients that improves scalability and punish bad clients that hog resources selfishly.

Update:

Following excerpt was pulled up from the comment section.

Here is possible solution for a site like blogs.msdn.com that doesn't require P2P:

1. Each blog feed is divided into two feeds, a daily feed (DF) and hourly feed (HF). There is also a master update notification feed (MF).

2. DF is updated once a day and has a permanent URL. HF is updated whenever a post is made and has a transient URL. MF is updated continually and has a permanent URL.

3. Both DF and HF embed a link to a MF.

4. MF contains transient links to updated HFs.

Since HF URLs are temporary and can only be found at MF, clients that ignore the link to MF in DF will only be able to pull DF.

Because DF has update period of 24 hours, dumb yet well behaving clients will hit it only once a day. Originating IPs of misbehaving clients can be identified and access can be slowed down enough to prevent abuse without refusing to serve entirely.

The main idea here is to require changes in clients to access the superior product  (HF) and entice users away from the inferior product (DF) in one of several ways (slower speed, summary only, etc.).  If done right, users will flock to clients that gives them access to the superior product over those that can only access the inferior ones.

Now, coming up with the solution outlined above took only ten minutes of thinking.  I think we can come up with more possible solutions if we put our heads together.

I spent a good part of Sunday recompiling many popular open source libraries (i.e. iconv, libxml, libxslt, xmlsec, openssl, zlib, etc.) as Win32 static multithreaded libraries without C runtime DLL name dependency (/MT) so I can use them in VC7.1 projects.  All because some guy at Microsoft decided to change the C runtime DLL name from fixed MSVCRT.DLL to version-based names like MSVCR70.DLL.

When that happend, popular open source tools and libraries got stuck with Visual C++ 6.  Binaries of Python and all the libraries I mentioned above, for example, are built with VC6 and links to C runtime library dynamically (meaning they require MSVCRT.DLL).  This means Win32 Python extensions couldn't be built with later versions of VC++ without walking into a lot of headaches.  Same problem stopped me from using prebuilt binaries of those libraries so I had to rebuild them myself.

I bent a few things and had to guess at a few places, but nothing seems to be broken.  Only trouble is that I am using WinInet to fetch XML files from Internet and it ain't behaving too well.  WinHTTP is supposed to be better but I think I'll opt for cURL instead.  Of course, that means I'll have more compiling to do next weekend.  Urgh.

Update:

Heh.  I didn't realize the weekend wasn't over yet until my wife informed me that today was the Labor Day.  To celebrate, I labored some more after a mini-vacation at the neighborhood pool with my wife and son.  cURL had Win32 project files so it was a cinch to build.  I did have to turn on OpenSSL and ZLib though to get HTTPS and gzip compression working (define USE_OPENSSL, HAVE_ZLIB, and HAVE_ZLIB_H flags).  Now I can reliably pull compressed RSS feeds over HTTPS from a Win32 client.

BTW, all these chores wouldn't have been necessary if I wrote it in Java or .NET because both platforms have most of these libraries built in.  So why am I humping the sidewalk?  Well, there are still things one can do with C++ that you can't do with Java or .NET…