Re: [Maya-Python] V Crypt System

[Rudi Hammad]

oh, about the screenshots. If the rig is encapsulated in a black box, maybe 
it would be possible set a callback preventing from unlocking the blackbox?
That way you can check want is inside and take screenshot.

El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
escribió:

> Quick question, I haven't use mel in 4 years now so it is probably 
> something foolish but why is this not working?
>
> string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
> return macAddress; foo()";
> string $macAddress = python($toEval);
> print $x;
>
> I would expect $x to print my computer mac address by it is empty.
>
> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, golu...@gmail.com 
> escribió:
>
>> Marcus, thanks for your comment!
>>
>> When I talked about export I meant not to ma or mb, I meant for example 
>> to alembic or other,  because as I knew alembic export is like a separate 
>> plugin, and .correct me if I am wrong export to alembic will be ignored by 
>> this callback.
>>
>> I've not understood you, sorry, yes it is already protected, but if this 
>> protected scene to /myrig.mb will be referenced in the main scene, during 
>> the main parent scene opening, I will need to decrypt my rig.mb and any 
>> other child scene which is referenced and send to a remote worker,
>> or I understand you wrong)
>>
>> About RAM I'm sorry, that's my mistake, later edited the message, but was 
>> too late, you absolutely right!
>>
>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>>
>>> The part of Maya that does the serialisation to ma and mb - be it via 
>>> export or save - is a singular point of access. The scene callbacks should 
>>> account for all ways in which creating those is possible, including via 
>>> Python and MEL. It wouldn’t account for manual export to other formats, but 
>>> there’s no end to that. Screenshotting your viewport is a format too, 
>>> albeit a lossy one. But I’d argue that depending on what you want to 
>>> protect, if that is rigs and animation, the Maya scene format should be 
>>> enough.
>>>
>>>- OpenMaya.MSceneMessage.addCheckCallback() 
>>>
>>> 
>>>  
>>>
>>> And all of it must be done recursively on the whole data tree in scene
>>>
>>> I’d argue not. The information you protect is the information in the 
>>> scene file. If that scene file consists of an absolute path to e.g. 
>>> c:\myassets\myrig.mb then that is *already* protected; nobody can 
>>> access that file but you on your local machine.
>>>
>>> so at some point how to handle your RAM memory, because you can’t store 
>>> this encrypted data somewhere…)
>>>
>>> I’d argue not (again :)). Is it to protect against hacker-animators and 
>>> hacker-riggers? Or against the general workforce that has no clue about 
>>> callbacks and encryption? If the latter, then saving it into a temp 
>>> directory first, and encrypting it after should suffice. To the user, the 
>>> file would end up where they said it should. But really, it’s a different 
>>> file altogether. Then that file is copied back into a temp directory and 
>>> decrypted whenever they open it. All of that can happen on disk.
>>>
>>> And besides, memory is just another location. A motivated-enough 
>>> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
>>> increase the level of protection.
>>>
>>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>>>
 It is a very interesting discussion.  

 Yeah, I will agree that it definitely must be invisible - so artists 
 don't even know that encryption happened.
 But you can't stop on scene saving and loading, you should create lots 
 of workarounds in this "secure Maya client".
 Somehow you need to lock any exporting of data inside in any format, 
 hide\lock\encrypt code of all used inside scripts, lock any new plugin 
 loading\or current plugins disabling. 
 And lock script editor, or make some sort of interceptor, to ensure, 
 that no script will run to export or explore private scene data. 
 Also, if I understand all correctly, it will give a lot of restrictions 
 for people who work with their tools(it will lock them on the layout of 
 instruments you gave to them).

 And this only stuff that comes up to mind immediately, I think during 
 the development of such Maya launch wrapper lot's of underwater stones 
 will 
 come up eventually.

 Additionally, if in your scene you will have references, during 
 reference load you will need to decrypt this data,
 the same will go to any geometry\textures or any files - you will need 
 to decrypt on the run.
 All of it must be done recursively on the whole data tree in scene,
 so at some point how to handle your RAM memory, because you can't store 
 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

Quick question, I haven't use mel in 4 years now so it is probably 
something foolish but why is this not working?

string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
return macAddress; foo()";
string $macAddress = python($toEval);
print $x;

I would expect $x to print my computer mac address by it is empty.

El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, golu...@gmail.com 
escribió:

