Monthly Archives: October 2009

White House moves to Open Source

Subtitle: Media posts uninformed rubbish as commentary

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.

Lots more to pick on

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.]

Is Open Source more or less secure?

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.

Phishing at Hotmail, GMail, Yahoo! Mail, etc.

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.

  1. Don’t use the same password everywhere.
    If your password gets exposed, or the service owner is malicious (or has a malicious staff member), you’ll be exposed everywhere.
    Many times, of course, you will be unable to use the same password everywhere, because one site will require a symbol, and another will not allow that symbol. It is better to cope with this than to have to try and synchronise all your passwords.
  2. Write down some of your passwords.
    What, seriously? Yep. Write down those passwords you don’t frequently use, and lock them away. Or store them in a password-protected (encrypted) file, whether that’s a Word file, Excel spreadsheet or any number of other storage mechanisms that will allow you to encrypt your passwords and store them away. Now you have replaced multiple passwords to remember with one.
    See point 1, though, make sure the password encrypting your password store is one you don’t share with any other sites.
    There are products out there which will protect your passwords for you – whether they are called password safes, vaults, strongboxes etc, they all do basically the same kind of thing.
  3. Consider what passwords should be accessible to others.
    This may sound like bad security – and in a managed environment where others can always exert administrative rights to access files and systems that your passwords were used for, you should generally not be sharing your passwords.
    But think on this – a friend of mine received a traumatic train/brain injury, and though his recovery borders on the miraculous, there are many things he has forgotten. Passwords seem to be the hardest for him to hang on to, and he has had to recover through other means – sometimes simply wiping and recreating the system.
    Just as you have a will to direct people how to continue after your passing, store safely away account details and passwords so that your affairs can be brought into control if you are interrupted like my friend, or more permanently disconnected from the Internet. And make sure someone trustworthy and reliable can find that store when necessary.
  4. Plan to change your passwords.
    If you don’t occasionally change your passwords, you will not know how to change them when it comes time to do so in a hurry.
    At several times in my professional career, I’ve had to deal with accounts whose passwords might have been exposed, whether through departing employees, lost password sheets, and at some of those occasions the natural security response of ‘change the passwords as soon as possible’ results in major push-back, by teams who have never changed their passwords, don’t know how to achieve it quickly, and aren’t sure what other applications depend on those passwords.
    If you don’t regularly change your important passwords, you’ll be flummoxed and panicked when it’s actually necessary to do so, and you may break something that depends on those passwords being synchronised.
  5. Change your passwords often enough, but not too often.
    How often is too often?
    How often is enough?
    Difficult questions – often enough that you can remember changes to the systems to figure out why a password change caused some difficulty, and often enough to cover departing employees or others who might have had legitimate access once, but shouldn’t have access any more.
    Too often is when you get so tired of changing your passwords that you start regretting the process entirely.

There are no doubt dozens more things that could be suggested as good password practice, but these five will stand you in good stead.

Windows 7 – what it’s missing

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.

  1. Media Center devices to provide support for DirecTV.
  2. Trimmable transparent screen overlays supporting multi-touch input.
  3. IPv6 support from my home ISP.
  4. A web browser that opens quickly enough that I don’t forget what I was about to browse to.
  5. A tool to answer “why is the system so slow right now?” – especially on those occasions when the CPU is not being over-taxed.
  6. A free Zune HD. (Why not, since I’m dreaming here.)
  7. Simple facilities to allow electronic commerce to operate on ‘zero knowledge’ principles, so that I would share my credit card account number only with my credit card provider, rather than with every merchant I might do business with. (Maybe Infocard or something like it could come close to fulfilling this wish)
  8. An “Expert” mode, where menus are visible, files and file extensions are not hidden in Explorer. (For that matter, file extensions should not be hidden in Explorer. Ever.)
  9. MSN – excuse me – Windows Live Messenger that works in a somewhat rational way, back in the system tray, rather than as a minimised icon.

So, what are the things in your twisted imaginings that would turn Windows 7 from this kind of Seven:

Seven, from Married with Children

into this kind?

Seven of Nine, from Star Trek Voyager

[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!]

SAL-like code annotations for Java

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.]

What do annotations do?

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.

What do the Java annotations capture?

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.

Should I include these annotations in my Java projects?

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 bans MVP

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?

Google told Jon Skeet that he shouldn’t accept the Microsoft MVP Award that was offered to him, despite the fact that he’s been awarded for the sixth year in a row.

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.]