Chrome Getting a Bit Rusty
Put this one in the rant category –
I'm honored that Google has been paying attention to my blog and decided to use my sandboxing approach to try and make their app more secure. Very cool stuff, and they did some interesting things that I want to better analyze. It would be even nicer if they gave credit to where the idea came from, but that's OK.
We've now seen an entire termite mound's worth of bugs come out of it – see https://www.computerworld.co.ke/articles/2008/09/09/security-agencies-rally-against-google-chrome.
I've been watching all the claims of Google claiming that they'd invented a new programming paradigm – I think its release early and often. Rubbish. It's really the "code like hell" seat of the pants programming model. This is nothing new – we've been coding that way since we invented programming. It isn't the best way to ship quality, and it is sure to emit security bugs. While I'm certainly an SDL heretic – whether or not people work hard at security and get it is really the most important component, kind of like what happens if you make bread with good or bad yeast – creating secure software requires some level of thought and planning that you just don't get when the code like hell software approach. This comes out when you look at some of the problems – their sandbox is so restrictive that some of the most dangerous code (plug-ins) can't run in it, so breaking out is as easy as finding a vuln in a plug-in, which I think happened the first day. Even a cursory TM would have called this out.
While I'm off on a software development cycle rant, let me correct a common misconception that if you're not using Agile (Beware Of Things With Leading Caps – Usually, It Is Overblown), then it must be the waterfall model. As was documented more than 10 years ago in "Rapid Development", there's a whole spectrum of techniques that can be used. Agile most closely resembles the spiral process, just with really short milestones. I'm not advocating overly cumbersome processes (where overly cumbersome varies depending on what you're doing). I am advocating _thinking_ about what you're doing, considering the security implications (as well as perf, robustness, and so on) up front. Planning really helps deliver more secure software.
It is quite possible to create software that's _more_ secure using Agile (I think XP is really well suited for this), but that's a topic for another day.
[9/15 - update]
From a link about Google's identity server problem:
The developers decided to forget about the SAML specification as it’s written and just “do their own thing.” As great as this kind of move might be on the dance floor, it’s dangerous when it comes to protecting peoples’ resources and privacy. In fact it is insideous since the claim that Google SSO implemented a well vetted protocol tended to give security professionals a sense of confidence that we understood its capabilities and limitations.
Full text here - https://www.identityblog.com/?p=1011
The thing to remember is that it's all connected - we all need to make secure software. As one of my professors used to say (loudly in a deep, booming voice with an Indian accent):
You have to THINK about it.
He didn't mean just a little - security is some subtle stuff.
Comments
- Anonymous
September 12, 2008
The comment has been removed - Anonymous
September 13, 2008
I feel that chrome is extremely basic looking and do not like it