> Marcus, thanks for your comment!
>
> When I talked about export I meant not to ma or mb, I meant for example to 
> alembic or other,  because as I knew alembic export is like a separate 
> plugin, and .correct me if I am wrong export to alembic will be ignored by 
> this callback.
>
> I've not understood you, sorry, yes it is already protected, but if this 
> protected scene to /myrig.mb will be referenced in the main scene, during 
> the main parent scene opening, I will need to decrypt my rig.mb and any 
> other child scene which is referenced and send to a remote worker,
> or I understand you wrong)
>
> About RAM I'm sorry, that's my mistake, later edited the message, but was 
> too late, you absolutely right!
>
> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>
>> The part of Maya that does the serialisation to ma and mb - be it via 
>> export or save - is a singular point of access. The scene callbacks should 
>> account for all ways in which creating those is possible, including via 
>> Python and MEL. It wouldn’t account for manual export to other formats, but 
>> there’s no end to that. Screenshotting your viewport is a format too, 
>> albeit a lossy one. But I’d argue that depending on what you want to 
>> protect, if that is rigs and animation, the Maya scene format should be 
>> enough.
>>
>>- OpenMaya.MSceneMessage.addCheckCallback() 
>>
>> 
>>  
>>
>> And all of it must be done recursively on the whole data tree in scene
>>
>> I’d argue not. The information you protect is the information in the 
>> scene file. If that scene file consists of an absolute path to e.g. 
>> c:\myassets\myrig.mb then that is *already* protected; nobody can access 
>> that file but you on your local machine.
>>
>> so at some point how to handle your RAM memory, because you can’t store 
>> this encrypted data somewhere…)
>>
>> I’d argue not (again :)). Is it to protect against hacker-animators and 
>> hacker-riggers? Or against the general workforce that has no clue about 
>> callbacks and encryption? If the latter, then saving it into a temp 
>> directory first, and encrypting it after should suffice. To the user, the 
>> file would end up where they said it should. But really, it’s a different 
>> file altogether. Then that file is copied back into a temp directory and 
>> decrypted whenever they open it. All of that can happen on disk.
>>
>> And besides, memory is just another location. A motivated-enough 
>> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
>> increase the level of protection.
>>
>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>>
>>> It is a very interesting discussion.  
>>>
>>> Yeah, I will agree that it definitely must be invisible - so artists 
>>> don't even know that encryption happened.
>>> But you can't stop on scene saving and loading, you should create lots 
>>> of workarounds in this "secure Maya client".
>>> Somehow you need to lock any exporting of data inside in any format, 
>>> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
>>> loading\or current plugins disabling. 
>>> And lock script editor, or make some sort of interceptor, to ensure, 
>>> that no script will run to export or explore private scene data. 
>>> Also, if I understand all correctly, it will give a lot of restrictions 
>>> for people who work with their tools(it will lock them on the layout of 
>>> instruments you gave to them).
>>>
>>> And this only stuff that comes up to mind immediately, I think during 
>>> the development of such Maya launch wrapper lot's of underwater stones will 
>>> come up eventually.
>>>
>>> Additionally, if in your scene you will have references, during 
>>> reference load you will need to decrypt this data,
>>> the same will go to any geometry\textures or any files - you will need 
>>> to decrypt on the run.
>>> All of it must be done recursively on the whole data tree in scene,
>>> so at some point how to handle your RAM memory, because you can't store 
>>> this encrypted data somewhere.
>>>
>>> And even this will not save you from attempt to try take this decrypted 
>>> data from RAM...
>>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>>>
 I agree with you. This would not solve all problems with working 
 remotely, but it would solve some. Perhaps the biggest problems, namely 
 accidental sharing and theft. I have also 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

Marcus, thanks for your comment!

When I talked about export I meant not to ma or mb, I meant for example to 
alembic or other,  because as I knew alembic export is like a separate 
plugin, and .correct me if I am wrong export to alembic will be ignored by 
this callback.

I've not understood you, sorry, yes it is already protected, but if this 
protected scene to /myrig.mb will be referenced in the main scene, during 
the main parent scene opening, I will need to decrypt my rig.mb and any 
other child scene which is referenced and send to a remote worker,
or I understand you wrong)

About RAM I'm sorry, that's my mistake, later edited the message, but was 
too late, you absolutely right!

понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 

