Suggestion Box

Here's a basic idea I had pertaining on how to implement both multi-user support, and security in one go.

First off, the simple way of implementing multi-user:

• In the directory /Users/ there are mountable filesystem images. Each is encrypted and has metadata for a password hint, contact information, whether or not the user is an administrator, an encrypted version of the main crypto key for the image, and an icon to represent the user.
• Early in the boot system an application will present a list of files in /Users/, the user picks one and types a password (which is used to decrypt the main crypto key). The system can be booting what it can in the background to save time.
• This file is then mounted as /home, or at least there is an attempt to do so. If the password is incorrect then the main crypto key will be wrong and the image can't be mounted.
• Administrators are prompted in Vista UAC style if they attempt to change files outside of their home directory. Less privileged users are informed that they can't do that.

Next is how to ensure applications behave:
Applications can be run in two ways. The first is the traditional way, with the full privileges of the user (Tracker would probably be run like this). The second is using "application virtualization".

• This involves the application residing in a file system image, and all of it's disk reads and writes are redirected to that same image.
• Upon user login each application's image is mounted on top of the root filesystem.
• There would also be a shared documents folder where any application can write to the root filesystem, but it can only read/overwrite files that it created (indicated by metadata).
• When a program attempts to do something for the first time, the user is prompted about whether to allow it to do so or not. Examples include accessing the internet, reading from the root filesystem, accessing other partitions (which aren't handled by the image redirection mechanism), or sending BMessages to other applications.
• Rules can be more advanced than all or none. Internet access could be restricted much like a software firewall can do. BMessages could be restricted to certain types (Copy/Paste) or to certain applications. Root filesystem access could be limited to a directory or two.

So, for an internet browser you'd want to allow it access to the internet (perhaps add a custom rule to only allow outbound port 80 & 443 and block access to pornographic hostnames), but you would not allow it read access for the root filesystem (breach of privacy). Furthermore, if there was an exploitable security hole all an attack could do would be mess up the insecure application (and access the internet in this case).

Today with advent of netbooks and high emphasize on portability it occurs to me that perhaps having a slew of highly portable applications a welcome addition to Haiku.

Firstly I'd like to note I'm not too much familiar with Haiku's current application installation system but from what I gather it will be quite different from my suggestion, so here it goes.

Basically my whole idea is based on klik. What it does is compresses all needed files into a single file which is then mounted and unmounted in order to respectively load and unload it from the memory. Using this approach comes with great advantages:

1. Highly portable applications - if constructed properly (meaning lots and lots of hours of developer work) these applications could be frozen and redeployed elsewhere in the exact same state as they were before they were frozen.
2. Intuitive way of handling applications - applications could be deinstalled by deleting and installed by just moving/copying file from one computer to another
3. Multiple versions of applications running side by side - rename your file and voila you can run programX v2.0 and v3.0 seamlessly without much confusion or fuss

But you may ask why is this any different from apple's AppDir approach except that it is a compressed folder? Well for one this is a single file meaning that when you overwritte an existing file it doesn't merge new and old files into a single entangled mess like AppDir do.

Of course there is also a great deal of disadvantages when dealing with a single file:

1. Meta data retrieval - it is harder to get meta data such as assosiations and icons from a single file unlike the folder structure
2. Current application would be hard to transform into an AppFile format - It is pretty much an issue of standardization and order. Some applications might want to store their settings and config files somewhere else on the system leaving behind tails.
   Possible solution: Internalize configuration files into the application file, which might be a hard task for some apps
3. Bloat - since bascially all apps would carry their own non-core libraries there is a chance that your apps will simultaneously load same version of certain libraries into the memory.
   Possible solution: Force AppFiles to check a common library repository for a library they might use before using their internal version.
4. Security issues - making the instalation this easy could be exploited by a third party to gain access.
   Possible solution: some form of control when accessing the application for the first time
5. Updates - Some older versions of the software could use older internal libraries instead of using newer which break compatibility.
   Possible solution: Design a way for upgrades to replace your current version while preserving settings.

The list of disadvantages does seem a bit bigger but I believe that the pros though less numerous outweigh the cons.

From ffado.org website:

Introduction
The FFADO project aims to provide a generic, open-source solution for the support of FireWire based audio devices for the Linux platform. It is the successor of the FreeBoB project.

FFADO is a volunteer-based community effort, trying to provide Linux with at least the same level of functionality that is present on the other operating systems. It is a work in progress, we are close, but we are not quite there yet. We are currently preparing the last beta releases before an official FFADO 2.0 release - your help with testing is very welcome!

http://www.ffado.org/files/bluemarine_logo.png
Official website

The middle button isn't really much used currently in Haiku, so I have been thinking about how it could be used to speed upp some tasks for the poweruser. One nice thing would be to use it for moving windows in the background or just give a backround app focus without bring it to front. Another thing it could do is to let the user select options in a menu without closing it. As an example at the deskbar if i would like to select 24 hour clock, show seconds and european date in deskbar settings I could this much faster because the menu wouldn't close when I select an option. The middle button could also be used to open folders in new windows if you have choosen single window navigation or in the same window if you use default navigation. It would also reverse the the move/copy dragging compared to the left button. Would it be easy to implement this behaviour to Haiku? I think it would be really useful for speeding up things for the user.