Script Protection Idea

[SirWobbyTheFirst]

Hey guys, I've got an idea for the engine that may give piece of mind to some developers out there and before I talk about I just want to give some background first to make it make sense to you. (Ahem) In 5.5 and earlier we had the likes of the script limits and stack encryption to prevent modifications being made to stacks running in the application and I in particular made use of these features to prevent my applications from maliciously wiped out. Now by maliciously wiped out, I mean that because my software was pretty much always meant to be extendable, I love my community if I didn't make my software extendable then I've probably been hired by EA, I always had the thought of what if someone wiped out my code by doing a Set The Script Of Stack "MikesApp" To Empty either maliciously or by accident.

This always concerned me as if you did do this, you could effectively render an application null and void and thus require a restart of the application, not particularly thrilling for the end user or me when I'm left wondering why my app white screened on somebody's computer. Thus I always made use of the ability to encrypt a stack to counteract this problem and it worked fantastically, I could keep my source code open to the user but ensure nobody could mess around with it at runtime.

But with the open source variant of LiveCode, the script limits and the stack encryption have been removed, thus reintroducing this concern for me, therefore I propose an idea to you, allow users to make a stack as read only in the memory but still allow people to perform stuff like Put The Script Of Stack "MikesApp" and be able to view the source code, it will not only allow me and I'm pretty sure other developers to maintain a piece of mind when building systems that are extendable, but also meet the requirements of the GPLv3 as the source code is still viewable.

Maybes offer something in the standalone settings dialog to turn the protection on in the engine during compile time or select a type of engine to use for the built stack such as "Use the read only engine for my application" or "Allow reading and writing to the script of my stack during runtime"

Something along those lines. I think this makes sense, however if any questions pop up, feel free to ask me and I'll try and answer them as best as I can. Also apologies for the essay, but sometimes you've got to go big to explain stuff.

[Mark]

Hi,

Surely, you can implement some kind of password protection in LC Community, but if I interprete the OS license correctly, all software created with LCC needs to be open source. This means that although you could add such a feature, using it would violate the OS license conditions.

The only legal protection you can make is data protection. E.g. give the user the possibility to set a password and encrypt data (in a custom property or in a file) with e.g. blowfish and this password as the key.

I'd like to add that other open-source platforms don't have this limitation. Phonegap for example is also an open-source development platform, but if you use PG, you are allowed to release commercial software under a commercial ()closed source) license. While I do understand that such a license would currently make it hard for RunRev to survive, I hope that the license will become more flexible in the future.

Kind regards,

Mark

[monte]

There is a really easy workaround to this that does't involve password protection. In mode_standalone.cpp there is a method MCModeCanSetObjectScript... I think if you change that to always return false then you are good to go. Not everyone will want that so you might need to add another engine mode... and then include that engine as an option in standalone settings if enough people want the same thing.

[SirWobbyTheFirst]

Thanks for the suggestion monte, but alas, the whole reason I got involved with LiveCode was to avoid the cryptographic-ness that was C and its brothers. Non the less, I might take a look into the code and see if I can perhaps build an instance of the engine with the change involve but I personally prefer the idea of a choice of engine in the standalone settings, that way everyone could benefit from it.

I'm hoping Mark could possibly pitch in his two quids worth seeing as ultimately he is the one who decides what happens with the IDE and engine.

[monte]

There's lots of Marks around here but I know the one you mean

Yes, I was talking about making it an option in standalone settings. It would add a heap of size to RunRev's distribution to do that though... I wonder if it would be possible to make it a global property. There is already an editScripts global property that is documented as not doing anything and only there for SuperCard compatibility. Perhaps that could be activated and only be allowed to be set once per session. That way your splash stack could set it to false before any plugins are loaded. It may even be possible in the gpl version to set the scriptLimits for similar security reasons too. Perhaps in the commercial version trying to set them higher than RunRev's requirements might throw an error but setting them lower would be allowed. Both of these should be a once per session thing.

[SirWobbyTheFirst]

There is already an editScripts global property that is documented as not doing anything and only there for SuperCard compatibility.

Wow, that would definitely be a blast from the past for some people, the other day on the sub-reddit, a guy was talking about getting really nostalgic with LC going open source.

Yes, I was talking about making it an option in standalone settings. It would add a heap of size to RunRev's distribution to do that though... I wonder if it would be possible to make it a global property.

That was what I was trying to portray in the OP, I thought my post seemed vague dammit! I had that concern too, given that the standalone engine is ~2 meg on Windows and Linux, on the other hand, the Mac builds are ~6 meg with the universal build being ~12 meg. So I can see a bad bit of bloat added on to the distribution if two separate engines were included.

Perhaps that could be activated and only be allowed to be set once per session. That way your splash stack could set it to false before any plugins are loaded. It may even be possible in the gpl version to set the scriptLimits for similar security reasons too.

That option right there would suit me down to the ground, it avoids the bloat of an extra set of engines, could be set by the stack that is started up by the engine and would meet the needs of a developer who seeked such functionality as well as the GPL. Not bad Monte, not bad at all mate.

[monte]