> The part of Maya that does the serialisation to ma and mb - be it via 
> export or save - is a singular point of access. The scene callbacks should 
> account for all ways in which creating those is possible, including via 
> Python and MEL. It wouldn’t account for manual export to other formats, but 
> there’s no end to that. Screenshotting your viewport is a format too, 
> albeit a lossy one. But I’d argue that depending on what you want to 
> protect, if that is rigs and animation, the Maya scene format should be 
> enough.
>
>- OpenMaya.MSceneMessage.addCheckCallback() 
>
> 
>  
>
> And all of it must be done recursively on the whole data tree in scene
>
> I’d argue not. The information you protect is the information in the scene 
> file. If that scene file consists of an absolute path to e.g. 
> c:\myassets\myrig.mb then that is *already* protected; nobody can access 
> that file but you on your local machine.
>
> so at some point how to handle your RAM memory, because you can’t store 
> this encrypted data somewhere…)
>
> I’d argue not (again :)). Is it to protect against hacker-animators and 
> hacker-riggers? Or against the general workforce that has no clue about 
> callbacks and encryption? If the latter, then saving it into a temp 
> directory first, and encrypting it after should suffice. To the user, the 
> file would end up where they said it should. But really, it’s a different 
> file altogether. Then that file is copied back into a temp directory and 
> decrypted whenever they open it. All of that can happen on disk.
>
> And besides, memory is just another location. A motivated-enough 
> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
> increase the level of protection.
>
> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>
>> It is a very interesting discussion.  
>>
>> Yeah, I will agree that it definitely must be invisible - so artists 
>> don't even know that encryption happened.
>> But you can't stop on scene saving and loading, you should create lots of 
>> workarounds in this "secure Maya client".
>> Somehow you need to lock any exporting of data inside in any format, 
>> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
>> loading\or current plugins disabling. 
>> And lock script editor, or make some sort of interceptor, to ensure, that 
>> no script will run to export or explore private scene data. 
>> Also, if I understand all correctly, it will give a lot of restrictions 
>> for people who work with their tools(it will lock them on the layout of 
>> instruments you gave to them).
>>
>> And this only stuff that comes up to mind immediately, I think during the 
>> development of such Maya launch wrapper lot's of underwater stones will 
>> come up eventually.
>>
>> Additionally, if in your scene you will have references, during reference 
>> load you will need to decrypt this data,
>> the same will go to any geometry\textures or any files - you will need to 
>> decrypt on the run.
>> All of it must be done recursively on the whole data tree in scene,
>> so at some point how to handle your RAM memory, because you can't store 
>> this encrypted data somewhere.
>>
>> And even this will not save you from attempt to try take this decrypted 
>> data from RAM...
>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>>
>>> I agree with you. This would not solve all problems with working 
>>> remotely, but it would solve some. Perhaps the biggest problems, namely 
>>> accidental sharing and theft. I have also personally received material from 
>>> artists at studios that really shouldn't have managed to leave the studio. 
>>> Some even have limited internet access with local browsers accessible only 
>>> through a virtual machine or local VNC connection, and assets *still* 
>>> manage to leave the premises.
>>>
>>> That not only puts the studio at risk, but the recipient too. Both as a 
>>> private person, as now your machine can leak confidential material, and as 
>>> another business. If a leak should happen that leads 

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

The part of Maya that does the serialisation to ma and mb - be it via
export or save - is a singular point of access. The scene callbacks should
account for all ways in which creating those is possible, including via
Python and MEL. It wouldn’t account for manual export to other formats, but
there’s no end to that. Screenshotting your viewport is a format too,
albeit a lossy one. But I’d argue that depending on what you want to
protect, if that is rigs and animation, the Maya scene format should be
enough.

   - OpenMaya.MSceneMessage.addCheckCallback()
   


And all of it must be done recursively on the whole data tree in scene

I’d argue not. The information you protect is the information in the scene
file. If that scene file consists of an absolute path to e.g.
c:\myassets\myrig.mb then that is *already* protected; nobody can access
that file but you on your local machine.

so at some point how to handle your RAM memory, because you can’t store
this encrypted data somewhere…)

I’d argue not (again :)). Is it to protect against hacker-animators and
hacker-riggers? Or against the general workforce that has no clue about
callbacks and encryption? If the latter, then saving it into a temp
directory first, and encrypting it after should suffice. To the user, the
file would end up where they said it should. But really, it’s a different
file altogether. Then that file is copied back into a temp directory and
decrypted whenever they open it. All of that can happen on disk.

And besides, memory is just another location. A motivated-enough
hacker-animator could access RAM as easily as any location on disk. Doesn’t
increase the level of protection.

