Encrypted ISFs for unattended installations

[Terry Payman]

We can effectively password-protect our Magic projects. Many thanks Eric

However access to the machines would enable someone to copy any custom ISF files, which could contain proprietary IP.

An encryption feature so that ISFs could be encrypted along with the project would address this vunerability.

[Magic]

ISFs aren't saved with the project though... they are global to the entire Magic installation.

[Terry Payman]

ISFs aren't saved with the project though... they are global to the entire Magic installation.

Regardless, can you somehow protect proprietary ISFs?

[Magic]

Theoretically yes, but since ISFs aren't saved with the project, there would have to be a separate command to encrypt them. And it feels a bit odd to add something like that to Magic, not just from a functional standpoint, but also because it seems to violate the open-source spirit of ISF. Perhaps a standalone utility would be better? But then there would be the matter of decrypting them each time they are added to a scene, which is computationally-intensive. Decrypting even small text files takes time, and they all add up.

For clarification, why would it be important to encrypt ISFs, but not videos/images/models/mp3s/etc.? Aren't those important IP too?

[Terry Payman]

... it seems to violate the open-source spirit of ISF...

Is ISF licensed under GNU GPL or equivalent, such that all ISF code is intrinsically open-source/public? If so, I wouldn't want to encrypt it.

Perhaps a standalone utility would be better?

I don't mind how it's done . I considered a separate application but couldn't think how it could have access to Magic's Perform & Edit passwords without fundamentally compromising the security they provide.

Decrypting even small text files takes time, and they all add up.

Surely it is for the user to decide if the time penalty is an acceptable trade-off for the increased protection?

For clarification, why would it be important to encrypt ISFs, but not videos/images/models/mp3s/etc.? Aren't those important IP too?

An ISF can encapsulate a great deal of know-how and could readily be repurposed without the output being identifiable. Videos/images/models/mp3s/etc could be identified much more easily than a graphics operation, so are arguably less likely to be re-used publicly. I'd be happy if I could encrypt everything though

[Magic]

Is ISF licensed under GNU GPL or equivalent, such that all ISF code is intrinsically open-source/public? If so, I wouldn't want to encrypt it.

Some of it is, but I was referring more to the fact that most ISF code is created collaboratively, based on universal techniques/algorithms, so it's unlikely to be entirely one person's IP. But of course it could be .

Surely it is for the user to decide if the time penalty is an acceptable trade-off for the increased protection?

Yes, but many users won't be aware of the tradeoff, and will wonder why the program runs more slowly when loading/adding modules. This may seem like a minor point, but customer support does require time and resources.

[Terry Payman]

Is ISF licensed under GNU GPL or equivalent, such that all ISF code is intrinsically open-source/public? If so, I wouldn't want to encrypt it.

Some of it is, but I was referring more to the fact that most ISF code is created collaboratively, based on universal techniques/algorithms, so it's unlikely to be entirely one person's IP. But of course it could be .

I have written some simple ISFs, without using anything but the ISF examples for reference. I would not feel bad about encrypting or obscuring those.

However, it has just occurred to me that steganography rather than cryptography would be an adequate approach, with a negligible load-time penalty that would only affect my own projects.

The existing Magic password protection will hide the interconnection of modules (thanks again for that, Eric ), so I have simply to use some mis-leading names for a large number of my own modules, and arrange that some of them need to be used in combination to give any processing functionality that I wish to protect. Others would be loaded in dummy scenes, as the file-loading actions of a password-protected Magic project could easily be monitored.

Surely it is for the user to decide if the time penalty is an acceptable trade-off for the increased protection?

Yes, but many users won't be aware of the tradeoff, and will wonder why the program runs more slowly when loading/adding modules. This may seem like a minor point, but customer support does require time and resources.

Understood. I hugely appreciate the time and resources you have devoted to my own requests and queries. Magic feels like custom software to me, and I now realise that you have already implemented all the functionality I need for ISF protection!