locked
A Sandbox file object - Safe file operations for Seamless Sharing RRS feed

  • General discussion

  • Small Basic needs a new file object. Not a replacement. File does a great job with… well… with files. No, what Small Basic needs is a special purpose file object. Something that won't be commented out of operation by the "publish" process. A file object that lets you save and load files to the user of a newly imported program, on any computer, without security fears. What Small Basic needs is a sandbox.

    Jibba Jabba commented on the topic of "Seamless Sharing" in a recent blog post:

    Turtle-maze versus Hangman - a Case for Seamless Sharing

    He outlines the process where Small Basic comments out all "File" operations in published code, and he gives examples of the issues that this causes. The basic logic is sound. If you remove the possibility of reading and writing to files on a computer, you eliminate any mischief that those programs can cause. The issue is that this kind of brute force modification to code will often render the programs unusable, or even cause bugs and compile errors.

    I encountered that last issue myself recently with the game I wrote: Meteor Shower (import code: RJP883-15).  After I first published the code, I realized that a silly amount of code was being commented out, gutting the high score system. More code removed than anyone would ever bother re-enabling. I sighed and reworked the system and got it down to two comment lines, one for read and another for write. Very proud of myself I published the code, only to realize to my horror two days later that the new import code wouldn’t run. If you imported and ran the program you would get a compile error (variable not initialized). Without the read, a variables value was never set and Small Basic choked. I needed to go back and waste a line to set a variable to zero just before the read set it again simply to allow the code to compile (import code: RJP883-17).  

    Jibba Jabba proposed an interesting solution. Giving each of the file operations an "enable" parameter. When enable is set to true (by default), the operation would function as normal. If set to false, as would automatically happen when the program was published, the operation would still compile and execute as before, the file operations would simply not function. Reads would return nothing, not having opened any files, and writes would never attempt to save any information at all. The true benefit would be stability of imported code. Because no code is commented out, or removed from the published files there would be no chance for errors. Code would run as before, only minus this one functionality. And changing the false values back to true would be just as simple as the un-commenting that is currently in use.

    A very slick idea.

    I have a different suggestion though. My idea is the creation of a Sandbox object.

    The Sandbox object would be a set of file commands that allow the saving and reading from a file in much the same way that the File object works. The big difference is the sandbox file itself. The Sandbox would only save to a single file. The sandbox file name would match the name of the executable: ProgramName.sbox. The location of the sandbox file would always be in the same folder as the executable (Program.Directory). The sandbox file would be size limited to something small, like 50k. The other file operations would pretend that the sandbox file didn't exist, preventing rename and other operations from turning the sandbox file into something dangerous. Because of its predictable size and location, the sandbox file would be available to the online interpreter.

    Secure, flexible and filling the needs of 99% of file operations that Small Basic is called to perform. Most importantly it would completely and perfectly fulfill the "Seamless Sharing" concept that is such an important part of what makes Small Basic great.

    What do you think? Do Jibba Jabba or I have the solution to this problem? Do you have a better idea? It is time for a discussion on this topic.

    Friday, June 5, 2015 8:29 PM
    Answerer

