Zugg Software :: View topic - Feature Ideas: Restricted / Trusted / Obfuscated modes for packages

Wizard Joined: 14 Aug 2004 Posts: 1269

I don't know about the rest of you, but I don't like the idea of downloading code onto my computer from someone I don't trust that will have the same privileges that my logon has. This is one of the reasons I've only just started looking at the Package Library (given the fact that I know a package can currently wipe my computer, FTP my files off, possibly including my session database and packages, possibly just using %pass with a #URL such that it gets logged on someone's website, or something more advanced. Anyway, the possibilities are currently limitless.

I know that of course one should download a package first and then check it out to see what it does, but reading all the code in a big package may be tedious and not everyone may end up doing this. And with the OnLoad event now, the package could carry out the malicious activity before you've had the chance to look inside it.

I've been thinking about aspects of this for some time and so now I suggest some extra options that can be set for packages only via the GUI (thus eliminating the possibility that a trojan CMUD script would mark an untrusted package as trusted):
(a) Trusted package - this should be the default for packages created locally.
(b) Normal package - this should be the default for packages downloaded from the Package Library.
(c) Restricted package
(d) Obfuscated package - this would be independent of the previous 3 options - I'll explain later as it's pretty separate.

(a) a Trusted package would be able to do anything a package is currently able to do.
(b) a Normal package would be able to do anything except use #DDE and related functions, #COM and related functions, #CHARACTER, #PW, %pass and probably most things listed in the "Session" manual page, #FTP (when it is implemented), possibly #URL, #MSS, #LAUNCH, #PLUGIN (when it is implemented), #SCRIPT, possibly #EXEC - probably not as long as %pass and %char are not available to it, #SS, anything else you think is dangerous. I don't know what built-ins Lua has and whether any of those may be dangerous...
(c) a Restricted package would operate in a 'sandbox' and not be able to read or write to any setting outside of its own package in addition to the limits in (b). (This may be like Local modules? But it would apply to the whole package.)

Ideally, the list of restricted commands and functions would have a default like I have described but could be customized by the user on an individual package basis (or globally, or both - inherited like Preferences).

-----------

I know some people sell zScripts, so they may find Obfuscated packages useful. Others may just not know if, or when, their friends / group-mates may turn on them, or maybe not want every Tom, Dick and Harry getting their hands on all their hard work.

Obfuscated packages would either (a) only contain the compiled code wherever it is available, or (b) have a password to view, export or save as the package, or copy or move the settings to another package. Obfuscated packages should default to Restricted mode when installed for the first time, given that they are more difficult to analyse.

The idea of obfuscated packages is so that owners can maintain ownership of the source of their package and possibly, for example, implement some sort of time-bomb (in zScript code) where the package ceases working after X date (but causes no other damage!) Or a time-limit on packages could be implemented directly in CMUD, but that would still require code obfuscation. Another example is to add some zScript code to prevent someone you give a package to distributing the package to all their friends or posting it onto the internet. Again, perhaps that check could be integrated somehow into CMUD - although that might only work with registered users - but Zugg might like that idea.

People should still be able to read the compiled code to work out more or less what the package does and to verify that it doesn't do anything malicious or underhanded. Module properties should not be changeable, so that modules can be set to Local by the owner and thus not allow any changes to be made from outside the package.

Obfuscated packages should be flagged as such in the package library.

I realise that these suggestions are probably not something for this beta period or the public period that follows, and doing all of the suggestions might be a substantial job, but I have more or less listed the suggestions in the order they would need to be implemented, so doing the first couple might not be too much work and then others maybe can be considered later.

[Edit: Not sure if the Beta forum is more appropriate than the normal forum for this - move it if you want to - I didn't want to scare any newbies.]

Posted: Wed Nov 14, 2007 3:50 am

In earlier discussions when packages and the library first came up Zugg did talk about the idea of have Public and Private packages; with the main idea for Private being for those who want share their packages with a select few or provide them for sale. The initial idea being is that much like open source software it's the visibility of the code that would ensure anything malicious was quickly removed. Of course, that was before the onLoad event.

The categories you have described would work well although I'm not convinced normal is absolutely required. From Zugg's perspective I think it would be easier to do Trusted and Restricted (with the later just having a scope check.) With that said you'd still want parsing rules around #EXEC etc commands to block them, and once you do that providing the Normal mode would be fairly simple.

As for Obfuscated I like the idea of it being password protected, i.e. you would need a password to copy/paste, export, see the Script Text, XML tab, and mask everything except the name in commands like #TRIGGER from the command line. I thought you could even take it one step further by having it downloaded each time you load up CMUD (if you already have access to it) to make it more secure. Of course if you had this options then that package would need it's underlying DB data encrypted. Alternatively you can put these options on a separate Commercial category.

This could tie in nicely with Zugg idea for a MyMUDs page and some other either for a package library. Also he could make Commercial packages only accessible from the library (i.e. author would upload then set the option there) and charge a small fee for hosting. It has the added benefit of providing an additional revenue stream for Zugg.

Of course it's up to Zugg to say how feasible this is. It would definitely be something for after the first 2.xx public release and depending on where Zugg puts the mapper rewrite it may even be a 3.xx release thing.

Posted: Wed Nov 14, 2007 6:59 am

In my opinion, the most important feature of the package library, is the pending private "area."

If I decide I wish to create a clan on my mud with a particular pvp purpose (as I am doing at the moment) I would love to have a set of scripts available only to members of that clan. I will offer a decent curing system to members, various group fighting scripts, and whatever else I can think of. Sharing scripts globally is fine and all - its basically like the finished scripts forum on steroids.

But the private area can really change the way this sort of thing works, AND at the same time give more people reason to buy CMUD. Most of the people from my mud use zmud. A handful have CMUD licences, and only a couple actually use CMUD. For people that already have zmud working well for them, what does CMUD really have to offer? Of the people I know that I play the game with, I am one of the better zscripters, yet when you lot go on about some of the new features (threading comes to mind) I start thinking about football Embarassed

. The people who manage to build working curing systems around #IF, #VAR and #ALA are not going to upgrade to CMUD because it took them long enough to get zmud working, let alone try and port it all to a new client. If it isn't broke, don't fix it >.>

On the other hand, a friend supplying them with a working system, installed with a mouse click, updated with a mouse click - thats a reason to buy CMUD over every other client on the market. But it hinges on the private area of the package library being implemented. There is no chance I am giving my proper system to everyone, and I'm not alone in this.

The obfuscated script is an interesting idea. Larkin may well be interested in this one, and could probably comment on it.

Wizard Joined: 14 Aug 2004 Posts: 1269

Yes, clans may like to share their scripts, but without the obfuscated mode, there is a danger of 'spies' secretly allied to another clan, or clan members leaving a clan and joining another and taking the scripts they received with them (I imagine).

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I like the idea of having trusted and restricted packages.
I know if I downloaded some of Larkin's systems (not implying for a moment that he'd make anything harmful - only that I imagine they're some of the more complex available) then I'd probably not go through absolutely every trigger and alias, so to be able to run it knowing the only thing it could alter was itself would be a comfort.

Posted: Wed Nov 14, 2007 6:09 pm

First, nothing like this will happen for the 2.x release. As Tech mentioned, some of it might fit with the MyMUDs project, which will also tie into the idea of private areas for script sharing.

However, in general, this stuff is very hard to do. For example, just look at the idea of "restricted" packages...sure, I can prevent "dangerous" commands, like DDE and COM stuff. But what about a script that just does something like this:

#TRIGGER {Zugg enters the room} {remove all;drop all;quit}

There is absolutely no way to prevent that kind of stuff in the package...it's just normal text sent to the MUD. So there isn't *any* way to really prevent a package from doing something harmful. The only way to prevent this kind of stuff is to allow people to actually see your script. But if someone can see it, then they can copy it.

Password protection doesn't help. All someone needs to do is post the password to the net. You need an entire "copy protection" system with license keys, etc. And that's a whole area that I don't want to get into.

Your point about the onLoad event is a good one though. I think I'll add a File/View option to the Package Editor that will load a package for viewing, but will *not* call onLoad or initialize any variables (not perform a #reset). Then you'll be able to safely view a package that you don't trust.

The analogy that I use for CMUD Packages is buying Delphi Components from a 3rd party vendor (or Visual Basic components, etc). I never buy any component from a 3rd party that doesn't come with full source code. And the vast majority of developers provide this. This allows me to recompile the components myself (like if I upgrade Delphi), or to tweak them myself, or even fix bugs myself.

What's to stop me from just posting all of this 3rd party source code to the Internet? Or maybe I could just modify the source code and then resell it as my own product? Of course it isn't legal. But mostly nobody does this. That's because I want to buy my components from a company that is going to give me support. I want to be able to ask questions, report bugs, get updates, etc. These 3rd party components can do *anything* to my computer. Delphi doesn't have any sort of safe "sand box" mode. And I'm probably not going to look at every line of source code looking for problems. I protect myself by only buying from reputable vendors that I can trust. Sure, I might be able to find it for free somewhere on the net, but whoever posted it might have added their own backdoor to the code, so I'm never going to trust that.

CMUD Packages are very similar. People are going to buy packages from people like Larkin (I'm using Larkin as an example of someone who might sell scripts, but I don't really know if he does or not) because he provides support and updates for his product. He is a reputable "vendor". He has a reputation to protect and isn't going to put a backdoor into his scripts, because someone would eventually find it and then his reputation would be ruined. Since he can keep track of who buys his scripts, he can limit who gets support. If someone gives a copy of Larkin's scripts to a friend, that friend isn't going to be able to get support. And in a way, this is good free advertising because if that friend likes the scripts and eventually wants support, he might buy his own copy.

All that is needed to implement this is a private area of the Package Library where Larkin can control the access list. When someone buys the scripts, they are added to the access control list for Larkin's area in the library. They can download the scripts and get updates, perhaps even view online documentation of some sort. But once they download the script, they can look at it, learn how it works, tweak it to fit their own needs, etc. Just like I do with 3rd party component source code.

If it's a clan, then you set the access control so that only trusted members of the clan can get the scripts. Again, there is nothing to stop them from sending the scripts to someone else, but that's why you only give access to trusted members. The clan that I belong to already has a private Wiki area for trusted members so a new member of the clan can't access it. And they are already posting zMUD scripts to this area for the high-level clan members. But there is nothing stopping them from leaving the clan and taking the scripts with them. There is no sure-fire way to prevent this.

Finally, remember that the Package Library is tied to the zuggsoft.com Forum accounts. There are not any "anonymous" accounts. So you don't get any anonymous packages in the library. If someone posts a package that does damage to a computer, or to a person's MUD character, then that person gets banned from the package library, which also means getting banned from the forums. Since their identify is known, they could even get banned from their Zuggsoft Store account, preventing them from getting their license key or future updates. Most people are not going to risk this. And that is why the Package Library already has a Comments and Rating section for each package. You can look to see how popular a package is, and how highly it is rated. That can help you determine what is more likely to be safe. I doubt malicious scripts would last very long...some people *are* going to look at every line of the script and report if there is something suspicious with it.

So, I'm not convinced that we need more than this, nor that it's even possible to provide more than this. As with any copy protection, there will always be a way around anything that I code. CMUD and zScript are complex...no matter how I would try to protect it so that the package could only alter it's own code, someone would find some way around it. And most useful packages *need* to be able to create variables within your session window and stuff like that.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Yes, I do sell scripts and I have for years now. It works exactly as you described, Zugg. I don't put in backdoors or cheats because I have a reputation to consider. People don't generally give away my scripts because they paid for them and don't want to devalue their own investment. The few who do give them away, however, I don't worry about because it can be a form of advertising and there's really nothing I can do about the rogues who use my scripts except not provide them with support.

Having private packages, however, would give us a channel for distributing updates to those who paid for access to the scripts without having to e-mail out one or more .pkg files and give instructions on where to save them, how to load them, etc. We'd just need a way to tie their character to their forum handle (a simple in-game message can take care of that verification, which is what I use now for getting someone's e-mail address), and for some people that means signing up for these forums just to get access to the Package Library...

Posted: Wed Nov 14, 2007 8:16 pm

I looked at Acropolis a few days ago, Larkin (it being an open download from your site these days) and was pretty impressed with the completeness of the whole idea. You've put a lot of thought into it, and it occurred to me that at the price it is, if I went and played Lusternia I'd probably buy it with a contract as well, rather than doing my own from scratch.

I guess it comes down to how well you price a good product.

Posted: Wed Nov 14, 2007 9:02 pm

One of the things that will be interesting about tying together the MyMUDs.com project with the Package Library is that the MyMUDs database will already know which MUDs are being played. Remember that MyMUDs is storing your session info on the Zuggsoft server (along with your packages). So, while the password info is totally encrypted and cannot be accessed by anyone, the name of the MUD and the player's character name is available.

So, imagine the possibility that when I create a session on Lusternia and store it on MyMUDs, the MyMUDs site can now tell you that "here are the packages available for Lusternia...". So it could automatically show a list of packages, including Larkin's packages. It might even be possible to set up a system via PayPal where package writers can get paid easily through a "Buy this package" button on MyMUDs.

Anyway, lots of possibilities for this. Which is why it's not happening until after the holidays ;)

BTW: Thanks for the info on your scripts Larkin. Glad to hear it's working how I'd expect it. I think it's a very good model and attitude for selling packages.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

If I could use PayPal to sell scripts, I'd be ecstatic! Heh. (Don't worry. I'm not expecting the feature any day soon.) From selling my scripts for in-game credits, I've managed to earn over $5,000 worth of stuff, which is important because I'm forbidden to spend any money on "virtual stuff" in my games. It's "bad enough" that I spend so many hours playing the games and writing the scripts. Very Happy

Really looking forward to MyMUDs.com and advances in the Package Library now. With the cool constructs in CMUD, such as packages and events, that allow us to build more modular systems, the possibilities are growing in leaps and bounds.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Wed Nov 14, 2007 11:06 pm

SubAdmin Joined: 18 Nov 2001 Posts: 5182

One post in these forums is about all it would take to have a package cleaned up. I am pretty sure that all the Guru's have the ability to delete any package on the library, and the Guru's manage to pop in and out almost like clockwork nearly every hour. So all it takes is 1 person finding it and a very small amount of time.

At some point I would probably like to distribute a package or 3 and be compensated for some of them. If you think about how many scripts I have just given away, hours spent writing and debugging scripts for muds I don't play, you will realize that it probably doesn't matter to me much if someone doesn't give me whatever compensation I ask for. Larkin's reality makes a good showing of exactly the philosophy Zugg is approaching this with. It is the right way to do it.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Thu Nov 15, 2007 2:08 am

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Thu Nov 15, 2007 4:25 am

Posted: Thu Nov 15, 2007 5:34 pm

Not very tempting actually. I've got too much code invested in ZeosLib, and ZeosLib allows me to work with almost *any* database. And this is useful when I start doing projects like MyMUDs.com that will be MySQL based.

Also, I prefer ZeosLib because it *does* use the DLL files. So if there is a bug in SQLite.DLL, I can just install a new DLL. We ran into this early in the CMUD 2.x beta testing when we discovered a better DLL that didn't have debugging enabled. Of course, going from SQLite 2.8 to 3.0 requires more than a DLL change, but once I update ZeosLib, then I should be able to handle future updates to SQLite 3.x much more easily.

The "DISQLite3 outperforms sqlite3.dll up to 50% for common operations" is kind of interesting, but right now CMUD only uses SQLite directly when writing the database updates to the PKG file every 60 seconds, and this isn't very slow. So it's not like this would be a huge performance boost for normal CMUD operations.

Also, money is tight right now, so 270.00 Euros is a bit much. Especially since I still have other components that I still need to pay for Delphi 2007 updates, and I still have an expensive update to Armadillo to do soon.

Still, thanks for posting the links. I'm not sure I'll ever find these again buried in this thread, but it's possible that it might be tempting in the future to play with that, especially since it has encryption support.

Posted: Thu Nov 15, 2007 7:30 pm

Is there an initial discussion about MyMuds.com, somewhere? I don't seem to be able to find one, but everyone else seems to know what you're talking about already.

Posted: Thu Nov 15, 2007 8:10 pm

Here's the link you're looking for. It's like a pre-New Years letter from Zugg.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Fri Nov 16, 2007 2:34 am

No, ZeosLib talks to the SQLite.DLL. So if they have a drop-in replacement, then it might work (well, once I upgrade ZeosLib to handle v3). Not sure how the encryption would be enabled...maybe that's a specific SQL statement or something?

Delphi has a very specific API for doing databases. The databases need to tie into this API so that Delphi "data aware" controls work properly. ZeosLib is a layer between the raw database DLLs and the Delphi database API architecture. So when I'm using ZeosLib, the actual database details are transparent to my Delphi code. I just use SQL statements directly, and I just need to worry about slight differences between SQL constructs for various databases.

So I couldn't use any of the free projects...I need that Delphi database API support. I also don't want to give up ZeosLib because it's one of the very few components that works perfectly with absolutely no changes on my part. I've never had to fix any bug in ZeosLib.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Fri Nov 16, 2007 8:28 am

Posted: Fri Nov 16, 2007 4:02 pm

This discussion comes up every couple of days, Caled - remove the safe search option from the URL and it'll start working. Or you can use the search option from the Site menu at the top.