Category: Software Engineering

want to know why Windows is so easily hacked?

As technologies progress and our devices are ever more networked with each other, security in operating systems has become increasingly complex. This complexity makes the systems themselves less secure because it is harder for developers to understand it. So the OS vendors add complexity to deal with the fact that applications are doing security wrong which creates a vicious cycle.

Are you a windows developer? Do you understand ACLs? Maybe you do, but most likely you only think that you do. Why? Because they are somewhat complicated. “What, I can explicitly grant permissions for my network printer to access this file?” Microsoft doesn’t make it easier. The documentation in MSDN is near useless. The web isn’t your friend here either since a lot of the websites I’ve found when looking for more info were just wrong.

I was working on a nasty file-permissions problem in a project that I was working on which necessitated a move from old-style file permissions code to ACLs. Now, I’ve been developing professionally on Windows for over 10 years, and I thought that I understood ACLs. Nope, I just thought I did. I spent days studying the web and writing test programs to figure out how to give the appropriate permissions to a single file. Luckily, I had an awesome tester who could break my stuff in ever more increasingly complicated ways, otherwise I probably would have shipped something that either didn’t always worked or was just a crazy security hole.

I realized that if it was that hard for me, what about all those less experienced or rushed developers currently shipping applications for Windows? The majority of developers inside of Microsoft probably don’t understand ACLs as well as they should. Is there any wonder why there are so many security issues in Windows?

The answer isn’t further complexity, but better documentation and education. This is critical stuff for Microsoft and 3rd party developers. It is time that Microsoft treated it that way.

I haven’t reviewed the ACL implementation in OS X 10.4 yet, but I shuddered when I heard that it was being added.

Cross platform development was never simple, but it could be simpler if Microsoft decided to support some standards occasionally

Now, I’ve been responsible for at least some of the Microsoft APIs inflicted upon developers, so I take some responsibility here. I don’t expect that Microsoft should have X Windows or Display Postscript or anything. I do expect that if I use standard C functions and the STL that they will at least work somewhat the same across platforms. That is too much to hope for when working in the wild world of internationalization it seems. Microsoft uses MBCS encoding for multi-byte encoding of char *s. This is a Microsoft-only thing that is the result of some dev way back when and is still foisted upon the world even though there is a much better standard called UTF-8. While I understand that Microsoft needs backwards compatibility for legacy applications, since they have already have a second set of APIs for Unicode, how hard would it be for them to support UTF-8? Actually, somewhat difficult, since Microsoft uses a different directory separator from the rest of the world that also doubles as an escape character for certain Japanese characters. If you have Japanese support on your XP machine, you’ll know what I mean already. However, this lack of UTF-8 support not only makes it difficult to port apps to Windows, it also makes it difficult to develop applications for multiple platforms. Microsoft already is forced to support UTF-8 for the web, XML and documents. It is about time that it works in C and the STL just like on all the competing operating systems.