Most of the desktop OSes today, such as Windows or Mac, expose and encourage a File-oriented UI model. You pick a file in the file manager, click it, and then the file manager automagically determines the best app to handle the file, starts the app, and passes the file to it.
Back in the MS-DOS days we used a different model: an app-oriented model – you started an app first, e.g. Word Perfect, or Lotus 1-2-3, and then you opened a file from within the app (Norton Commander and similar programs somehow changed that later).
Interestingly this very same app-oriented model is now becoming popular again thanks to systems such as iOS and Android. There is no such thing as a global File Explorer or Finder on an iPad. Only the apps. One must first pick an app, and then it's the application's responsibility to expose an option for opening one of your “files”, if the app supports it (e.g. the calendar or task list apps would always open your default calendar or task list without asking for anything).
I actually like this app-oriented model a lot! It's much less confusing to the user. Just think about all those attacks in the past where an attacker could prepare a file with some innocently-looking extension but which in fact was an MZ executable. Or how many times people are not even aware which app they use! One might argue that user should not be distracted by such “unimportant” things as what app he or she uses for her work, but I disagree. Apparently Apple, and millions of iPhone and iPad users, disagree too.
But the main reason why I like this app-oriented model is because it just fits greatly into the Security by Isolation philosophy.
Just think about it: if it's possible to get users to consciously select an app, and we now know it is possible thanks to the millions of app-oriented devices sold, then it should be not much more difficult to get them to also consciously select the domain or area, such as “work”, or “personal”, which they wish to use. Just imagine that instead of one “Mail” app, you would have two apps (and two icons): “Mail Work”, and “Mail Personal”.
There are some technicalities here – such as e.g. how to isolate apps between each other? Do we need to build another layer of isolation in a form of VMs to isolate “Mail Work” from “Mail Personal”, or should the (new) OSes and the (new) APIs be designed in such a way, that they were thin and secure, and allow for very good isolation between processes without using virtualization?
In Qubes we must use this additional layer of abstraction (virtualization), because we want to use Linux apps (and in the future also Windows apps), and they require huge POSIX/X API (and Win32 API) to work correctly. And those APIs are not easily isolate-able. So we use VMs as “API providers”. Same with isolating networking drivers and stacks – we need Linux kernel API to get those drivers and stacks running, so that's why we use a Linux-based “NetVM” for isolating networking. For this reason we expect users to explicitly define domains, such as “work”, “personal”, etc. This is because we cannot afford to run every single app in a separate AppVM (more precisely we cannot afford to create a working copy of this huge POSIX/X API for each app).
But we could very well imagine a well constructed API for apps that would just be easily isolate-able (I'm not saying iOS or Android has such an API), and so there would be no need to define domains explicitly. Still, we would need a possibility to define more than one instance of each app – such as the previously mentioned “Mail Work” and “Mail Personal”.
The app-oriented model seems to be the future. And so seems the Security by Isolation philosophy!
From a UI design perspective, neither of these is good, though the file-oriented approach is likely better.
ReplyDeleteWhat should be in the foreground is not the software you're using, or the data you're manipulating, but what you're doing.
That requirement is fulfilled by some apps in the app-oriented model. A TODO list app is a decent example; you're not expecting to manipulate a file, you don't massively care what software it is you're using, what you do care about is that you're writing your TODO list.
But for e.g. word processors, the app-oriented model fails because there is no intrinsic link between the data and the task. To put it differently, the TODO list example works because there is only ever one file to manage, not N.
UI design research has pretty clearly shown that having to break down a task into a verb-subject form like "edit filename" than just a subject like "filename" is a much harder concept for Joe Average to grok.
That's not to say people don't get it. It's to say it's slightly jarring, it interrupts workflow. Good UI aims to never interrupt workflow.
From a security point of view, I can't argue with you. It *is* much easier to pick a known safe program if you have to explicitly name it.
Incidentally, the situation isn't half as clear on Android as it is on iOS. As apps are generally split into various Activities, and each Activity can respond to an Intent such as "open this URL", it's really a very mixed approach. On the home screen it looks clearly app-oriented, but behind the scenes it's entirely intent-oriented.
Hm, I'm still happily using Midnight Commander whenever I can :)
ReplyDeleteI would be interested what are your thoughts about "Rethinking the Library OS from the Top Down":
ReplyDeletehttp://research.microsoft.com/apps/pubs/default.aspx?id=141071
http://channel9.msdn.com/Forums/Coffeehouse/MSR-OS-Project-DrawBridge--OS-services-as-libraries
http://www.reddit.com/r/ReverseEngineering/comments/gqd0p/rethinking_the_library_os_from_the_top_down/
(link to the paper in the last link)
If they would do this to Windows, how far would that bring Windows (in your view) to what you would define as a great os (os architecture)? Or how would it compare to Qubes?
@saso: After quick look at the paper it seems like all the "novelty" in their approach is that they tune the amount of Windows code to put into each (para) VM so that only the parts required by a given app are used (e.g. only those DLLs that Power Point uses), and everything else discarded. This surely offers advantage of saving some memory per VM.
ReplyDeleteEssentially you can the same in Qubes -- you can build any customized template you want -- e.g. some very small template only suited for running Firefox, with some very thin Xorg running there. This would save on RAM usage per VM. In Qubes we don't care about saving on disk usage, because we use root fs sharing between AppVMs.
Besides the above, there doesn't seem to be anything really interesting in their system -- it still keeps all the drivers in the TCB (like e.g. VMWare). They also don't provide any secure form of clipboard or file copy between VMs. They don't consider safe GPU virtualiation.
Personally, I dislike the app model. (I particularly hate it when using a Mac, or a Mac-like application on the PC, and closing the window associated with one document also closes all the other documents associated with the same app. YMMV.)
ReplyDeleteIdeally, I think the document model can be made even more secure than the apps model, by the simple expedient of isolating the documents from one another.
Obviously this requires a more granular model than that which I gather Qubes uses, and would have poor compatibility with existing application code. But it would have significant advantages, such as being naturally resistant to macro viruses.
"This is because we cannot afford to run every single app in a separate AppVM (more precisely we cannot afford to create a working copy of this huge POSIX/X API for each app)."
ReplyDeleteAt least in the case of Windows XP, you're wrong on that one.
A VM of well stripped XP starts in about 20 MB RAM, the system less than 10 MB. It runs well under 50 and perfectly at about 70. Add more per each app's requirements. And that doesn't take into account sharing of OS memory among VMs, available in VirtualBox. The VMs share a single base file system with differencing. And since saving the state releases memory, in practice you can afford to have as many VMs as you require.
Using thousands of VMs is no problem on today's systems, though the number of running instances is limited by RAM. If not, you're not doing it right.
Go hard core with minimizing the UI. Limit user interaction to only what's necessary. Hide everything.
ReplyDeleteDon't let the user bother whether an appVM is running or not, or whether it has the right software. Don't involve the user in their creation and maintenance. Create a GUI that allows the user to express a wish to do something and then make it happen. The user brings the data to the appVMs, works on it, and the system does the rest. Make it as appliance-like as possible.
Provide a secure system that does everything a normal user might want to do out of the box. Don't allow the user to make stupid choices.
Btw, does it backup and restore everything automatically?