#8 reconsider the addition of system and kill commands ...
I would suggest to seriously reconsider the addition of the system and the kill commands, they will basically allow kids to delete crucial files, possibly even system files. I am personally not convinced about the educational value of providing access to system level details that are better hidden to most users; a programming environment like kidbasic is all about trying out new things, running experimental code. And my personal view is that experimental code should always be run ina "sandbox" environment, like a VM for example ... now starting to provide access to system level APIs to execute arbitrary commands or unlink files could possibly be problematic, especially once users start to share "fun scripts" to erase files or run arbitrary commands - not all kids will immediately understand every piece of code, and so it is very well possible that kidbasic could be used to cause harm...
If these commands are really deemed necessary, I would personlly consider providing a kidbasic specific verification dialog that EXPLAINS exactly to the user what is happening when a certain command is executed or a particular file is to be deleted.
Confirming this should then only be possible by the user, and not within kidbasic directly, i.e. using a modal MessageBoxA dialog
Don't get me wrong, I am absolutely aware of the fact that other BASIC dialects (or scripting languages) provide even more access to such low level APIs, however I have always been convinced that this is not right for a teaching environment - which really should be "SANDBOXED" in my eyes, whenever code is run that might possibly harm the system, the user should be made directly aware of this. As soon as it's possible for people to run code in kidbasic that could theoretically render their system usable, I can no longer allow kids to run kidbasic on every computer, certainly not on MS windows systems where ACL is much less securely implemented than on Linux ... which basically means that a kid could -for examle- delete a complete Windows OS, including important documents, just by running experimental code.
So, yeah - I am somewhat opposed to this ... even though I can see that this could be useful for more advanced things.
Maybe the best thing would be to introduce some form of "system level firewall" for enabling/disabling access to such APIs.
I really don't know for sure... but I would hate seeing people report how their kids managed to delete important data by running some rogue kidbasic programs, that -quite possibly- they may not even have written themselves let alone have understood in the first place.
J.D.
J.D.
I can see your point. In the educational environment, especially. The old file I/O commands can also be used to damage existing files so I am conflicted how to resolve this.
I have notes on implementing persistent settings code to remember files edited, screen position, and size. A permission level could be added to disable file I/O outside the current working folder and another to disable the system statement. Password protection logic would also bee needed to keep end users out of the settings.
I am working on my dissertation proposal right now and it will be a while until that can be added. It is on the list unless we get a better idea how to address these concerns without making the whole thing too complex.
Jim Reneau
renejm, thanks for your swift reply.
It is correct that the file I/O commands could also possibly be used to damage existing files.
But I think different permissions and access privileges are way too complicated, and would not be needed.
Maybe the sandbox/VM concept should be further pursued by introducing the concept of a "virtual file system", i.e. one that really is fully sandboxed?
For example, there are a number of open source libraries that provide VFS support, i.e. for mounting zip archives and directly reading/writing files within the confines of the zip archive. The file I/O could thus be trivially redirected to a corresponding ZIP archive this way.
So that real access to the actual underlying FS is not provided at all.
And if people do need to process certain data files using kidbasic, it would still be possible - just by opening the zip archive and adding their files to it.
I think it does make sense to think about this now, before people might possibly start abusing/misusing this facility, be deliberately or not.
I am mostly concerned about providing a teaching environment, where people may actually use the program in an unattended fashion - users should not have the possibility to damage the system, willingly or not. I am really convinced that "whatever happens in kidbasic ... should stay in kidbasic" ;-)
All the best for your dissertation!!
And thanks for providing this project!
J.D.
Hi again, just to add one possible option for a VFS based approach: http://icculus.org/physfs/ (zlib)
HTH
J.D.