The future of klik: GPL

[mrclark1971]

...hey probono...

LOL! I agree with you... I was just trying to shock you back to your "open sourceness."

[paradocs]

Greetings all,

First of all, I favor a main trusted collection of easily downloaded material for the targeted users. I stress trusted because of the mischief a rogue script could produce. A bad experience could be a big set back for this effort. Until there is better security -- like confining the script to one directory -- getting scripts from a trusted source is the only answer.

With trust, innovation and good design klik can compete as open source.
The recent improvements are a step in the right direction. Would calling the project a kiosk or server rather than a store project an image of service?

I am sure probono has a lot on his to-do list -- but now that were are in the "Ideas" section here goes.

In my burn_home project I have experiment with getting and saving the users files from the internet. Could klik have a login user area where the user would be able to down load his own content? The server would keep a TITLE, URL, INSTALL_PATH, and checks for RUN or DOWNLOAD. Perhaps start with say 20 entries. The user would have the files and scripts on his own web space. Each user could have a public and private area into which a user could give others access. Dedicated users would be contacting the site frequently -- increasing loyalty.

Best Wishes
paradocs

[champagnemojo]

I also agree on a single trusted site for now. The way it's set up at this early stage, the "recipes" could do all kinds of damage if not moderated in some fashion. Many users will not look at the scripts and will simply run them trustingly. Also, persons like myself with little linux knowledge could even look at a script and miss an exploit I'm sure.

I get no sense from probono that he doesn't want this to be open source...he's merely being realistic about security. If you want to convince him to make it GPL help him figure out how to secure Klik...don't preach to him about ideals he probably already holds.

[bfree]

If you want to convince him to make it GPL help him figure out how to secure Klik...

Does the following address the main concern?
Step 1: decide who is absolutely trusted, the admins.
Step 2: require user accounts to submit recipies.
Step 3: don't make a recipe installable until an admin has ok'd it!

Now the problem with the above is that it places the burden of adding all recipies on a small group of people, the admins. This is probably fine for now, the initial stages, and in fact may be preferable as a small group will also get to see how people are implementing recipies with a view to improving the system (including perhaps identifying any vectors people are trying to use to create trojans/worms/virus/bad things).

To scale the system up beyond a small core team will require one of:

A: Chefs are given authority, manually by the admins, to publish recipies directly, based on their history.
B: The system monitors recipie submitters and the validity of their recipies (initially determined by admins and any user feedback from installation) to give them scores. These scores can then be used either on their own with a threshold to allow chefs to publish recipes directly, or as a basis for peer moderation, where the chefs become the "admins" for the recipies. All the chefs should be sufficient (and scale correctly) to ensure bad things don't sneak through.
C: The system monitors all recipies, and allows all users to mark them as working/not working/bad. Whether or not a recipie can be installed normally depends on how many moderations/feedback it has, and the ratio of working -> not working and working -> bad. All the users will definetly be sufficient to check the recipies, but are they capable, would user feedback alone be sufficient to trust a recipie?

All of these options require some more intelligence on the part of the server running klik.

The key point is that it is the history of the klik server which will really determine its level of trust, and not the software at all. Whether or not the source is freely available will have a low impact on the risk from bad recipies compared to the diligence of the people involved in verifying recipies.

Of course adding in tracking on the popularity and postive feedback of recipies will also help to guide users away from the potentially riskier recipies. No matter what system is in place, if the system allows a random new user to submit a recipe to the system, which can then be installed by an end user, then the risk is their. Simply forcing people to take an extra step (for example having to save the recipie and inject it into kilk on the command line) to use recipie which have not yet been given a thumbs up by the community is probably the best thing to do to ensure a good balance between free and open development and non-recklessness.

Am I making any sense?

[qa1433]

Could Klick be used on programs that are downloaded to the drive?

Example: Real Player located in my /download director

Good work,
paul

[probono]

Could Klick be used on programs that are downloaded to the drive?

Theoretically yes, but it will be easier for you just to save your home directory along with the apps you have installed.

[probono]

First of all, I favor a main trusted collection of easily downloaded material for the targeted users. I stress trusted

full ack

Could klik have a login user area where the user would be able to down load his own content? The server would keep a TITLE, URL, INSTALL_PATH, and checks for RUN or DOWNLOAD.

You mean the user would upload his own recipes? For sure, that is planned. Recipes below a certain quality threshold would be just _displayed_ (with the option to run them manually), proven ones (by whatever means we come up with) would be _run_ through klik.

[probono]

Step 1: decide who is absolutely trusted, the admins.
Step 2: require user accounts to submit recipies.
Step 3: don't make a recipe installable until an admin has ok'd it!

I share your view, bfree. That's how it should be.

Now the problem with the above is that it places the burden of adding all recipies on a small group of people, the admins. This is probably fine for now, the initial stages, and in fact may be preferable as a small group will also get to see how people are implementing recipies with a view to improving the system (including perhaps identifying any vectors people are trying to use to create trojans/worms/virus/bad things).

To scale the system up beyond a small core team will require one of...)

I don't see this for the near future. For now, I think two-layered a system of users=contributors=evaluators plus admins=releasers would be sufficient. Contributed recipes not officially released would be just displayed instead of being run from within klik.

Am I making any sense?

Definitely

So, now is the question: whom would we trust as admins=releasers?

[bfree]

So, now is the question: whom would we trust as admins=releasers?

I realise I am sounding like a broken record, but if you are taking the manual approval approach what is the added benefit for security of keeping the klik client closed (I really don't see how keeping the client closed is a security benefit)? I had gooten the impression that you wanted the client closed to make it harder for "bad people" to inject "bad recipies" into the system which could exploit the client. Surely you don't need to "exploit" the client at all, as the client has the power to do just about anything the user can, so as to get software installed. Surely it is the recipies that need to be controlled and not the client? Do you really think that the benefits of having the client open (more eyes to spot problems and make improvements) are outweighed by the benefits of keeping it "closed" (reduced chance of someone finding a security problem in the client to exploit)?

As for who should actually be trusted, I can think of a few people but the question first is who wants to do the work?

[morglum666]

I think some of you code monkeys have stepped away a little from reality.

You need to get your idea up, running, and reliable before you can argue over copyright and open source. The author is absolutely correct; he wants it running smoothly so that modified copies of the client don't show up on the internet and break his invention.

Let that happen.

One of the key differences between huge corporations like microsoft and open source enthusiasts is that corporations need to complete tasks to make money, so they don't screw around as much with mindless debates. If you are building something, help contribute to his invention before begging him to GPL it.

Morglum