SuperPower Security Rights: Be a Superhero

It’s an attractive proposition being a superhero. You get superpowers: you can fly, you can see through walls, you can hear conversations from a mile away. But, of course, it’s no bed of roses either: there are villains bearing Kryptonite round the next corner; or there are bucketloads of personal angst because you can’t be a normal person; or it’s really hard to give someone a high five without smashing them through the nearest wall.

As a group, we software developers tend to be superheroes. No, I don’t mean that we write code that can make mere mortals gasp in admiration (although that is undoubtedly true), but instead I mean that we all tend to run with local admin rights. We can do anything on our machines because we’ve given ourselves the (super)powers and the access rights to do so.

Is this a good situation to be in? Well, I’ll certainly agree it means that, in developing our software, we’re not constantly bumping into roadblocks where we don’t have sufficient rights. We can install whatever software we need and remove it at a moment’s whim. We can write files pretty much anywhere in the file system. We can open up any old port with impunity.

Unfortunately, this relish in having and using our superpowers extends into the software we write. Our applications tend to require superpowers before they will run properly. If someone uses our program or system, he or she will have to have local admin rights too. And therein lies the problem.

One of the biggest security risks in any organization or society is the human one. People, no matter how many times you tell them not too, will open dodgy e-mail attachments. They’ll click on malevolent web links and click OK on the resulting "do you really want to install this" dialog. If only they were running with limited rights, we’d have less problems with viruses, trojans, spyware and the like.

But the superhero ethic is prevalent. Installing Windows XP gives the primary non-admin user admin rights anyway, and we tend not to restrict it later. Millions of normal people out there are running with local admin rights: they are superheroes on their own machines. But do they need these rights? Of course not: the majority of people are surfing, balancing their checkbook, using e-mail, or writing letters. Unfortunately, people haven’t been educated about the need for running under restricted rights; Microsoft hasn’t made setting it up easy enough; and too much retail software erroneously requires admin rights. It’s like everyone had lockable internal doors in their houses for extra security, but then just had one key for them all.

So my exhortation to you (and to myself — I’m as guilty as everyone else) is to restrict the local permissions of your normal login. See what happens. Learn how to install software by temporarily running as admin. Find out which software you run as a matter of course assumes you have admin rights. Get frustrated and berate other companies for their lousily secured software.

Also, see how your software works under a restricted environment. Learn where you should really be installing the user’s config files for your application so that they can be modified (hint: it’s not in a subfolder of C:\Program Files). Learn what devices are available to you, where the restricted rights make a difference and why.

It’s only when developers hide their superpowers that they can be normal people and improve security for everyone else.

Whither Delphi? (Pun intended)

I was reading Nick Hodges’ article last week on how to sell Delphi, when it struck me: Nick’s making a big assumption. Should the Delphi that is sold in this manner be the Delphi sold currently? Or, even, should there be a Delphi to sell?

It seems to me that Borland isn’t moving in the right direction with Delphi, no matter how they sell it. Why is Delphi the way it is? In most developers’ minds, Delphi is this holy trinity of the language, the VCL and the IDE. But, apart from tradition, why is the IDE there? Why hasn’t the VCL been updated to use newer interface models, to use other containers than the ubiquitous TList and TStringList?

I chatted a bit about all this with Charlie and Lino, but didn’t put figurative pen to virtual paper. Then I read a couple of blog posts on the Borland Bloggers site and suddenly pen and paper were required. The first blog post from the Borland Bloggers site was Corbin Dunn’s announcement that he was leaving Borland to go work for Apple on the Cocoa Framework. (In case you didn’t know Corbin was a highly visible member of the Delphi IDE team.) The second post was an apology for Delphi 2005 not having remote debugging.

From one of the referenced posts, it seems that they don’t have the resources (time? developers? money?) to add remote debugging to the IDE. It is entirely disingenuous for Chris to say "I’d like to point out that the existing remote debugging features were not simply removed from the product.  Although, it may seem this way to our customers, this is definitely more a case of ‘the feature was not added’ as opposed to ‘the feature was removed’." Quite simply, I find this a lame excuse for not having remote debugging in the Delphi IDE because the debugging kernel happened to be rewritten.

The Old Fashioned Blues

I installed Delphi 2005 last week; I had a small Win32 project to write and I decided to use the latest and greatest rather than my usual Delphi 7. Besides which I live on automated refactoring these days.

Ye. Gods. The VCL is so Twentieth Century:

  • Where are the base interfaces like those in .NET? Not there! The VCL is a hierarchical inheritance-based class library.
  • I needed a stream that understood text. Not there! So I faked it by writing text drivers that understood a stream and then used Reset, Rewrite, writeln, readln. I first wrote a text driver in Turbo Pascal 3 I think.
  • And where’s the automated formatting? Not there! Spoilt, moi? Heh, it’s back to "indent block." It’s funny, I used to have carved-in-stone standards about code formatting. Then I started using VS 2002. Automated formatting is so productive and efficient that I changed my formatting standards to suit VS with nary a bad thought. I don’t even know the keystroke for VS’s indent block command.
  • I needed a hash table. I almost started (yet again) to use one I’d written when I remembered that the Contnrs unit had a hash table, but bizarrely it’s called a bucket list. (No doubt that’s why the rest of the VCL doesn’t use it: no one knows it’s there.)
Throw out the IDE

Now, if Delphi no longer had an IDE, Delphi R&D would be able to concentrate more on improving the language, enhancing the VCL and adding extra functionality to it. But you need an IDE, no?

There is an IDE out there that does remote debugging, as well as normal debugging, syntax highlighting, code completion, project management, compiling, building, supports multiple languages, etc, etc. The next version of this IDE even supports debugging 32-bit apps on a 64-bit processor and other fab tricks. It’s called Visual Studio 2003. Why isn’t Delphi a compiler that can be added to VS?

Certainly, Delphi R&D would have to write VS add-ins to access the editor, produce a CodeDom, interface with the debugger, etc. But they wouldn’t have to write and maintain a code editor, they wouldn’t have to continue improving the debugger, playing catch-up with what’s going to happen in VS 2005 and with 64-bit operating systems.

And therein lies the problem, I think. The catch-up this year is going to be brutal. Not only is Danny going to have to implement things like generics, anonymous methods, iterators in Delphi The Language, .NET subdivision. For a timeline, I seem to remember a promise of "within a couple of months from the release of .NET 2.0". But Allen’s team is going to have to implement legion enhancements to Delphi The IDE.

I looked at a pre-release of VS 2005 Beta 2 this week. Good grief. There’s a lot of new stuff I remember from 15 months ago, but there is a whole lot more. The new debugging facilities are downright impressive.

Concentrate Resources where they are Needed

So, what should Delphi become? IMHO, for it to survive and grow (and pundits are two a penny on this subject) it should become an add-in to VS. Concentrate on language enhancements to make our developer lives easier and remember to port them to Win32. Concentrate on improvements in the VCL. Is the language going to be support "for in", let alone generics, and other new things? If there are missing components in .NET, or the components that are there are less useful than those in the VCL, write a Delphi component package to redress the balance. Sell it to C# developers.

The resources in Delphi R&D are small and finite compared to Microsoft’s Visual Studio group. I’d say concentrate those resources on where Delphi can make a difference, not on playing catch-up.

Let me end by saying that like Nick, I am at some distance from the Powers That Be at Borland and the reasons for their decisions. If you want, take what I say with a grain of salt, and consider me little more than the CodeFez equivalent of some bloke on a crate at Speaker’s Corner in Hyde Park. Nevertheless, I think it is time we all did some serious thinking about Delphi’s future.