PDP of Gnucitizen fame has posted a very simple defence against CSRF attacks that avoid the complexity of generating additional session management code/tokens. If you're a web developer, do it, do it now. Given that most developers don't know about CSRF, I'm sure there isn't much hope for this. Ideally, PHP and ASP .Net need to build this kind of thing into their session management routines.

This is an interesting finding from Finjan. This could demonstrate how interrelated security and privacy really are. Especially, since browser vulnerabilities can lead to a host of juicy information about a user.

However, I suspect there is more to this than an advertiser's need to make the world an ugly place. Without the privacy twist, this isn't really a surprise. Ad servers are prime malware targets because of their penetration across the web. Infecting one server allows someone to punt their malware to hundreds of thousands of sites.

The implication of this is that ad server's are getting hacked left right and centre. If this is true, then blocking advertising moves from being a convenience to a security feature.

I attended another awesome 27 dinner last night. Mike++ on the organisation. I was given the opportunity to present. My presentation was entitled "Privacy on the Web 2.0". Sorry the slides are so spartan, I felt silly next to Heather's Lessig-like Keynote jobbie. Also, anyone interested in the browser history hack, the original demo is at ha.ckers.org, the guy who put it all together has his demo here, and my example used in the talk is here. As for the blog entry with the links to the privacy extensions it is here, although it needs a bit of work.

Giorgio Maone, the author of one of my favorite Firefox extensions, NoScript, has been doing some work to extend the functionality to prevent XSS attacks. Download it, test it. It looks like Mozilla is going to make some changes to their parser to limit the potential for XSS attacks too!

If you don't know what NoScript is, I highly recommend installing it. It adds a slight cost to your surfing; you will need to occasionally click 'temporarily allow' on certain sites that require JavaScript and will need to 'permanently allow' some sites when you first start using it. On the other hand, it will significantly reduce your vulnerability to JavaScript based attacks, including privacy worries (like the google analytics tracking on this site :) ).

In retrospect, I don't think I have enough information on the whole affair to comment.

Apple doesn't seem to have learned any of the lessons of how to deal with vulnerability researchers. The bizarre events that unfolded after the wifi exploits demo'ed at BlackHat last year have finally been detailed. They've already been burned by the Month of Apple Bugs, and it will be interesting to see if they continue to mislead their users about security and deal so disingenuously with disclosed flaws.