[happyjoe]

For most apps, such as a calculator or a 3D game, vandalism is not a very big problem because:

- 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.

[omail]

I am also a Linux user and have a few questions.

> 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?

[happyjoe]

> Will my data be on the WikiOS or on my hard drive?

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.

[Chickencha]

Okay, that makes sense. I guess the bar's a little higher for vandals anyway since it requires some programming knowledge.

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?

[happyjoe]

There is currently no user-generated code that runs on the server. All user-generated code runs inside a sandbox on the client.

[codedivine]

disclaimer : I havent used it since I am on linux. What about non-data related vandalism? Like someone painting the whole thing in pink? You start it one day and its blue, the next day its pink and the third day the "bold" button in some text editor application actually does italics?

[happyjoe]

Repeated vandalism is banned. Other conflicts are solved like on Wikipedia, where moderators step in if no consensus is found.

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.