All replies

  • Hello Coding Cat,

    you (and Jibba Jabba) introduce valid points about this topic, the intrusive commenting of file objects. Sadly, this inconvenience hinders the programmer reading the program and thus learning.

    Sharing is extremely crucial in the learning process because it allows programmers to expand their coding skills by exploring different techniques, data structure, algorithms, and how the author solved their problems. Besides writing code, reading code is the next important process to becoming an efficient programmer.

    Seamless sharing is seamless learning.

    Again, I thank you both. This gives me a problem to think about. If I have anything of value to offer, I'll be sure to post any ideas or thoughts in the future.

    Saturday, June 6, 2015 5:45 PM
  • I'm glad we gave you some thing to think about. I am curious, did you have an opinion as to which of our ideas you prefer, or think is more likely to succeed?
    Saturday, June 6, 2015 6:34 PM
    Answerer
  • I want to reiterate both ideas and ask for clarification before I decide.

    Jibba Jabba:

    An additional parameter is added to the file object that will enable the read/writing function based on its value:
    "true" or "false".

    Coding Cat (What I know): 

    An additional object, called sandbox, is created to work the same way as the existing file object.

    Here I get lost:

    " The Sandbox would only save to a single file. The sandbox file name would match the name of the executable: ProgramName.sbox. The location of the sandbox file would always be in the same folder as the executable (Program.Directory). "

    Saturday, June 6, 2015 9:40 PM
  • In computing, a sandbox is any system that has no unfiltered access to the computers systems. All iOS are sandboxed. In other words, they have no idea what the file system is like, they can not share files, and they are not aware of other apps.

    This is what I am proposing for the Sandbox object. The when you use the object, you are accessing one specific file that is in one specific place. You can read and write info to this file as you would any other file. however, the sandbox file's location, name, and maximum size would be completely out of your control.

    Because the file's location, characteristics and size are all locked down, there would be no security issues.

    And, unlike the current File object, or JJ suggested change, the sandbox object would work from the moment the app is imported without modifying the code. Using Meteor shower as an example, the High score system would work automatically, and always, even on line, without having to analyze or modify the code.

    The best of both worlds IHMO.

    Sunday, June 7, 2015 3:31 AM
    Answerer
  • I like the sandbox idea - its a bit like the settings object originally suggested by Vijaye.

    Perhaps a bit more thought on what it could do:

    • Just store text locally - for game statistics like high score to prevent File commands being required as suggested.
    • It might be nice to have a variant that may be uploaded and download/imported with the source in some way to store simple game resources like small sound or image files embedded in it - a bit like game resources.

    Some file commands are more dangerous than others - like File.DeleteDirectory - I wouldn't want any downloaded file to allow this without me explicitly turning it on.  But a File.Read I am much less worried about, so maybe Jibba Jabba's idea could be used for the File operatons that alter files in some way, with those that just read data not being commented out.  At run time file modifying commands that operate outside the current Program.Directory would be disabled without explicitly allowing in some way.  So the File auto commenting and running could be more selective.

    I am also aware that extensions can be very dangerous (accidentally or maliciously) so I would like something in the IDE to allow/disallow them.

    • Edited by litdev Sunday, June 7, 2015 3:49 PM
    Sunday, June 7, 2015 3:43 PM
  • Hi Coding Cat,

    To summarize, your idea is an extension that operates similar to the file object but writes/ reads files in an alternative location, which can't be accessed by the user. Correct?

    I have a question about Jibba Jabba's idea. What if the user post their code online with "True" parameters. Will it automatically change to false?

    I want to continue educate myself by re-reading the replies here before I further comment. Also, I am finding this discussion more interesting. I hope more people participate.







    • Edited by Ezra94 Sunday, June 7, 2015 7:10 PM
    Sunday, June 7, 2015 6:58 PM
  • My idea is more basic than that Ezra. The Sandbox object would act on a single file in the same location as the program. You would only be able to read and write from the file. And it would be limited in size, something arbitrary and small, but still usable in 90% of cases... like, 50k.

    I like liddev's suggestion that the file travel with the import. I imagine that would make it a head ache to implement, but if it was working right it would open up a world of possibilities.

    I will even one up the idea. If moving the sandbox file around in an option, why not directly tie it to a publish code. That way the file itself would live on the MS servers, reading and writing to the original and only copy of the file. Again, I can only imagine the headache that would be to implement, but the idea of a global leader board makes my mouth water.  :-)

    Of course, I would be content with a local, recreated with import, text only sandbox.

    Now, to answer the other half of your question Ezra regarding Jibba Jabba's proposal. The enable flag would be set to false on publish. Even when true in the original code. Especially when true in the original code. The point of the option is for it to be set to false when published, providing a soft landing for the File commands rather than the abrupt removal they have now. 

    Monday, June 8, 2015 2:17 AM
    Answerer
  • Ezra if set to "true" then no commenting on publish.

    Also no access (when setting that parameter to "true") to anything higher than the special root directory.

    It would only access at and beyond the special program root directory.

    The special root would be created by the compiler in the ProgramDirectory and its name would be the same as the filename that the program was saved as.

    Perhaps like this:

    'If at Run compiler does something like:
    File.CreateDirectory(Program.Directory + "\programFileName")
    'Then
    myRoot = Program.Directory + "\programFileName"
    
    TextWindow.WriteLine(myRoot) 
    'All children of this are accessible if 'parameter set to "True"
    '------------------------------------------------------------------------------------
    'e.g.
    
    File.WriteLine(myRoot + "\aFile.txt" 1 "Small Basic")
    'If 
    'File.DeleteFile("myTextFile.txt", "True")  'uncommented
    'Then  the effect would be:
    
    'an Uncommented
    File.DeleteFile(myRoot + "\aFile.txt")
    '------------------------------------------------------------------------------------
    
    'It may or may not allow deletion of the automatically created directory
    'c:\..\myRoot
    
    'All children of c:\..\myRoot  would be accessible including child directories 
    'and files in that directory.
    '=======================================================
    
    'When the sb file is run the compiler would create the special parent directory
    'if it doesn't already exist. The name of the directory would be the same as the
    'sb File Name and it would be created in the Program.Directory.
    
    'If the sb file was not yet saved then perhaps it would be given a generic name that
    'could be renamed to the fileName once the sb file is saved.


    • Edited by Jibba j Monday, June 8, 2015 12:20 PM
    Monday, June 8, 2015 12:07 PM
  • Hi CC

    Oh dear! I think you're right about the "False" on publish. Thanks.

    Sometimes a P looks like a G to me. Sometimes the whole idea transposes until I click run and get 3rd party feed back.

    Doesn't matter, just transpose where I wrote "True/False". Same thing.

    Monday, June 8, 2015 1:09 PM
  • Okay . . . .

    Could you explain how it would work if you published meteor shower with the sandbox?

    Thank you for bearing with me. I know that I'm not providing any insightful or constructive ideas. I'm trying to thoroughly understand the concept first. 

    Monday, June 8, 2015 7:59 PM
  • Wikipedia gives some insight into Sandbox (computer security)
    Monday, June 8, 2015 9:22 PM
  • You know both the ideas have a lot of similarities.

    The only differences I can see is no limit to 1 file and no creation of a new object.

    The only risky bit I see in my suggestion is a malicious bit of code that could use up all the free space on the host. The host would still be safe and could easily delete created files.

    And absolutely Coding Cat this would be a huge improvement to SB and how we share. I think the next big fix would be the browser. It's got big issues. And maybe one day we could have free hosting using individual tailored (sb style) user accounts.

    This would make SB the premium learning language. Raspberry Pi atm is taking hold a bit in Aussie schools. SB for me is more focused on simple language and diverse coding skills.

    • Edited by Jibba j Tuesday, June 9, 2015 8:02 AM
    Tuesday, June 9, 2015 7:52 AM
  • Ezra: Meteor Showers high score system would work the instant you imported the code. The Sandbox object would have access to its one file and would be able to save the small amount of information that the leader board represents.

    With the current system, and even with JJ's suggested change, the code is modified by the publish process, and the user importing the program must modify the code back to its original before it will run.

    And that JJ is the other big difference between our two proposals. Having usable file operations at all times.

    :-)

    Tuesday, June 9, 2015 12:42 PM
    Answerer
  • Thank you CC and JJ for taking the time to answer my questions. I'm going to read all these post again and research online to make sure I completely understand before I ask any more questions.

    Also . . . .

    If we're going to determine which would likely to succeed. We have to look at it from an

    end-user's perspective:

    Which of the two ideas are more user friendly and allow seamless sharing?

    AND

    programmer's perspective:

    Which of the two ideas can we realistically implement? (I don't have enough experience in this field so I looking forward for feedback here)

    By the way, are either of you going to propose the idea here?

    Small Basic Feature Ideas


    Tuesday, June 9, 2015 6:01 PM
  • Yeah will list in the features wiki, it's good to discuss it a bit though.

    Just to clarify, here's a quote from the blog post:

    "So I wonder if it's possible and worth while considering if some if not all the File class members be given an extra optional parameter that could set if the operations are using a child of the Program.Directory().

    Then these File statements be parsed by the Programs Listing script and exempt any instance that contains the value "True" from security commenting.

    Just a thought and a desire for SB to be even more fun."

    The underlined section above takes place on publishing.

    So if you publish File.DeleteFile("myTextFile.txt", "True")  this would be uncommented on publish.

    Tuesday, June 9, 2015 9:22 PM
  • Coding Cat,

    Would you be interested in joining the Small Basic Community Council.

    http://social.technet.microsoft.com/wiki/contents/articles/23723.small-basic-community-council.aspx

    There are no obligations, just to provide ideas and discuss the best way for Small Basic to move forward, with developers and other council members.

    If you fancy it, then please email me - litdev at hotmail dot co dot uk

    Monday, June 15, 2015 9:23 PM