23
$\begingroup$

How safe is an encoded package (using locked, etc)?

If I don't specify a personal key, I understand that the encoding key must be somewhere in the Mathematica program itself, and so it is not a perfect system, but:

  • can we trust it for commercial deployment?
  • has someone of you ever heard of it being found?
  • do you know if there are backdoor to reverse the code, like shadowing the encode/decode system...? (don't want to know them, just checking how safe it is...)

If I specify a key, I understand that it becomes a stronger system, but:

  • how can the client use the app without me giving back the key (without him seeing the code -> I'm supplying the app, but with closed source)?
  • is there a workaround for this personal key system?
  • how do you typically do it, or see it done?

I heard of MX files being used, but at first glance, they look very version/system specific, and so kind of difficult to manage when the client updates his Mathematica, or player. Nevertheless:

  • are they safer than encode?
  • can they be mixed up with encode to become safer?

On other programming languages I use USB dongles:

  • do you know how it could be done with Mathematica (my program is 100% coded on Mathematica language)?
  • would I need to go through the new librarylink?

I know that these are lots of questions, but I cannot find a lot of info on this theme.

| improve this question | |
$\endgroup$
  • $\begingroup$ Could you try narrowing the subject of your question somewhat? Ideally a question should have a single correct answer; putting a dozen questions in a single "question" isn't really the appropriate format here. I realize some of them are highly-overlapping, and could probably be asked together, but as it is this will probably be closed. (If so, please do try to repost one or more of them, they are good questions.) $\endgroup$ – Jeremy Banks Jul 31 '11 at 10:34
  • $\begingroup$ Seems like you could contact the Wolfram company with those questions. $\endgroup$ – j0ker5 Aug 4 '11 at 16:21
  • $\begingroup$ Related: How to distribute proprietary Mathematica code $\endgroup$ – Szabolcs May 28 '12 at 8:50
13
$\begingroup$

The documentation of Encode states:

No function is provided in Mathematica to convert encoded files back to their original form.

implying that an average user should not be able to view your proprietary code.

If you look at the example on the Encode doc page you see that Get is used to read back the Encoded Collatz package and Collatz works as intended. If you now type: 

Definition[Collatz]

you get

Collatz[1]:={1}

Collatz[Collatz`Private`n_Integer]:=
    Prepend[Collatz[3 
        Collatz`Private`n+1],Collatz`Private`n]/;OddQ[Collatz`Private`n]&&
           Collatz`Private`n>0

Collatz[Collatz`Private`n_Integer]:=
    Prepend[Collatz[Collatz`Private`n/2],Collatz`Private`n]
      /;EvenQ[Collatz`Private`n]&&Collatz`Private`n>0

So, some or all of your code becomes visible.

Of course, you can use TagSet to prevent this:

Collatz /: Definition[Collatz] := ""

but I'd think there will be ways to get around that and other measures.

So, it doesn't seem that Encode is sufficient to keep your code proprietary. It might be a good way to prevent third parties from viewing your code during transport, though. In a quick search I couldn't find the type of encryption, so there's not much to say about its actual safety.

If you want to deploy your code in encoded form, your clients might have to use Mathematica Player Pro (or MMA itself) as I don't think the CDF-player reads encoded documents (it doesn't import and export documents at all, see the CDFplayer FAQ). There may be Digital Rights Management in future versions according to the same FAQ:

Can I put copy protection on my CDFs?

At the moment, we do not have Digital Rights Management (DRM) for CDF, but we are working on making it available. Contact us for more details when DRM support becomes available.

Update:

There was a discussion about DRM in the LinkedIn group Mathematica. Perhaps you could contact the guy who seemed to have a solution?

| improve this answer | |
$\endgroup$
  • 3
    $\begingroup$ You could add the Attributes ReadProtected and Locked to the symbols in the package to prevent users from seeing their definitions. $\endgroup$ – Heike Jul 31 '11 at 16:14
  • $\begingroup$ Yeah, that would seem to work, but is it really airtight? $\endgroup$ – Sjoerd C. de Vries Jul 31 '11 at 16:38
  • $\begingroup$ That is exactly my question. I don't need military grade. I just need to avoid that competitors profit from my code. If the way of breaking the system is not on the internet, it is already something. If up to now there's no record of someone breaking the system, even better. What it seems to me is that if someone ever breaks the system, it will work for every encoded code (it will be done by finding the encryption key or a backdoor). And if my apps are not worth the effort, I'm not certain if there is interest enough on other apps that has already taken someone to that inglorious actions... $\endgroup$ – P. Fonseca Jul 31 '11 at 16:53
  • $\begingroup$ So, can there be a way of mixing a personal key with the system key, so that if someone breaks the general key, it will not immediate risk my code, but at the same time, with just my key, there's no way of reading the code? Obviously I'm not talking of a a literal key mixing, but rather of a process or strategy on that way... Probably being paranoid here, but I don't know the strength of the standard system... $\endgroup$ – P. Fonseca Jul 31 '11 at 16:55
  • 1
    $\begingroup$ You can make the encoded version depend on the $MachineID of your client, that's one of Encode's options. See also my update. $\endgroup$ – Sjoerd C. de Vries Jul 31 '11 at 18:32
8
$\begingroup$

The main purpose of Encode function is to make sure that your source code can not be directly edited.

Licensing mechanism should be embedded in the code of your application. Mathematica provides interfaces to Java, .NET and, as of version 8, Mathematica can load and use functions from DLL, see LibraryLink.

You could use any of these interfaces to implement USB dongle for your application as well.

See the list of Mathematica's Add-Ons. Some of them do successfully implement licensing schemes.

Finally, ask Wolfram's tech-support for help.

| improve this answer | |
$\endgroup$
  • $\begingroup$ So, should I take from your answer that it is not very safe? For simple applications meant to be used with Player Pro, like a report that uses a proprietary package, would you still recommend that I should go thru an external protection system (you understand that this is not very practical just for sending a report that has a proprietary package attached, in order for it to run)? $\endgroup$ – P. Fonseca Jul 31 '11 at 14:36
  • $\begingroup$ Protection is always a balance between your effort and the percentage of users deterred from ripping you off. Encode will do some of it for you, but nowhere in the docs does it say to be cryptographically secure. The judgement call is yours to make. $\endgroup$ – Sasha Jul 31 '11 at 14:42
  • $\begingroup$ But on the player pro features, we can read: "Supports commercial applications with source code encryption". Does this refers to a different encryption strategy, or is this statement based on the use on Encode? Based on the image that is shown and on the guidelines available, I would think that it refers to Encode... and if so, I'll take it as an overstatement since, as you said, nowhere on the docs we can read it to be secure. So, do you know what is WRI strategy for commercial "safe enough" simple player pro apps (simple, I mean, keeping 100% Mathematica code). $\endgroup$ – P. Fonseca Jul 31 '11 at 15:03
  • $\begingroup$ Well, not every encryption is of military grade. I was referring to cryptographically secure, as a synonym for strong encryption, sorry it caused a misunderstanding. $\endgroup$ – Sasha Jul 31 '11 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.