We are a small company, and we have some tools that aren't really that great, but the company's owner is asking me if we could do something to protect them. For me they are simple code, but for him they are property of the company.
I understand him but I don't think protecting all of our simple scripts would worth the trouble, so I may end up convincing him to just give up or hire a specialist. In my previous work, the chief programmer used to protect all the compiled tools with some sort of intranet authentication so the tools could only be used when the PC is connected to the company's LAN. I didn't want to do that because I would have to rewrite every vbs and js files to something compilable, so I was wondering if it could be done at file management level. Me, I just want to protect the files to avoid pollution. One time I had a designer complaining that some script I wrote wasn't working, and when I opened the script file, it was blank. It seems that he opened the file in the script editor, who knows why deleted everything and when he was closing SI just clicked on save. Martin On Wed, Jul 10, 2013 at 1:44 PM, Raffaele Fragapane < raffsxsil...@googlemail.com> wrote: > Can I ask on what grounds? > It's very hard to think of something you could write in Python (let alone > in JS or VBS) that, without the company's infrastructure, would represent > enough of an edge to be protected so fiercely. > Unless it's a security risk, and not the "theft" of the tools worrying > somebody. > > I've seen it fairly frequently where some places got fairly protective > about some stuff that without the asset/infrastructure was downright > useless, or that was held in high regard but really was so incredibly > trivial that the round-about ways taken to protect it got quite laughable. > > You can always offer only the pyc compiles for most of the stuff anyway, > so all they would get is bytecode. Reversible, admittedly, but again, is it > really such hot property that it's worth protecting? > > > On Wed, Jul 10, 2013 at 2:25 PM, Martin <furik...@gmail.com> wrote: > >> My main goal was to share a Workgroup folder for main production, and we >> have some not compiled (jscript, python, vbs) plugins that we don't want to >> be copied, specially if we are going to have outsource temporal workers >> helping us. I'll have to look for another solution. Code protection sounds >> like a very troublesome task. >> >> Matt's suggestion sounds interesting, I'll give it a shot. Thanks. >> >> Thanks again, >> >> Martin >> >> >> On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind <ml...@carbinestudios.com>wrote: >> >>> Depends on your goals/needs:**** >>> >>> ** ** >>> >>> If you’re trying to set up a renderfarm and have a workgroup set up to >>> be used by the nodes, then just put the workgroup on a machine where users >>> cannot reach it.**** >>> >>> ** ** >>> >>> If you’re trying to set up a workgroup to be used by users in main >>> production, then you really can’t hide the workgroup as Softimage operates >>> under the same user permissions as the user. The best you can do is make >>> the workgroup read-only.**** >>> >>> ** ** >>> >>> One thing you could try is an old-school method that was employed before >>> the existence of workgroups - write your tools as script functions in files >>> instead of self installing plugins. The concept is to write a master >>> wrapper command that acts as a front end to call all the other commands >>> using Application.ExecuteCommand() or Application.ExecuteScript() or >>> Application.ExecuteScriptCode(). The scripts can be placed on any server >>> away from user direct access, or can even be embedded in a database table >>> which is called dynamically. There will be a slight hiccup while the >>> plugin looks for the command to execute in the database table, but it >>> completely hides the location of the script preventing user tampering >>> unless they’re quite adept at scripting to extract whatever it is you’re >>> protecting.**** >>> >>> ** ** >>> >>> The technique I use is to brute force replace the contents of the >>> workgroup on application startup. I intended this to be a way to ensure >>> users all have the latest versions of the tools, but it has a beneficial >>> side effect of frustrating users enough they don’t bother tampering with >>> the workgroup because they know any modifications they make are only valid >>> as long as the current session. Next restart and all their changes are >>> wiped.**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> Matt**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Martin >>> *Sent:* Tuesday, July 09, 2013 3:22 AM >>> *To:* softimage@listproc.autodesk.com >>> *Subject:* limit access to workgroup**** >>> >>> ** ** >>> >>> Hi list,**** >>> >>> ** ** >>> >>> This isn't exactly an SI question but I was wondering if there is any >>> way to limit direct access to a SI Workgroup allocated in a server so it >>> could be used by SI, but not copied or altered.**** >>> >>> ** ** >>> >>> Martin**** >>> >> >> > > > -- > Our users will know fear and cower before our software! Ship it! Ship it > and let them flee like the dogs they are! >