Hmm... I had a bit more of a look at script limits and I think it would need the following change:
- change script_limit, do_limit, using_limit, insert_limit to signed int
- change no limit condition to -1
- add a command to set each limit but restrict commercial limit setting to whatever constants RunRev requires (currently 10, 10, 50, 10). This command would throw an error if the scriptLimits have already been set

Actually it looks like there is already code in the development mode for setting these limits so it would just need to be opened up a bit with an appropriate implementation for standalone mode that RunRev were happy didn't break their restrictions of the commercial product... + either the no limit condition or the complete block of the command condition would need to be -1.

[LCMark]

If I understand the original post correctly then the problem is this:

In an app designed to be extensible, it is currently possible for the core stacks of the app to be modified by the extension stacks developed by third parties. The case causing most concern is the ability to change scripts.

I guess there are several questions here:

Is it enough just to protect scripts? Other code can still muck around with custom properties and the objects of the stack.

Would extending something like the cantModify property to affect script setting be sufficient? Scripts would have to turn this to false before being able to modify the core stacks.

Do the core stacks need to modify themselves? Ie. does the protection have to be context specific.

Essentially, is it just sufficient to replicate the behaviour of a password protected stack without the script hiding aspect when it comes to modification by script.

[monte]

I think whatever feature it is should probably only work in the standalone engine. The development engine should open it back up to allow editing. Now that we have behaviours I can't imagine why anyone would want to set a script. My problem with scriptLimits has always been the unnecessary restrictions on modularity with stacks in use and inserted scripts and the occasionally annoying limits on the merge function. So blocking script setting in all standalone engines might be an idea...

Another idea that would possibly be good for the IDE too is to have a sandbox concept in the engine. Where one stack can create a sandbox and open one or more other stacks in it. Separate global namespace, no access to properties of objects outside the sandbox, permissions to interact with engine and a new handler type public command/function that is the only API available to the sandboxed stackfiles from it's owner. Possibly separate image cache and separate threads too??? I know there's an IDE thread on the menu already though...

In a plugin architecture each plugin could have it's own sandbox. In the IDE each project (defined somehow as something more than a single stack file) could have a sandbox... not sure how you deal with each wanting to load the same files etc... could get complicated.

[SirWobbyTheFirst]

To put it into context, I like monte's idea of setting a global property like allowScriptEdit to false and preventing third parties from clearing your code or modifying it during runtime, it would preserve the ability to view the code and meet the demands of the GPL but also allow people like me whom build applications that have a plugin like architecture to ensure our code isn't cleared during runtime and be met with angry users.

Additionally as monte stated in his post, the property could be a set once property like SecureMode, so once you set it to true, it can't be set back unless you restart the application. At the end of the day, it's your call Mark, I was originally going to suggest two separate builds of the engine and choose between them in the IDE but as monte said it would end up bloating the installation and download.

Personally it is the only thing sans the inability to run NativeDoc (But I've got 5.5 for that) that is preventing me from properly using 6.0 as my default version of LiveCode. I hope I don't sound whiney but it is something that is important to me.

[trevordevore]

Just my 2 cents here - IMO the main problems you need to address with 3rd party plugins in an application are a) the plugin deleting files, installing malware on the computer and b) the plugin breaking your application. I think you have to assume worst case scenario if you are allowing anyone to extend your application.

Anything short of a sandbox mode for 3rd party stacks doesn't solve the problem of 3rd parties being able to mess up your application. If they can insert frontscripts, backscripts then they can potentially cause havoc. Unless your app has turned off file access then the plugin can also read/write files which means they can delete things from the users computer or install malware. This is being done through your application so regardless of whether or not it is your code it is your application that facilitated it.

My current solution for 3rd party plugins is to use a separate engine that only runs plugins. I turn off the ability to mess with files, etc. so I know the plugin won't ruin the users computer. I then broker messages between my application and the plugin application.

[SirWobbyTheFirst]

Hey guys, I had a little bit of time to think about this and have thought of a good way to implement this, the development engine and standalone engine are always going to be separate in terms of functionality so here is my proposition:

A stack specific property called AllowScriptEdit that is available to be set and when set to true, follows a SecureMode kind of operation, in that once it is set to true for that stack, it cannot be set back unless the stack is unloaded from memory and reloaded in again, ala SecureMode and when it is set to true, it results in the MCModeCanSetObjectScript method in the engine returning a false statement for that stack.

Monte, if you are up for a little collaboration project, I could help implement some code to do something like this, my C++ skills aren't really existent but I could add to the IDE functionality and then if Markie boy says its good, it could be implemented into the mainstream IDE.

[FourthWorld]

A standalone can control how stacks open, and which stacks it will allow to run. Until we have an engine-level solution to make this more convenient, why not just set a property in each of your stacks that your app requires for them to run, or require them to make some specific call, and when absent the app will close them or simply quit?

[SirWobbyTheFirst]

I could but I was just putting it out there as an idea given that community edition doesn't allow stack encryption and I think it might be important to other people as well as me.

[FourthWorld]

I could but I was just putting it out there as an idea given that community edition doesn't allow stack encryption and I think it might be important to other people as well as me.

Agreed. My apologies if it sounded otherwise. On the contrary, that's why I felt it may be worthwhile exploring existing solutions while we wait for a more convenient engine-based one.