On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:

> It is a very interesting discussion.
>
> Yeah, I will agree that it definitely must be invisible - so artists don't
> even know that encryption happened.
> But you can't stop on scene saving and loading, you should create lots of
> workarounds in this "secure Maya client".
> Somehow you need to lock any exporting of data inside in any format,
> hide\lock\encrypt code of all used inside scripts, lock any new plugin
> loading\or current plugins disabling.
> And lock script editor, or make some sort of interceptor, to ensure, that
> no script will run to export or explore private scene data.
> Also, if I understand all correctly, it will give a lot of restrictions
> for people who work with their tools(it will lock them on the layout of
> instruments you gave to them).
>
> And this only stuff that comes up to mind immediately, I think during the
> development of such Maya launch wrapper lot's of underwater stones will
> come up eventually.
>
> Additionally, if in your scene you will have references, during reference
> load you will need to decrypt this data,
> the same will go to any geometry\textures or any files - you will need to
> decrypt on the run.
> All of it must be done recursively on the whole data tree in scene,
> so at some point how to handle your RAM memory, because you can't store
> this encrypted data somewhere.
>
> And even this will not save you from attempt to try take this decrypted
> data from RAM...
> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson:
>
>> I agree with you. This would not solve all problems with working
>> remotely, but it would solve some. Perhaps the biggest problems, namely
>> accidental sharing and theft. I have also personally received material from
>> artists at studios that really shouldn't have managed to leave the studio.
>> Some even have limited internet access with local browsers accessible only
>> through a virtual machine or local VNC connection, and assets *still*
>> manage to leave the premises.
>>
>> That not only puts the studio at risk, but the recipient too. Both as a
>> private person, as now your machine can leak confidential material, and as
>> another business. If a leak should happen that leads to loss of cash for
>> any larger entity such as WB there will be investigations and consequences.
>> Private persons can get in trouble and businesses can crumble.
>>
>> The part I'm sceptical about is whether this particular tool is what
>> solves this problem. If it complicates saving and loading of scenes (and
>> even launching of Maya?) then I'd imagine people simply would not use it.
>> But the idea sounds worth exploring, so off the top of my head I would try
>> implementing a scene save/open callback to perform the encryption live and
>> natively, rather than rely on an external tool. It could be as simple as
>> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing
>> the whole thing on save, and then do the opposite on load. No one would
>> know it happened, and it would unlikely have any noticeable effect on
>> save/load time, and there are equal callbacks for exporting.
>>
>> On 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

It is a very interesting discussion.  

Yeah, I will agree that it definitely must be invisible - so artists don't 
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of 
workarounds in this "secure Maya client".
Somehow you need to lock any exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.

Additionally, if in your scene you will have references, during reference 
load you will need to decrypt this data,
the same will go to any geometry\textures or any files - you will need to 
decrypt on the run.
All of it must be done recursively on the whole data tree in scene,
so at some point how to handle your RAM memory, because you can't store 
this encrypted data somewhere.

And even this will not save you from attempt to try take this decrypted 
data from RAM...
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> I agree with you. This would not solve all problems with working remotely, 
> but it would solve some. Perhaps the biggest problems, namely accidental 
> sharing and theft. I have also personally received material from artists at 
> studios that really shouldn't have managed to leave the studio. Some even 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> I think they must have thought about the export aswell. Otherwise it 
>> wouldn't make any sense.
>> Of course ideally you would each person would work in their office 
>> stations remotly, but it is not up to me. So if I choose not work with a 
>> client unless he guaranties remote workstation solutions, I will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
>>> wrote:
>>>
 That is true, that does sound like a good idea. Assuming the software 
 actually does what it says on the tin, it would at least protect against 
 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

And additionally, if in your scene you will have references, 
during reference load you will need to decrypt this data,
the same will go to any geometry\textures or any files - you will need to 
decrypt on the run.
And all of it must be done recursively on the whole data tree in scene,
so at some point how to handle your RAM memory, because you can't store 
this encrypted data somewhere...)

понедельник, 6 сентября 2021 г. в 12:14:38 UTC+3, Andrew Golubev: 

