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 <rudih...@gmail.com> 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 <konstr...@gmail.com> >>>> 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 mGear loaded >>>>> left >>>>> with a sorely broken rig. And no amount of exporting or tampering with >>>>> the >>>>> scene file could fix it. >>>>> >>>> From the video it looks like you have to launch Maya from their >>>> launcher, which I assume installs a particular reader/writer plugin. I >>>> wonder if it's specific to ma/mb file types or if it hooks into every >>>> type. >>>> Because I was thinking that same thing you said about exporting to other >>>> formats, and would that go through the same hook? Also once Maya is >>>> launched, could someone turn off the plugin after the scene is loaded? >>>> >>>> When it comes to protecting stuff like code, usually you hear the best >>>> security is to just never let the source get onto the client side. But >>>> with >>>> DCC scene files if you have to work with them locally then it feels like >>>> there is going to be some way to defeat it. Once its unencrypted in the >>>> DCC, there must be a weakness that might just be more obscure to many >>>> people and the security is really just focused on the obvious act of >>>> copying files around. Probably the better approach is just not letting >>>> people work on their person workstations and only support a remote >>>> workstation solution like teradici. >>>> >>>> >>>>> >>>>> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad <rudih...@gmail.com> wrote: >>>>> >>>>>> Yes I am refereing to the actual file, not source code. >>>>>> Here's a usecase: >>>>>> due to covid a lot of production are done remotly. In somecase you >>>>>> can connect by logging remotly to office computers to work, in which >>>>>> case >>>>>> no protection is needed since it pretty much as if you where in the >>>>>> office. >>>>>> But in many cases, the files are sent to personal computers. Let's >>>>>> say you rig characters that are sent to 10 different animators to >>>>>> their >>>>>> personal computers. Despite the NDAs, its impossible to police everyone, >>>>>> specially if you don't know the client but you don't want to miss the >>>>>> opportunity to get a job. There is no guaranty that someone will not >>>>>> leak >>>>>> the file outside the production. >>>>>> So here is where you use in V Crypt system. It is not like you are >>>>>> recieving a file from an untrusted source because you are part of a >>>>>> production and you know that your .mb and .ma files are from the rigger >>>>>> not >>>>>> form a the prince >>>>>> of niggeria that is asking you for money XD. >>>>>> >>>>>> That's seem a pretty secure way of working don't you think? you know >>>>>> you recieve a file that is encrypted because you know you are in >>>>>> production >>>>>> context. You can open it and work with it. It simply won't work outside >>>>>> you >>>>>> computer. >>>>>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus >>>>>> Ottosson escribió: >>>>>> >>>>>>> To protect the contents of a Maya file? Typically protection would >>>>>>> involve software, like Python source, but you mean to protect like a >>>>>>> model >>>>>>> or some animation? At that point, why wouldn’t you just hold onto the >>>>>>> file, >>>>>>> and not send it or make it publicly available? Maybe you have a >>>>>>> particualr >>>>>>> usecase in mind, because I can’t quite see it. >>>>>>> >>>>>>> Also I would be most weary opening an .mb from an untrusted source. >>>>>>> That’s what .ma is for, so you can inspect it for any >>>>>>> script-related things. I’ve been bitten before and, as they saying >>>>>>> goes, >>>>>>> fool me once. >>>>>>> >>>>>>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad <rudih...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> a while a go I create a thread about protecting your work. >>>>>>>> Along the same lines I saw this >>>>>>>> >>>>>>>> V Crypt maya files <https://www.youtube.com/watch?v=kZc2-FcLuiI> >>>>>>>> >>>>>>>> So in theory, you can generate a license for the computer mac >>>>>>>> address, and inside your >>>>>>>> .ma and .mb so some kind of assertion make sure sure that the file >>>>>>>> is being open in the right computer. And since both files are crypted, >>>>>>>> you >>>>>>>> can remove that block of the code. >>>>>>>> Also, if you try to saveAs, it is saved with th crypted format. >>>>>>>> >>>>>>>> It seems like a good solution right? what do you think? >>>>>>>> >>>>>>>> R >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Python Programming for Autodesk Maya" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to python_inside_m...@googlegroups.com. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Python Programming for Autodesk Maya" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to python_inside_m...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Python Programming for Autodesk Maya" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to python_inside_m...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCpAua2TmorENN9OOzG%3Deg5T-cxotu%3DW8OBTA%2B-RacWjQ%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCpAua2TmorENN9OOzG%3Deg5T-cxotu%3DW8OBTA%2B-RacWjQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to python_inside_m...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/5eca697d-3760-42ec-af82-9663b5f963edn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/python_inside_maya/5eca697d-3760-42ec-af82-9663b5f963edn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/884bfeed-1024-4c09-9682-62c252cc34abn%40googlegroups.com.
