From the MSNBC story “White House opens Web site coding to public”:
"Security is fundamentally built into the development process because the community is made up of people from all across the world, and they look at the source code from the very start of the process until it’s deployed and after," said Terri Molini of Open Source for America, an interest group that has pushed for more such programs.
Expecting Open Source to be more secure because the general public contributes to and reviews it is like expecting a televised football match to be safer, because the folks at home are engaged in crowd control and looking for pickpockets.
While you might luck out in finding a few talented, devoted, and dare I say it, obsessed individuals who will call the police every time they see an infraction on screen, most of the people tuning in are going to be watching the game; and those that are trying to help are often clueless about how the security in the grounds works, and you’ll get many calls from people who see the security guards searching bags on entry as pickpockets.
There’s lots more to pick on in the article – for instance, the inability to determine the difference between a content management system and the web site it serves (akin to not knowing the difference between a story and the typewriter on which it was written), which itself significantly reduces the need for this one Open Source product to be secure.
The news article barely hints at some of the true advantages of Open Source – that others can drop additional components in at their pleasure, and that you can pick up whichever of those components you need. [Of course, the same is true of closed source products with good published interface specifications, so perhaps this is only an advantage in the extreme case that the provided interfaces are incomplete.]
There are plenty of reasons to believe that Open Source offers security advantages – it’s possible, for instance, to do your own deep security investigations and fix problems when you become aware of them. Of course, that’s rather like saying an advantage of buying an old car is that you get to do your own services – great if you’re a mechanic, not so good if you have to check the owner’s manual to remember which end to put petrol into.
Software is more secure because it is written by good, dedicated, experienced programmers, reviewed by other good, dedicated, experienced programmers, analysed by tools and experienced programmers looking for security flaws, and tested pretty much to destruction.
Don’t forget, as well, that there is little perceivable difference between secure software, lucky software, and uninteresting software. All will appear to be unhacked – until luck runs out, or the software becomes interesting to an attacker.
I don’t claim to be able to determine that all Open Source is more or less secure than all Closed Source.
Just that the “more eyeballs” line doesn’t remotely provide anything close to an explanation.
Recent password exposures at a number of online email services remind me to give a little advice on passwords.
Definitely use this as a reminder to do something about your passwords – but don’t do the obvious thing. Don’t rush round and change all your passwords right away.
Don’t change your passwords, change your password habits.
There are no doubt dozens more things that could be suggested as good password practice, but these five will stand you in good stead.
Unless you’ve been living under a rock, you’ll be aware that today was the release of Microsoft’s latest operating system version, Windows 7.
So, everyone else has their own ideas of what’s missing in Windows 7, here’s my list, and it’s not the same petty focus that everyone else seems to have. Mine is based on what I want, rather than what’s remotely close to being reasonably achievable.
So, what are the things in your twisted imaginings that would turn Windows 7 from this kind of Seven:
into this kind?
[Note: Having said all of this, it should be clear by now that I think Windows Seven is well worth having. But I still want more!]
http://types.cs.washington.edu/jsr308/ seems to be talking about a set of type annotations for Java that are similar to those provided in Microsoft Visual C++ by SAL, the Standard Annotation Language.
One thing that the Java annotations have going for them over the SAL is that these annotations are going to be a part of the Java 7 standard, so it’s something that will come with the language no matter who implements it, whereas the C++ SAL extensions are specific to Microsoft. Of course, when I say “no matter who implements it”, I’m not aware of any significant currently supported implementations of Java outside of Sun, so it’s possible that such a statement is necessarily limited.
[Note that the SAL extensions can be included in C++ code that is compiled with other compilers, you just won’t see any benefit from them when using other compilers.]
As explained in the blog post that Michael Howard put out when SAL was first made available, these code annotations add something to object and function prototypes. What they add is the ability to turn run-time issues into compile-time errors.
So, for instance, a null pointer dereference, that would be an instant denial of service on your application, is trapped at compile time, because you declared in your function or class prototypes that you expect the pointer not to be null.
Adding these annotations to your code can certainly be a time-consuming task, since you have to revisit old code and add them in by had, recapturing assumptions that you had originally made about objects you reference. That in itself can be a learning experience, of course, and because you will capture a number of outstanding reliability, quality and security bugs, it’s far from being an empty investment.
The first checker that the Java annotations implement is the Nullness checker. This allows you to declare whether you are expecting a reference or value to be null or not. This generally avoids you seeing exceptions through dereferencing null.
The Interning checker prevents you from seeing poor results when comparing two objects (such as two instances of “Integer(2)”) using “==” or “!=”. Without the Interning checker, using “==” to compare two Integer variables each containing an instance of Integer(2) will produce the result ‘false’. This can cause logical processing errors, which the Interning checker will address.
The Mutability (IGJ or Javari) checker allows you to specify that an object reference should not be used to modify the contents of that object.
The Lock checker prevents locking errors by allowing you to declare that objects can only be accessed when guarded by a lock, or to declare that a function can only be called when holding a particular lock.
The Tainted checker allows you to mark an object as coming from an untrusted source (think “user”). Marking some functions as expecting Untainted data will prevent them from being fed Tainted data, and will ensure that other developers accessing such a function will call checking routines to convert the data from Tainted to Untainted before passing it to your functions.
The Linear checker prevents your code from holding more than one reference to objects marked as Linear. Since Java, like C#, likes to copy references to objects, rather than the objects themselves, this checker can prevent you from finding unexpected side-effects from objects being modified through aliases you weren’t expecting.
Further checkers appear to allow you to write your own checkers, but I haven’t got the Java programming chops to really play with these.
Definitely. Or something like them. Using annotations to define to the compiler some of the expectations you make of your code (a hyped-up interface contract, if you like) allows the compiler to check more deeply into whether those assumptions can hold true throughout your code.
My own experience of SAL-annotated code is that it has allowed me to discover some relatively subtle bugs in my programs. Or bugs that weren’t quite so subtle, but just weren’t jumping out at me.
A quick look at these Java annotations suggests that they will do the same for Java projects. Frankly, the more help you can get from these static analysis tools, the better. Analysis tools don’t catch all problems, and they aren’t a substitute for good programming, but they do provide a second check on your own assumptions that can be very useful.
Previous articles on SAL:
Google certainly sounds like it’s a nice place to work. Table football, free lunches, that whole “don’t be evil” mantra, and the requirement to spend 20% of your time on projects that aren’t specifically to do with any particular company goal (with the obvious intent that some of those projects will result in interesting discoveries and/or personal development that the company can use).
But I can’t say that I’ll be applying there, at least until they publicly state that they are permanently reversing a decision they made in the last few weeks.
What did Google do that was, to my mind, so very close to evil?
Remember, this is a retrospective award – it is a recognition of what you have done for the community of Microsoft’s users, not a request or obligation to do anything in the future or act in a particular way.
Jon’s award stems from his frequent, continued and voluntary assistance to other C# developers.
As far as I can tell, Google has not told Jon to stop helping C# developers, and certainly his blog is still up, his support pages and FAQs are still up, and he’s still posting helpful advice on C#.
I could even understand if they said “don’t go to the annual MVP Summit”, or “don’t advocate Microsoft products” (although that’s not expected of MVPs, who bristle at the slightest suggestion of being ‘evangelists’).
So, Google’s not angry with his behaviour – they are angry with his being recognised and rewarded, by Microsoft, for that helpful volunteer behaviour.
My own C# projects have benefitted on numerous occasions from finding an article Jon has posted on the Internet. I’d like to thank him for that, and I hope he isn’t required by Google to reject my gratitude as well.
Thanks, Jon Skeet, for all you do for the C# developer community.
Thanks, Google, for reminding us that there’s a line that divides “evil” from simply “really, really bad”.
[Note: Please feel free to pass this posting on. I’d like to see Google feel very very ashamed for this, and to recant. If only because Jon will be eligible every quarter for the MVP award, and he’s going to get awfully tired of refusing it over and over. News coverage would be great, but I don’t see any at the time of writing on Bing’s News search.]