> It is a very interesting discussion.  
>
> Yeah, I will agree that it definitely must be invisible - so artists don't 
> even know that encryption happened.
> But you can't stop on scene saving and loading, you should create lots of 
> workarounds in this "secure Maya client".
> Somehow you need to lock any exporting of data inside in any format, 
> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
> loading\or current plugins disabling. 
> And lock script editor, or make some sort of interceptor, to ensure, that 
> no script will run to export or explore private scene data. 
> Also, if I understand all correctly, it will give a lot of restrictions 
> for people who work with their tools(it will lock them on the layout of 
> instruments you gave to them).
>
> And this only stuff that comes up to mind immediately, I think during the 
> development of such Maya launch wrapper lot's of underwater stones will 
> come up eventually.
> But I must admit that it is a very cool task to work on!:D
> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>
>> I agree with you. This would not solve all problems with working 
>> remotely, but it would solve some. Perhaps the biggest problems, namely 
>> accidental sharing and theft. I have also personally received material from 
>> artists at studios that really shouldn't have managed to leave the studio. 
>> Some even have limited internet access with local browsers accessible only 
>> through a virtual machine or local VNC connection, and assets *still* 
>> manage to leave the premises.
>>
>> That not only puts the studio at risk, but the recipient too. Both as a 
>> private person, as now your machine can leak confidential material, and as 
>> another business. If a leak should happen that leads to loss of cash for 
>> any larger entity such as WB there will be investigations and consequences. 
>> Private persons can get in trouble and businesses can crumble.
>>
>> The part I'm sceptical about is whether this particular tool is what 
>> solves this problem. If it complicates saving and loading of scenes (and 
>> even launching of Maya?) then I'd imagine people simply would not use it. 
>> But the idea sounds worth exploring, so off the top of my head I would try 
>> implementing a scene save/open callback to perform the encryption live and 
>> natively, rather than rely on an external tool. It could be as simple as 
>> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
>> the whole thing on save, and then do the opposite on load. No one would 
>> know it happened, and it would unlikely have any noticeable effect on 
>> save/load time, and there are equal callbacks for exporting.
>>
>> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>>
>>> I think they must have thought about the export aswell. Otherwise it 
>>> wouldn't make any sense.
>>> Of course ideally you would each person would work in their office 
>>> stations remotly, but it is not up to me. So if I choose not work with a 
>>> client unless he guaranties remote workstation solutions, I will loose a 
>>> lot of work.
>>> Also  many studios have not the resources , and even if they do, the lag 
>>> is some times to high to work remotly.
>>>
>>> Many times sharing is accidental due to the lack of control, or planning 
>>> in a production. In my experience I was doing a freelance work a couple of 
>>> month a go. And we where all working remotly in our personal computers.
>>> The supervisor at somepoint, sent me a rig from another project as a 
>>> reference. So obviously that was accidental because working in this 
>>> situations like that, you do always thing that you are doing anywrong.
>>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>>> of course, there is always people with bad intentions, so we can't be naive 
>>> thinking that everyone will be professional. I work with a guy who managed
>>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>>> told me he took them out of the office in his last day.
>>>
>>> My point being, that with a system like V Crypt, wheter it is by 
>>> accident or not, it might be the solution to encrypt files and safely work 
>>> as freelance (specially for me since now I am full time freelancer)
>>>
>>> I'll keep you posted
>>>
>>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>>> justin...@gmail.com escribió:
>>>
 On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
 wrote:

> That is 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

It is a very interesting discussion.  

Yeah, I will agree that it definitely must be invisible - so artists don't 
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of 
workarounds in this "secure Maya client".
Somehow you need to lock any exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.
But I must admit that it is a very cool task to work on!:D
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> I agree with you. This would not solve all problems with working remotely, 
> but it would solve some. Perhaps the biggest problems, namely accidental 
> sharing and theft. I have also personally received material from artists at 
> studios that really shouldn't have managed to leave the studio. Some even 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> I think they must have thought about the export aswell. Otherwise it 
>> wouldn't make any sense.
>> Of course ideally you would each person would work in their office 
>> stations remotly, but it is not up to me. So if I choose not work with a 
>> client unless he guaranties remote workstation solutions, I will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
>>> wrote:
>>>
 That is true, that does sound like a good idea. Assuming the software 
 actually does what it says on the tin, it would at least protect against 
 theft and accidental sharing.

 It wouldn’t protect against sending files though, because if someone 
 wanted to send some model or some rig, they could still just export it to 
 a 
 new .ma? For that, you’d probably be better off intermingling it with 
 custom nodes. Like how anything rigged with mGear is riddled with mGear 
 nodes, making anyone attempting to open that rig without