Google charts are an interesting tool for producing graphic representations of your data.. The Google Chart API returns a PNG-format image in response to a URL.

This is an extremely useful tool, and there is already more than one wrapper for the API so that you can call it from your code.

But how about the security aspects of this tool? Well, if you're worried about availaibility, you can store the resulting .png file on your own server, and provide your own resilience.

However, the confidentiality and integrity aspects are quite suspect. Only http is available, not https. This is a shame, as your business data deseerves better than this. You've provided HTTPS for your website, perhaps strong authentication and have protected your servers and database. Then you send that data unprotected across the internet.....

Also, you're at the mercy of Google for protection of the data while it's on their servers. I know all the techies are going to say "Yeah, but Google use xyz operating system and abc brand firewalls." Fine, but have they vetted the CVs of the admin staff that work on those servers? How do they dispose of the discs? How is the dev environment segregated from production?

If I was a hacker/criminal/hostile government, Google Charts would be a prime target for my attack.

I'd suggest the answer at present is to only send non-sensitive data across the internet to this service.

What's non-sensitive for your company? OK, answer the following question:

Can you print out the data on A4 paper, stand in your local shopping mall and hand it out to everyone passing? If the answer is NO, then don't use Google Charts for that data.

Microsoft have produced a beta of the WCF  Security Guide.

I'm chuffed to bits to see this appear. I've waited for quite a while to see some of the older guides updated, and this is very good quality.

I worked with a security consultancy last year that gave their graduates the older Patterns and Practices Guides on the first day at work. The new graduates all wondered why they'd not been given the documents at university!

One of the strengths of these documents is that they've been tried and tested. This is proven by the code samples that are included - so many questions are answered by providing this.

Several solutions are included, which can be mapped on to your requirements. This is what design patterns are all about for me - integrating parts of the application together, rather than being lost in classes and interfaces. This is extremely useful, as security often changes (fundamentally) the architecture of an application. Having a mapping from requirements to architecture saves a great deal of time and money, as there is less change later in development. The overall security integration can be done sooner.

What are the downsides? Well, they're vey few in number:

Only Microsoft products are considered. Shame, as MS are much stronger in the enterprise now. I'd like to see how a WCF service can be called from web server xyz, rather than just IIS. I'm not asking for all web servers to be covered (that would be duplication) but just some general guidelines.

IPSec. Several sections of the guidance sugest setting up IPSec for security. This just doesn't happen (usually) in ver secure environments. There are too many technical and beaurocratic reasons why you won't get this sort of connection set up when requested. For instance, many large organisations are moving toward application layer security as the hardware encryption accelerators just can't keep up with WAN traffic.

ASP.Net membership providers. They're a good suggestion, but they're not as useful in the enterprise as one might imagine. Generally, one would provide a heirarchy of roles and permissions within the application, and the roles would map to groups within the enterprise. The Asp.Net providers only allow the user to role mapping, which can lead to spaghetti code after a few releases (if user.isinrole("Manager") or user.isinrole("External") or user.isinrole("Support") etc. for each programmatic role check).

Then again, that's what MVPs like myself are for, isn't it? I humbly aim to fill in the gaps in some future presentations.