.netlink - Prevent package from being opened in a notebook interface

I have a package which I need to deploy in a client's environment. It has proprietary code and solutions that I need to protect from prying eyes and inquisitive minds. The forum has discussed much of this sort of thing in the past. See:

How safe is Encode?

How to distribute proprietary Mathematica code

Seeking strategies to deploy a function securely without a front end

I will utilize Encode, DumpSave, and attributes: Locked and ReadProtected. They help but I wonder if I can impose other barriers to access.

The package in question will only need to get called from NET/Link. This leaves me with three related questions:

• 
  

  Does any means exist to prevent the package from ever opening in a front end notebook?

  
  


• 
  

  Does any means exist to prevent the package from ever being called from a front end notebook?

  
  


• 
  
  

  Does any means exist to delete or erase the package's code if someone did open it in a notebook?

  
  

Answer

I have been thinking about this for quite some time but didn't had enough spare time to develop it into something finished. Nevertheless, I want to give my two cents.

As you have already understood, there are two different problems here. First, you want to secure your package from looking directly into the .m file. Second, you need to secure your package when/after it is loaded into the kernel from all kinds of spelunking techniques.

For your first problem, there is maybe an easy and fast solution which should give you some security. But before you read on: I have not tested this carefully. I only assume that it gives a moderate protection! So be warned and prove me wrong.

The trick I'm using is the following: When you have written your package, you have to load it somehow in the clients kernel. What I suggest is that your client never gets any kind of source-code. You simply take your whole package and compile it into a library.

The good thing is that this can be done completely from within Mathematica. First, let's create the encode version of our example package in the same as I did in this answer:

file = FileNames["Collatz.m", {$InstallationDirectory}, Infinity];

encoded = ToFileName[$TemporaryDirectory, "encoded"];
Encode[First[file], encoded];
encCode = Compress[Import[encoded, "Text"]]

The variable encCode contains the encoded package code for which Wolfram claims that there is no way to decode it. Furthermore, I have used Compress because the result

...generated by Compress contains only printable ASCII characters.

Next step is to load the CCompilerDriver` package and create a minimal WolframLibrary code which will create a library. This library will contain the encoded, compressed and compiled version of your Mathematica package:

Needs["CCompilerDriver`"]

libsrc = "#include \"mathlink.h\"
   #include \"WolframLibrary.h\"       
   DLLEXPORT mint WolframLibrary_getVersion(){
     return WolframLibraryVersion;
   }       
   DLLEXPORT int WolframLibrary_initialize( WolframLibraryData libData) {
    return 0;
   }       
   DLLEXPORT void WolframLibrary_uninitialize( WolframLibraryData libData) {
    return;

   }

   DLLEXPORT int setup(WolframLibraryData libData, mint Argc, 
     MArgument *Args, MArgument Res){
       int pkt;
       MLINK link = libData->getMathLink(libData);
       MLPutFunction ( link, \"EvaluatePacket\", 1);
   MLPutFunction ( link, \"ImportString\", 2);
   MLPutFunction ( link, \"Uncompress\", 1);
   MLPutString ( link, \"" <> encCode <> "\");

   MLPutString ( link, \"Package\");
   libData -> processMathLink ( link);
   pkt = MLNextPacket ( link);
       if ( pkt == RETURNPKT) {
           MLNewPacket(link);
       }
       return LIBRARY_NO_ERROR;
   }";

The important part here is hidden in the setup function where the package code is directly injected into a MLPutString call.

To create the library you need to distribute to your client, you now use

lib = CreateLibrary[libsrc, "collatzPackage"]

The final package your client will see is only a stub which will contain the library in the aproapriate library folder (see under Applications) and the code which, instead of loading a package, sets up the package through a library-call. This last part is as easy as loading the setup from the library and calling it:

LibraryFunctionLoad[lib, "setup", {}, "Void"][]

And now you have your package ready