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.
Encrypted ISFs for unattended installations
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Encrypted ISFs for unattended installations
ISFs aren't saved with the project though... they are global to the entire Magic installation.
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Encrypted ISFs for unattended installations
Regardless, can you somehow protect proprietary ISFs?Eric wrote:ISFs aren't saved with the project though... they are global to the entire Magic installation.
Re: Encrypted ISFs for unattended installations
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?
For clarification, why would it be important to encrypt ISFs, but not videos/images/models/mp3s/etc.? Aren't those important IP too?
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Encrypted ISFs for unattended installations
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.Eric wrote:... it seems to violate the open-source spirit of ISF...
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.Eric wrote:Perhaps a standalone utility would be better?
Eric wrote: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?
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 thoughEric wrote:For clarification, why would it be important to encrypt ISFs, but not videos/images/models/mp3s/etc.? Aren't those important IP too?
Re: Encrypted ISFs for unattended installations
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 .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.
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.Surely it is for the user to decide if the time penalty is an acceptable trade-off for the increased protection?
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Encrypted ISFs for unattended installations
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.Eric wrote: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 .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.
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.
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!Eric wrote: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.Surely it is for the user to decide if the time penalty is an acceptable trade-off for the increased protection?