OSNews

It doesn't have to (as the mono guys have proven).

It doesn't have to (as the mono guys have proven). "

True, but that's basically what it does on Windows. It's doesn't call down to the NT Kernel API for everything - it uses Win32 where it can. Thus it won't work for what I said. And, not everyone is or will ever use .NET for everything. C/C++ and other languages will be needed for applications that will work outside the .NET framework, so they still need another API in addition to .NET even if they ported .NET to using just the NT kernel API.

BTW, GUI alternatives are no better. E.g. it is way too easy for one X11 app to crash the whole sessions (in fact, much easier than to crash WinXP GUI).

I am not sure about MacOS X here, but since it follows basically same coding paradigms, I would not be surprised it shares same problems.

In reality, I believe that bad security of GUIs is somehow caused by its very purpose:

Advanced GUI is about sharing between applications (mouse, keyboard, clipboard, objects etc...). Wherever is sharing, there is insecurity. Security is about isolation - but not many users would welcome "isolated" GUI....

BTW, GUI alternatives are no better. E.g. it is way too easy for one X11 app to crash the whole sessions (in fact, much easier than to crash WinXP GUI).

I am not sure about MacOS X here, but since it follows basically same coding paradigms, I would not be surprised it shares same problems.

In reality, I believe that bad security of GUIs is somehow caused by its very purpose:

Advanced GUI is about sharing between applications (mouse, keyboard, clipboard, objects etc...). Wherever is sharing, there is insecurity. Security is about isolation - but not many users would welcome "isolated" GUI.... "

I don't think it's so much that issue. Sure, applications can share data. However, to do so they need to do it over approved channels and every application should have to approve what from itself can be shared. The one thing you can't get around is sharing with the kernel - but that typically happens by request of the application so that's not really an issue.

But when another application wants to get data from the application, there should be a function that application (or even the kernel) calls into the application its trying to get data from and say 'hey, i'd like this access, can I have it?' with a default of denying access (for applications that don't code the function - default to secure) - threads and processes spun off from the application would be a challenge to answer for (likely default of approve for threads and deny for processes). And that would have to go for everything the application controls (e.g has opened, creates, etc.).

It's practical and it would work. And the security it would provide would work wonders - though not seen by the average user. You'd be able to quickly eliminate a lot of bad software (virii, trojans, keyloggers, etc.) as they would have to (a) break into the API to get what they currently get and (b) they'd be denied outright by the security.

Sure there would be some challenges with getting it working right, and developers would have to learn some new tricks too. But in the end, it would provide a security that is very well needed.

Additionally, the simple fact that an application is getting data from another application (e.g. keystrokes, etc.) does not prohibit this. Your base layer (e.g. the GUI API) would be able to get the application approved to receive that data from the OS/App providing it. The application would be able to act just as it does not, except with the security. Copy/Paste would be one bit that would likely have to be approved when going from one application (e.g. Notepad) to another (e.g. Wordpad, Vi, Emacs, etc.), but not within itself - the same instance of the program.

So, do suggest that all Windows software, including e.g. OpenOffice or FireFox, is to be rewritten?

Can you imagine the real impact of obsoleting Win32?

And, BTW, Win32 has security in its foundation. Maybe later, to allow users to do what they need to do (like sharing clipboard etc...) they have softened the approach.

So, do suggest that all Windows software, including e.g. OpenOffice or FireFox, is to be rewritten?

And, BTW, Win32 has security in its foundation. Maybe later, to allow users to do what they need to do (like sharing clipboard etc...) they have softened the approach. "


Win32 has only as much security in it as the NT kernel forces it to have. That security is primarily related to user or system related tasks (e.g. files, permissions, etc.). It has nothing to do with application to application security, which is what is heavily needed - especially in Windows. If Microsoft really wanted to clean up the security of applications - they'd start there. It'd go a long way to eliminating virii, trojans, keyloggers, etc. (Phishing probably wouldn't be destroyed since that's a different attack angle.)

As I said in the GP - they could keep Win32 around for legacy or even sandbox it to protect the apps. Developers could, over time, update to the new APIs.



Yes, I can. Yes, a lot of apps would need to be updated - if the companies/projects were going to continue releasing new versions. Yes, there would be tremendous opportunity for new work, rework, etc.

But think of this - wouldn't the security for end-users be work it? For your application even?

It could potentially make a lot of current virii obsolete since it would eliminate entire attack vectors - e.g. keyloggers, API generated buffer overflows, etc.

(By API generated buffer overflow, I'm referring to situations where a program has set a dialog control to be an exact size - e.g. 10 characters - and a third party program changes it, and then stuffs data at the end. The originating program should expect that the control won't change its size unless it itself changed the size.)

The power of OSS is that they can probably move to whatever new api comes out without much issue. Firefox and OpenOffice are cross platform, they have no issues running without win32 now why would they have issues in the future. Developers will move to whatever they see fit to get their applications running on the platform, I really doubt an api change will deter them for long. The real issue are devs like Adobe, they are now stuck porting Photoshop to cocoa to get 64-bit support despite the countless warnings by Apple that cocoa was the way to go. Of course Adobe is getting their ass in gear now, and they would do the same on the windows platform if push came to shove. They aren't going to do it if they don't have to though. This is what scares MS though, things like what happened with Adobe may force adobe to look into a cross-platform solution or toolkit to avoid the same issue in the future, the easier it is for adobe to port their application with little expense the better the chances are that Adobe will start to get friendly with other OS's out there, because it would be easy and cost effective to do.