Twitter responded and said not to blame Google or cloud computing in general.

I agree… mostly.  In my opinion, this isn’t a problem with storing your documents on a hosted “cloud” service like Google Apps.  It is, however, a problem with not enforcing (at the corporate level) the same kind of security requirements that have become common for on-premises document storage.  That means password complexity requirements, regular password expirations, and very very strict account retrieval options (if you allow such an option at all).

Does Google allow Google Apps customers to enforce such restrictions?  Actually, I can’t tell.  I went to the Google Apps site and looked around and couldn’t find any indication, even in their Security FAQ page.  I even did a search for “password” on the Google Apps Premier site, and got no results! (same for words like ”security” – hmm).  Maybe someone should tell them to switch to Bing for searching their site ;)

A web search on Bing or Google returns this story, which seems to indicate Google does or at one time said it would support such restrictions.  But I don’t see any other sites mentioning it, nor any indication from Google itself.  If they don’t offer that ability, they certainly should!

But as Twitter said, this was really a failure on their part, not Google’s.  On the bright side, hopefully all of the attention they’re getting will result in others fixing these kind of problems before they suffer the same fate.

At this point , having it locked to the 3.0 developer preview of Silverlight actually seems to work as an automatic filter to keep the initial testing group nice and small   Perhaps in the next few days as I get more functionality enabled in it, I will set up a forum on BrandonTools.com and try to recruit a few more testers to try it out and report bugs + suggestions.

If you want to keep up to date on its progress, just watch this space, or follow me on Twitter!

Anyway, the current build works like this:

First, you browse to Twilver.Cloudapp.net which is an Azure ASP .NET page hosting the Twilver Silverlight 3.0 control.  The control checks to see if it has a cached access token, and since it’s your first visit, it does not.  It then redirects the hosting web page to Twitter and makes a call via the OAuth API.  Then you log into Twitter directly so only they see your credentials, and they give back an authorized token to my ASP .NET service on Azure, via the OAuth callback registration.

After that my service exchanges the auth token for an Access Token and Access Secret, which are provided by Twitter and don’t expire unless the user goes to Twitter and revoke’s my app’s authorization.

The web page passes the Access Token and Secret to the Silverlight control, which stores them in local isolated storage.  Then when the Silverlight control wants to make a request to Twitter, it calls into my proxy WCF service running on the Azure server.  This is necessary (I think), because Twitter doesn’t register their API for cross-domain access by Silverlight and Flash.  So Silverlight prevents me from making a direct cross-domain call.  My proxy service is a very, very simple WCF wrapper around the Twitter API.  Building this in Visual Studio was dead simple.

In the future I could change it so that the access token and secret aren’t stored in the Silverlight local storage, but instead are stored by my service in the Azure storage service.  For now, having the control do the caching seemed simplest, as it means my service is stateless and doesn’t track anything at all about users.  I may want to change that any way in the future, though, so that I could offer features like roaming settings and such.

So that’s what I put together this weekend.  Any feedback or suggestions would be more than appreciated!

If you follow me on Twitter, or read my earlier post about Twitter clients, you might have figured out that I’m not exactly thrilled about the state of Twitter clients on Windows.  I’ve also long been itching to see what all the hype with Windows Azure and Silverlight was about, and to try and wrap my head around XAML.  So a few days ago I decided to check out the Silverlight walkthroughs and installed the Azure and Silverlight 3.0 Beta SDKs.  Since then I’ve been busy (well, mostly yesterday and today)…

So there’s my first Silverlight + Azure app, running standalone thanks to Silverlight 3.0’s new out-of-browser support.  Of course the UI and feature set are very early at this point.  But I’m pretty happy with what I was able to get working in such a short time.  Especially since I spent several hours just figuring out how to deal with Twitter’s OAuth authentication API.

Unfortunately there isn’t an end-user friendly version of the Silverlight 3.0 Beta (you have to get it via the SDK), as it is targeted at developers only.  So that means it’s not very convenient to share this with potential testers.  In the meantime I may look at putting up a Silverlight 2.0 version (confined to a browser window) for people to look at.  I have no idea what the Silverlight 3.0 timeline is like, but now I have reason to hope it gets released soon =)

I plan to work pretty aggressively on matching feature parity with the popular clients, like Witty and Tweetie, and then start working on some other ideas I’ve had.  My very first goal, though, is to get the basic functionality available in a lightweight, attractive client UI.  Right now the Windows offerings are either horrendous resource hogs (Witty), or butt ugly (all the Adobe AIR apps, like Seesmic Desktop).  The Mac client situation seems quite a bit better, and that just makes the Windows situation bug me even more.  Hopefully I can help change that.  And since Silverlight is cross-platform, I may be able to win over some Mac users as well

Oh yeah, the name I’ve been using for the project is Twilver.  This is likely just a placeholder until I decide on something I like better… I was originally going to call it Twilight, but apparently that name has already been claimed.