> there is no sensitive data to steal
What would I use this for? Is it simply a system to propagate programs to users? (Collaborative software development?) Will my data be on the WikiOS or on my hard drive?
> there is low motivation to vandalize (whereas some wikipedia articles are highly controversial)
Motivation can not be predicted in advance. If I make a program, could not a competitor add a change that "accidentally" introduces a security hole?
> sensitive portions of the OS require moderators approval in order to be modified
What would you define as sensitive?
> We are also working to implement code access security systems to address this issue.
What is your planned security model?
I like the fact that its is sandboxed from the host. Can a program on the WikiOS interact with host programs and if so, to what degree?
The sandbox allows for OpenFileDialog and SaveFileDialog, so you can directly access user-specified files on the hard drive.
There is also an online storage, but it is currently in the alpha stage. For the moment we recommend using the open/save dialogs and work with local files.
> If I make a program, could not a competitor add a change that "accidentally" introduces a security hole?
A competitor may indeed commit acts of vandalism, just like on any other web 2.0 site. However, we work hard to ensure that such illegal acts cannot - by design of the system - lead to security holes.
> What would you define as sensitive?
Currently, all the classes that are involved in the boot sequence (from the startup to the moment you see the desktop) are marked as "critical" and can only be modified by moderators. Furthermore, the "Code Editor" and the "History" applications are also marked as "critical" so that it is always possible to undo vandals changes.
> Can a program on the WikiOS interact with host programs and if so, to what degree?
No, a program on Wiki-OS cannot interact with programs running on the host machine, except through the OpenFileDialog, the SaveFileDialog, and a few other very controlled features of the sandbox.
On a similar note, is any of the code run on the server side? If so, how do you prevent DoS attacks? Are there checks in place to make sure that I don't create an infinite loop or allocate a ridiculous amount of memory?
Furthermore, people are encouraged to add new features and create alternatives instead of modifying the existing classes, so that the popularity-based mechanisms do the job. For example, the "Filters" menu of the "Image Editor" is automatically populated with all the classes that inherit from the IFilter interface, sorted by popularity.
- there is no sensitive data to steal
- there is low motivation to vandalize (whereas some wikipedia articles are highly controversial)
- it requires more effort to vandalize an application (the code is not saved if there is a syntax error) than to vandalize a Wikipedia article.
- the sandbox in which the applications run ensures that the user's computer is not accessible from the application.
However, for applications that manipulate personal data, there is indeed a challenge. At present, sensitive portions of the OS require moderators approval in order to be modified. We are also working to implement code access security systems to address this issue. But for the time being, we indeed recommend not entering personal or sensitive information.